Photo by David Travis on Unsplash

Agile manifesto and its correlation with testing

Agile testers are involved in the requirements, design, and development of the project and have constant interaction with the entire team ( including developers, fellow testers, business analysts, scrum master, and product owners).

They are co-owners of the user stories, and their input helps build quality into the product instead of checking for quality in the end. They need to collaborate with the programmer team to share the scenarios and try to identify the defects at the unit level itself. This practice will contribute towards preventing the bugs rather than finding the bug and then fix it.

All processes and tools are only used to help make life easier for the agile team, rather than to complicate or over formalize the process

For example, while working in the scrum team:
* We had regular discussions apart from daily scrum
* Used jira for reporting bug
* Test rail for writing test scenarios and test cases
* The reported bug was linked to test scenario or test cases

The test design and specification process needs to be quick and effective while leaving the maximum time for test execution, exploration, and defect finding.
Instead of comprehensive documentation, one should look at the ways to keep the document lean and ‘just enough’ . This balance can be achieved by using one-liner scenarios, exploratory testing, risk-based testing, or error checklists.

For example, while working in the scrum team, I:
* Wrote test scenarios and test cases on the basis of user stories
* Linked test scenarios were to the user story
* Wrote user acceptance test cases on the basis of Definition of Done and Acceptance Criteria of the story

Agile testers must prioritize and re-prioritize their tests. They need to focus on what will help the team reach its goal, minimize risk and keep customers happy. For this purpose, the plan has to be dynamic in nature and molded as per the requirements. The focus should be on meeting the Definition of Done and the Acceptance criteria.

For example, while working in the scrum team:
* Test strategy was created on the high level in collaboration with all the stakeholders and keeping in mind company’s and project’s interest
* I created test plan at epic level instead for every story
* Priority was given at unit and API level test cases rather than UI level.
* I created a robust automation framework uisng behaviour-driven development (BDD) practice which translated requirement user stories into automated scripts.

Direct communication with the customer plays a vital role in a deeper understanding of the feature and more precise test coverage. We should not restrict ourselves to seek clarification from only the product owner to understand the functionality and business.

Agile testers are constantly looking out for the customer’s best interests and needs. Agile tester questions everything based on their perceptions of the user’s actual requirements, convenience, and satisfaction with their “user glasses” on.

For example, while working in the scrum team, I:
* Shared the test cases, data and results with the customers and ask about if they are happy with the results or they want any specific scenario to be tested
* Communicated the testing approach
* Questioned the functionality according to the user experience

For any kind of suggestions, feedback or queries, please feel free to contact me on my email address