Letter from the Editor – March 2016


I once consulted for a company to give a week-long course on testing and QA. It was a survey course covering a wide range of topics. I was setting up and chatting with students in the room. One man came over to me and said: “I have been testing for 6 months and I am completely bored. I plan on getting a different job in software, either in the company or outside—but it won’t be in testing. I know testing is important—very important—but it’s so boring. It’s not for me. This is my last chance: I hope I can learn something from this class that makes testing more interesting or challenging.”

This exchange is atypical—although I have met people in testing who find no challenge in what we do, meeting someone at that breaking point is rare.

The problem he faced was multi-faceted: The company was seriously underusing their testers—the testers were restricted to doing simple happy path validation checking, rather than including tasks for quality improvement and focusing on customer experience. Also, the more technically interesting automation was given “in-your-spare-time” priority, meaning it never got done. However, where this company was most deficient, was in encouraging their test team to find interesting bugs and design issues. What they needed to do was embrace the test team as software development engineers who test.

The team had no knowledge of the efficiency of data driven testing. There was no optimization of tests by parameterizing expected results to be able to more efficiently drive more data through a minimal number of tests and get greater coverage. There also was a lack of knowledge of Soap Opera testing and its unique goals, or its superiority to other types of tests to find certain classes of issues such as race condition and concurrency issues.

The company above was deficient in training as well as failing to give the necessary time budget required to do so. It also needs to be stressed that the individuals on the team also bear responsibility in not knowing our craft to the degree where they’d be able to advocate for smarter, higher-quality testing, more responsibility and the necessary allotment of time to improve quality.

Blame perspectives on quality, the intrinsic value of the test team, time budgeting, or care for customers, but all that aside—this team needed an entire course just on test design. They really were clueless as to what was involved in test case design and test development.

Simply put, test design is the engineering of a test to accomplish your quality goal. It takes knowledge, intelligence, understanding, vision, business acumen and a certain variety of mental sharpness that most people usually do not associate with testing.

If someone is going to find engineering “boring,” then perhaps they are not cutout for a career in testing. Consider this, testing leads directly to customer satisfaction. Test teams are increasingly collaborating on design, UI, UX, product capabilities and time estimates. All of these factors are crucial to product success! Testing can be interesting and exciting in a variety of ways, and a key factor of this is test design. Test design is central to both effective, efficient testing and the engineering of tests, as well as a crucial element of every successful test automation project.

In this issue, I have written “Making the Case for Better Test Design,” and our blogger of the month, Julian Harty, talks about pushing the boundaries of test automation. Justin Hunter has written a great book review on Elizabeth Hendrickson’s book, Explore it! Randy Rice’s article, “TestStorming™—A collaborative Approach to Software Test Design,” delves into the nuances of Test Design techniques and Han’s Schafer’s “Are Test Design Techniques Useful or Not?” focuses on the importance of black-box and white-box testing. I’m pleased to announce that we also have a new feature series, TestArchitect Corner, which explores different ways to use our flagship product.

We hope you find this issue of LogiGear Magazine useful and a great reference over time for excellent test design.


LogiGear Corporation

LogiGear Corporation provides global solutions for software testing, and offers public and corporate software-testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast and cost-effective results. Since 1994, LogiGear has worked with hundreds of companies from the Fortune 500 to early-stage startups, creating unique solutions to exactly meet their needs. With facilities in the US and Vietnam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

For more information, contact Joe Hughes + 01 650.572.1400

LogiGear Corporation
LogiGear Corporation provides global solutions for software testing, and offers public and corporate software testing training programs worldwide through LogiGear University. LogiGear is a leader in the integration of test automation, offshore resources and US project management for fast, cost-effective results. Since 1994, LogiGear has worked with Fortune 500 companies to early-stage start-ups in, creating unique solutions to meet their clients’ needs. With facilities in the US and Viet Nam, LogiGear helps companies double their test coverage and improve software quality while reducing testing time and cutting costs.

The Related Post

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 ...
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 ...
I remember the times when test teams sat in their own area and we were not allowed to “bother” developers.
There has been a tectonic shift in software development tools in just the past few years. Agile practices and increasingly distributed teams have been significant factors but, in my opinion, the main reason is a new and more intense focus on tools for testing driven by more complex software and shorter development cycles. There have ...
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 ...
I spend about half my work time in the role of a consultant assessing, auditing and examining software development team practices and processes for the purpose of process improvement. I am regularly surprised to find teams that lack basic skills, management support, tools, information, access to users, Product Owners and to developers. And yet they’re ...
Because of the type of work I do (consulting projects at different companies), I’ve been lucky in my Software Development career to have worked on a bunch of software projects specific to hardware devices or integrating new hardware into software systems. Starting with the Palm Pilot, I worked on some operating systems (OS) projects, firmware, ...
A while ago, I helped start a Software Quality Certificate Program as a part of the Software Engineering Program at the University of California, Santa Cruz Extension in Silicon Valley. I was on the Board of Advisors. While putting the curriculum together, a few people suggested a Measurement and Metrics course. Since I was teaching ...
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.
The Greek philosopher Heraclitus of Ephesus (c. 500 BCE) is credited with saying, “The only constant is change.”   This is a statement that, more than 2,000 years later, still holds true. Today, we are in a time of great change. Everything is in flux. The fact is, we are always in a state of change even if ...
A lot has changed since I began staffing test projects. From hiring college students and interns for summer testing programs, to building networks of offshore teams around the world, and from having 24-hour work schedules to having instant crowdsourced public beta or bug bounty testing—things have changed.
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.

Leave a Reply

Your email address will not be published.

Stay in the loop with the lastest
software testing news