Hey there,
I hope you enjoyed the first lesson.
Today is the Lesson #2 of design effective test case course, but before going into the details of lesson #2, I would like to re-cap what you learned yesterday.
Yesterday, you learned:
- What test design is and why you need it
- Pros and cons of scripted test cases
- Process to design a test case
Let’s start with Lesson #2: Collect Test Artifacts
What is test artifact?
Simply put, test artifacts are the documents you need to design your test. You will use these test artifacts as inputs to design your test. If you don’t have or can’t find these test artifacts, your test design will be much more difficult.
Below are some common test artifacts I often use to design test case:
- Functional Requirement Specification (FSR)
- System Requirement Specification (SRS)
- UI Mockup or UI Wireframe
- Use case
These are common documents you can find in almost software projects. If you don’t find them, just ask your manager for these documents.
These documents are really really important to design your test.
Why? Because they contain REQUIREMENTS
Many new testers (and senior testers too) make this mistake:
They do testing (and write theirs test cases) without understanding requirements.
Don’t make this mistake!
Actually, the requirement is an essential part of software engineering. I can’t think of how software is built without requirements. Every software is built to serve a specific user’s purpose with specific requirements.
So, understanding requirement is a must-have activity before you can start any testing activity.
Don’t skip this step.
Needless to say, the better you understand the requirement of your system, the better your testing is.
Where are the requirements?
Every system or product has their own requirement documentation, but basically, you can find the requirements documented in the following documentations:
- Business requirement document: This document contains all the business requirement of your system.
- System Requirement Specification (SRS) or Product Requirement Document (PRD): Your company may use or refer to a different term but the idea should be the same. This is the documents containing all the requirements of your system. It describes how the system should work
- UI Mockup or Wireframe: This document describes the GUI of the systems such as windows, controls, color, etc.
- Use Case: This document describes how the system is used in reality via use cases.
You should have one of these documents with you so far.
“What if these documents are not available in my project? “ You might ask
As a tester, you will never run out of idea! Try these:
- Help file. Every system should have a Help document or User guide to help end user uses the product. While this document is a bit simple and not in detail, it’s not a bad option at all to start with.
- Release note. More often when developers release a new build, they often include a Release Note to describe what’s new features or what’s fixed in the build. Start from there.
What if you can’t even find any good documents to start in your project?
Don’t give up. Testers never give up. Try this:
Ask up!
If you have a product owner, ask him
If you have a project manager, ask him
If you have a developer, ask him
The goal of this phase is to collect as much information about the requirement of the system, how it’s expected work, how it’s expected to be designed and built.
Requirement documents vs Requirement:
Testers often complain that they don’t have any documents in their projects and that they can’t test (or design test case) without documents.
Even though it’s true that in some projects the document system likes a mess, it doesn’t prevent you from understanding requirement.
You may not have requirement documents, but you always have requirements.
Why? It’s simple. How software is built without requirements?
Stop for a few seconds and list out some of your documents in your project that can help you with understanding requirements.
Here’s a small challenge for you:
List out documents you can find in your system so that you can use them as the input for your upcoming test design process.
That’s all for Lesson #2. In Lesson #3, I will teach you how to collect requirements from these test artifacts.