A free ebook brochure covering the most common FAQs for Agile Testing.
Common Questions about Testing on Agile Projects Answered
Download this free eBook Brochure answering the most common questions about how Software Testing fits into an Agile Software Development project.
When you need help implementing Agile Testing on your projects then Contact Alan Richardson.
Want to know when we create new guides?
To keep up to date, sign up to our mailing list:
This is a double opt-in list. Full Privacy Policy Details
What is Agile Testing?
A Test approach crafted uniquely for your specific environment.
Test in a way that fits, and adapts to, your Agile Development. Nothing complicated. Involve everyone on the team in your Testing process, because Testing is a major part of your Software Development Process.
Every Agile project is unique - staff mix, skill sets, business concerns, tool sets. You need to adopt a Testing approach crafted to your specific environment. To do that you need to understand the essence of testing in terms of feedback, and as a means of evaluating and exploring models of your system. Then test in a way that fits, and adapts to, your approach to Agile Development. Nothing complicated. Don’t shoe horn in something you would traditionally call ‘Testing’ and label it Agile. Do adapt your process to meet the needs of your project. And do involve everyone in your Testing process, because Testing is a major part of your Software Development Process.
Do we still need testers in Agile?
Once you’ve worked with a good tester, this question won’t even cross your mind.
You still need to test, and you need people to do that. You can train other people to test, but they may not have the motivation to learn testing in depth and push your System to its limits.
People often ask this question because they’ve never seen a good tester in action. After working with a good tester, this question won’t even cross your mind. You still need to test, and you still need people testing your software. You’ll need the people doing that to understand how to test, and to test well. Testers generally know how to do that. But of course you can train other people to do your testing. They may not have the same motivation to continue to learn testing in depth and the nuances and subtleties of system and risk exploration as people who view testing as their main focus.
What is an Agile Tester?
An Agile Tester brings flexibility to their role.
They take the essence of testing and implement it as part of your Agile System of Development. They explore the System deeply, spot Risks, and ask questions to help everyone think differently about the quality of the software and the process of development.
An Agile Tester brings flexibility to the role of tester. They don’t just quote testing books at you and best practice definitions. They take the essence of testing and help implement it as part of your Agile System of Development. They will know how to test with minimal information and ask questions to help other people think about the quality of the software and the process of building the software. They will know how to spot risks and target those risks with hands on system manipulation. Very often they spot gaps in the development process and help fill them.
What does a Software Tester Actually Do?
Testing builds a model and compares it to the delivered system.
Models like: requirements, acceptance criteria, risk (business, technical, process), flow, and functionality.
A tester expands the model by observing, exploring, interrogating and manipulating the system.
The essence of Software Testing is building a model of the System Under Test, and then comparing that model to the delivered system. A tester builds lots of models; requirements, acceptance criteria, risk (business, technical, process), flow, functionality, etc. The tester has different techniques to prioritise how they explore the relationship between the model and the system. A good Tester adapts their model based on the information they observe as they interrogate and manipulate the system, they reflect on this information to communicate effectively and expand their model.
Should we automate our testing?
Automate execution flows through the system to assert on agreed acceptance conditions.
Humans automate the mechanistic, to free ourselves to use emotion and imagination. We should look for opportunities to automate parts of our testing process.
We are Human. Humans automate processes. We will automate the mechanistic parts of our processes, to free ourselves from drudgery and allow us to more fully exercise our emotion and imagination in our Software Development. We use IDEs to automate parts of the coding and refactoring processes, we automate builds and software releases. We should look for opportunities to automate as part of our testing process - often this will be checking, and asserting on, the agreed acceptance conditions. We can automate execution flows through the system with pre-agreed acceptance condition assertions. This is only a small part of evaluating the risk associated with releasing software, but it can be automated.
What tools should we use for our Agile Testing?
That depends on your technology. Automate strategically and tactically.
Strategically automate system execution making it maintainable and robust.
Tactically use tools to support deep system Observation, Exploration, Interrogation and Manipulation.
Your tooling will vary depending on the technology you use. You’ll need tools to help you strategically automate system execution to make it maintainable and robust. You’ll need tools to support you in tactically observing the system functionality and message passing in detail. Tools to help you interrogate and manipulate the system in ways a user would never need to do, to help you explore the system in detail. I generally try to use the same tools as the rest of the development team. I don’t recommend separate “Test Tracking” tools, when you do that you end up having only testers use them, and we want to harness the skills of all team members as part of our testing process.
How Much Should we Automate?
Automate to convince yourself the system continues to meet the acceptance criteria.
Review the automated execution code, to ensure it is relevant, delete anything that takes time to maintain but doesn’t help evaluate the risk of release.
Automate as much as you need to. Are you convinced that you have a low risk of changes unexpectedly and adversely impacting previously tested areas of the system? Are you convinced that the agreed Acceptance Criteria are still met by the system? As you maintain your automated execution code, review what you have created to make sure it still seems relevant, and delete anything that takes time to maintain but doesn’t help you evaluate the risk of the release.
How can we automate and still finish the sprint?
Commit to automating as part of your Definition of Done.
Don’t just write code, commit to maintaining an system which automatically asserts that you continue to meet the acceptance criteria the code was designed to fulfil.
Automating acceptance criteria is part of your sprint planning. Commit to automating as part of your Definition of Done. Don’t just write code, commit to maintaining a system which automatically asserts that you continue to meet the acceptance criteria the code was designed to fulfill. It is possible to work on the acceptance criteria checking in parallel to writing system code. Take advantage of abstraction layers and good coding and design principles to support your development process.
How can we finish all our testing in the sprint?
If you haven’t finished testing, then you don’t release that functionality.
Everyone on the team tests to the best of their ability. Leave the simple condition checking to the automated system or people less skilled in testing.
Making time for testing is part of your sprint planning. Don’t create a bottleneck by having a single person allocated to testing. Have everyone on the team test the software to the best of the ability, and use the people who are best at testing to really explore the risks and conditions in detail while leaving the simple condition checking to the automated system or people less skilled in testing. If you haven’t finished testing, then you can’t evaluate the risk, and you don’t release that functionality.
How can I help you with your Agile Development?
Free - Download and Print Your Own “The Evil Tester’s Guide to Agile Testing Brochure”
Download Your PDF Version (For Free) Now
- Don’t wait to meet Alan at a conference.
- Don’t hope that event organisers have placed a professionally printed copy of the Brochure in your Goodie Bag.
- Do print your own, on whatever printer you have available.
- Do Print the “Commonly Asked Questions about Agile Testing” on a large sheet of paper and print it on your wall for handy reference reading. marp
Contact Alan to help you with your Agile Testing and Development
