Why Can’t Programmers Test & What Can You Do About It
In the Webinar we will review:
- Why are developers bad testers?
- How can you help your developers test better?
- When and how to involve developers in your testingefforts
- Open Questions and Answers.
*For those of you who prefer to read through we present the following summary.
How To Include Developers in Your Testing Strategy
As we start moving more into agile processes, and DevOps approaches we are compelled to start adding developers into our testing projects and into our testing tasks.
This is not something that has come out of thin air. It's a process that has been evolving even as long as 20 years ago, when we were having issues towards the end of the project, where our managers used to say, “Hey, you know, when you have a bunch of developers doing nothing, why don't you go and add them to your testing projects.”
So as including developers becomes more common, the issue becomes how to accomplish this in an efficient and effective way.
Overcoming misconceptions
The first thing we need to do in order to start talking about this topic, is to debunk a fact that sits very tightly in most people's minds, and that is the misconception that developers simply cannot test.
In order to start debunking these myths, if we want to? then we can understand a couple of things:
Testing isn’t rocket science.
Developers do not need to go over hundreds of hours of training in order to become good testers. Indeed, they do need to be taught, and they need to develop their skills but it's very far from being rocket science. And, given that most of our development peers are actually quite intelligent people, they certainly can be taught how to test.
Developers are already testing.
As the State of Testing reports continously show, a significant amount of testing is actually already being done by “non-testers” in the organization. As we shift more to DevOps, and teams start adopting agile correctly, we will see more non testers/developers doing testing, and we will need to start working with them in order to do it correctly.
Why do people traditionally think that developers cannot test?
This stems from some main differences between how developers think and work compared to how testers work and think.
1. The work of a developer focuses on the positive scenario.
A developer will look into a feature and will mostly be focused on how they create the positive scenario for what they want to achieve. How can we perform a specific feature? How can we do something in a positive way? This is the opposite case for testers, who continually seek and explore the negative scenarios.
2. The work of a developer is based on taking a very complex problem, and breaking it down into very small and simple units of solutions.
For instance, when needing to create a new graph that will provide this and that information, a developer will take this complex problem and basically break it down into small areas of pieces of information, or sub processes that will help them actually come to the solution.
While the work of a tester is the complete opposite of that. Whenever we look into a feature, the question that we're looking into is “how can it be more complex” in order to actually find the areas where the solution will actually not ? or where it will break?
3. Functionality vs. user experience
In general, developers are concentrated on how to develop the functionality that will comply with the requirements they have been given. Whereas a tester will always start by looking from the user’s perspective, trying to understand behavior, and testing whether that will match up with the functionality.
4. Developers claim they do not know how to test
We often hear such statements from developers themselves. And you know what? they are right. If you're not a trained tester, you will be able to run part of the scenarios, but you won't be able to test effectively. But more on that further down the page...
5. Developers believe they have more important things to do
If that is their approach from the beginning, then indeed they won't be able to test. Because if you think that you're basically wasting your time doing the operation that you're doing, you will not do it thoroughly, you will try to just get it done quickly. And you will not invest the time or the effort in order to do it.
Getting developers to test
Whenever we start working with developers on how to test we'll try to first understand where they are coming from. Perhaps they have some intrinsic issues that we need to work with. We must recognize which one of these points mentioned above might be affecting their own perception of the task.
So if we already know why developers cannot or maybe do not want to test, then how can we actually go about and help them to do it better?
Get management on board
Regardless if a developer wants to test or sees the importance of her testing, or even if they don't want to test, the first point is that unless you get management to push for developers to test, it simply won't happen. Once you have backing from management, and everyone on the team understands that testing is part of everyone’s responsibility, you can start helping non-testers to test better.
Pair Testing
Pair testing is recommended whenever you're starting to work with developers on how to test. Pair testing should be applied for test execution as well as test planning, issue reporting and so on. Once they see exactly how you do it they will be able to ask questions and basically get more information out of it.
In support of pair testing it is helpful to create checklists, and heuristics listed out for developers to follow. The more information to offer guidance the better. Be sure to make the information accessible and not hidden in a folder somewhere, and even suggest to them how they should apply it.
Review sessions
When a non-tester is about to start testing, make sure to assign time for a pre briefing, where the developer can review what you're going to be doing. And after they're done testing, do a post review session of what they did. If they find something, look into that, ask them what they tested, try to bring up ideas of stuff that should have been tested and they might have missed.
When you do review sessions, just as when you're doing pairwise testing, these are lessons that are easier to catch and to absorb than if you do it on a theoretical basis. It is also important to give feedback immediately after they're done testing, as it will be easier for them to correct how they're working moving forward.
As mentioned, often one of the biggest issues is that developers do not really understand the customer. So it's very important to make sure that your review includes the user needs the user background, anything that for them might not be trivial, and it might affect their testing, it's very important for you to not take it for granted, and try to review it with them all the time.
Cross testing
When having developers involved in testing, it is best to not have the developer test the code they created, but rather have them test something someone else developed. This allows for a fresh perspective when testing.
There are two main reasons for this. Firstly, developers subconsciously have parental feelings towards their work. Basically, that means that when they're looking into the stuff that they're doing, they already made all sorts of decisions, they already feel responsible, so it's going to be harder for them to look for issues, especially if you're talking about logical issues.
Secondly, there’s an inattentional blindness when working on something for so long, that even if there's something that is buggy, we’d be blind to it. So we should have a separate person basically validating.
Accommodate your developers
Make a formal effort to try to focus developers on the type of testing that is best suited for them. For example, any type of automation or instrumentation, having to go over logs of information, and generating all sorts of alerts, these might be things that are easier for a developer to take over. The key is to look into the developer's strong points.
Be prepared
Make sure that all your user stories include testing risks, and complete user scenarios, both positive as well as negative scenarios. So whenever we give these user stories to a developer, it will be easier for them to understand and test just like you would have.
Create environments with high realistic data that will be able to provide developers with a realistic environment to find those bugs that they're looking for. This includes making sure your system integrations and reporting run smoothly.
Creating accountability
It's not only about trusting your developers, it is to make sure that whenever they are running their tasks, you will have full visibility into that. And with visibility comes accountability. If everyone sees who's doing what, they will be motivated to complete tasks because their team is counting on me.
It's also very important to have the correct dashboards to reflect everyone's work. That is one of the reasons we at PractiTest have given deep thought and planning into our dashboards and reports. We believe that there must be accountability and visibility embedded into the testing process, regardless of who does the testing. By adding dashboards that show the different tests that people need to run and different requirements that are assigned to people and even the bugs that are assigned to people, we can generate that visibility and better accountability.
Summary
Developers want and can help with testing. And while testing has had a bad reputation in the developer community, we can see this slowly changing as more developers take part in testing tasks.
It's not that developers cannot test but management needs to back the effort.
Every new tester, including developers will need training and guidance. Take the time to pair test with them, have the preparations in place in order to help them with checklists and heuristics that will make their lives easier and their test a lot better. Make sure that you have all your infrastructure as well. It's very cost effective to have good environments, so they can deploy whenever they need to. There will be pitfalls, so make sure that you know about those pitfalls upfront and then you'll be ready to correct them. And be patient.
