Here are my experiences as a test engineer in adopting the AGILE approach:
Initially when i was working in Waterfall model, our QA work
for a feature completely depends on the functional specification written by
developer. We used to consider that document as the main reference. Based on
that, we used to write a detailed test plan and start testing the feature once
the whole feature is available to us. Then write automation tests before the regression
cycle begins for a release.
When our company, switched to AGILE model, the first
question that raised in my mind is "How can QA engage effectively during a
sprint before anything has been built?". Scrum is an Agile approach to software
development, which focuses on delivering valuable business features in short
development iterations of 2 to 4 weeks (In our case, it 3 weeks). After working a few years as a QA in a Scrum
team, I have learned that the role of QA in Scrum is much more than just
writing test cases and reporting bugs to the team.
In initial days of scrum, I used to think daily stand-ups are
nothing but wasting time and seriously, i used to see AGILE approach as A-JAIL. The concentration in scrum is on what to tell instead
of the work being done. Also, the information being shared in scrum is well
known by everyone. We know who is working on which feature, but why do we need
a separate 15 min meet to just know a statement saying “working on so and so”. Yes,
its more than the status. Team shares the detailed status where QA can know the
details of the feature and the impediments being raised and what is stopping
developers from continuing the work.
Here are few things i learned.
- In Waterfall model, QA involves at the end of
development. But, in AGILE, QA will be involved right from the very beginning
of a project.
- Working together - Scrum team is a cross-functional team where
development, QA, platforms and documentation teams work together as a team.
- QA, the first and ever customer - I
always used to think that QA is the first customer of the product and QA
knows well about the product more-than development team who typically focuses
on the “happy path” of the feature. Since, QA excels at identifying and
capturing complex and negative test case scenarios. Including testers during
Release and Iteration Planning, when user stories are estimated, QA can help
the team think beyond the happy path.
- Helping Product Owner - QA role provides feedback from their testing
experience to the Product Owner and work closely with the Product Owner to help
them develop detailed acceptance criteria for their user stories. QA can also
help the Product Owner modify or enhance existing user stories to better
reflect the true requirements.
- Fast feedback – Developers can consult the QA
about acceptance criteria or the expected behavior of any functionality from
the user's perspective while working on the feature, which results in saved
testing and bug fixing cycles.
- Automation, QA’s best friend - In scrum (3
weeks), QA generally have less time to test the application. Also they are
responsible for testing the feature implemented in current sprint as well as regression
testing the feature implemented in last sprint. In such short cycles,
automation is the best friend for QA (as alwaysJ).
It helps to reduce the pressure QA feels.
- Participation in Release readiness - With short
sprint cycles, developers have less time to explore the complete functionality
of their user stories on their own. As a result, developers typically consult
with QA to better understand the user stories since they are the ones aware of
the complete functionality and know each and every requirement and acceptance
criteria. As a result, it is a good practice for QA to perform the demo at the
Sprint Review meeting.
- Preparing test strategies - Scrum believes in
preparing only enough documentation to support the immediate needs of the team.
As such, QA will prepare just enough high-level documentation for test
strategies and plans to guide the team.
- Sometimes it may not be possible to perform
testing of non-functional aspects, such as system performance, within a sprint.
This can taken once after the development sprints complete.
While QA still write tests and report bugs, they also
support many other roles and responsibilities on the team. They are an
important part of the team.
Having worked as QA in AGILE team, i have learned
many things, it has added many wonderful skills to my toolbox and has helped me
learn how to play many different roles.
