Letter from the Editor

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!

 

Michael Hackett

Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006).
He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

Michael Hackett
Michael is a co-founder of LogiGear Corporation, and has over two decades of experience in software engineering in banking, securities, healthcare and consumer electronics. Michael is a Certified Scrum Master and has co-authored two books on software testing. Testing Applications on the Web: Test Planning for Mobile and Internet-Based Systems (Wiley, 2nd ed. 2003), and Global Software Test Automation (Happy About Publishing, 2006). He is a founding member of the Board of Advisors at the University of California Berkeley Extension and has taught for the Certificate in Software Quality Engineering and Management at the University of California Santa Cruz Extension. As a member of IEEE, his training courses have brought Silicon Valley testing expertise to over 16 countries. Michael holds a Bachelor of Science in Engineering from Carnegie Mellon University.

The Related Post

Test automation is a big topic. There are so many different areas to talk about: tool choice, jumpstart, cross platform, services, cloud… Each of these areas have changed so much in the recent past that they could each be worth their own magazine issue.
Change is constant. What’s different today is the rate of change. Moore’s law resulted from the observation that that the rate of change in computing power is exponential. The products, services and software landscape appears just as dynamic. At the same time, we pretty much take for granted the ubiquitous presence of software running our ...
In every year since 2011, we have devoted one edition of our magazine to the topic of mobile testing. In this year’s issue on mobile, we focus on testing from the point of view of the user experience. Most teams start with UI testing, and it may seem basic — until you look at the ...
I led the Editor’s Note in our very first mobile issue with “Everything is mobile”, but it is now way beyond what we thought. Mobile has come to mean only the smart phone, mobility is the word that describes everything a smart phone enables you to do. Mobility is more than a device! Mobility is ...
Testing Embedded systems and testing the Internet of Things could each have their own issue of LogiGear magazine. But these days they are referred to presupposing knowledge of the other, so we thought it would be a good idea to tackle the two together in this issue to give a broad understanding of the landscape ...
Testing tools – very important, very often overlooked, and very often where mistakes are made. First, the most common mistake people make about tools is thinking tools are only about test automation! False. Automation tools are merely one type testing tool. We will try to balance this issue between test automation tools and other test ...
This is our third issue concerning topics of Continuous Delivery (CD) and DevOps with the inclusion of Continuous Testing. DevOps has been around for a while and I hope the period of buzz is over and companies moving towards building a development pipeline have begun their process, including changing their test strategies.
DevOps can be a big scary thing. Culture change, constant collaboration— whatever that means— a big new set of tools… it’s a lot. What most teams want is to have a smooth running software development pipeline. I have stopped using the phrase “DevOps,” and now I say “Continuous Delivery.” There are many reasons for this.
In the November 2011 issue: Mobile Application Testing, I began my column with the statement, “Everything is mobile.” One year later the statement is even more true. More devices, more platforms, more diversity, more apps. It boggles the mind how fast the landscape changes. Blackberry has been kicked to the curb by cooler and slicker ...
Methods and strategy have been my favorite topics since I started working in testing. It’s essentially engineering problem-solving. It’s both looking for efficiency and attempting to measure effectiveness. So, how do we develop a set of practices to solve our Software Testing engineering problems?
Continuous Testing… what is it? When we first decided to do a magazine issue dedicated to the DevOps practice of Continuous Testing, I joked with someone: “It’s about testing continuously.” And their reply was: “Yeah. What else would it be?” I was joking, but clearly the joke didn’t land. Continuous Testing is about testing continuously, ...
This is LogiGear magazine’s first issue on the big world of DevOps. DevOps is a very large topic. Just when you thought you were safe from more process improvement for a while—not so fast. There’s DevOps, Continuous Testing, Continuous Delivery and Continuous Deployment. In this issue, we are focusing on Continuous Testing, the part most ...

Leave a Reply

Your email address will not be published. Required fields are marked *

Stay in the loop with the lastest
software testing news

Subscribe