Obligatory and first document in Software testing life cycle

There are many documents which we make in the Software testing life cycle. Those documents are Test plan, Test design and Test case specification, Test summary reports, Weekly Status Report, User Documents/ manuals, User Acceptance Report, Bug reports etc.

We make these documents in STLC and all of them hold equal importance. During my interviews, when I was questioned, what is the first document a test professional prepares? My answer to this question remained one: Test Plan.

Many of us would give the same answer. But is it true?

I would say,NO.

Aren’t we missing our First and Important document, “CLARIFICATION LOG”

This should be the first and obligatory document made by Test professional.

As a Software testing professional, we come across many documents like SRS, BRS or Functional, Impact analysis, wireframes etc. and we review all these documents.

When we go through these documents , SRS or Wireframes, we get lots of doubts or questions. To make the process fast and as a habit, we throw our doubts and questions to Point of Contact who can be BA, PM or client during any meeting or 1 on 1 basis or on phone, emails and get the information. In these scenarios, every information is in the air and we tend to lose this important information.

Let’s assume few scenarios,

• What if, any one of your project team member has same doubt or question?
• The information given by your Point of Contact is incomplete or changed because there were updates in project requirement.
• You received half of the information and started working on documents.
• Due to half received information you missed an important point and your testing is gone for a toss.

These scenarios can occur at any point of time and can lead to a bug in the Software.

To avoid the complications from all these scenarios the very first document we should make is

“Clarification log”

Clarification log enables you to collate questions and answers, to have traceability.

Why should we have Clarification log?

1. It helps to identify gaps in Requirements.
2. We can get Defects in initial phase of the project, which will be less costly.
3. A common pool of storing important points or questions.
4. It can act as a reference point during the SDLC.
5. It helps to avoid misunderstandings and assumptions.
6. It can save re-effort and time.

When do we start making Clarification log?

At the start of project or as soon as you receive any document for any project to go through.

How do we maintain it?

Clarification log is followed in any project in the initial phase, execution phase and at the end of phase. We should keep updating our queries or questions in the clarification log. This log should be shared with all your team members and client.

Who will use and maintain this document?

This is a flexible document and any one in the team can use it to clarify important information. As a best practice in my team, Testers creates this log and share it with all their team members. These questions can be addressed in any of the meetings and answers can be recorded for each line item.

Who updates this document?

This is a versatile document, where any one can ask their doubts. It is team’s responsibility to update this documents during Software Development life cycle. Since we (Testing Professionals) are the owner of this document, we hold major responsibility towards this document.

How to make it?

You can use any tool or create template in Excel. This document is divided into two sections. One section contains the information about Who has, What question and Other section is for the person who answers the question or clarifies the doubt. The basic format is:

SR No|Date|Asked by|Module name|Feature|Clarifications|Status|Comments|Clarified by| Clarified date

When can we close this document?

This document has line items which has Status — Resolved, Pending, Open, Closed, Invalid. When status of each line item is not equals to Pending or Open we can close Clarification log.

A Clarification Log is a Testing Best-practice document which can be used at any point of time in Software development life cycle. We should start to use, to store the information which can help us deliver a quality product with less costly bugs.

Stay high on blogging and please do like,comment and follow my post.