Agile is a philosophy focused on continually providing value to customers step by step and often, based on communication and feedback. These are two important components of a successful Agile formula and Tester plays an important role in creating values in Agile projects during the iteration stages.
Agile is no longer a noisy word or a silent area no one knows in the software industry anymore. Agile has made great strides in the past few years and has matured into a widely accepted method. Testing in the Agile project requires a paradigm shift for traditional testing roles. It requires a change in the attitude of the tester (tester) from a case-oriented approach to a role that is deeply involved in the development process from early on. The Agile approach focuses on getting the right things right from the start, reducing the need for more quality assurance testers (QA Tester) at the end of the process to achieve results. But it's easier said than done. How can that be in practice? Does it really happen or not?
I have outlined quality assurance activities like the three phases in the Agile project. However, there is no golden rule and it can be flexibly customized according to each project. The role of QA testers in Agile is not limited to a predefined set of processes, as well as the methodology that will indicate roles based on a specific situation.
Pre-iteration: This is a request that is analyzed in detail by BA (Business Analyst) and the acceptance criteria written for each one. story (user story). Since QA are users of these requests in the first place, they need to verify them early and often.
Story Verification: Agile testing is about giving early feedback, not only by testing the requirements, but also by doing it early. QA testers need to review requirements / stories early to clarify the meaning and testability. This will ensure the requirements are always clear and testable (I believe it is clear that in Agile there is not much difference in context compared to a typical waterfall project).
The requirement should be small enough to make sense in the context of accepting the acceptance criteria – stories often used for acceptance criteria should not be duplicated, overlapping from different stories. , this can be very difficult and can only be achieved with close communication between the Development Team / Business Analyst / Quality Assurance parties.
Testability: Testable aspects of a story must be considered in detail to be able to test that story. These factors are usually:
Finding hidden requirements Environment test data Reliance on other requirements Getting these details early will help the story take precedence more correctly in the backlog, and allow real-world implementation. Show that story more smoothly in the iteration.
The QA tester also participates in a planning meeting for the segment to provide a testing perspective so the team can make development estimates. Participation in segment planning plays an important role, when some of the underlying requirements are often revealed by the QA Tester.
The operation of QA in the loop
Once the QA tester is comfortable with the acceptance criteria for a story, they can help the team define the acceptance tests for that story. Acceptance tests are requirements in terms of testing that need to be performed to understand what is expected of the software requirements. These acceptance tests are automatically generated and used to drive the development process. Acceptance tests should not cover all scenarios, as this can create unnecessary bottlenecks and may create too many automated automated test suites. No need together.
People often do not understand that acceptance testing in Agile projects is different than traditional projects. Unlike traditional projects, where acceptance testing occurs at the end of the software life cycle, in Agile acceptance testing projects are carried out before the software is delivered. Acceptance tests also tend to be automated so they can run as regression tests.
Automated testing is very important for any Agile project. Builds often require short response cycles, so regression testing must be quick and accurate. It should be noted that automated testing in Agile is very different from traditional automated testing. In Agile projects, automated testing is performed by all levels – programmers, quality assurance testers (QA testers) and business analysts (BA). Everyone's participation increases the relevance of the tests and often helps to identify the tests correctly. However, this does not mean that everyone must write test code.
One thing that has always been controversial is "who is in charge of automated testing in the Agile project". For me, it is more a responsibility than a role. In my experience, automated testing is most effective when developers and QA testers work together.
Use automation with purpose
Automation in Agile is a contentious issue. Many people try to automate everything and fall into the trap of having a long feedback cycle. Automation is meant to provide early feedback on what code is generated, and it's important to determine what needs automation and what doesn't.
All automated testing costs us a little. The cost of automation should be compared to the cost of not doing it. The questions are: what happens if a test is not automated? What will it cost and what will it cost to fix things around the code we are losing coverage? The answer may not be as easy as when we went to find the value of a test. It is usually a contextual decision depending on the size of the project and the number of participants. In other words, a longer feedback cycle means more people have to contribute more time to get immediate feedback.
A typical quality assurance activity in segments is the continuous measurement of software quality. The QA tester is involved in handing over the stories to the developers. This helps them understand the testing requirements of the story so they can implement Test-Driven Development (TDD). In addition, handing acceptance tests and helping developers understand the testability of the story to avoid common defect. These activities require a high level of communication between programmers and business analysts to clarify requirements and ensure products are properly built from the outset.
The QA tester can help solve problems first of all by actively participating in the overall process. They can even pair with developers working on a story or story tests to better understand the requirements. It is imperative that a story is delivered, it must be properly tested, in an appropriate environment. Once the QA Tester is satisfied with the required stories, they initialize the work, and then put it into the next testing process.
It is also important to think beyond the written requirements and experiment with exploratory testing to execute the 'marginal' scenario and perform negative tests to ensure Make sure the software is written down as quality. Test exploration is not about executing all predefined test scenarios, it is the art of software exploration in addition to test cases and at the same time keeping focus around the requirements. Specifically.
I have tried to cover most aspects of the basic operations of a QA Tester in an Agile project. However, the role is not limited by these activities and the QA Tester should be more active in demonstrating a collaborative role when possible.
The article was translated according to "A Tester's Perspective on Agile project", Pankaj Nakhat
http://www.logigear.com/magazine/agile/a-tester's-perspective-on-agile-projects/