Scrum Master, Product Manager, Developers and Testers collaborate to discuss about the requirements. How are requirements communicated?
STEP 1: REQUIREMENTS
Product Manager comes up with the requirements and communicates it in the form of user stories and UI prototypes. User stories generally follow the following template:
As a [role] I want [feature] so that [benefit]For example: As a user, I want to login to the Gmail online email service by providing my username and password, so that I can view my personal emails.
STEP 2: ELABORATION OF REQUIREMENTS
Tester elaborates the user stories are transforms into the test scenarios in BDD style. BDD generally follow the following template:
Given [context] And [some more context] When [event] Then [outcome]For example: Scenario 1: Given that I am an end user, And I am in the login screen of the Gmail online email service, When I input valid username, valid password and click on the ‘Sign In’ button, Then I should login to my personal mailbox and view my emails. Scenario 2: Given that I am an end user, And I am in the login screen of the Gmail online email service, When I input valid username, invalid password and click on the ‘Sign In’ button, Then I shouldn’t login to my personal mailbox and system should display an error message “Invalid username/password”. Scenario 3: Given that I am an end user, And I am in the login screen of the Gmail online email service, When I input invalid username, valid password and click on the ‘Sign In’ button, Then I shouldn’t login to my personal mailbox and system should display an error message “Invalid username/password”. Scenario 4: Given that I am an end user, And I am in the login screen of the Gmail online email service, When I input invalid username, invalid password and click on the ‘Sign In’ button, Then I shouldn’t login to my personal mailbox and system should display an error message “Invalid username/password”.
STEP 3: REVIEW OF REQUIREMENTS
Product Manager reviews the test scenarios written by the testers and moves the user stories to the Estimation board, if he is happy with the test scenarios. If not, Product Manager provides feedback to the tester and the tester needs to update the test scenarios based on the feedback and provide it for the next review. This process continues until the Product Manager is happy with the test scenarios.
STEP 4: ESTIMATION OF REQUIREMENTS
To start an estimating session, the product owner reads a user story and describes a feature to the estimators, who should include team leaders of Development teams, UI Design teams and Testing teams. Each estimator is holding a deck of cards with values like 0, 1, 2, 3, 4 and 5, where the values represent the number of story points. When the feature has been fully discussed, each estimator privately selects one card to represent their estimate. All cards are then revealed at the same time. If all estimators selected the same value, that becomes the estimate. If not, the estimators discuss their estimates. The high and low estimators should especially share their reasons. After further discussion, they come up with the same value. Scrum Master records the stories points for the each areas (i.e., Development, Testing and UI Design) and places the user stories in Product Backlog.
STEP 5: ROLL-OUT OF USER STORIES FOR IMPLEMENTATION
Product Manager discusses with the Business/Customer, priorities the stories for implementation and rolls-out the user stories to the Implementation board.
V-model is a software development model that involves building a logical V shape sequence where the testing techniques associated with the design are reflected as descending and are applied for the “verification” and connected to the requirements or specifications parts are reflected as ascending and are applied for “validation”. Equal weight to coding and testing in the V-model gives software development process. The V-model ordains that the code testing documentation is written in tandem with the development phases that means, for instance, the integration tests should be documented as and when the high level design is finalized and the unit tests should be ready as and when the detailed specifications are laid down.
The idea of the V-model is to have a implementation plan for the software testing at each level namely component, interface, system, acceptance and release of the software project which need to be adhered to eliminate discrepancies in the software simultaneously rather than waiting for the software development process to complete before handling it to the software testing professionals.
Agile testing is a software testing practice that follows the rules of the agile manifesto, treating software development as the customer of testing. Agile testing involves testing from the customer perspective as early as possible, testing early and often as code becomes available and stable enough from module/unit level testing. Agile methods were developed as a response to the issues that the traditional V-Model and waterfall methodologies had with defining requirements and delivering a product that turned out to be not what the end user actually wanted and needed.
Testing from the beginning of the start of the project and continually testing throughout the project life-cycle is the foundation on which agile testing is built. Every practice, technique or method is focused on this one clear goal. Agile methodologies are designed to break the software down into manageable parts that can be delivered earlier to the customer. The aim of any Agile project is to deliver a basic working product as quickly as possible and then to go through a process of continual improvement. An Agile project is characterized by having a large number of short delivery cycles (sprints) and priority is given to the feedback-loops from one cycle to the next. The feedback-loops drive continuous improvement and allow the issues that inevitably occur (including the way requirements have been defined or the quality of the solution provided) to be dealt with much earlier in the development life cycle. To achieve this, companies need to re-think their approach to delivery and have their previously independent contributors (Business Analysts, Developers, Testers, End Users etc.) worked together in teams.
The key challenges for a tester on an agile project are:
- No traditional style business requirements or functional specification documents. We have small story cards developed from the 4×4 inch cards, which only detail one feature. Any additional details about the feature are captured via collaborative meetings and discussions.
- Testing starts as early as practical and continuously throughout the lifecycle so expect that the code won’t be complete and is probably still being written.
- Acceptance Test cases are part of the requirements analysis process and are developed before the software is developed.
- The testing team has a responsibility to create automated unit tests which can be run against the code every time a build is performed.
- With multiple code deliveries during the iteration, the regression testing requirements have now significantly increased and without test automation support, the ability to maintain a consistent level of regression coverage will significantly decrease.
Why I prefer Agile over V model?
In the phase diagram, it is clear that testing in Waterfall happens at the end, right before release. The diagram is idealistic; because it gives the impression there is as much time for testing as there is for coding. In many projects, this is not the case. The testing gets “squished” because coding takes longer than expected, and because teams get into a code-and-fix cycle at the end.
Agile is iterative and incremental. This means that the testers test each increment of coding as soon as it is finished. Iteration might be as short as one week, or as long as a month. The team builds and tests a little bit of code, making sure it works correctly, and then moves on to next piece that needs to be built. Programmers never get ahead of the testers, because a story is not “done” until it has been tested.