Root Cause Analysis (RCA)

How do you analyse the root cause for a defect?

As a software tester, we can use Root Cause Analysis.

Root Cause Analysis (RCA) is an approach used in software testing to analyse and identify the root causes of defects and address them, instead of treating the symptoms. If some problems happen, instead of just fixing it, we can also investigate and try to fix the underlying cause so that this kind of problems will be prevented from the next or further phases.

How to do the RCA?

Five whys technique: whose goal is to determine the root cause of a defect or problem by repeating the question “Why”. Each “why” forms the basis of the next question. For example:

6How to do RCA?
Why we've received an issue?
Why Save button is not working on users page?
Why does specific symbol affect...

(Source: https://www.slideshare.net/DavidGevorgyan1/root-cause-analysis-of-defects)

The answer to these questions will give us the exact phase, where the defect actually exists. Then, we can come up with “What” question:

What will you do to avoid this in future?

So now we can prevent the same defect to arise again by implementing the answer of this question.

Why doing this?

Doing the RCA accurately helps to prevent defects in the later releases or phases.

Examples?

Problem Statement: You are on your way home from work and your car stops in the middle of the road.

1. Why did your car stop?
– Because it ran out of gas.

2. Why did it run out of gas?
– Because I didn’t buy any gas on my way to work.

3. Why didn’t you buy any gas this morning?
– Because I didn’t have any money.

4. Why didn’t you have any money?
– Because I lost it all last night in a poker game.

5. Why did you lose your money in last night’s poker game?
– Because I’m not very good at “bluffing” when I don’t have a good hand.

(Source: https://www.isixsigma.com/tools-templates/cause-effect/determine-root-cause-5-whys/)

What are the Fields in a Bug Report?

In a bug report, we can include multiple elements, e.g.:

  • Bug name: the name of the bug
  • Bug ID: which will be automatically created by the Bug Tracking tools
  • Area path: where does this bug exist?
  • Build Number: e.g. “Version Number 5.0.1”
  • Severity: how fast does this bug need to be fixed? High or medium or low?
  • Priority: do we need to fix this bug at first? Give a certain priority, high/medium/low
  • Assigned to: which developer?
  • Reported by: of course me
  • Reported on: the date
  • Reason: defect
  • Status: “New/Open/Active” depends on the tools that we are using
  • Environment: what operation system and what software? e.g. “Windows 2003/SQL Server 2005”
  • Description: describe the bug
  • Steps to reproduce: how you can get to the bug/defect?
  • Expected result: what is the system supposed to deliver?
  • Save

 

(A good resource here: http://www.softwaretestinghelp.com/sample-bug-report/)

Create a Manual Test Script

Test scripts are the automation scripts written in any of the programming languages which can be interpreted and executed automatically by a testing tool. It likes a combination of a test case with test data.

A test script can be either automation test script or manual test script:

  • Automation test scripts: are the programmed test cases with the combination of test data which can be executed by a tool; whereas
  • Manual test scripts: are the manual test cases fabricated with the multiple sets of test data to enable even a layman to do the testing as per the documentation.

To be continued…

 

 

 

Defect Management

What is Defect management?

Basically, defect management (DM) is the process of detecting bugs and then fixing them. It is a part of software testing process. The primary purpose of DM process is to prevent defects. It is kinda like “bug tracking”, a process of tracking bugs and removing them from our software product.

The process of DM usually includes four main steps:

  • Defect detecting: so, find the defects!
  • Dedicated to the formulation of bug reports: document all the necessary information about defects involved in the software product, which includes data on the type of bugs, possible ways of its corrections, priorities, etc..
  • Defect fixing: fix them!
  • The bug/defect list is created: this is the document that contains information about all bugs that occurred during the project’s performance.

 

Defect Management Lifecycle

1.png

Here is the lifecycle of DM. Note that DMLC is different from DM.

The lifecycle of DM starts from when a defect is found for the first time. So now it has a state as “new”, which means that the bug is not yet approved. Then, the tester will post that particular defect/bug, and testing lead will approve that the defect is genuine and the state will be changed to “open”.

Once the state of the defect is changed to “open”, this defect will be assigned to corresponding developer or development team to fix is. After the defect is fixed, it will be assigned back to the testing team for the next round of testing. If the defect is not present, the tester will approve that the defect is fixed and verified. Otherwise, the defect will be re-open and fixed again.

What does “referred” means? That is, this bug or defect is expected to be fixed in future releases. For example, the use case states that customers want a “1+1=3”, and the system is doing in the same way. Under this situation, a tester should pass this test. However, based on our common sense, it is impossible to see that 1+1=3. So we pass this test, but give feedback to the BA and say that there are no defects about this one, but there may have something wrong as 1+1=2. So now this defect has been “deferred”, and the BA will go back and check their document again.

 

Test Plan, Test Design, and Test Execution

What is a test plan?

The concept of “test plan” refers to that a comprehensive document which describes the scope, approach, resources, major activities, and schedule of intended test activities. It is kinda like a baseline so that testers or the test team can apply testing based on it and track the progress of the testing project. It documents the strategies that will be used to verify and ensure that a software product meets its design requirements. Usually, it is prepared by test engineers. A test plan includes:

  • Scope of the project
  • Objectives
  • Target market
  • Assumptions
  • Testing cycle start/end dates
  • Major roles and responsibilities/overall resources
  • Testing environment
  • Deliverables
  • Major risks and how to handle these risks
  • Defect reporting and mitigation
  • Testing end date

Test plans can have different types:

  • Master test plan: a single high-level test plan for a project/product that unifies all other test plans;
  • Testing level specific test plan: a plan for each level of testing, e.g. unit test plan, integration test plan, system test plan, acceptance test plan, etc..
  • Testing type specific test plan: a plan for major types of testing, e.g. performance test plan, security test plan, etc..

A good website to view about test plan: http://softwaretestingfundamentals.com/test-plan

 

Test plan VS. Test case

A test plan is a comprehensive document which lays out all the major activities of a particular testing project. It is designed to be a resource or baseline for both testing team and stakeholders.

In contrast, a test case is designed to describe detailly what should the testing team do. It is always used for a singular test scenario.

 

What is test design, and test execution?

Test design is the act of creating and writing test suites for testing a software. It is the process of creating a set of inputs for given software that will provide a set of expected outputs. Often, testing engineers and analysts should have knowledge of the software, and the essential functionalities of the software that needs to be tested.

Test execution is basically that execute the test we have planned. It refers to the process of executing the code and comparing the actual results with the expected results.

For example, when we’ve got an inventory system which needs to be tested, we need to design and plan how we are going to test it. We should have knowledge about how it is supposed to work and what functionalities it should have. Then we can execute our tests to see that whether the software system is the one that meets customers’ requirements.

 

Test design VS. Test plan

A test plan, as defined above already, is a document that identifies the major activities that should be done by the testing team to finish the testing project and the stuff related to the testing team and stakeholders. This deliverable often includes the scope, activities, roles, resources, risks, entry, and exit criteria, test objective, etc.. It can also include a test strategy, which outlines the testing approach, and gives generic details for the team to follow. While a test plan gives or assigns specific tasks and responsibilities to team members, the test strategy ensures that anyone is able to execute the tests.

The test design revolves around test themselves, including how many will need to be performed, the test conditions, and ways that testing will be approached. It involves creating and writing test suites for testing a software product.

 

 

 

Use Case, Test case, Test scenario

Use Case VS. Test Case

Both of them are essential when solving customers’ problems. However, there are still some differences existing between use case and test case.

A use case is prepared by a business analyst (BA), which is a pictorial representation of client or customer requirements. It describes how we are going to solve problems for clients or customers and the flow of events of an application, and provides us with the story how people is going to interact with a software system to achieve a goal at the same time. A use case will always be done at the beginning phase.

In contrast, a test case will be done by a test engineer or analyst at the end phase when the software or an application has been developed. It defines a set of conditions or variables under which a tester will determine whether an application, software system or one of its features is working as it was originally established for it to do. The root of the test case is the framework of the use case. Instead of that a use case always interacts with users, a test case interacts with the results. It kinda likes a document which contains actions, events and the expected result of a particular feature of an application.

For example, when a customer come and want us to solve a particular problem, let’s say inventory management. A business analyst will start communicating with this customer, learning this customer’s problems and issues, and write use case which captures the customer’s requirements related to system functions, or say how the customer will interact with the system. Such use case can help the development team understand precisely what the customer expect the system to do, and what functionalities the system can provide.

Then, after the development team has finished their jobs, like building a software system or application for the customer, testing team will come and start writing the test case, which is used to validate whether the requirements have been met or not. So here, the functions that were agreed upon by the BA and customer will be listed on the test case, and such test case will be used to perform the actual testing activities.

So to simplify it, a use case describes the customers’ requirements, and it provides a baseline for the development team and testing team. But for a test case, it depends on the use case and it describes the testing requirements that the project needs to accomplish to ensure that the quality requirement expected by the customer is met.

 

Test Scenario

A test scenario, aka test condition, is any functionality that can be tested. It is the high-level classification of test requirement grouped depending on the functionality of a module. The purpose of scenario testing is to test the end-to-end functionality of a software application and to ensure the business process and flows are functioning as needed.

For example, when we are doing the writing part of a testing project, say we are testing a website, we need to identify test scenarios and test cases. One of the test scenarios can be that: “The Login Page”. Under this test scenario, we can have several test cases, e.g. “To verify the “Register” button”, maybe.

 

The difference between test case and test scenario is basically that: test scenario is “what to be tested”, whereas test case is “how to be tested”.

Test Case Test Scenario
Test case consist of test case name, Precondition, steps / input condition, expected result. Test scenario consists of a detailed test procedure. We can also say that a test scenario has many test cases associated with it. Before executing the test scenario we need to think of test cases for each scenario.
Test cases are low level actions and it can be derived from test scenarios. Test scenarios are the high level classification of test requirement grouped depending on the functionality of a module and it can be derived from use cases.
Test case is give detailed information about if any pre-condition, what to test, how to test and expected result etc. Test scenario is one liner statement which tell us about what to test.
Test case means detailed documenting the cases which help executing while testing. Test Scenario means talking and thinking requirements in detail.
Test cases are set of steps which performed on system to verify the expected output. Test scenario is thread of operations.
Test cases are more importance in case where development is happening onsite and QA is happening Off shored. It will help to understand and make both developer and QA in sync. Test scenarios are more important when time to write test cases is no sufficient and team members are agree with the detailed one liner scenario.
Writing test cases is one time effort which can be used in future while executing regression test case.
While reporting defects it will help tester to link the defect with test case id.
In new software testing generation it is new idea and time saver activity. The addition and modification (easy maintainability) of test scenarios is easy and independent on specific person.
The detailed test case document is full proof guard for new software tester. If developer missed something then it is easy to catch while executing these full-proof test cases. One of the most positive point about test scenario is good test scenarios reduces the complexity and repeatability of product.
It requires more time and resources due to detailed test case which talks about how to test and what to test. If the test scenario not detailed enough then it might take some time to discussion and understand what test scenario is exactly talking about.

(Source: http://www.softwaretestingclass.com/what-is-difference-between-test-cases-vs-test-scenarios/)

SLDC VS. STLC

Difference between SDLC and STLC

SDLC, software/system development lifecycle, refers to the various phases involved in the software development process, including gathering requirement, designing, implementation, testing, deployment, and finally maintenance.

“sdlc”的图片搜索结果

Whereas STLC, or software/system testing lifecycle, describes all the activities performed during the testing process of a software product. STLC focuses more on testing, instead of the whole development process of a software product. The foundation of STLC is a developed software product instead of a business document which outlines all the requirements of customers/clients. It is common to see that STLC is contained in SDLC.

Below is a really good table which describes the similarities and differences between these two:

S. No. Phase SDLC – Software Development Lifecycle STLC – Software Test Lifecycle
1 Requirements Gathering Requirements gathering is done by the business analyst. Development team analyze the requirements from the design, architecture & coding perspective. Testing team also reviews & analyzes the requirements, and identifies the testing requirements, e.g. what types of testing will be required. The team will review the requirements for logical functional relationship between various features / modules, to ensure that any gaps can be caught at an early stage.
2 Design Technical architect works for the high level & low design of the software to make sure that high level and low design are met. The business analyst works for the UI design of the application Here, test architect, generally the test lead/manager, does the test planning, and identifies high-level testing points. Basically, requirement detailing is done in this phase.
3 Coding or development Development team does the actual coding based on the designed architecture. Testing team writes the detailed test cases.
4 Testing In SDLC, actual testing is carried out in this phase. It includes unit testing, integration testing & system testing etc.. Test Execution and bug reporting, manual testing, automation testing is done, defects found are reported. Re-testing and regression testing is also done in this phase.
5 Deployment Application is deployed on production environment for real end users. Final testing and implementation are done in this phase and the final test report is prepared.
6 Maintenance Basically, it includes posting production and deployment support, and follow-up with enhancements.  Test team here will do updating & maintenance of test plans, test case required for the testing of support requests & enhancements as a part of maintenance.

Which phase of SDLC we write test case

Within the loop of SLDC, we write test cases and execute the testing stuff in the phase of “Testing”. For STLC, the test cases will be written when then phase of “Coding/Development”.