How understanding stakeholders optimises your testing strategy and the software you end up with.
In my experience working as a Senior QA consultant at Triad, I have seen many organisations consider Quality Assurance (QA) only as an additional cost in the project and ignore the intrinsic value that it brings to software quality.
The main reason seems to be that the project managers and key stakeholders are not be aware of the benefits of QA and the value it adds to the development team.
In this article, I will explain why it is important to know who your stakeholders are and how to optimise your testing strategy to include the interests of these stakeholders.
Because better engagement leads to a better testing strategy that results in better software.
Quality Assurance in Agile projects
In Agile Software development, it is important to create a test strategy that is results-oriented and fits well with the team and organisation as a whole. In Agile, Quality Assurance is about integrating testing into every stage of the software development life cycle, hence the testing strategy should focus on achieving this.
As with other aspects of software development, to create an effective test strategy you need to know who your stakeholders are. You need to understand their requirements, interests, concerns and goals at the outset, and be prepared to accommodate change. In turn, this will make buy-in from the wider team easier to secure, and they will be interested in the testing outcomes.
Who are the tester’s stakeholders?
Most commonly they are those people who have an interest in the outcome of tests and the information that QAs provide: developers, designers, product owners, project managers, users and sponsors.
Developers are the people who build the product. These stakeholders need to know where their product fails so they can fix defects [close to their source]. For them, it is important to identify issues early in the development process, because the cost of remediation increases over time, and the later defects are found the less flexibility a project has to respond to them.
- The test strategy should contain good development practices like feature branching, pull requests, peer reviews and quality measures such as unit test coverage, integration test coverage, automated smoke/regression tests, performance tests, security tests and code quality checks. These measures provide a safety net giving developers greater confidence to make changes in the application.
Designers are responsible for designing the User Interface (UI) and User experience (UX) of a product. These stakeholders also need to know where their design fails so they can fix the issues. It is important to identify any design issues as early as possible, typically before the development starts.
- The test strategy should include testing techniques such as design reviews, usability testing, accessibility testing, etc. to address the interests of these stakeholders.
Product owners and Business Analysts (BAs)
Product owners and BAs may work together to develop user stories and discuss priorities. They are interested in understanding whether a feature meets their needs and expectations. The QA team should work collaboratively with the POs and BAs to understand the requirements (user stories) and effectively communicate them to the wider team.
- A well-defined user story should include background, acceptance criteria and non-functional requirements for that feature. The test strategy should contain activities to review that the user stories are testable and to create acceptance tests to verify that the implemented feature meets the acceptance criteria.
These stakeholders need to know the status of deliverables (i.e. application features): are they available, acceptable, and reasonably free of defects? If there is a problem, the manager may need to re-plan or at least manage expectations.
- It is useful to include the test deliverables (i.e. test scenarios, test cases, requirement traceability matrix (RTM)), schedules and quality measures in your QA strategy to prove the quality of the application being developed.
These stakeholders need evidence that the system can support their business goals and that the risk of failure is acceptable. It is important to understand the business goals and product risks and include them in the test strategy.
- Demonstrate an understanding of the business goals and risks in your testing strategy, it will also help you in defining the right test approach.
These stakeholders need evidence that the system will work for them. As a QA, you should always think as an end-user.
- Your test strategy should address real-time use case scenarios such as testing in different browsers, operating systems, devices, usability testing and accessibility testing.
As QAs we need to embrace that we are accountable to stakeholders; you need to engage, consult, and communicate with a range of stakeholders and reflect their needs into your testing strategy. Testing approaches should focus towards meeting their needs at all times.
However, even once the testing strategy is agreed and being put into practice, for QA’s, it is important to communicate effectively with those stakeholders. Sometimes, this will take the form of documentation, shared wikis, Kanban or Scrum boards. If your test strategy addresses the concerns of the stakeholders, then they will feel involved and will support the QA team during critical times.
The best test strategies are the result of exploration, thinking and collaboration.