I read a question on one of the software testing subreddits a few weeks ago. The company this person worked for had a process where developers were responsible for writing very detailed test procedures, along with annotated screenshots. Those procedures, and all of the supplemental screenshots and videos, were then passed to someone on a testing team to perform. The testers were expected to walk through the steps, follow the instructions, and report back on what they found. The developers complaint, the reason for the reddit post, was that this process took too long. They were looking for tips that would allow them to continue creating detailed procedures to hand-off, but get through it much faster. This isn’t a lone occurrence, there are plenty of companies that still view testing groups as people to run procedures and nothing more.
I want to talk about my experience in moving from this servant model to one of service and collaboration.
Get TestRail FREE for 30 days!
Demonstrate Skill
Companies get into this situation when they don’t view testing as a skilled activity, or they just don’t think their testers are very good. I was talking to a designer at one of my first jobs. He made a comment that I found so many more problems than other people, and he didn’t get it because we were all just “clicking around”. He wasn’t trying to be a jerk, he just didn’t know anything about testing. I asked him how he managed to make such pretty software. Wasn’t he just dragging boxes around on a page?
One simple way to perform testing is to take a specification or user story, and then make each line into a set of test cases. There would be at least one for the scenario that is described in the spec, and then another for the scenario that would fail. After going through the specification, you end up with a discrete list of things to do. Run through the list, and testing is done. That is how many people are expected to test. That is exactly was expected of me from several employers.
Quietly, a few of us started expanding the testing work we were doing. Testing, for us, shifted from a set of steps to some guided and open-ended questions about the software. For example, I was working at a company that made software for behavioral health facilities. The medical staff at these places would use our software to document information about their patients, which helped them get federal and state grants so they could stay open and keep helping people. One sprint, we were working on a report that returned some demographic information about patients. The people using this report would search based on a range of birth dates. These date fields were implemented as text fields per the specification. They took dates, typed in by a user, in a mm/dd/yyyy format . Anything other than that threw an error complaining about format. I also noticed that there was no restriction on having the report start date be before the end date. The software was completely within spec, but it was terrible.
The implementation was bad, despite what our spec requested, but describing the problem was simple. We had similar reports throughout the application. Most of the time, when date fields were used, there was a date picker of some sort and javascript validation to ensure the user didn’t set an end date that came before the start date. I reported my observation of the date fields in the new report, and listed other reports that used date pickers instead of text fields. Getting this change required the convergence of being frustrated and thinking about that, researching other parts of the application, thinking about usability, and presenting a convincing argument.
Demonstrating skill is the best way to battle peoples idea that testing is just performing steps in a checklist.
Communicate Effectively
Testing beyond a specification, or any sort of documentation, puts us in a tricky situation. If the one source of truth is a specification, then people don’t tend to care about bugs that can’t be traced back to that document. Changing to a more effective test approach has to happen in tandem with learning how to communicate with the technical team in a way they will appreciate.
Think about the worst bug reports you have seen. They probably start with “submit cart page is broken” or even worse “submit cart page is broken and why is this developer so bad at their job”. Both of these reports are useless. One because it is not descriptive, and the other because it is not descriptive compounded with being jerky. My bug reports started something like the first example and shifted over time.
Today, when it’s possible, I like to talk to the developer. If I can only get them on IM, I’ll describe the problem I am seeing, show them any relevant logs, and maybe a video recording to really make things clear. Sometimes they would say “hang on a second…” and then come back a few minutes later with a new build and ask me to redeploy and try again. Sometimes, they know about the problem and already have it on their TODO list. Sometimes they are busy at the moment and will ask me to just write it up in the bug tracking system and assign it to them so they can look later.
When I am in the same office as the developers, I’ll go by their desk. If they are not busy, I can demonstrate the problem in their development environment. This gives some added context because the developer can reproduce the problem themselves and and be able to compare it to the code they are currently running (which is probably different from whatever I was running).
Reporting problems is a skill driven by context. A good report shows that you understand the problem and can talk about it coherently, that you know who you are talking to and what information they value, and that you can get the timing right.
This isn’t about bug reporting, though. That subject is just a convenient way to approach communication. Communicating what you know as a tester means developing social skills. For example, when I was reporting those bugs directly to developers, I had to get the timing right. Are they too busy or focused on something else? Are they having a good day and feeling receptive, or a bad day that I would be making worse by bringing throwing another problem into the mix. Do they have a meeting in 5 minutes they are trying to get ready for or are they thinking about what to do for lunch. I have to read the person I am talking with and be able to figure out if I should be speaking with them right now. And that is just getting started.
Communicating effectively means getting information in your head to another person so that they understand what you are saying and why. Just like software testing, it’s a skill that can be developed and improved upon. I won a useful amount of respect, and some friends, in the process of learning how to talk to people on technical teams.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
Putting it Together
Testers are treated like a commodity when people don’t understand their skill, and when they aren’t able to talk about what they do in a meaningful way. This is one of the many reasons for the rise of outsourced testing work in the past 15 years.
Demonstrating your skill in testing, and being able to communicate it in a way that people care about can change a team’s view from testing as a servant role to a useful and valued service. How have you made this change?
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
