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

This is a very special issue of LogiGear Magazine. When we were putting together the Editorial Calendar for this year, we decided that instead of a technology issue, we would focus on the human side of quality and test engineering. We want to focus on individual Test Engineers and their jobs. We talked to a ...
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.
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 ...
If you are reading this issue, you are probably aware of the impact on the business world of cloud computing. Most people do not have a good grasp on what the cloud is or how people and products can use it. BTW, you are already a cloud user. If your email is stored somewhere “on ...
Hello everyone – I’m hoping each one of us is having a great October. This time of the year is always my favorite, with the changing of the seasons, Fall was always my favorite time of year; it signified change and renewal – but I don’t want to digress to much from what’s going on ...
For everyone still celebrating holidays: Happy Lunar New Year! At this time of the year many teams and companies are starting new projects, new initiatives, and hiring new staff. LogiGear Magazine will continue to be the resource for you for better testing with much less stress! We are excited about the focus of this month’s ...
Big and complex testing. What do these terms conjure up in your mind? When we added this topic to the editorial calendar, I had the notion that we might illustrate some large or complex systems and explore some of the test and quality challenges they present. We might have an article on: building and testing ...
As part of my work, I spend a lot of time at client’s sites and talk to various software development organizations. I am beginning to see a problem arise regarding Test Automation. There is too much automation! Surprised? While there are still many teams struggling to make progress with Test Automation, many teams have been doing ...
“Why do we need to understand a bunch of test methods? I write test cases from user stories or requirements, automate what I can and execute the rest manually, and its fine.” If this is your situation: good for you. If you are time crunched, if your automated tests have lost relevance, are hard to ...
Testers need to learn their craft and hone in on their skill set. That means building skills, sharpening their tools, and becoming creative detectives. There is no cookie-cutter tester and no best practice. The best circumstance is a fully-skilled, aggressive tester mixed with curiosity, nimbleness, and agility.
API testing– an old school technology gets way cool again. APIs and testing them is nothing new; the technology has been around for decades. The most basic definition of an API is an exposed function— a producer (person or company) writes a function and exposes it so that others, consumers, can use it. We copy ...
There is a growing software development dynamic of teams without Testers. When I first went into Software Quality, I learned one thing right away: My role was user advocate. My main job was to find bugs. This is the Lean principle called Amplified Learning. We learn about behavior by testing. Even then, validation was not ...

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news

Subscribe