If you ask 10 people to define Quality Assurance, you will likely get 10 different answers. This should come as no surprise because there are at least that many different quality organizations trying to define this term. Organizations like; IEEE, ISTQB, QAI, HP, and AST, to name a few. The primary goal of the software test professional, is to find problems for the purpose of improving the quality of a software product. The Software Testing Body of Knowledge (STBOK) for Certified Software Testers (CSTE) defines Quality Assurance this way:
“...an activity that establishes and evaluates the processes that produce products.”
“Products” can be hardware, software, upgrades or integration projects. Quality Assurance, then, is a continuous improvement process that implies, if we do certain things, known as “best practices,” we can assure the quality of the product. I cannot completely agree with that statement... for a couple of reasons.
- No single group can assure the quality of any project or product. We need the whole organization involved or we will not achieve our highest quality.
- There are no “best practices;” there are only good practices in context. What works well in one project may not work well in another.
This is especially true here at UConn where we do not fit the mold of a common software producer. We do not create a new software program every week, or month, or even a year. We are more likely to adapt someone else’s software into our environment, so we don’t always need a large group of software testers working around the clock testing software. What we do need, though, are processes we can use that will provide us with some commonality between the disparate projects that come our way, a way to test the integrations into our ERP system and data bases, and a way for our users to check that everything is configured correctly – and remains that way.
So, the QA Team is not only here to write scripts and test software. We also need to analyze the context of each project to determine the fastest and most efficient way to test it. We will question everything. We will learn the product. We will determine the approach that will work the best. And whether testing, checking, or both are required. Testing will be of an exploratory nature and checking will be in the form of scripts.
We recognize that we are not the gatekeepers of quality or of the software we are testing. We know that quality is a team effort and we encourage everyone to become more aware of the role they play in quality assurance, and we invite all of you to show your enthusiasm by looking for ways improve your product’s quality. Follow us in our journey as we begin to grow, and learn, and improve the products that we all use every day - one project at a time.
Our Approach to Testing
The description of QA stated above is leading us to the Context-Driven approach to testing. Due to the variety and complexity of the software projects that come our way, this makes the most sense. It’s not a new approach (see Software Testing Schools of Thought), but it is a "newer" approach that deals with change more effectively than other approaches, and change is fast becoming the central theme here at UConn. Here are the guiding principles of this approach:
The Seven Basic Principles of a Context-Driven Approach to Testing
- The value of any practice depends on its context
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project’s context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn’t solved, the product doesn’t work.
- Good software testing is a challenging intellectual process.
- Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
(From Cem Kaner, James Bach & Bret Pettichord, Lessons Learned in Software Testing.)
"Quality is never an accident, it is always the result of intelligent effort!"