Even though the Agile philosophy has been in the market for more than two decades, it has only been in the past few years that the trend of using Agile for software development projects has taken off. Though it is gaining popularity, adopting and integrating this philosophy it is not always simple.
You need to pack some valuable knowledge and skills to help you overcome the obstacles you would find in your transition “trip” from traditional to Agile and insure a smooth switch. The QA activities are one thing you will definitely want to adjust.
||Sprints (partial deliverables)
In the Agile philosophy, the product to deliver (system) is divided into several pieces; these are developed/tested in different sprints (usually 2-4 weeks each one). The transition to sprints (iterations) may produce some backlash at first. How can we possibly write test cases and execute them so quickly?
Furthermore, in Agile a regression test suite execution is required at the end of each sprint, this is something important to consider for the testing effort estimation.
Though it may seem like QA time has been reduced, in the sprints schema the QA time is properly estimated according to the “value” to be deliver on the iteration; that is because every sprint deliverable is clearly identified so its estimations can be more accurate.
This change, mainly affects the“usual” time allotted for Test Planning (Test Cases) creation, because you do not have to wait until the whole product has been developed to start test execution.
A new communication paradigm is required, where all communication ways has been opened inside the project team. A daily meeting is planned to improve the productivity and support others’ activities. During this meeting each team member describes: What they did, what they are going to do and if there are any roadblocks for these activities.
In the QA process, the Test Strategy is reviewed and discussed for all the team members (not just for the QA Team), so all the requirements and assumptions are openly discussed and can be managed accordingly.
In the “Traditional” methodology, the Functional Specification (and other documents) are the “alpha and omega” for all the testing activities and deliverables. Traditional project management did not welcome oral notifications for changes.
In Agile, the Functional Specification is an important source of information. The original instructions may change in order to look for and assimilate the information, irrespective to the way it is displayed (verbal, written, etc.). Face-to-face interaction is a plus.
NEXT: The trip does not end here. Coming up:
What to pack for your “Agile Testing Trip” Day 2