Some of the options while deciding the strategy for structuring of Agile Testing teams are as follows
- Testers Embedded into the Development Teams : Independent testers are often more effective at finding defects. In some Agile teams, developers create many of the tests in the form of automated tests. One or more agile testing engineer may be embedded within the team, performing many of the testing tasks. However, given those testers’ position within the team, there is a risk of loss of independence and objective evaluation.
- Testers on a on-demand basis : Other Agile teams retain fully independent, separate test teams, and assign testers on-demand during the final days of each sprint. This can preserve independence, and these agile testing engineers can provide an objective, unbiased evaluation of the software. However, time pressures, lack of understanding of the new features in the product, and relationship issues with business stakeholders and developers often lead to problems with this approach.
- Independent Test Teams : A third option is to have an independent, separate test team where testers are assigned to Agile testing teams on a long-term basis, at the beginning of the project, allowing them to maintain their independence while gaining a good understanding of the product and strong relationships with other team members. In addition, the independent test team can have specialized testers outside of the Agile testing teams to work on long-term and/or iteration-independent activities, such as developing automated test tools, carrying out non-functional testing, creating and supporting test environments and data, and carrying out test levels that might not fit well within a sprint (e.g., system integration testing).
- Testing in case of multiple large Agile Teams and Independent Test Teams : Organizations may plan on having independent testing teams for large implementations involving larger number of teams. It is therefore important to integrate across scrums so that the testing team sees a fully integrated version at all times instead of working on versions which may work for a particular functionality but may not work well if integrated with other teams. Principles of Continuous Integration are particularly useful in such an approach. Doing a regular Scrum of Scrum meetings across development teams and testing teams is also a useful technique which may help in independently assuring quality.
- Applications where Requirements are Fluid (Mobile Applications, Internet Applications) :
Where the requirements are fluid (e.g. Mobile Application Development, Internet websites etc), the obvious choice of most customers is to go for Agile Development Methodology.
To speed up testing, it is worth taking a N+1 approach as shown in the diagram below. In this approach, Functional testing is done (manually) along with the development team. However, the functional testing done manually is automated in the following sprint (N+1). This makes it possible to have a fully updated Regression Test Suite. This Regression Test Suite will be useful in performing the functional testing in the subsequent sprints.
- Large Enterprise Applications:
For Large Enterprise Applications, upfront planning and design is generally done in a waterfall way. Thus a detailed design and detailing of all important features is available upfront before the implementation starts.
However, in such situations also, where the requirements and known upfront (Large Enterprise Applications) Customer may still prefer Agile Development for various reasons
o Customer may still like to see incremental deliverables instead of a big-bang delivery.
o Agile gives the customer ability to Inspect and Adapt based on what they see.
o In requirements may end up changing due to various needs of the market or how the market evolves over time.
o Risk of the requirements fluidity may be high, while it’s a perception that the requirements are known upfront
In such situations following are the things which could be done upfront to create a more effective deliverable
o Automating the Acceptance Test suites and providing the same to development upfront to create an environment of preventive testing rather than reactive testing. The focus here is on prevention rather than on finding defects.
o A More thorough acceptance test suite could be written in close coordination with the business teams.
o The testing team now focuses on keeping the acceptance test suites updated all the time based on changes in the requirements.
o The testing team will now get more time to focus on Exploratory testing and finding defects that the machine may not be able to do.
o Thus a right mix of Automated and Manual testing could be used by the independent testing teams.