QA role experience sharing in scrum

Scrum is an agile approach to software development. It emits a valuable business function with a 2-4-week iteration. The scrum team has two distinct features: they are versatile (e.g. they have all the skills they need to do their job); they are self managed (e.g., the team is constantly exploring the best way to do the work). With the continuous practice of the QA role of the scrum team over the past two years, I have learned that QA in scrum is not simply about writing test cases and reporting defects.

In contrast to the synchronized activities in the project of the traditional waterfall model, scrum expects the development activity to execute in the order that it is actually needed, such as asynchrony. This is contrary to tradition and makes many novice customers, developers, and business Contacts Wonder "How to test effectively before the code is finished?" "This article focuses on how QA performs agile testing and the importance of QA roles in scrum teams." I will share in this article my knowledge of the QA roles and responsibilities in the Scrum team.

Not only is writing test cases

In traditional waterfall model projects, the timing of QA intervention is often the end of the project after the code is complete. In these projects, QA gets a requirement document and completed code, and then starts writing and executing test cases to check if the application meets the requirements documentation. However, the QA role in scrum is no longer just the execution of test cases and reporting defects.

In a scrum team, the QA analyst participates or performs a large number of responsibilities with other team members. They are involved from the start of the project and are in close contact with business analysts and developers. In scrum, QA is not a separate team of test applications. Instead, the scrum team is an integrated team of business analysts, developers, and QA working together. In addition to writing use cases, QA also helps the product owner (PO) to write accepted use cases, which is equivalent to assuming the role of product owner agent. QA as an agent keeps the team moving forward when the product owner has no time. QA and product owners interact with each other by asking questions and questioning assumptions to eventually clarify business requirements.

Participate in evaluating User Stories (Story)

QA analysts are generally good at creating test case scenarios based on user requirements. It is also remarkable in identifying and capturing complex and negative use cases. In fact, at this point, QA tends to do better than development because developing good aspects that tend to focus on user stories. To invite QA to participate in the evaluation of user stories in version and cycle planning meetings is to allow the team to stop thinking only about the good, and to produce an objective and realistic assessment of the overall quality of the situation. Assessment is a very difficult thing to do and it is good practice for everyone to participate in the assessment.

Helps to maintain a clear perspective and goal

When the team performs tests and other stable product activities, QA needs to be in charge of planning, organizing, or putting the entire team into the test and keeping members active as Scrum Master (SM). Few developers like to do test tasks. QA needs to work with Scrum master to make the tests visible and clear to the entire Test team. Thus maintaining the enthusiasm of the developer or other members. Sometimes the construction of a test scenario needs to be developed or helped by other team members, so it's easy to innovate. Try to make the test activities interesting, such as stimulating test scenarios, unexpected test data, and competition with entertainment implications. In short, do anything, as long as it helps the team be happy to join the test work.

Work closely with customers and developers

One of the main responsibilities of QA is to feed their test results to the product owner or collect their feedback. QA and product owners work closely together to help them develop detailed user story acceptance criteria. As the team understands each iteration, QA can also help the product owner modify or enhance the user story to better reflect the real requirements.

Occasionally, the QA analyst also acts as the product owner agent. In this case, QA and developers will sit together and work together as a team to improve product quality. QA can write unit tests with developer pairs to discuss acceptance criteria. The more you work together, the more clearly you need. The clarity of work that comes with working together will reduce the number of problems or doubts that are often encountered in the coding process, giving you time to effectively improve development efficiency, save development and QA.

According to each team's needs and actual situation, the whole team will become one, will help test. Such practices balance the shared responsibilities of team and job completion, and the early test feedback and the quality of continuous growth will make the project progress faster.

Provide quick feedback

The repeated "build-test-fix" cycle of the traditional waterfall model team has added a lot of extra work and wasted a lot of time. In scrum, QA and developers work together throughout the project, making the activities simpler. During the development process, developers can directly consult QA acceptance criteria or any functional expectation behavior from the user's perspective. This makes testing and bug fixes simpler.

Automated regression testing

Automated testing is often hailed as the best friend of the tester because it can be repeated and executed consistently to achieve better test coverage of the software's capabilities. This is especially true in a 2-4 week iteration scrum project. Because QA generally does not have much time to test the application. In a 2-week iteration, QA must complete the functional-point testing of all the new features in the iteration, as well as the test of the previously implemented functionality. As such, this responsibility increases the importance of using the available automation practices in each iteration to reduce QA pressure.

Automated testing is useful for fast feedback when the team performs continuous integration. With each release of a new version of the software, you can perform automated tests and quickly provide feedback to reflect whether new and old features are working properly. Without automated testing, you have to perform all the tests manually, not only monotonous, but also easy to make mistakes. Automated testing can detect defects earlier, giving QA more time to explore special use cases for new features. With automated testing, QA can perform testing more quickly and efficiently.

Participate in the release preparation demo

At the end of each iteration, the team needs to convene an iterative review meeting to present the user stories of the iteration to the project responsible person and other interested stakeholders. Iterative review meetings are the "medicine" of the team that can effectively motivate them to do as many user stories as possible.

In the 2-4-week iteration, everyone on the team must be immersed in their work in order for the user story to be completed on time. Developers focus on implementing user stories and fixing bugs, QA focus on use case writing, clarifying questions about product-responsible people, and automating iterative testing. A shorter iteration cycle means that development has little time to learn the full range of features required by a user story. In this way, development will generally ask QA to better understand the user stories. Because QA knows the full functionality and each requirement and acceptance criteria. It's good practice to have QA demonstrate the project and answer the business questions at the iteration review meeting. This also allows developers to focus more on technical aspects of the problem.