Leadership In Test: Introduction
Editor's Note: Welcome to the Leadership In Test series from software testing guru & consultant Paul Gerrard. The series is designed to help testers with a few years of experience—especially those on agile teams—excel in their test lead and management roles.
This article starts at the beginning: what is software testing all about? You’ll learn the basic software testing concepts that will frame your thinking as you approach the art and science of quality engineering.
Sign up to The QA Lead newsletter to get notified when new parts of the series go live—and get a deeper dive in Paul’s Leadership In Test course. If you do, use our exclusive coupon code QALEADOFFER to score $60 off of the course!
When you are a test manager in a project, it is very likely that people will assume you are the expert on all things testing-related. Other team members will probably have their own well-founded or eccentric views on testing; some may have (or at least say they have) more experience than you.
Expectations of testing are often unrealistic and even experienced people take up lazy positions on what testing can achieve. Some people will doubt your competence, value to the team, or even your motivations. It can be tough.
In your test management career, you will have to adapt to new and changing circumstances. You will encounter business and senior project stakeholders. You will be joining teams of various sizes with different people in them who have widely varying backgrounds. They may have extensive experience, or really, not much at all.
Your role might vary from being the tester to running a large team or to provide oversight to the testing in a project, being tasked with advising an Agile team, or figuring out how testing fits into a continuous delivery regime.
Before we start using terms like testing, stakeholder, and stakeholder goals, we’d better be pretty clear about what we’re talking about.
Definition of “Test”
The word test is used as a noun and as a verb. It’s about testing as an activity and the outcome of that activity. It’s about the people or organizations who commission that activity and those who use the results. Very much it’s about the people who call themselves testers and the complex systems on which we work.
If we are to talk about context-neutral testing we’ll need a definition of a test that is context-neutral, so I looked up the definition of test on the dictionary.com website. Of the many pages of references to the word test and its applications in many areas, the definition from the American Heritage Dictionary is the most appropriate:
Test: (noun) a procedure for critical evaluation; a means of determining the presence, quality, or truth of something; a trial
There is not just one definition; rather, there are three variations. Well, this isn’t so bad I think, as all three taken together give us the foundations we need. Let’s take a closer look at each one.
A procedure for critical evaluation
Critical evaluation involves a skillful judgment as to the truth or merit of something. A test is a procedure, usually with a series of steps that include some form of preparation, execution, results gathering, analysis, and interpretation. This isn’t a definitive description of a test procedure. There could be more steps and one could break these main steps down further.
The procedure doesn’t necessarily require prepared documentation, but some tests are so documented (and automated tests are always scripted in some way). The important thing is that there is a perspicacious thought process at the heart of a test.
This thought process is driven by the need to evaluate the system under test with respect to its adequacy, consistency, behavior, accuracy, reliability, or any other significant aspect or property.
A means of determining the presence, quality, or truth of something
A test could determine the presence (or absence) of something easily enough, but the quality is a different matter: the term is loaded with emotional connotations, but we are rescued by the same dictionary. Quality can be, “an essential or distinctive characteristic, property, or attribute”. Now we can see that a test can reveal these properties.
Note that I’m not using the term quality to reflect the relationship between a user or stakeholder and a product. Quality is like beauty – in the eye of the user. Don’t be drawn into discussions of how one measures quality (with testing). I tend to avoid the Q-word altogether.
Note that I’m not using the term quality to reflect the relationship between a user or stakeholder and a product. Quality is like beauty – in the eye of the user. Don’t be drawn into discussions of how one measures quality (with testing). I tend to avoid the Q-word altogether.
Can a test determine the truth of something? Well, this makes good sense too. Typically, we need to test an assertion such as, “this system meets some requirement” or “this system behaves in such a way” or “this system is acceptable” and so on. There’s a certain amount of subjective judgment involved but we can see that a test or tests could provide evidence for someone to exercise that judgment and make a decision.
A trial
The notion of a trial implies that the process of testing a system will help us to evaluate that system with respect to its qualities. The purpose of such an evaluation is normally to make a decision.
The decision might be to accept or reject the system, but it might also be to expose its shortcomings so they can be remedied in some way. A test might also influence an individual or organization to change direction – to rethink a design; to relax or change a requirement; to scrap a component and start again; to buy rather than build or build rather than buy.
A natural way of looking at a system under test is that it is on trial, and will be judged in some way.
Definition of Testing
From our definition of the noun test, we can derive a verb easily enough.
Test: (verb) to critically evaluate; to determine the presence, quality, or truth of something; to conduct a trial.
So far so good.
But not that good, really. Unfortunately, the testing profession is dogged with terminological problems. There’s no way we can present a definite glossary here. In your projects to avoid misunderstandings, I suggest you ask what the goal of any defined test type is rather than rely on an assumed definition to tell you.
Common Types of Testing You’ll Hear About
Giving a tutorial on each of these types of software testing goes beyond the scope of this article, but as a software tester you’ll hear a lot about these (some of which you’ve probably read up on):
- Black Box testing
- Regression testing
- Unit testing
- Beta testing
- Manual testing
- Automated testing or automation testing
- End testing
- Stress testing
- Security testing
- Performance testing
- White-box testing
- Acceptance testing
- Integration testing
- Load testing
- System testing
- Non-functional testing
No matter what type of test you’re talking about, my advice is to always ask what the goal of the test is, even if it appears to be a commonly accepted name like a unit test or acceptance testing. The interpretation of what these mean can differ from team to team.
Sign up to The QA Lead newsletter to get notified when new parts of the series go live—and get a deeper dive in Paul’s Leadership In Test course. If you do, use our exclusive coupon code QALEADOFFER to score $60 off of the course!
Related Read: 7 BASIC QUALITY ENGINEERING TOOLS AND WHY YOU NEED THEM
