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!