Two weeks ago we asked if QA Management was a oxymoron. Today we are going to partially answer that question with a NO!
In the smallest set of terms; QA Management is there to save a company or organization money and to make a project run more smoothly. (more…)
An oxymoron is two contradictory terms that have been used in conjunction so is “QA Management” an oxymoron or is it simply contradictory? Is it possible to manage Quality Assurance for Quality Assurance or are we wasting our time trying to manage quality? (more…)
Software tester training seems to be something that needs a lot more attention, given how many conversations we’ve had on this topic. A few weeks ago we talked about How We Train Software Testers? We get a surprising number of questions about software tester training and plans, and we now want to touch on the results of software tester training. (more…)
System Boundary Diagrams sometimes come up in the context of a Use Case and sometimes in the context of Software Testing. Either way they are a useful in the effort expended when determining what to test. While the ‘normal’ System Boundary Diagram shows the boundaries of the system and thus the boundaries of the testing, we try to use it only as a starting point for other diagrams that may also aid in defining the testing effort and scope. (more…)
Sources of information for testing tend to come from two extremes. In some cases you may have almost no information and find it difficult to start. In other cases you may have far too much information and not know what to do with it all or where to start or stop reading. The ‘happy medium’ or ‘just right’ amount is rarely the case when it comes to testing sources of information. (more…)
Test training is something that should be a ‘given’ and not something that a blog series should be devoted to. However, we get a surprising number of questions about test training and plans, that we thought we’d address a few of them here. So why train testers? You may recall that we defined three broad categories a couple of weeks ago in the blog. (more…)
Training seems like an obvious topic and not one to which a blog or two could be usefully devoted. However we get a surprising number of questions about training and plan to address a few of them here. The first one is what type of training is offered. We define three broad categories here:
You only have to read the job advertisements to see the expectations related to open positions. You may see a long list of test tools with which the applicant is to be proficient. You will most likely see some reference to a Test Methodology or SDLC. Most job advertisements finish off with some soft skills.
So how do our three categories relate to day-to-day work?
Taking them in reverse order:
Application related Training
Clearly the more the person knows about the application for which the system was built, the easier it is to understand the risks, define the scope of testing and explain the results to the business. It is also easier to understand the business requirements and expectations.
Training related to a particular Test Tool
This type of training is usually supplied by a vendor and can range from an overview of the test tool allowing one to to use it without in-depth knowledge all the way to becoming a technical expert. The only comment is that every tool has been superceded by something else eventually so every tool or technical process will eventually become redundant.
Training related to testing
This type of training covers the rest of the requirements. It teaches about SDLC, Communication, Risk, Planning, and Testing to name only a few items.
Discussion Questions
Next Week: Sources of Information
Test Conditions is a term that has multiple definitions. For the sake of this blog, we are going to define them as the equivalent of (Low Level) Test Objectives and state that they are One-Line statements of what is going to be tested. (High level Test Objectives may relate to more system level objectives and some of them may be derived from the Project Charter or plan.)
For example, the Test Conditions may read as follows:
The question that frequently arises is why bother to write these Test Conditions? It seems like an extra step with minimal return. Why not just go directly to the Test Cases?
We use them for a number of reasons.
We have found that the effort in building test conditions is more than paid back in early information and helpful triggers for what needs to be done.
Discussion Questions
Next Week: Process Improvement – Deal with Results