If you are a professional application tester, or work in quality assurance, I consider you to be
(like me) a "conventional application tester." Increasingly, conventional application testers are finding themselves on teams using the Scrum development method. For testers unfamiliar with iterative lifecycles, this can be a real challenge. Having been on a variety of projects using Scrum as a conventional application tester, I'll share four stories that describe different approaches for testers.
The Scrum methodology can pose a challenge for application testers who are used to more traditional waterfall-inspired development processes. Jonathan Kohl relates his experiences working on Scrum teams who found some clear advantages in changing their methods.
What is Scrum?
According to the website of Scrum, Scrum is an agile process, light that can be used to manage and control software and product development using iterative, incremental practices. "The best place to start learning about Scrum is the page About the Scrum website. It's a good idea to learn as much as possible about Scrum as a tester, in particular the principles and theory behind it. To understand the terminology of this article, I will summarize some aspects of Scrum.
Scrum is a software management process that uses an iterative lifecycle and focuses on communication, including feedback loops. Each iteration, called Sprint, takes about four weeks. A Sprint is a block of time in completing the software development. Ideally, a complete vertical section of the application is submitted at the end of each Sprint. When each "slice" board, you have the full product. A Sprint is a longer cycle of votes in which the software developed in the last iteration is demonstrated to project sponsors and end users.
Short resubmit loops are also produced every day. These everyday Scrum meetings last fifteen minutes, during which team members describe what we are working and raise issues they might find. The Scrum Master (the person who manages the project management) will Scrum meetings.
Work to be undertaken during the life of a project (a project contains several Sprints) is summarized in an accumulation of products. The Product Backlog contains a list of characteristics needed for the project; this is the scenario for the project. Each also has a Sprint backlog tasks to meet a number of features in the Product Backlog. This describes the work of a special sprint. These documents are often written in a high level. The details can be filled in according to the practices of the team. How to perform tasks to achieve the objectives of the project left the team in Scrum, so it's common to see Scrum teams using Extreme Programming or other within Scrum.
For the evaluator, the most important things to note about Scrum are its iterative lifecycle and frequent communication. Both may require some adjustments by the examiner, who can be relied on to do the following:
- Proof of within each iteration, rather than the end of a development cycle
- Decide what to test when a product is still unfinished
- Collaborate with team members rather than working in isolation
- Participate in daily status meetings are a maximum of 15 minutes duration
Request Information on individual chemical through tests, and work with other team members to determine what to test, rather than testing requirements documents.
0 comments:
Post a Comment