design effective test case

Hey there,

How are you doing so far? I hope you enjoyed the Lesson #2 I sent out yesterday.

At this point, you may find the course (or test design activity) a bit boring.

It’s understandable.

I know writing test cases is not one of the most interesting activities in software testing…so bare with me!

Anyway, here’s what you learned yesterday:

  • Prepare some important test artifacts before writing test case
  • How important understanding requirement is

In today’s lesson #3, we will learn how to collect requirements and create a list of test requirements.

“hey Thanh, why do I need to collect requirement? I thought requirement documents are good to go”.

You’re right…but here’s the thing:

  • Not all requirements are testable
  • Not all requirements are crystal clear

Don’t ask me why…it’s just the nature of requirements. Requirements are not always clear and testable.

The goal of this phase is to collect clear and testable requirements so that you can work on it accordingly. Collecting requirements also help you measure your test coverage too.

We have a name for this phrase. It’s called “separating chaff from the wheat” 😀

Here’s what you will do to collect requirements:

  1. Read the document line-by-line
  2. Identify phrases that describe the requirements
  3. Skip phrase that’s not a requirement
  4. Take note unclear requirement and ask product owner, project manager, client to clarify them

Here are two important questions you always ask yourself so that you can identify good requirements:

  • Is this requirement clear? E.g.: Do I understand clearly what feature/functions is expected to work? What is the expectation here?
  • Is this requirement testable? E.g.: Can I test it? Can I predict the expected result?

Fails to answer those two questions, you should either ask to clarify the requirement or just skip it.

Remember the goal of this step?

Collect clear and testable requirements so that you can test.

Where to put these requirements? Do you have a template?

You will put these requirements in spreadsheet and yes, I have templates for you too and I will share at the end of the lesson.

Please note that if you are using a Test Management System like Jira, TestLink,  you don’t even need the spreadsheet. Even though the fields in these systems may be different from my spreadsheet template, the idea is the same. From my experience, spreadsheet still works really well.

Here are few important attributes of test requirements:

  • Requirement ID: The ID of test requirement. Ex: TR_0001
  • Description: It tells the objective of the test requirement
    • Ex: Verify that the user can login using FB account
    • Ex: Verify that user can sign out by clicking the Sign out link

Note: To make things simple, I would recommend you always to start your requirements with prefix “Verify that….”

  • Priority: It tells how important this requirement is.
    • Must: This is a very important requirement. It’s a must-have requirement and the system is expected to meet this requirement very well.
    • Could: This is a major requirement. More often it’s related to major features of the system
    • Would: this is a minor requirement. More often it’s related to minor feature of the system…or it’s just a nice-to-have requirement
  • Traceability: It tells where you get the requirement from.
    • Ex: FRS > Section 3.1.1.1
    • Requirement traceability is important because it will help you measure the coverage or your requirement and if you are missing anything. The traceability will help you answer this question: “Where’s the heck you get this requirement from?”
  • Type: It tells what type of requirements are:
    • Functional
    • Non-functional
    • UI
    • Negative

Want to get your hands dirty? I have homework for you 😀

Here are 3 exercises for you (don’t worry they are very easy)

Exercise #1: Collect requirements from FRS
Exercise #2: Collect requirement from a UI Wireframe
Exercise #3: Collect requirement from Use Case

The idea of this exercise is to help you familiar with different types of documents and how you approach them to collect requirements.

Here’s the instruction:

  1. Download the sample document
  2. Download my test requirement and test case template
  3. Read the sample document -> collection testable requirements -> put them into test requirement sheet.
  4. That’s it

I will also provide my sample answers for these exercises in next lesson #4. However, if you have never done this task before, I would recommend you do this exercise. The exercise will only take you around 15-30 minutes and it’s easy too.

What’s next?

Now, do your homework 😀

————————————————————————————————————-

Too busy to learn right now? I’ll send you all 5 lessons to your inbox so you can learn later.

 ————————————————————————————————————-

prev_lesson_2next_lesson_4