I remember the times when test teams sat in their own area and we were not allowed to “bother” developers.
We sat there idly waiting for code hand-off. We only tested through the GUI. We worked all week and had meetings half of each Friday, to review status reports, metrics and bug reports. One day a week was “build day” and everyone ran around getting all kinds of various tasks done: qualifying the build, smoke test, verifying bug fixes, and combing the build notes for feature changes. To some people— this may seem strange. Times have changed. A lot! It was actually not too long ago this was common and, most importantly, there are still organizations like this.
Testing— as has all development— been revolutionized. Even calling people “Testers” has changed. The team name QA/Quality Assurance is practically non-existent any more. The whole team has responsibility for quality, not one group. And that group certainly does not promise or guarantee anything! They run tests, they don’t promise quality.
The idea of testers being not part of development is outdated as well. People who test are in the middle of software development— not on the outside. An often cited example, now 12 years old, is when Microsoft stopped having Test Engineers and had a new role of Software Development Engineer in Test (SDET). For more information on that transition, find the details at MSDN blogs. What is important to me here for this issue, is the declaration that people who run tests help design the software product. It’s not only POs, Bas, Programmers, or Marketing.
Testers contribute to product design and help specify how a feature will work and what will be blocked or throw error messages. In many teams today, test teams are the ones most responsible for adding acceptance criteria to user stories so they are essentially ironing out the deep details of how a feature will work.
Now, instead of waiting for handoff, we are in the middle of designing and testing it.
No longer outcasts, and now, right at the center. This is a great modernization.
With so much changed today, and working together on smaller teams with more collaboration, there is more distributed ownership of testing. Many teams stopped writing test plans. Most teams stopped writing test plans— so they stopped planning testing projects. Bugs were missed and technical debt builds up.
In my consulting practice, I go to many companies each year and evaluate, recommend practices, implement, and coach. We get a bit biased in Silicon Valley that everyone develops “like us.” Also, in research and writing about software development today, we rarely hear from teams anywhere but at the cutting edge.
Regardless of where you are on the spectrum of your software test practice, there are some basic skills and practices in testing that use to get more attention in those old days. Some teams today either don’t know how to perform or even get help with basic practices. We are here to help.
This issue of LogiGear Magazine is focused on the essentials of a testing practice. Whether the testing is done by developers, traditional testers, customers, or product owners, these are the basics of communication in testing that everyone needs to know. But as with everything in development today, these things are done differently than they were just 10 years ago.
In this issue, we will cover everything from writing modern test plans, and writing great bug reports. Blogger of the Month, Thanh Huynh discusses 3 simple reasons why your bug reports suck, and how to fix them. Zephyr’s Sanjay Zaldivia discusses distinguishing the differences between smoke and sanity testing in this exclusive article. Leader’s Pulse is Part 2 of Managing the Knowledge Worker, and this issue of TestArchitect Corner shows how you can use TestArchitect for API testing for SOAP and REST Web Services— without a single line of code. Catch Minh Ngo and Thong Nguyen discuss the latest release of Selenium in “Selenium 3.0”. We also have two cool infographics exploring the evolution of software testing, and we review ten things QA teams should know about testing.
Thanks for reading. Good luck! Learn and share skills across your team!
