I recently purchased the book Agile Testing by Lisa Crispin and Janet Gregory. It's been on my reading list for a long time, and with my recent focus on testing, I decided to begin reading it. I'm about 15% into the book, and it's already becoming one of my favorite software testing resources out there. I highly recommend it to anyone involved in an agile environment at work, regardless of your current position or specialty.
One of the reasons I wanted to read this book is due to some organizational changes my current workplace is going through. Earlier this year, we began to focus more on test automation by integrating more robust testing practices into our workflow. Some of the main changes have been implementing end-to-end tests for our projects and more checkpoints for running those tests earlier in the pipeline.
Most of our teams integrated some agile software development methodologies, like one- or two-week sprints. However, our testing procedures were very traditional. Developers handled most of the automation via unit and functional tests to a certain point. The QA team dealt with the rest in a manual fashion. The organization treated QA as a separate entity, and interactions between the team weren't as effective as the organization wanted.
To manage this better, the organization decided on adopting a "whole team" approach to our project teams. It's been the most significant change during this transitional period.
Everyone is responsible for delivering quality
The "whole team" approach means that everyone on a software team - from planning to development to testing to deploying - is responsible for providing a quality product. You no longer have distinct, separate responsibilities for each phase. Everyone can be and should be involved in everything.
That doesn't mean that product managers will suddenly have coding tasks or developers focus strictly on QA. It means that team members should get involved in the entire process. Everyone has unique strengths, and different perspectives, and often those viewpoints provide a ton of value to a product.
Adopting agile methodologies such as the "whole team" approach can do wonders with any organization. It allows team members to self-organize, deliver quality software at a faster pace, and handle potential problems without letting them linger on forever. When done right with a team that embraces these changes, agile software development is the real deal.
Expect a rough, bumpy road ahead
It's not all sunshine and rainbows, however. Adopting these practices can also cause lots of problems within the organization and its team members. It's understandable since often these changes drastically change the way teams work. But other times, the friction is caused by unclear expectations, like team members not knowing exactly how their role will change.
Every team adopting a new set of practices will experience rough patches. In my professional experience, one of the areas of most conflict that I've experienced during one of these transitional phases is getting everyone on board with the "whole team" approach. And it seems that testers are one of the most affected by these changes.
One of the reasons is that in a more traditional QA setting, testing occurs as a discrete step of the entire software development cycle. It also usually occurs at the very end of the cycle, when everyone is almost guaranteed to be stressed out with trying to deliver on time. It's one of the least-ideal times to have stable communication within team members.
Separate QA teams also rarely communicate with other groups of the project team. They may talk to developers, but often it's through a bug tracker or some other form of electronic communication with little face-to-face. It's also extremely rare to have testers in this kind of environment talking with non-techies like product people and customers.
It's no wonder that integrating testers into a broader team is a pretty big shock. Their roles are changing drastically, and communication is expected to be frequent and fluid. For some, it's not an easy task to partake. It's a stressful and confusing time, but more for testers because of the changes they have to make.
I've recently dealt with a transition like this that hasn't gone too smoothly. One of the test engineers had been spearheading our initial push towards better automation testing with the rest of the QA team. When the organization adopted the "whole team" approach, he suddenly found himself closer to a software engineering role. I've been helping coach him in this area, but it was apparent to me that the transition was more jarring to him than the rest of the team.
There are many ways to handle this type of friction, depending on your team. There's no "one size fits all" approach. But I've found a few ways that will help you successfully transition testers to an agile software development process.
1) Ease testers into the process
One of the benefits of agile software development is that it often provides lots of freedom to the members of the team. Instead of having isolated groups, each with their agendas and having to answer to each other, teams have the liberty to organize things how they think is best for the project.
When transitioning to agile, though, it's not as simple as it sounds. Many team members will not have interacted much with other groups. They won't know what's the best way to proceed and will lack the trust necessary to self-organize effectively.
The main issue is that each team's old way of thinking will remain intact for a while. That means everyone continues working on their specialty and focus area, instead of integrating with the rest of the team. It takes a while for them to shake this mentality.
Every group has its main focus areas. For instance, developers mainly focus on churning out features or fixing bugs as quickly as possible. For testers, their focus is on quality. These two mindsets will inevitably clash when they have to co-exist. Generally, it manifests itself by turning testers into the so-called "Quality Police," where they feel the need to impose their mindset to the rest of the team at all costs.
Everyone wants to put out a quality product, but in the real world, it's often unreasonable. We don't live in a perfect world, and not everything can be bug-free from day one. We also can't drop our work to focus on quality the entire time solely. Software development is a balancing act between good, fast, and cheap.
To combat this, the best way I've seen is to ease the testing team into agile processes instead of doing a full integration from the beginning. Start with few testers to join the rest of the group and have them serve as an intermediary of sorts between development and testing. It will give both developers and testers a start to work with each other without having the entire team trying to figure their way through the changes.
As the organization transitions more deeply into the new processes, introduce more testers to the process until everyone is comfortable. Give them enough rope to do their jobs freely, but someone still needs to keep an eye out in case someone's good intentions become a hindrance to the operation.
One of the biggest mistakes I've seen teams make when adopting any new procedure is to have everyone jump into the deep end of the pool head-first. If you test the waters for a while, it becomes less stressful for everyone involved.
2) Pair testers with developers
As mentioned above, testers working in a traditional setting (like the Waterfall Model) often work on their own. Their work is usually given to them before they're scheduled to begin their testing duties, which kick in towards the end of a long development cycle.
This process means that the only interaction testers have with the rest of the team is often during this period. And it's the worst possible moment because no one has time to do anything. Testers will barely have enough time to run tests, and developers have to deal with bug reports and things they have to fix. The stress levels are through the roof.
Under agile practices, testers need to keep their finger on the pulse of the project's development. Not only do they need to know what the team is currently working on, but they also need to be in constant contact with everyone else to ensure that they're testing what matters for the current iteration.
The best way to have the team communicating effectively is to pair with their work often. It gets different team members who otherwise wouldn't spend much time talking to share their knowledge and tackle problems together.
The main benefit of pairing in this scenario has different disciplines seeing the value each side provides. It increases trust and confidence - both of which are essential if you want a successful project.
Scheduling pairing sessions is up to each team and each member. However, it's best to pair team members with different strengths to maximize the session. Usually, people want to pair with someone who has similar skills (like a developer with another developer). This type of pairing works, but it won't serve the long term purpose of improving communication between distinct groups.
For instance, pairing a developer and a tester is a great way to help the team. They can cycle the focus of their sessions. For one session, the developer can work on coding a new feature while the tester observes and provides input from a testing perspective. Then in the next meeting, the tester can teach how to build automated tests for that feature. Both members can see the value the other party provides, which is what you'd want in your organization.
If your organization isn't accustomed to doing much pair programming, it may feel like it's unnecessary. It might feel like a complete waste of time, or that it will slow down the work of each team member. Those are valid concerns, especially when pairing for the first time. But in the long run, the benefits of increased communication are worth any initial hits in productivity.
3) Always have a tester present at meetings
It's an unfortunate fact that some organizations don't place testers in the same ranks as a product engineer or developers. Depending on the team, they will relegate testers to second-class citizen status, separate from the rest of the team in the perceived value they provide.
Due to this inaccurate labeling, it's no surprise that testers are often kept entirely out of the loop in essential discussions. It's not rare that technical meetings consist of exactly zero testers, and testers don't get a say in important discussions for the project.
Even when a team adopts agile practices, this behavior can persist. Usually, teams need some time to adjust to the "whole team" approach. Testers might not feel like they need to be a part of these meaningful discussions, or the rest of the team doesn't view them as "technical enough" to contribute.
That's a big mistake many teams make. Even if testers aren't planning new features or directly implementing them, their perspective is different from
In Agile Testing, the authors talk about the "Power of Three." It's a concept to explain that discussions in agile projects should occur with team members representing business, development, and testing. It's also known as the "Three Amigos."
The "Power of Three" is incredibly useful for agile projects due to each side's perspective. The business side focuses on what the project is trying to solve. Development can think about the implementation of the business problems. Testing complements both sides, providing their thoughts on potential pitfalls.
Covering multiple angles of the same issues provides different points of view that other groups never thought about before. It reduces the risks of unforeseen problems. The added perspective of a tester can save lots of time and headaches by raising questions as early as possible. Having testers more involved in these discussions will help others in the testing team be in the loop.
Each team should have a rule in place to ensure that at least one tester is involved in all project discussions. It doesn't matter if developers think it's "too technical" or product people believe there's nothing to talk about when it comes to testing. Different viewpoints will help build a better product in the end.
Summary: Don't keep your testers separate
Many problems that occur when a team adopts agile methodologies are continuing to treat different roles as their separate entity. It's especially true with testers, who are often left in their own silo with little to no communication. They usually have the most struggles when transitioning to agile processes.
Embrace agile practices by integrating everyone in a "whole team" approach. You can't have a project team split up into groups. The team needs to have constant communication with everyone, regardless of their tasks. Everyone should have the power to contribute in any way they see fit.
To make the transition smoother, you can follow a few tips to help testers adapt to the "whole team" approach.
Testers should ease into the process instead of pushing them into the deep end from the get-go. Integrate a few testers into the process at first, serving as an intermediary with the rest of the testing team. It helps bridge the gap between testing, development, and product on a smaller scale. Eventually, integrate the rest of the testing team when the level of comfort increases.
Pairing testers with other team members diminishes the communication barrier between disciplines. Having developers and testers pairing on their tasks spreads knowledge and increases trust. It may be slow in the beginning, but the payoff in improved communication is worth it.
Never have a meeting without a tester present. It will highlight blind spots others have in the planning and development sides and keep them in the loop so they can do their job well. Even if the rest of the meeting participants don't think testers will have much to contribute, their perspective is invaluable.
Changing organizational processes can be rough, especially during the initial transition periods. With a little planning and collaboration, you'll have a lean team doing quality work faster than you ever imagined.
Have you worked on agile teams? What problems have you encountered as a tester? Write your experiences below and help fellow testers if they're going through similar rough patches!
Photo credit: David Travis on Unsplash
