Empower your QA Team with Tests!

I have worked with a number of QA teams, usually internal teams in product organizations. I have also been lucky to work with some of the most talented and detail oriented people I have ever met on those teams. Of note one QA person made great short screencasts of bugs showing all of the recreation steps, which even included a voice over of the steps as they occur and included annotations. These were attached to bugs in our project tracker which were assigned to me. From those awesome and comprehensive screencasts I was able to make a failing acceptance test followed by some failing unit-tests (once the bug had been triaged), and I made them all pass in order to fix the bug. The question remains, we had an awesome and technical person finding bugs in my code, yet I was writing the tests. How awesome would it have been if the discoverer could have written the failing acceptance test?

Why are QA teams, who are so focussed on getting finding and eliminating bugs, not contributing back to our test-suite directly?

Are our testing-languages too opaque? Behavior Driven Development testing frameworks such as RSpec, Jasmine, Gikgo strive to make human-readable tests. Going even further are tools such as Cucumber, Spinach, and Turnip in the Ruby world which produce nice looking examples that a QA team could certainly write. Without knowing too much about development in the large our QA folks could certainly move from writing ‘examples’ to writing ‘steps’ as well. The tools may be somewhat opaque but they are certainly tractable.

Are we hiring non-developers who are not interesting in programming? Why do think only “developers” can program? There is a greater and greater interest in “softer”-skilled developers as evidenced by the rapid growth of Digital Humanities as a discipline. Our QA folks already show the interest in understanding the business domain. There is already a focus on automating those test suites in systems like Selenium. Let’s empower them to learn enough code to write tests that fail which developers can make pass. Just as “DevOps” combines programming and operations skills to reduce the distance between the two disciplines maybe we need “DevQA” in order to maximally empower our QA teams. I think what we really want to make sure our QA teams get to click less in the future in order to make sure that regression stays gone.

What else can we do to help our QA teams help us and reduce the overhead of fixing bugs and making sure they stay squashed?

Have something to contribute? Open an Issue on Github and let's have a chat!