On my path to learn about agile and scrum, I learned a lot about Unit testing and integration testing, Test Driven Design (TDD) Design and eXtreme Programming (XP), The definition of done and ready, continuous build and integration... I also earned about acceptance criteria and even Acceptance Test Driven Development. Those terms were not entirely new for me, but let's say I understand them better now since I saw them being put in practice by the teams.
But what about exploratory testing, non functional testing, front-end automation, test data preparation, test environment management for example? And how do testers get their test-related jobs done when they require considerable extra effort? I found, next to the very structured applications of unit testing and TDD, manual testing and test automation aspects as well as test related tasks and estimations were not yet very mature.
As I'm now only 2 years active in Agile development and more particularly in Scrum, I do not claim to own Agile development. But I do claim to know something about testing and where I would take proper testing tasks into consideration while working in for example Scrum. This is how I did it:
I divided the test related tasks into 3 parts
- Taks to be taken up during product backlog definition
- Tasks to be taken up during sprint backlog definition
- Tasks to be taken up during the sprint
Product Backlog definition
Production issues
It is important that production issues ( and maybe also issues coming out of acceptance testing if this is not taken into the definition of done of a sprint) get a proper description and impact and become part of the product backlog.
Test related features and testability items
Features needed to accommodate testing (stubs, drivers, datasets, monitoring plugins, maybe even a button and input field within the application to provide feedback for beta testers) need to be defined and developed in time.
Also product supporting elements like test automation, performance tests, security tests, exploratory sessions are items that could be put on the product backlog.
Sprint backlog definition
Test estimation
During the sprint backlog definition, testing has to make sure that all testing efforts are estimated for every user story that goes into a sprint. Things that are easily forgotten are test data preparation and often even testing of negative paths and exploration sessions.
Acceptance Criteria
Making sure the user stories have adequate acceptance criteria defined.
Evaluation
Proof-reading user stories - checking if they are concrete and elaborated enough to go into development. Check them on corner cases and look for inconsistencies and interdependencies between stories.
Sprint
Daily scrums
Testing is or should be part of the definition of done of a sprint. Therefore testing is an activity taking place within the sprint and testing should be part of every daily scrum.
Manual testing
Manual testing, checking on acceptance criteria but also exploratory testing is a very important part of the sprint. Whatever piece of code that is test-ready should be tested.
Exploratory testing is not always.. or let's say almost never related to one user story. Exploratory sessions could focus on company history, comparable products, internal consistency, browser and device compatibility... and often is a trans-feature test activity. This means that exploration sessions might need individual tasks, next to the user story related checks that need to be part of the user stories definition of done.
Automated testing
Best is to automate tests that on stable code of the previous sprint and run a test set of automated regression tests on top of the unit and integration test framework
Test data preparation
During the sprint, testers or developers need to make sure the required test data is available. sometimes this is part of release management, some times it needs to be prepared in files, directly in the database or in the application, using the front end.
This needs to be a well-coordinated.
Test environment
As agile development equals constant build and and constant integration, the test environment needs to be ready for testing when it needs to be ready and needs to stay in a certain situation maybe for a small period of time before a new version of the product is released. This requires intensive communication. We need to know at all times which version is under test and under which version bugs are being reported.
User coaching
Another duty of testing is coaching of users in acceptance testing or even in the definition of requirements and acceptance criteria. Users need coaching. Often they don't understand the principles of scrum to much and a scrum master can not go into details involving and coaching all users. A tester has the competences and the adequate product knowledge to take this role.
