Table of Contents
The word 'agile' became trendy years ago and the eagerness of using it in projects in organizations remains high even today.
We have Agile dev teams and Agile testers, Agile projects. Unfortunately, the term 'agile' has become a convenient replacement for lack of requirements, lack of documentation, or, just basically, a pure mess.
On the other hand, Agile means nothing more than a way of working well to reduce the cost of change and uncertainty.
Traditional vs. Agile
Talking about methodologies is always good as it leads to spotting the difference between traditional - usually phased or gated (Waterfall) ways of making software,
as opposed to iterative, where every story is expanded, coded, and tested with a possible release after each iteration.
The Agile change
Agile testing influences the whole process of making software, including:
- Whole Team Approach
- Coding and testing as a single process
- Feedback, collaboration
- TDD/ATDD practices
- Test-infected developers
- Better tools
- Better designed tests
It also allows a tester to be an actual part of the team rather than a siloed unit in an organization. A tester is not a gatekeeper or quality police but he/she provides valuable input into each phase of development.
In real life, it means that an Agile tester takes part in all team meetings, provides the input, asks questions, is invited to pair programming sessions with developers, and takes the same responsibility for the code and product as any other member of the team. Of course, it requires from the Tester a larger skill set, great communications skills, and at least basic knowledge of coding and test automation.
How to include testing?
There are many ways for extending Test Specialist responsibilities in an Agile team. They don’t necessarily include testing itself but also include a vast range of communication, presentation, and consultation activities.
Traditional testing relies on ample documentation. Agile testing is an approach to a process that mimics the principles of agile software development, especially where:
- Testing is done more often,
- The whole team knows how and what to test, it is possible to share tasks
- Testing relies less on documentation and more on team member collaboration.
One of the great examples of how to include testing into an agile process is to start from Test-Driven Development. The TDD methodology is a software development process that emphasizes the need for good software quality. Traditionally, a developer has written the code, and then the testing department has examined it and reported bugs. Moreover, in TDD, it is the developers who write unit tests first before even writing any code that would complete a user story.
Of course, it is possible to pair in every task, so in most situations, it is possible for a developer to work together with a Quality Expert and think of possible test cases.
The tests initially fail until the developer writes a minimal sequence of code to pass the tests. As the next step, the code is refactored to meet the quality requirements of the team.
It is possible to implement TDD into the Scrum or Kanban type of working. The point is to focus on testing and quality in general. Additionally, it makes testing more agile by moving most of the testing procedures to the early stages of the development lifecycle. When writing test scenarios at the beginning of each story, developers need to understand the requirements and cooperate with the other team members. This minimises unnecessary code creation and also resolves any doubts at the beginning of the development cycle.
Automate regression testing
Regression testing is yet another type of software testing to verify if the software, previously developed and tested, still performs correctly after changes or interface with other software. Changes may include software enhancements, patches, configuration changes, etc.
If regression testing in a software project is supposed to make any sense - it has to be performed as often as possible - at least on a sprint basis. Ideally - daily. Why? Because stable test suites would detect any unexpected system behaviors and react to a major change.
Small systems usually have checklists rather than test suites - large ones - even ‘monstrous’. Deciding what should be automated is always tough because having automated test scripts may not be something that the team could present to the customer. The question is rather: WHY would you want to automate anything?
The problem is that sometimes, automated suites are not reliable or trustworthy and the effort to keep them alive is quite hard. Test suites have to be regularly maintained and extended. Automation is great for this task but it is just another tool – not the purpose of the project.
Most importantly, even in the Agile environment, all tests need to be reviewed often and prioritized daily.
No one will benefit from extended long-running test suits. What is more, automated regression tests should be efficient and alert early in the development phase, to be of better quality and truly agile.
Visualize testing activities
One of the great examples of working with a Scrum or Kanban board is to visualize all the tasks in the project, not only the developer’s ones.
It is a great idea for the team to select even small, repetitive manual test tasks as prospects for automation. All these ideas and tasks can be placed on a board and addressed accordingly. It doesn’t mean that a tester is responsible for doing it.
Besides, in cross-functional Agile teams, there is a great opportunity for the testers to learn more coding and test automation, and for the developers to pay more attention to code quality.
Irrespective if a project is handled in Scrum, Kanban, or another Agile manner – the key to success is (?) the communication in the team.
Also, there are useful respective tools which help teams deliver faster and fight for better quality and efficiency. CI/CD build tools can be easily integrated with common tools for communication such as Slack, and can inform automatically that the build is done or if the build has failed. It can also be helpful in automated regression and getting the test result accessible to everyone.
Avoid single used solutions
The responsible software development process requires planning and adjusting, not working “here and now” and then fixing production bugs. Single–used solutions in a code, in testing, unnecessary work done in the cutting-corners mode to satisfy the customer’s demands are the things that often boomerang in the future.
When a manager approaches you and asks for doing development quickly instead of properly – “because it’s Agile” – remember that this is nothing else but a start of technical debt.
Discuss, propose, think, but when you agree on a shortcut – for example skipping performance testing or postponing some exploratory sessions due to lack of time – be aware of the consequences in the future.
You’ll save some time now, but you’ll be in real trouble soon.
As Elisabeth Hendrickson said in her book “Explore it!”:
“No matter what your job title, you most likely find yourself testing regularly. Testing is an integral part of creating anything.”
This is so true in Agile. Exploratory testing is simultaneously designing and executing tests to learn about the system, and then using your insights from the last experiment to feed the next.
Exploratory testing involves scouting around areas that the net of other forms of testing doesn’t cover. A tester interacts with the implementation, designing, and executing tiny experiments in a rapid succession.
Give and receive feedback
Every Agile Team uses feedback to improve. It does not matter whether feedback is provided daily or during longer sessions such as Retrospective or Planning. Testers are expert feedback providers, they usually have overall knowledge about the product and can advise at the beginning of brainstorming or at the end of the iteration to improve further work. Feedback lets the team make course corrections.
Testing in Scrum
How to incorporate testing in Scrum? The Scrum Guide doesn't say anything about testing because it's "a framework for developing, delivering, and sustaining complex products". It transcends the type of product that the team is developing, and the types of testing that the team needs to do, or how testing fits into the process is different for producing different types of software products. It does not define a specific “Tester” role, as testing is the whole team’s responsibility.
Of course, there can be a person more focused on delivering high quality, measuring application performance or assuring application security, but this role is not defined by the book. It usually means that when a team decides to work according to Scrum Guide and at the same time, there is an organizational role of a “Software Tester” - an expectation might arise that this person should provide guidance for the entire team (or even organization) on how to test software most effectively and lead the others in the field.
It is not the choice of a methodology or technology that limits us from raising the quality of the product or including test automation in a daily routine. It is rather a drive that comes from the team and helps everybody to get better at coding, testing, and taking care of the product.
The choice of the methodology is always a process, not a single decision. It requires work and effort from every team member, not only from the tester.
If you have anything to do with test management or quality assurance - this short exercise is great for practicing on a daily basis: start your working day from a short trip around different metrics - nightly builds, code coverage, cyclomatic complexity, etc. Try to explore and add a new flavor to the testing. Every day you can make an important discovery and improve the quality of your work.