Agile, Scrum and TPI
Agile methodologies have emphasized many excellent practices from a testing perspective such as test-driven development and exploratory testing. Nevertheless, practice also shows that the overall approach and process of testing is often less than satisfactory in agile projects.
Like in waterfall situations there is a need for improvement of the test activities or test processes. This aspect has been elaborated in the TPI NEXT® book Business Driven Test Process Improvement, where it (paragraph 7.2) explains how the model can be used in agile situations.
However, we learned that organizations struggle with the implementation and use of agile methods. In many situations we see that it’s Agile ‘In Name Only’, or specific elements of Scrum are adopted like the (daily) stand ups. We also learned that the professional tester is able to contribute to the agile teams with his skills and above all experience. Through his work as a tester he becomes the ‘center of operations’, closely working together with analysts, developers and users. From this position the tester is also capable of convincing others of the benefits of testing, thus creating a quality driven mindset with other team members and stakeholders.
Based on our test experience and our test activities in agile environments we think that this document will help organizations, project teams and individuals apply the Agile Manifesto that states:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
While there is value in the items on the right, we value the items on the left more!
Although ‘Agile’ has many different flavors we will use the Scrum terminology for this document, as Scrum is a commonly used methodology. Furthermore we refer to “TMap NEXT® in Scrum”, where the authors use the Scrum methodology as a basic starting point.
Developer or tester
In the ideal situation the Scrum team will consist of developers, with no specific roles or expertise: Scrum recognizes no sub-teams in the Development Team, regardless of particular domains that need to be addressed like testing or business analysis; there are no exceptions to this rule. [The Scrum Guide, July 2013]
In the real situation however we see that the developers do have a specific role, especially the tester. With this document we do not want to challenge the Scrum Guide but, building from the practical situation, support and improve the test activities within the teams. Furthermore with this document we aim at a situation where each team member is capable of performing the test activities in the right way; where we address the ‘tester’ we imply each team member that performs test activities. Testing in a Scrum team is a team activity: as a team you develop test scenarios, as a team you decide what will be tested, where and how (manual or automated). Tasks coming from that activity, and shown on the Scrum board, can be picked by anyone in the team.
Read more: Download the whitepaper (ENG).
The whitepaper is also available in Japanese.
Read more: Download the whitepaper (JPN).
With thanks to: Mariko FUJIKAWA, Takashi YAMASAKI, and Ryuji MORI from VeriServe Corporation