Outlining some Key success factors for Agile Testing –
Success Factor -1 Use the Whole Team Approach
When the whole development team takes responsibility for testing & quality, you have a large variety of skills sets and experience levels taking on whatever testing issues might arrive.
Success Factor -2 Adopt an Agile Testing Mind-Set
Use agile principles and values to guide you. Always try the simplest approach first. Experiment with new practices, tools, and techniques.
Success Factor -3 Automate Regression Testing
Use Agile Testing Quadrants and test automation pyramid to help you automate different types of tests effectively. Experiment with different ways of getting support from management and from team members to start some tiny automation effort.
Success Factor-4 Provide and Obtain Feedback
One of the most valuable skills you can learn is how to ask for feedback on your own work. Feedback is imperative for agile teams.
Success Factor -5 Build a Foundation of Core Practices
Continuous Integration process needs to be implemented, setup test environments and manage technical debt
Success Factor -6 Collaborate with Customers
Help customers clarify and prioritize requirements, illustrating requirements with concrete examples and turning those examples into executable tests.
Success Factor -7 Look at the Big Picture
Testers tend to look at the big picture, and usually from a customer point of view, which is a big contribution to the team. Plan testing to cover all angles. Use Exploratory testing to learn more about how the application should work, and what direction your testing needs to take.
And here ends my ‘Read Along’ Series for ‘Agile Testing’ by Lisa Crispin and Janet Gregory. It sure was a fun and informative read and I learnt a lot from it! I hope this series helps someone read along chapter-wise or even someone looking for quick introduction to agile testing.
Agile team delivers working software at the end of the iteration – demonstrate to the customers and get their feedback.
Having testers conduct the ’Iteration Review’ is a common practice as they’ve usually worked on all the stories. The Scrum Master, programmers or testers could demonstrate the new features – It is recommended to rotate this honor.
Retrospectives are an excellent place to start identifying what and how you can do better.
Start, Stop, Continue technique – Discussing What went well, What did not go well and what we can start doing to help.
Write task cards for actions to be undertaken to implement the steps
At the end of the next iteration, take a checkpoint to see if you improved
Retrospectives are a simple and highly effective way for teams to identify & address issues. The retrospective meeting is a perfect opportunity to raise testing-related issues. Bring up issues in an objective, non-blaming way.
Make sure your team takes at least a little time to pat itself on the back and recognise its achievements.
Even Small Successes deserve a Reward.
Many agile teams have trouble taking time to celebrate success.
Have a weekly fun gathering or team games.
For big milestones such a big release or achieving a test coverage goal, the whole company can have a party to celebrate, bringing in catered food or go out.
It is also important to celebrate individual successes. A ‘Shout-Out Shoebox’ – is a great idea to recognize the value different team members contribute.
Taking time to celebrate successes lets your team take a step back, get a fresh perspective, and renew its energy so it can keep improving your product, giving team members a chance to appreciate each other’s contributions. Don’t fall into a routine where everyone has their head down working all the time!
Take advantage of the opportunity after each iteration to identify testing- related obstacles, and think of ways to overcome them.
Use the Agile Test Quadrants to help you identify the different types of test automation tools you might need for each project, even each iteration.
Test Automation Pyramid (introduced by Mike Cohn)
Lowest Layer- Bulk of automated unit , technology facing tests. Quickest feedback, code much more quickly using xUnit family of tools
Middle layer – Automated business-facing tests that help the team. “Are we building the right thing” Tests operate at the API, behind the GUI level. Bypass the presentation layer – less expensive to write & maintain these tests. Fit & FitNesse are good examples, written in domain language
Top Tier – Should be the smallest automation effort as they have the lowest ROI. Done through GUI, operating on the presentation layer. More expensive to write, more brittle and need more maintenance.
Any tedious or repetitive task involved in developing software is a candidate for automation.
AN automated deployment process is imperative – getting automated build emails listing every change made is a big help to testers. It speeds up testing & reduces errors.
A fast running continuous integration and build process gives the greatest ROI of any automation effort.
Another useful area for automation is data creation or setup. Cleaning up test data is as important as generating it. You data creation toolkit should include ways to tear down the test data so it doesn’t affect a different test or prevent rerunning the same test.
What we shouldn’t automate
Tests that will never fail
Plan-in plenty of time for evaluating tools, setting up build processes, and experimenting with different test approaches in the initial iterations.
If management is reluctant to give the team time to implement automation, explain the trade-offs clearly. Work towards a compromise.
We will always have deadlines, and we always feel pressed for time. There is never enough time to go back and fix things. During your next planning meeting, budget time to make meaningful progress on your automation efforts.
Good test management ensures that tests can provide effective documentation of the system and of the development progress
Retrospectives are an integral part of every project we undertake, as well as a key ceremony in the Scrum lifecycle. Agile principally stresses the need to perform periodic meetings to reflect on the functioning of the team, their processes and actions and try to improve their shortcomings, so retrospectives are essential. The team gets to look back on their work and answer three key questions: What went well? What did not go well? How can we improve?
Even if agile teams perform retrospectives as a regular part of their project lifecycle, there are a few common mistakes they may be making due to a lack of understanding, perspective or communication, and these mistakes can prevent obtaining the maximum benefits of the retrospective.
In my article for Gurock TestRail blog, I have discussed five common mistakes that we must avoid in Agile Retrospectives.