The word ‘agile‘ has become so trendy that people can’t live without it anymore. The interesting part is that almost every work advertisement mentions that an ‘agile organization‘ is looking for an ‘agile tester‘ for an ‘agile project‘. Being not agile means not keeping up. Old school…
We have agile dev teams, agile testers, agile projects, agile organizations, etc. 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 is nothing more than a method of reducing the cost of change and uncertainty.
In addition to the agile methodology, another great method of visualizing and managing your development work is Kanban. It visualizes both the process (the workflow) and the actual work passing through that process.
How to Include Testing in Agile Environments?
Test-Driven Development (TDD)
Traditional testing depends on a lot of documentation. Agile testing is an approach to the 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, and 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 type of software development process that emphasizes the need for good software quality. Traditionally, a developer writes the code and then the testing department will examine it and report bugs. Moreover, in TDD, the developers are the ones who write unit tests first, before even writing any code that would complete a user story. Of course, it is possible to collaborate in every task, thus there are situations possible in which the developer works together with a Quality Expert and thinks of possible test cases.
The tests initially fail until the developer writes the minimal amount of code to pass the tests. As a next step, the code is refactored to meet the quality requirements of the team.
It is possible to implement TDD into Scrum or Kanban type of working methods. 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 minimizes unnecessary code creation and also resolves any doubts at the beginning of the development cycle.
Automate regression testing
Regression testing is a type of software testing that verifies that software, which was previously developed and tested, still performs correctly after it was changed or interfaced with other software. Changes may include software enhancements, patches, configuration changes, etc.
If regression testing in the 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 catch any unexpected system behaviors and react to a major change.
There is yet another question – how big your system is. Small systems usually have checklists rather than test suites – large ones – even ‘monster’ ones.
Deciding what should be automated is always tough because having automated test scrips might not be something that the team could present in front of the customer. Thus, the question should be: WHY do you want to automate anything?
The problem is that sometimes automated suites are not reliable and trustworthy and the effort to keep them alive is quite high. 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.
What’s most important – even in agile environments – is to review often and prioritize.
No one will benefit from extended long-running test suits, right? Automated regression tests should be efficient and alert early in the development phase, to achieve better quality and be truly agile.
Visualize test tasks
One of the great examples of working with 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 the candidates for automation. All those ideas and tasks can be stuck on the board and addressed accordingly. It doesn’t mean that a tester is the only responsible person 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.
Communication
No matter if the project is handled in Scrum, Kanban or another agile manner – the key for success is communication among the team.
There are many useful tools for that, 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 failed. It can also be helpful in automated regression and getting the test result accessible for everyone.
Summary
If you have anything to do with test management or quality assurance as well – this short exercise is great for practicing every day: Start your working day from a short trip around different metrics – nightly builds, code coverage, cyclomatic complexity and so on. Try to explore and add some new flavor to the testing. Every day there can be a discovery that can later be addressed to improve the quality and stability of your product.
It is not the methodology or technology that limits us from rising the quality of the product or including test automation in the 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. 🌱