Updated: Mar 2, 2022
In this article, I want to share a story of mine that happened almost a decade ago but is still relevant today to the Agile team mindset related to testing as an integral part of the Agile team activities. So, back then, when I was a tester, I worked in different teams, most of which were built from groups of 5-6 developers and a single tester. Now, while most of the teams thought that testing activities should mainly be conducted by the tester of the team (What is changed since then 😊), there was one team that made it all different when it comes to the quality mindset and testing in particular.
So as the only tester in this team, I worked with developers who value testing and treat it as an integral part of the development cycle. I can’t forget the first planning meeting when we, as a team discussing one of the features that we were about to deliver at the end of the sprint, and suddenly one of our developers addressed me asking, “Yeah, but how are we going to test it?” As a result, we started a team conversation where each shared his thoughts, causing them to change the whole design.
I think that this was one of the critical points in my career. It was the first time I saw an Agile team that understood that testing is a team activity and not exclusivity belongs to its tester (similar to what I used to see in other teams). The crucial part in this meeting wasn’t the team asking me, the tester, how I intended to test the feature. It was a question asked of the whole team: “How are we as a team going to test it” How can we develop and test this so that we as a team have the confidence that it will work once delivered to the customer?”.
In this team and as part of any new feature development, the developers would always participate in the testing activities. They write everything from unit tests to E2E tests, including doing some manual testing before it was passed to me for testing in testing environments.
With this mindset and the mindset that we are all responsible for testing our deliverables, it comes to the point that by the time it was handed to me after the testing effort done by my associates, I rarely found defects on main flows or defects that were due to carelessness (as I used to see in my previous teams). Most of the defects I encountered were due to complex scenarios related to E2E tests that hadn’t been thought of earlier.
So you might think, as a tester, did I have much to do on a team like this? Yes, and a lot! I had many ways to contribute to the team, starting from the overall system knowledge that contributed to the team in all the different phases involved in software development. In addition, I had the most valuable asset in the team, which is the way I thought about the product from a user standpoint. The defects I found were that my product knowledge and testing expertise became less valuable at the end of the iteration and much more valuable at the start (as, again, it was precisely the opposite in my previous teams).
Then I realized that in a team with this mindset, the more effort I put into testing the product conceptually at the start of the iteration, the less effort I had to put into manually testing the product at the end because the quality was excellent and fewer defects would emerge as a result. But the crucial part of this was that I had the confidence and trust in my developers doing their part and testing the product effectively by thinking about testing, writing tests, and manually testing as the product was being developed. I was so confident in my team that if we had thought of a scenario during planning, it would be effectively developed and tested with a complete set of automated tests by the end of the process.
Now that I shared my story focusing on my experience as a tester, it's time to start thinking about the role of a software Developer in the current industry, which is moving very fast and demands much more than just coding skills. A software developer needs to build a product with confidence that it does what it's expected to do. It cannot be done without the basic understanding that testing is integral to development. For that reason, we need to change the narrative of testers and developers and focus on more testing in software development. And it needs to be also done by the people who are building the product.
Having a tester or a testing specialist on the team is a valuable asset. Still, the responsibility for testing shouldn’t be restricted to a single person but a collaborative team effort. The tester can help with the complexity of testing issues that may arise, simply knowing that the rest of the team can deal with the simple testing problems.