Thanks to PractiTest for providing us with this blog post:
Let’s start by reminding ourselves why we need to talk with developers about testing.
According to the 2022 State of Testing report by PractiTest and Tea-time with testers, 86% of organizations now report working in an Agile or Agile-like approach. Close to 40% of organizations are working in DevOps methodology. And while the more traditional Waterfall approach is still practiced at 17% of organizations, it continues to decline.
This means that the traditional testing roles and teams, as we used to know them, are gradually disappearing, and instead, testing is becoming the responsibility of an entire agile team that also includes developers. Hence, it is of no surprise that in 77% of organizations testing is executed by testers and non-testers alike.
This shift often encounters resistance from developers with various claims about lack of knowledge on how to test, being too busy to do so, the perception that it’s a waste of their expensive time, or simply lack of desire to do so.
In order to help you bring everyone on board with the concept of product quality being the team’s responsibility we have prepared a 5 steps guide to help you:
1. Communication
The business environment is no different than others: when it comes to human interaction, communication is the basis for a successful relationship. In order to get everyone on board, you need to start with making people understand that performing testing is not a punishment, but rather a contribution to the company’s bottom line, due to the ability to deliver faster with higher quality that will meet customers’ expectations. It requires executive sponsorship, to support the required change both in culture and in methodology.
Communication is a two-way channel, and as a result, it’s also about listening, understanding, and addressing the developers’ concerns. Pay close attention to the developers’ feedback and take it into account in order to maintain an open communication environment.
2. Coaching & Mentoring
One potential reason for people to object to a change, is their fear of dealing with the unknown and the concern of not excelling in their performance. That’s why we need to dedicate time and effort to guide developers with essential information about testing. We need to convey to developers that testing is not ‘simple’ work. We want them to understand the software testing process, implement test management platform usage, and so forth.
In addition, invest some time in short pre & post briefing sessions. These meetings should include the developer of the tested feature, the testing developer, and a product team member. By doing so, we will bring a better understanding and efficiency to the process.
3. Shift left
Adopting Agile and DevOps methodologies has also created a shift in what is tested and when. We see a major shift left with the introduction of Behavior Driven Development (BDD) support and Test-Driven Development (TDD).
- BDD/TDD are approaches that are focused on shift left. It aligns people and generates most of the tests before the testing is actually performed. Mistakenly, the common thinking is it’s used only for automation, but it can also be applied in manual testing.
- Testing as a part of the user story – this means that user stories should also include testing elements.
- Personas – a representation of the typical users that are going to make use of our development and their characteristics. For example, in an application that aims for the elderly, we need to think about them when creating the scenarios.
- Testing sessions during development – you can have pair testing and have sessions while features are being written. It doesn’t have to be completely built to be shifted left.
- Dashboard for unit/integration – include in your dashboard unit/integration test results like any other testing. This will place developers’ unit/integration tests at the same level as tests executed by testers.
- Stability – the features shouldn’t be stable only before the release, it should be stable all the time. It is very important, it signals developers that they are already testing if they open their eyes.
4. Other testing
Sometimes it is easier for developers to relate to testing which isn’t the main core of the functional testing. The easiest way to use the “other testing” is simply to ask the developers and use their own ideas. It’s significantly easier to implement your ideas instead of someone else’s. We can also use developers’ knowledge to improve our automation framework and make the testing process closer to their hearts.
Specialized testing is another great way to leverage our developers’ knowledge to contribute to the testing efforts. Testing types like security, chaos, and performance are simpler to developers than testers. Developers would have a strong motivation to execute those specific specialized tests.
5. Transparency & Visibility
This is extremely important, and yet, it is amazing to see how often this is left aside. Transparency and visibility have a massive added value when we involve different people in the process.
- End-to-end dashboards – if you are going to have multiple testing types such as unit tests, functional testing, and integration tests, you should have everything in the same place and give the same legitimacy to all tests. The moment you see that “my tests” are also included in the dashboards, that’s when you understand the importance of the tasks and your contribution to the mutual goal.
- Count every test I have – regardless of the type or complexity.
- Add testing to standups – a lot of time people do talk about testing in standups but we leave it to the last minute and don’t talk about challenges other than sharing ongoing activities.
- Celebrate achievements – even in testing, if we have a developer that found a show stopper it is important to celebrate that because it has a positive effect on the staff members.
- Testing retrospective – especially when a bug slipped and was found in production, it has a lot of value when we learn from it. Our victories and errors are equally important and valuable.
Summary
In conclusion, with most organizations working in an Agile or Agile-like environment, the software testing process is no longer exclusively assigned to testers, and other staff members like developers are taking part in the testing process. Developers have great expertise and in-depth knowledge that could substantially contribute to testing efforts. Therefore, you should follow the 5 steps mentioned above in order to effectively make them an integral part of the testing process.
Practitest is an exhibitor at EuroSTAR 2022.
Author
Joel Montvelisky, Co-Founder and Chief Solution Architect at PractiTest.
Joel has been in testing and QA since 1997, working as a tester, QA Manager and Director, and a Consultant for companies in Israel, the US and the EU. Joel is a Forbes council member, a blogger and is constantly imparting webinars on a number of testing and Quality Related topics. In addition, Joel is the founder and Chair of the OnlineTestConf, the co-founder of the State of Testing survey and report and a Director at the Association of Software Testing.