In our earlier post, we made discussion on “Introduction and purpose of writing test cases”. Now we shall discuss about major stakeholders in testing and misconceptions about testers as stakeholders.
Overview: Stakeholders in testing
Software Testers spend a meaningful part of their work lives, doing testing! How frequently do testers stop to think about the question – whom are we testing for? The answer that managers would usually say is – stakeholders. That brings up the next set of questions – who is a stakeholder and who are the stakeholders for testing? A stakeholder is someone who has a stake or interest in the work that we do. The testing stakeholder also has an interest in the quality of the final work product. Stakeholders in testing may be broadly classified as internal and external stakeholders.
Some organizations see all stakeholders within the organization as “internal” while any stakeholders outside of the organization are considered as “external”. In some other groups, anyone who is involved with the test effort – in terms of performing testing, leading or managing the test efforts are considered as “internal stakeholders” while all other stakeholders are considered to be “external”. The list of who constitutes a stakeholder can vary across projects and organizations. Given below is a brief list of stakeholders for testing.
- Other testers in the group
- Test Managers and Test Leads, involved in managing and leading test efforts
- Architects and Designers, responsible for designing the product
- Implementers – the developers, development managers and leads involved with developing the product
- Product marketing persons, involved in determining the features for the product and are interested in the quality of implementation of these features
- Analysts, involved in determining the requirements for the product and the related quality attributes
- Program/Project Management folks, responsible for project planning, organizing and managing resources for successful completion of project objectives
- Customer Support individuals, responsible for supporting customers and users of the product produced
- Sales folks, responsible for selling the software
- Executives / Senior Management of the organization, who run the organization
- Shareholders of the organization
- Users of the software
- Partners of the organization
- Vendors, who may supply components that are integrated with the product
- Customers, who pay for the software
- Community / Society, where the software product is being used
- Governmental authorities, who are interested in the software complying with applicable laws and regulations
The above list is not complete and can vary depending on particular project or organization.
Stakeholders generally tend to want the software testing efforts to succeed and ensure that a quality product be produced. However, some stakeholders can be neither positive nor negative about your testing outcome. Few stakeholders might even be interested in seeing the project fail and could be glad if testing showed up a lot of failures. These could be folks who are interested in maintaining the status quo (the existing state of affairs) and opposed to change that the project might get. It is important for the software testing group to identify who the testing stakeholders are, which of these stakeholders are supportive, who are neutral and who are not supportive.
Introduction
Test case document helps almost every person who directly or indirectly involve in the development of the project. Test case document helps the owner of the system to identify boundaries of system. It provides an over view that how the system is tested. Which scenarios the system passes and which scenarios are unsuccessful.
Similarly test cases help developers to find issues in system. Rework on cases that failed. Test cases help the project managers and system architects to identify the health of the project/product. It may guide them in identifying release time of product, defining new plans and to meet deadlines timely. It favors the system architects to verify the design issues and business process flows well.
Example
Every software product has a target audience. For example, the audience for medical software is completely different from gaming software. Therefore, when an organization develops or otherwise invests in a software product, it can assess whether the software product will be acceptable to its end users, its target audience, its purchasers, and other stakeholders. Software testing is the process of attempting to make this assessment. Therefore, test cases should be written according to the nature of the audience.
Some Misconceptions about “testers” as Stakeholders
1. One big mistake that a project manager makes is that testers are not treated as major stakeholders in the project.
2. Development team has a misconception of treating tester as someone watching and pinpointing loopholes in developer’s area of expertise.
3. The test team is intentionally kept out of loop up to a certain stage of the project.
4. The knowledge transfer from development team to test team starts at a later stage and immediately they are told to start testing without providing them sufficient time either to absorb what they have understood about the customer business or to prepare test cases for complete coverage.
5. The bugs reported are not taken as seriously as they are reported – usually the bug closure priorities are set more on the basis of time required to fix a bug or the time left to release rather than the severity of the bug. Most of the project meetings are conducted without test team involved in it – and worst thing is that a lot about quality is discussed in such meetings.
In our forthcoming/future post, i.e. in the third part of “test case writing” we’ll cover concepts like how to design effective test cases, their benefits and the essential design elements of the test case.
