How the best software QA testers can truly own their projects

It’s common for software QA testers to focus only on the well-defined testing responsibilities in our daily work. Testing, after all, is what we are hired to do. But to be really exceptional at our jobs takes more. We need to go beyond just writing test cases and scenarios for the products we’re testing — especially on agile teams.

On our app development teams here at ArcTouch, we’re constantly emphasizing the concept of “ownership.” Ownership means that every member of our cross-functional agile team takes ultimate responsibility for the final software product that we deliver — from the design and development to meeting the business objectives. And everyone has an opportunity, and an obligation, to participate in the whole product development process — not just for their specific piece.

QA Testers – 11 ways to own your projects

So, what exactly can QA testers and QA analysts on an agile team do to truly “own” the project and more effectively drive it to a successful conclusion? And how can software testers help the entire app development team’s journey, from start to finish?

Here are 11 ways the best QA professionals can take ownership of a project, beyond their typical responsibilities.

1. Track the business goals throughout the project

QA testers should help remind the team of the ultimate goal of the project. We need to build products that not only deliver a great user experience, but also deliver on the business objectives defined at the beginning of the project. Quality Assurance is more than just moving tickets to the “Done” column in the agile planning board. QA professionals need to think about how a quality product provides business value to our clients, and delights the product’s users.

2. Participate in design and product reviews

Great QA testers and analysts on agile teams are not just involved in the engineering phase of a project. Get involved early in design to understand the users and their expected experience from the very beginning. Raise questions about design, especially as the project evolves and the user experience is brought to life. The sooner we identify potential issues, the better — don’t wait until the end of a project, when UX/UI bugs are more expensive to fix.

Relevant questions to raise during early design reviews include:

• What problem does this feature solve?

• How does this feature/design handle typical cases of user interaction?

• Does this behavior embody the best UX/UI practices for the platform?

• Is this feature ultimately going to deliver value to the client and to the user?

3. Contribute your expertise in sprint planning

During sprint planning, the development team documents the technical details for how they plan to implement new features. That includes libraries and tools that will be used, components that can be reused, and any blockers developers may face. Typically, the person responsible for this documentation is someone in the development team, but QA testers are important contributors.

That’s especially true if you, the QA professional, have previous experience working on a related feature or technology. Your prior knowledge might just save your colleagues some trial and error. For example, if you already know how the backend works and how it can impact a new feature, share what you previously learned that could cause setbacks.

4. Don’t passively wait for tickets to be assigned to testers

It’s human nature when you’re part of a team to sometimes wait for someone to assign you a task. It happens all the time in development when team members are passively involved, just waiting for a project manager to issue a ticket with their name on it.

QA professionals should have a different mindset. Before any tickets are created or moved to the testing phase, you should proactively help to define tickets. After all, you know best how your job and talents can ensure a product’s quality. And when you are assigned tickets, evaluate the story description and the design specifications and ask yourself: Does this ticket makes sense? Is something missing or incorrectly specified?

When writing test scenarios, check if they are covering all that is needed to achieve the expected final result. And when executing the tests, don’t focus only on executing what is written inside a ticket and moving that ticket forward — or only taking what is written in test scenarios and defining it as pass/fail.

Also, think proactively beyond the ticket. When you only worry about fulfilling the work you are assigned, you lose the opportunity to provide your insights and collaborate more with other team members to ensure product success.

Be a problem solver, not a ticket solver.

5. Test what matters the most first

When testing, focus on what matters the most. Is the software doing what it should be doing? Is the app screen’s user flow correct? Are all the needed components included? Will the user be able to execute all actions, from the beginning to the end, and have success and without setbacks?

Focus on edge cases only after testing the highest priorities. One of the ways we do this for mobile app testing is to use a device test matrix to ensure the broadest coverage. But beyond just efficiently testing devices, we scrutinize how we test features to cover the most important use cases. That doesn’t mean we should ignore edge cases — but we should focus and give more importance to performance in normal conditions first. One good way to validate user experience and prioritize test plans is to get user feedback via user testing, even before development begins. To learn more about how we do this, check out our free ebook, “A practical guide to app user testing.”

6. Don’t view bugs as an excuse to point fingers

As QA testers, it’s easy to encounter a bug and then immediately task (and blame) the culpable developer whose code was responsible. But a bug is not only a dev-team problem, it is a whole-team problem. Work to fix it together.

Rather than just reporting the problem, think about how you can provide helpful information to efficiently squash the bug. Do more than just write the bug description and steps to reproduce the problem. We can do more.

For example, if an application is not displaying information correctly, you can investigate whether the information is coming to the application, if the request to get the information is correct, and determine if the root cause of the bug has been experienced by others — helping developers make the fix easier.

You might not always be able to determine the root cause. But it’s worth a try, and your developers will appreciate the extra effort to help them resolve it.

7. Don’t forget the backlog

When you’re working on a ticket, always take a look at the backlog and determine if there are other related tickets. If you can proactively bundle and solve multiple issues at once, you might just save your team time down the road. Also, keep in close contact with your team members so you can solve or fix bugs in parallel with other work and spare project time.

8. Think beyond the typical test scenario

At ArcTouch, we use behavior-driven development (BDD), a practice where the expected behavior of products and features is written in a very clear format — referred to as “user stories” and “scenarios” — so all stakeholders can easily understand them. These become the references for team members to test against throughout development.

Even if your team does not use BDD, write test cases to guide and document what should be tested. When writing scenarios or test cases, besides thinking about all the obvious and non-obvious paths that a user can take, don’t forget to cover the unexpected circumstances that the app should handle (e.g., failing requests, error responses, variable environments, internet connection failures, etc.). If the app gives appropriate feedback to users in all situations, that will help buffer setbacks like poor Internet connections or entry errors. Seek maximum possible coverage with the test scenarios, so all that should be tested will not be forgotten.

Ask other team members to review your test scenarios (developers, project managers, designers, etc.). It’s important to make sure all team members can clearly understand everything — and they might have insights to improve the test scenarios or even add some new ones.

9. (Really) listen to internal and external users’ feedback

It’s one thing to ask for feedback and another to act upon it. As core members of an agile team, QA testers should always be asking for feedback from team members on different features and your own test plans. But it’s also important to ask for feedback from people that are NOT on your team. That could be other people who work for your company in a variety of roles. And, as we mentioned earlier, it should also include user feedback and user testing.

As you gather feedback, make sure to share it with your team and define next steps for how to act on that feedback.

10. Stay current during the course of a project

Development projects can last weeks and even several months — and we all know how quickly technology changes. Make sure you are proactively staying up-to-date on information related to the product — from news about integrations and platforms your software is designed for to the target market your product is serving. The software you’re building will live in an ecosystem of dependencies — and part of your job as a QA tester or analyst is to anticipate how your product will perform based on changes and anticipated changes.

11. Don’t ship it and forget it. QA testers should own it, for life

Our concept of product “ownership” goes far beyond launch; it covers the lifecycle of a product. And for QA testers, that means once an app is launched we should be watching how it performs in the hands of its users, with each update. Review performance data and analytics and proactively make suggestions to your team for how the user experience can be improved. Read the app store reviews and ratings for your products, and suggest ways to improve them.

And in addition to ensuring the quality of the product, we should also analyze the performance of our role within the team and identify ways to strengthen the cohesiveness of the team.

Don’t just wait for your next project and your next ticket. Truly own your QA role and the products you worked on. Your teammates will appreciate it — and you’ll enjoy your job even more.