If you spend too much on testing and do not understand why testing takes so much time to be done, by all means read our short summary of various agile methods that can be implemented in your testing routine.
While dozens of development teams follow some basic principles of quality assurance, their methods are often lackluster and can be improved.
Many developers separate testing from development, do one after another, avoid building their software to be acceptable as an SUT, and poorly manage the very process of testing.
So here are the typical aspects of testing that can be improved:
- Management methods
- Process-related improvements
- Execution improvements
Definitely, every single team of developers that works on a complex project would benefit from adopting efficient testing management techniques.
One of the most important things to notice is that a team’s efficiency rarely depends on the type of tools used. The focal point of efficiency is proper resource management, and agile methods are all about allocating resources and teaching your staff how to use them properly.
Passionate developers and testers who run around with great ideas and dream of all-around automated solutions are important, no doubt.
However, you need to understand that agile methods require the team to be, above all, disciplined. Only a team formed by responsible dedicated professionals can yield great results. Let’s talk about the pillars of agile testing.
Pillar #1. Automation is the key to success
One of the most obvious improvements within our industry is that we’ve started to use a lot more automated tools than a decade ago.
Nearly every process can be automated to a certain degree. This is great! Automation reduces the human factor, allows us to use time more efficiently, and costs less than a team of testers.
Unquestionably, you cannot substitute all of your testers with machines, but you can definitely add some diversity by implementing automation solutions.
There are specific test automation patterns that allow you to implement testing solutions seamlessly without harming your overall work flow. These patterns address pivotal points of testing:
- Processual issues
- Managerial issues
- Executional issues
Using time-tested patterns is one of the best ways to ensure that automation goes smoothly and actually improves your company and its products.
Patterns help you to organize the process, add efficient tools, make your testing more agile, and remove executional errors.
Automation is one of the foundations of modern agile testing. It is important to use computing force and the whole complement of your IT resources in order to maximize the team’s efficiency.
Various tools and solutions, stretch tasks, and creative testing activities—these are the facets of agile testing. Agile makes testing less redundant and boring, but still demands your employees to be responsible and productive.
Pillar #2. Keep up the diversity
Contemporary developers inarguably accept the fact that the team must be as diverse as possible. While your team will most likely specialize in some particular areas, keeping up the diversity is the surest way to establish a productive work flow.
The same goes for testing teams.
There are different kinds of testers and testware designers. Some love to use standardized frameworks and reliable all-around solutions, others prefer to craft intricate testware and innovate.
You need all kinds of people to ensure that your application receives enough attention from testers. A diverse team is less likely to fail at accomplishing a variety of tasks that demand specific skills.
- Case studying;
- Creating automations;
- Implementing patterns;
- Gathering and sorting data;
- Analytics and reports.
None of these tasks are by any means easy. They are redundant, time-consuming, demanding various skills, and they test the limits of your employees.
In order to ensure that your team can give enough constructive feedback and perform a plethora of testing activities, you simply must diversify it as much as possible.
Bring in external talent and never stop scouting for useful additions to the squad.
Pillar #3. Cohesive teams win the race
It is more than just important to create a team who will work as a unit. You need to focus on various teambuilding activities, teach your employees how to work together, etc.
However, even if you manage to build a squad of team players, it is not the end of the road. There is still a thorny path in front of you: now, you need to tangle together two teams who will work together—the team of developers and the team of testers.
Agile methodologies force us to build teams who can swarm tasks and exchange information. Communication is vital for an agile team.
Our learning experience, estimations, and improvements are based on the amount of information exchanged within the team. Such a case can be made for a bigger scale. Developers and testers need to work together, constantly learn from each other, and appreciate mutual feedback.
In essence, you need to create tight bonds within teams and between teams. How can one achieve the cohesion between functional units? Firstly, you need to ensure that those units are capable of working on their own.
Jaqueline Whitmore from Entrepreneur released a very simple article with a couple of suggestions for teambuilding activities. Start small and keep connecting your employees. Make sure that teams cooperate and hang out together at least sometimes.
Pillar #4. Standardization
Discipline is a child of dedication and abidance. Some teams don’t follow any guidelines, even project-level ones. They simply don’t have any.
This is a very bad approach that can point at systemic issues. A team needs to create guidelines and rules that everyone should follow. Such regulations should address not only the technical aspects of the project.
It’s very important to have rules regarding behavior within the team.
If your team can follow such guidelines, it will become more disciplined and therefore more productive. There’s nothing in this world that cannot be achieved through dedication and discipline.
As mentioned above, there are two core dimensions of regulations within a team that works on a project:
- Technological guidelines. Standards that every single developer follows. Amongst these standards, one can find common naming patterns, coding and design guidelines, etc. This study shows that on average only 58% of developers are informed about certain guidelines and follow them.
- Behavioral guidelines. Daily stand-ups, planning, sprint overviews, meetings, and even parties should be scheduled and have a set of rules to abide by. Without such regulations, a team quickly loses its efficiency.
Standardization is one the simplest yet most efficient ways to improve a team’s performance. A unit that performs testing activities needs to be properly supervised and perform up to expectations, never lagging behind the development.
This is barely achievable without strict regulations and specified guidelines.
Another important part of this “pillar” is the need for identification and clarification. A truly agile testing team will form a set of regulations naturally due to redundancy of its work flow.
However, it doesn’t mean that you should just leave the team be and allow them to slowly grind their way towards a comfortable and efficient set of guidelines.
Take an active stance and work together with the team in order to identify and clarify the most important ambiguities that need to be removed.
Pillar #5. Review process is a pivotal part of your success
Reviewing is a weighty element of agile methodologies. Without proper reviews, the team loses its ability to evaluate and estimate, thus failing to identify the project’s goals.
Testing requires the same amount of reviewing as any other part of development. We need to evaluate the efficiency of testing and estimate our goals for the next sprint.
Reviewing also helps to pinpoint process-related issues and to evaluate how well we are using specific automation solutions.
This is a crucial aspect of agile testing.
There are specific review techniques that make sense for a testing team. Obvious examples are peer reviews, walkthroughs, and inspections.
Peer review is one of the most productive review methods. The theory behind it states that one’s peers can objectively evaluate the amount of work done and rate it using certain criteria.
Sometimes, testing reviews can be voided, but in most cases the complexity of the project will force the team to commit to heavy reviewing.
Depending on the type of product you are developing, you will benefit more or less from proper reviews. Some examples of situations that require reviews are:
- If there are regulatory requirements that you need to consider. Such requirements are Food and Drug Administration or Security Administration. You will be required by law to hold a review process.
- If your stakeholders want to actively participate in the development process (demos/iteration reviews) or want to ensure that the quality of the product is being assured (all-hands demos).
- If you want to double-check your strategy. Try to briefly evaluate your team’s work and achieved milestones. Use performance metrics.
- If you need to evaluate contributions from different team members. This is especially important when you avoid non-solo development methods.
Holding reviews can help in improving the team’s productivity and ensuring that your testers understand project goals.
It is very important to show your employees the big picture. Some redundant testing activities may seem unnecessary or insignificant if taken out of context.
Pillar #6. Do not forget about refactoring
Refactoring holds the essence of discipline inside. This is the most important agile technique to master.
While we try to avoid redundancy in agile management, this part is detrimental to the success of the project, just like adding new features and functionality is. Refactoring should be done in a very disciplined manner. When you need to change one instance of the code (Rename Method), you will have to refactor all other instances of the code affected by this change.
This is a boring and redundant process that needs to be done without mistakes and as quickly as possible.
Refactoring is a great technique for both testers and developers. While the former need to understand this agile method and its importance, the latter must follow its guidelines and perform all necessary tasks within a reasonable timeframe.
Testers providing feedback and searching for code errors should give feedback and report with refactoring in mind. At the same time, your developers need to understand clearly that adding new features and functionality is often impossible without the preceding refactoring.
Pillar #7. Static and dynamic code analysis
This is another strictly technical aspect of agile management. There are some development practices that are characteristic for the industry in general, but need to be highlighted when discussing agile methods in particular.
Code analysis is certainly one such practice.
Agile teams often consist of remote employees. Additionally, some projects require walls of code to be written. Both these factors contribute to the demand for static and dynamic code analysis. You need to make sure that code pieces written by team members working in isolation are compatible with the rest of the project.
At the same time, ensuring that the code is robust and has no errors is a pivotal part of the quality assurance process.
- Static code analysis refers to a process of searching for defects and errors in the code, focusing on obvious spelling and style errors as well as security-related issues.
- Dynamic code analysis is a more complicated process that checks the execution part of the code and ensures its stability.
Both code analysis methods are important and should never be ignored by agile teams who want to be efficient.
This complements our statement about the necessity of team’s versatility. Some testers may be more skilled in reading and checking code, others may not be up to the task.
Agile testing is an integral part of agile development. If you truly want to create high quality products, you need to tangle together testers and developers and force them to cooperate and exchange information in a truly agile fashion.
You need to consider both managerial and technological aspects of project management to be able to do so.
Check out our related articles: