Apple captured news headlines with the release of Group FaceTime in October of last year. A mere three months later, the tech giant found itself in the headlines again when a teenager found that he could use the feature to eavesdrop on other Apple customers.
If nothing else, the Apple debacle makes us aware of two things:
- Now is a good time to examine your QA team structure, and
- Having your QA failures discovered by a 14-year-old makes for some rotton press.
At least one lawsuit has already been filed in response to the glitch. And even though Apple will live to see another day, a smaller company might not.
Admittedly, building robust, error-free software is a challenge for any company.
However, building quality assurance into your software is not only crucial, it’s doable. Let’s see how.
QA Team Structure Roles And Responsibilities
You want the software products you build to put you or your customer in the headlines for all the right reasons.
Historically, the key to doing so has been understanding the roles that make up a QA department, and how to structure those roles to get the best results.
The list below represents the typical roles included in QA teams, along with a very brief synopsis of their duties.
Not every company that runs QA teams will employ all the roles listed here — most will not. The specific roles a company chooses to use will depend on the scope of its projects, and budgetary constraints.
Junior Tester — The tester is at the bottom rung of the QA ladder, and follows a strict set of instructions to test or validate the software product.
Manual QA Engineer — Also called a Manual Test Engineer, this role is responsible for developing the procedures and hardware/software needed to manually test an application or its constituent components, such as modules or libraries.
Test Automation Engineer — The Test Automation Engineer goes further and develops and maintains the hardware and software systems that run automated tests on software
Test Automation Analyst — The Test Automation Analysts develops, executes, and maintain automated test plans.
Test Engineer/QA Tester — Test Engineers generally design, implement, and support testing strategies and systems.
Test Manager — The QA testing team structure of some companies includes a Test Manager. This role has the overall responsibility to ensure that the test team stays on schedule. They will coordinate with others to see that problems are resolved in an efficient manner.
Technical Lead — Usually an engineer, the Tech Lead applies a hands-on approach to helping the team solve technical issues and may define testing requirements. This role requires strong technical skills with solid management ability in order to move the team toward its objectives.
Team Lead — A step above Tech Lead, with less focus on technical issues and more on people and processes.
Business Analyst (BA) — Basically, the BA ensures that an application meets the business objectives of the company or client, while also satisfying the technical requirements. In some companies, the BA is a liaison between upper management (or the client) and the development / QA teams.
Program Manager — Manages a series of projects, and oversees the big picture, from enlisting teams to measuring ROI.
Project Manager — Manages resources to accomplish one-off initiatives. The Project Manager is more focused on executing individual projects than is the Program Manager.
QA Analyst — Sometimes synonymous with QA Tester, in some companies the QA analyst goes deeper than a tester. In this case, they can go “off script” to evaluate or validate an application, either during or after the development phase.
QA Team Test Lead — Provides leadership specifically to the test team. In some companies, the Lead might only support test teammates and processes. In others, they might be involved in the complexities of test plan development.
QA Team Leader — Synonymous with QA Manager in some companies, in others this person monitors the quality of projects in progress and assists team leaders in correcting problems. Emphasis is often on process control.
QA Manager — Provides leadership in the efforts to develop, deploy, manage, and maintain quality assurance processes. This person supports all other team members and all QA processes.
The specific duties of each role may vary from company to company. In smaller organizations, duties may change from project to project. The point is, there is no single definition of role titles and duties that apply in every case.
Just as role definitions may change from one company to the next, even the definition of QA team can change, as we will see.
How QA Team Works in an Agile Environment
Understanding how QA is handled in an Agile team requires a departure from conventional QA team structures.
In conventional waterfall software development, quality assurance activities can take place anywhere along the development-deployment lifecycle. However, they are usually concentrated at the testing and release phases.
With Agile, there is no QA “team” in a conventional sense.
Rather, quality assurance is embedded in every process along the way. By making each team member responsible for quality, time-to-market and product quality are much improved.
Therefore, the QA testing team structure is also different from the waterfall approach.
Instead of siloed end-of-process teams of testers and test engineers, testing occurs at every stage of the process. Each member is expected to be capable of testing their own work.
Best Practices of QA in Agile
Agile offers proven benefits over linear waterfall approaches. However, adopting the agile framework does not, in itself, guarantee positive results.
If you want a heightened assurance that your development team will consistently produce quality products on time and under budget, you need to employ best practices for agile QA.
The list of established agile processes is a lengthy one. The following five represent a good starting point for those using agile for the first time.
1. Break Free From Traditional QA Roles
Agile is radically different from conventional project management frameworks. Getting the most from it means making a clean break from the past. Agile is all about creating iterative and incremental releases of a tested and functional product. Let it be so.
Avoid the temptation to push QA to the end of the process. With agile, QA is not an afterthought. It is woven into every step of development.
Enfuse the team with the mindset that testing is not someone else’s job. The QA manager’s role is to ensure that quality processes are in place, not to make sure everyone else does their jobs right.
Once each team member learns they own the quality of the work they produce, you will begin to see the benefits of agile.
2. Test Early and Often
Testing must be planned to occur frequently throughout the development process.
There is no catch-all QA waiting at the end of the line. Each iteration requires its own testing so that problems can be identified and corrected before beginning the next sprint. This ensures the quality of the product throughout the development lifecycle.
It might appear that frequent testing will slow the development process. And, to a degree, it does. But by planning when testing will occur, its impact on the delivery schedule can be calculated.
When testing is done only at the end of the process, numerous problems may be found. The result is often major rework, with unplanned delays in delivery.
3. Automate Testing
If testing is to be an efficient part of the development process, it must be automated whenever and wherever possible.
The entire software product may not need automated testing, at least not at the beginning phases of development. The team should decide at the start of the project which parts of the software will be tested using automation.
Further, the team must decide at the outset how test failures will be handled. How test failures will be prioritized and assigned should be known before they occur. This way, entire sections of the process do not come to a grinding halt everytime there is a test failure.
4. Avoid Ambiguous User Stories
Part of the beauty of agile is that it allows for flexibility, even in customer demands. But flexibility must not be confused with ambiguity, especially when it comes to user stories.
Ambiguity in a user story reflects a lack of understanding of what the user experience should be. And if you don’t understand the UX, how can you expect to get it right?
Even though requirements are not generally included in user stories, that does not mean they should not be detailed. The more accurately user stories describe the desired UX, the easier it will be to achieve it.
5. Keep Backlogs Lean
The product backlog will change as new features are added or taken away. The sprint backlog represents tasks that the team feels need to be completed during the sprint.
Backlogs are intended to help developers move along from sprint to sprint at an orderly pace. But when they become overloaded, they can have a detrimental effect on the entire team.
Managing backlogs is crucial to making agile work. Key to keeping backlogs from becoming bloated is planning and ownership. The backlogs must have clear ownership, and the team must plan how the backlogs will be managed.
Will there be a limit to the number of items that may be placed in them? What happens if the sprint backlog still has to many items to be completed by the end of the sprint? These are the kinds of questions you must answer.
Agile backlog management is a complex subject, and there is no one right way to do it well. However, if you start with ownership and planning, you will have your first to steps completed on the journey.
How to Build a Successful QA Team with Ignite
The benefits offered by Agile are too great to pass up. That is if you want to be competitive in today’s fierce software marketplace.
The solution for many is to partner with a development company that offers Agile teams for hire. Ignite is such a company.
We offer world-class Agile teams for the development of your product. And with us, quality is built-in every step of the way.
Why not contact us today for a no-cost consultation?
Your Agile team is waiting.