Main Page
Scope
The scope of software testing is wide and deep. To cover it all in a weekend was naive. To cover it at all
might be naive, because we keep inventing new contexts all the time. What can we do instead? Provide a
skills book with a sampling of skills grounded in context.
You just opened that book.
Test Design
Communication
Community
Time Management
Critical Thinking
Management
Role, goal, and how to use this document
This skills inventory was commissioned in order to help AST accomplish its third mission -- to 'publish content both
online and in print containing leading-edge information on testing practice and theory.'
The approach we took, in accordance with AST's mission, is a context-driven one. We decided to produce a list of
skills based on our own experience.
We do not claim this list is comprehensive. It doesn't tell you everything you need to be successful in your job. We
haven't done your job; we've done our job, and we have some stories to tell.
We do claim the stories we tell are true, at least to the best of our recollection, and that we found them useful, and
thought they would be useful enough to enough people to be worth sharing.
We expect this material will be useful to at least six audiences:
- New testers, and even experienced testers, who want a picture of what's out there, to learn what they might learn.
- Experienced testers looking for new and interesting ideas for professional development, or resources to explain
- Test managers, to help craft professional development plans for the team, to help identify weaknesses and strengths for create a balanced team
- Non-primary-testers who want to understand the value testers can bring
- Software delivery workers in organizations without a test role, looking for 'holes' in their risk management approach ... and ways to patch them.
- Trainers and consultants who would like an additional reference that is experience-based and context-driven
For this document, we define a skill as:
“The ability to perform some action for a purpose.”
In order to be listed here, a skill must be:
- Demonstrable - You can show it to someone else
- Isolatable - To a single repeatable element
- Observable - After demonstration and explanation I know it when I see it
- Improvable - Can be done better or worse, and you can improve with practice
- Comparable - It is possible to observe people modeling skills and determine a relative qualitative ranking that most people agree on - at least between a novice, intermediate, and an expert.
In Bloom's taxonomy, we hold this definition is good enough for application. You should be able to take up these
skills, learn and do them.
An Example: Knowing network theory, including TCP/IP, bandwidth, dropped packet %, and propagation delay -- all of
that is knowledge. Applying network theory to figure out how bandwidth impacts customer experience as concurrent
users increase is a skill.
What do you mean by testing, exactly?
You will notice that many of the examples here use a working definition approach - creating a definition of what we
mean when we use the term that is intended to be "good enough", for enough of the people, enough of the time, to
have value. We may at times sacrifice comprehensiveness in order that what we write can be easily understood.
Like 'skills', the definition of testing is critical to this document: It helps decide what skills are 'in' and what skills are
'out.' That means we needed a working definition whose primary purpose was to help us decide what was in or out,
while sticking to the spirit of the word we meant when we say 'testing.'
For this document, the working definition of testing is: “Activities around the theme of investigation, critical thinking,
feedback, critique, and reporting.”
Scope: Why these skills and not those skills? What are context-driven skills?
The definition of 'skills' and 'testing' allowed us to set a scope. Our contents are based on real-life experiences that we
believe have a broad general applicability to software testing. That means we put much less emphasis on skills
outside the classic 'test' role (BA, programmer, scrum master, and so on). We did not include skills that are industry or
company specific, often referred to as -"subject matter expertise”. On the other hand, how to learn those skills
(“learning to learn”) is certainly in scope.
For what kind of software?
Most of the attendees of the workshop had experience in commercial, free-market business software. Three of the
more experienced contributors, Robert Sabourin, Doug Hoffman, and Jon Hagar, had significant experience working on
Government, Academic, and Defense projects. The group also had some experience working in regulated industries -
health/medical, financial services, etc.
We expect the skills book to be most useful for people working in free-market, unregulated environments, but still of
some value for teams that are audited, produce mission or life critical software, etc.
Finally, about these skills
Our purpose with this document is to go very broad; to give the reader an introductory exposure to many of the skills
involved in testing. The typical skills description is a page or less. Some of these these (security testing, exploratory
testing) could be an entire book. Let’s consider the list a start -- and let’s get started!
Workshop Attendees
Organizer
Matt Heusser, lead organizer/content owner, Excelon Development and SQE et al
Erik Davis, facilities host, Hyland Software
Peter Schrijver, facilitator, TesT-PRO
Attendees
Alessandra Moreira, Smartbear
Chris George, Red Gate Software
David Hoppe, Excelon Development
Doug Hoffman, Software Quality Methods
Jeremy Carey-Dressler, JCD, Kount
Jess Lancaster, TechSmith Corp. and Lansing Community College
Jon Hagar, Grand Software Testing
Justin Rohrman, Sharable Ink
Nick Stefanski, Hyland Software
Pete Walen, Software Testing & Anthropology
Robert Sabourin, Amibug
Final Draft Review and Edits
Matt Heusser
Pete Walen
Alessandra Moreira
Jeremy Carey-Dressler
Chris George
Jon Hagar
Version 1.0.0 - Licensed under the Creative Commons Attribution License, version 4.0
The source material for this document was created at the first WorksHop for Self-Education in Software Testing,
December 5-7, in Westlake, Ohio. The workshop was an Association for Software Testing event
and Hosted by Hyland Software.