Project Management

Blog for Project Management Practices by Pravin

by
Project Management Practices, Stories, Learning about Project and Program management. How to deliver value and getting best from your team.

About this Blog

RSS

Recent Posts

Rethinking Project Leadership in a Dynamic World

Software Product Upgrades

Welcome 2022!

Challenges in recent times - Work from home

Software: Reopen Defects

Categories

PMO, Quality, Requirements Management, Software Products, Test Case, Use Cases

Date

Software: Reopen Defects

Categories: Quality

linkedin twitter facebook Request to reuse this  

Working in Software development environment as leaders, all of us faced the issue of defects, which are Reopen by Testing and Quality teams.

Why it is important to address the reopen defects?

Being in Software development everyone comes across the reappearing of the defects declared fixed by the development team. It is important to address the reasons behind reopen as quickly as possible to avoid more defects appear in this category. Fixing of Reopen defects always takes extra effort and cost. It is called Rework.

Reopen defects may cause:

  • Delay in delivery
  • Efforts overrun
  • Schedule overrun
  • Risk of impacting other items while fixing reopen

While considering the reason to address Re-open defects. One of the most important exercises, which is very essential to target reopen defects,  this exercise is called a causal analysis of re-open defects.  

Root cause analysis gives the idea about where improvements needed while looking into possible reasons for reopening.

  • Inadequate QA coverage.
  • Incomplete Implementation.
  • Non-adherence of process/causing gaps.
  • Lack of technical knowledge.

Root cause analysis without corrective actions is a futile exercise. The below table gives a more pictorial representation of linking root causes and action items.

               

=====================================================================================

Posted on: February 27, 2020 11:56 AM | Permalink | Comments (0)

What is good to have in a Test Case:

linkedin twitter facebook Request to reuse this  

Test Case is a scenario created to validate or test any program using sample data. The outcome of the test case determines whether the test is successful or failed. Successful execution of test case implies that business requirements met and program produces the desired results.

It is imperative to have test cases efficient, covering all the aspects of programs in order to validate. A test case may contain multiple steps.

Following are the characteristics of a test case:

  1. Completeness – A test case should be thorough, having necessary steps covering the requirements and business cases, clear mapping with requirements i.e. use cases.
  2. Clarity – Easy to understand and anyone can execute it.
  3. Sufficient Data – It must contain sufficient data perform test. Without sufficient and meaningful data a test case becomes inefficient and there are chances to overlook important data validations.
  4. Reference to dependent cases – Sometimes it is required to execute the other test cases to complete one cycle, the reference to such cases written clearly.

In general, test cases should be written in plan simple sentences, referring to Use Cases as and when required with complete traceability for requirements.

Quality Engineers write test cases based on different types of testing. Scope varies from Unit to System to Acceptance test cases. Irrespective of the type, each test case must have its basic characteristics. Happy writing test cases!

(Thank you Rashika, Test Engineer, Aithent Inc for sharing her experiences with test cases.)

Posted on: November 23, 2017 10:25 AM | Permalink | Comments (6)

Quality of Test Cases is directly proportional to Use Cases : Why to Review Use Case thoroughly

linkedin twitter facebook Request to reuse this  

Quality of Test Cases is directly proportional to Use Cases : Why to Review Use Case thoroughly

As a principle, every QA Engineer follows the use cases to design Test Cases irrespective of methodology they adopt.

Completeness and coverage within Test Cases fully depends on how the Use Cases are written and organized.

It always recommended having a QA review of Use Cases before releasing and freezing it for next usage, i.e. development or writing test cases. The focus should be bring sufficient business cases and identify gaps as early as possible to help teams in avoiding defects.

A lot written on use cases and what it should contain, primarily, it should have:

  1. All business and attributes clearly defined
  2. Clearly identified entities involved
  3. Alternate cases clearly defined with complete cycle
  4. Business analysts tend to link the Use Cases to avoid redundancy; it should not be done at the cost of clarity.

Once QA does a comprehensive review of use case, it certainly got value added and qualifies for writing test cases. A nicely written use case always makes job easy for QA Engineers and Developers.

More to cover about test cases in next blog.....

Posted on: November 17, 2017 11:14 PM | Permalink | Comments (9)
ADVERTISEMENTS

"Why is it that people rejoice at a birth and grieve at a funeral? It is because we are not the people involved."

- Mark Twain

ADVERTISEMENT

Sponsors