I recently had the pleasure of attending CAST 2014, the annual conference of the Association for Software Testing, a conference that Tasktop sponsored. If you couldn’t attend the conference, you can watch some of the sessions and get some of the flavor of the conference in the comfort of your home or office via the Association for Software Testing’s YouTube channel.
I’m a proud Tasktopian and wore my Tasktop shirt every day. Since there were no areas reserved for sponsors, that was the only way folks could find me to ask about Tasktop and how we help testers … more on that later. This blog is really about the art and science of testing (which was the conference theme this year) and some of the other controversies that exist within the testing community.
In truth, the thing that’s interesting about CAST is the level to which there is active discourse on the controversies within the testing community. If you’re not immersed in that community, you may think it a very homogeneous discipline. It is far from that; it is LOADED with controversy and differing opinions.
There were many sessions on the central topic: “The Art and Science of Testing.” There are folks that believe that testing software is an extension of the liberal arts, heavy on the use of skills learned by studying psychology, sociology or philosophy… such as developing and using various heuristics. And there are practitioners who feel strongly that testing software is best left to those that have studied engineering or computer science… using the knowledge of how the application was constructed to approach the challenge of testing it. But that was the least of the controversy!
There was quite a bit of heated discussion around a software testing standard being proposed by ISO (the International Standards Organization) and IEEE (the Institute of Electrical and Electronics Engineers). ISO/IEC/IEEE 29119 proposes to define “an internationally-agreed to set of standards for software testing that can be used by any organization when performing any form of software testing.” But much of the conversation at CAST was firmly against this standard, as embodied by a petition to suspend the standard’s publication. It can be difficult to represent a consensus against a particular idea, but it seems that the fundamental concern is that the implementation of standards can easily create dogmatic adherence to a particular process. And the view of software testing as a definable process, flies in the face of the “context driven testing” school of thought. According to CDT, there are no particular best practices that fit every situation – what is required is the expertise of a professional software tester that can bring to bear the right techniques for each particular situation.
This controversy lead right into the discussion around automated testing: with some practitioners claiming that test automation signals a demise of the professional tester and some practitioners with more moderate views. The moderates propose that test automation has important applications, but agree that it is not a panacea. In particular, it’s no silver bullet for overcoming the challenges inherent in organizations seeking to increase the velocity of release cycles through Agile or DevOps initiatives.
One “controversy” that tends to be fairly universal no matter what practitioner-oriented conference I attend, is the schism between testers and developers.
To be honest I never understood the developer – tester antipathy. Everyone on the team has a common goal to deliver the right software, on-time, with the agreed-upon level of quality. As a developer, I never wanted to be viewed as the person who delivered “crap code.” I never checked in code late Friday night, enjoying my weekends, while others were left dealing with the fallout from a broken build. But more selfishly, I never wanted to be awakened in the middle of night to fix my broken code. I tested my code and helped my tester buddies, because to me they were an equal part of the team and, selfishly, the line of defense between me and a 3AM wake up call.
So, it actually gives me great joy that Tasktop helps bring developers and testers together by eliminating some of the tedium introduced because testers and developers use different tools to manage their work… making the little time they have to collaborate “face to face” even more productive and (gasp) enjoyable. The fact of the matter is, most testers DO use tools to manage their plans, test cases (when appropriate) and the defects they find. And these tools are often not the same tools that their dev colleagues use to triage, fix and report the status of defects. And the same is true for the development and management of requirements and user stories.
Tasktop Sync integrates these tools, allowing everyone to use their tool of choice, while collaborating on project artifacts. Moreover, Tasktop Sync can help testing teams turn their existing tools into the “single source of the truth” of project health. (To learn more, read the white paper).
There will never be a shortage of differing opinions among practitioners in software development and delivery. But presumably we’re all in agreement that working together to solve our mutual challenges HAS to be more effective than working at odds.