”Why are you bothering with tests that don’t work?”
I remember the incident distinctly, even though it took place several years ago at a company that no longer exists, while my team was building and testing a long forgotten product. I was reviewing a software test plan with a development team colleague as I wanted his input on the risks associated with a new feature. I described the functional tests that wanted to build for the feature, and then mentioned that we would in parallel be updating the product’s non-functional tests (such as performance and security tests) to take into account the new operation of the new feature. He looked confused and asked me,”Why are you bothering with tests that don’t work?” His question caught me off guard and when I asked him to explain, he said, “You’re talking about tests that won’t function. Why are you wasting time on those tests? They’re broken, right?”
At that point, I thought of George Bernard Shaw’s famous quote about the British and Americans being two peoples divided by a common language. In this case, however, the problem was two groups of people being divided by the lack of a common language. That being, the language of software testing.
Historically, Development and QE teams have been kept separate. The separation was based on the belief that the only way to have effective and unbiased testing of a product was through having an independent testing team. One of the rationales for this separation is that testing always includes an element of “creative destruction” and that is difficult for people to act in a destructive manner toward their own work.
In an agile development model, this artificial separation is done away with. The walls that divided development and test engineers are torn away broken and they work together as members of the same team, where the quality of the product created is owned by every member of the team. The transition to this model from a traditional waterfall development model can, however, be difficult. The problem is that people without a QE/test background will be asked to build and run tests when they may lack hands in experience in test development beyond building unit tests. The “test guys” (that is, the QE/test engineers) can help by providing guidance and coaching, but but that coaching can difficult because people new to testing will not have a frame of reference to build upon.
A Shared Language - And Two “Good Reads” for Anyone Building Software Tests
When you work in a technical field it’s easy to become totally absorbed in the technology and forget the importance of human communication and community. What makes a community? Shared values, shared goals, shared experiences, shared literature, and a shared language for software testing.
It’s winter here in Boston, which makes it a great time to sit down by the fire, or at least a video of a fire, and do some reading. There are a couple of resources that anyone new to testing should read:
The year 2019, marks the 40th anniversary of the original release of Glenford Myers’ book, The Art of Software Testing. It’s still my favorite software testing book. In this little book, Myers provides a practical, and very readable description of methodologies for software test design. Equivalence partitioning, boundary value analysis, it’s all there in The Art of Software Testing.
In its syllabus and glossary, just updated in 2018, the International Software Testing Qualifications Board (ISTQB, https://www.istqb.org) provides a detailed and systematic definition of software testing. Founded in 2002, the ISTQB has established standards and certifications for software testers. In their glossary and syllabus, the ISTQB painstakingly describes how to design, organize, execute, and report on the results of software testing.
Building effective software tests are not just for “the test guys” anymore. In an agile model, we all own and contribute to and execute tests to improve product quality. Doing some basic research by reading The Art of Software Testing and the ISTQB syllabus and glossary would make for a very useful New Years resolution for anyone wanting to learn learn the language of software testing and to create better tests. Happy 2019!
