Software Testing Models

How to Design Test Cases Using State Transition Testing Technique?

(adsbygoogle = window.adsbygoogle || []).push({});

In the previous article we have seen about “How to Design Test Cases Using Cause and Effect Graph Testing Technique” Similar way in today’s article we are learning one more interesting test technique used in the software testing called “State transition testing technique”.

State transition testing is a form of Dynamic Testing Technique that comes in use when the system explained as a finite number of states and the evolutions between the states is ruled by the rules of the system. Another use of this technique when features of a system are characterized as states that converts to other state, this transition is explained by the method of the software

The diagrammatic explanation is shown below,



So, the diagram shows that, the input condition has came the reason of an entity transitions from State 1 to State 2 that guides to an event and results to an action and finally gives the output.


Four major parts of state transition model: States that the software might get (open/closed or sufficient/insufficient funds) The transition from one state to another (with single transitions) The events that origin a transition (closing a file or

Continue reading →

What is Cause and Effect Graph Testing Technique - How to Design Test Cases With Example?

Cause-Effect flow diagram

Cause-Effect Graph graphically shows the connection between a given outcome and all issues that manipulate the outcome. Cause Effect Graph is a black box testing technique. It is also known as Ishikawa diagram because of the way it looks, invented by Kaoru Ishikawa or fish bone diagram.

It is generally uses for hardware testing but now adapted to software testing, usually tests external behavior of a system. It is a testing technique that aids in choosing test cases that logically relate Causes (inputs) to Effects (outputs) to produce test cases.

A “Cause” stands for a separate input condition that fetches about an internal change in the system. An “Effect” represents an output condition, a system transformation or a state resulting from a combination of causes.  


The Cause-Effect Diagram can be used under these Circumstances: To determine the current problem so that right decision can be taken very fast. To narrate the connections of the system with the factors affecting a particular process or effect. To recognize the probable root causes, the cause for a exact effect, problem, or outcome.

Benefits of making cause-Effect Diagram

It finds out the areas where data is collected for additional study. It

Continue reading →

What is Risk Based Testing in Software testing?

Risk Based Testing Approach

Today’s article is going to be a complete guide to learn Risk Based Testing in Software testing. Before explaining Risk based testing, it is necessary to know what mean by Risk in software testing. A Risk is a problem or situation that has not happened yet and it may never happen in future as well. It is basically a possible problem.

In this article we understand what is risk based testing, reasons & situations to implement risk based testing, and benefits of risk based testing.

Risk based testing is type of software testing that the features and functions to be tested based of priority, importance and potential failures. First we identify the risk to the project, we analyze the risk associated with the potential cost of the projects.

Let come to the point why and what all reasons and scenarios to implement in the risk based testing. Many projects have different constraints like time, resources, quality requirement in terms of organization standards. The Risk based testing works really well in this regards. While implementing new projects there are high risk factors involved like New technology, Lack of knowledge, lack of experience etc.


Major objective of Risk Based Testing: To

Continue reading →

Positive and Negative Testing In Software Testing

Positive and Negative Testing In Software Testing

Software testing is process of Verification and Validation to check whether software application under test is working as expected. To test the application we need to give some input and check if getting result as per mentioned in the requirements or not. This testing activity is carried out to find the defects in the code & improve the quality of software application. Testing of application can be carried out in two different ways, Positive testing and Negative testing.

Positive Testing:

Positive Testing is testing process where the system validated against the valid input data. In this testing tester always check for only valid set of values and check if a application behaves as expected with its expected inputs. The main intention of this testing is to check whether software application not showing error when not supposed to & showing error when supposed to. Such testing is to be carried out keeping positive point of view & only execute the positive scenario. Positive Testing always tries to prove that a given product and project always meets the requirements and specifications. Under Positive testing is test the normal day to day life scenarios and check

Continue reading →

Difference between Regression Testing vs Retesting?

Difference between Retesting and Regression Testing

Next commonly ask interview question in any software testing interview is “What is difference between Regression Testing and Retesting?” Regression testing and Retesting have different objectives and priorities, they equally important for project’s success.


Definition of Retesting and Regression Testing:

Re-Testing: After a defect is detected and fixed, the software should be retested to confirm that the original defect has been successfully removed. This is called Confirmation Testing or Re-Testing

Regression testing: Testing your software application when it undergoes a code change to ensure that the new code has not affected other parts of the software.



Let’s quickly start with actual difference between Regression Testing and Retesting.


Regression Testing Retesting Regression testing is a type of software testing that intends to ensure that changes like defect fixes or enhancements to the module or application have not affecting unchanged part. Retesting is done to make sure that the tests cases which failed in last execution are passing after the defects against those failures are fixed. Regression testing is not carried out on specific defect fixes. It is planned as specific area or full regression testing. Retesting is carried out based on the defect fixes. In Regression

Continue reading →

What is Globalization, Internationalization and Localization in Software Testing?

What is Globalization Internationalization and Localization?

In Today’s competitive world many of the clients are targeting the global audience, which means going beyond borders and working with clients to make sure application has proper global sets in terms of functional, readable, and viewable in multiple platforms and cross-browsers. Along with that there are many languages in the world, so in this situation do we need to create a separate application or website for each languages & countries? The answer is NO. This can be accomplish by simply doing the code in such a way that changing the text in the file they can localize the product in any language & this type of testing is called as Globalization (Internationalization) and Localization Testing.

Overall summary of what is mean by Globalization, Internationalization and Localization Testing?

Translation is one part of Localization Internationalization is a pre-requisite of Localization Internationalization and Localization are parts of Globalization Globalization includes many business-related activities outside of the product itself.

In this article I am focusing on what all best practices to be followed for Globalization and Localization Testing. Also we are discussing all common bugs found from this type of testing. Prior to start, many testers are thinking about what is use

Continue reading →

Key to Successful BVT – How to run the Build Verification Test?

BVT (Build Verification Test)

What is BVT (Build Verification Test)?

Build Verification Test is a set of pre-defined test cases run on every build to make sure that build is testable for further testing. BVT test is carried out before build pass to testing team for further testing. This test contains pre-defined Test Cases which focus on the core functionality of software application to make sure that build is stable & ok to start with actual testing. This test is done to check the Build validation & Build Acceptance.

So sometimes BVT is called as “Build Acceptance Test (BAT)” or “Smoke testing”.

Why BVT to be carried out after every build?

Many of the testers are thinking of why build verification testing should be carried out once new build is received, so answer is simple “To check the Stability of the build”. If new build received & you are testing functionality but after spending some time you got a blocker issue which blocking all other functionality, this means test team spend time to test application but due to blocking issue test team have to carried out same operation again. So to avoid wasting valuable time of test team we can use automated Build Acceptance

Continue reading →

Why testing should start early in software development life cycle?

Software Development Life Cycle Planning

One of the software testing principles say that “Start Testing Early” in the software development life cycle, so in this article we will see what all advantages & practical reasons if we start testing early in SDLC.

It has been observed that most of the errors are identified in the testing phase which is already introduced in the requirement or design phase. Defects identified later in SDLC are expensive to fix than defects identified in early stage. So testing should start early to avoid the introduction of defects in the early phase.

First let’s see normal software development life cycle process planning:

Software Development Life Cycle Planning

In SDLC first step is ‘Planning’ in which planning of entire project where all requirements are captured, discuss if any queries & got clarified from Client. Requirements are finalized & entire planning is prepared. Upon finalizing requirements, start requirement analysis & system is designed as per the Planned Time. In this planning all steps are dependent on previous phase. Unless and until previous step is not completed then not to start the next step. In this step actual implementation (Coding) starts. Finally upon completion of Coding actual Testing starts here.

This is

Continue reading →

Top 10 reasons why there are Bugs in Software!

Top 10 reasons why there are Bugs in Software!

Many of the testers are thinking that why these bugs are introduced in the code or why developer leaves the bugs in the code. I think this is contradictory type of question means if no introduction of errors in the code then there is no need of testing of software, just develop the defect free software application & use it without testing. This is not practicable, if the complexity of the software application increased then it consider that the defects will introduced in the code. There are few factors which are the preliminary causes of introduction of the defects in code. So in this article I will discuss about what all probable reasons which may cause the defects in the software? Also I am talking about top 10 possible causes of errors, defects and bugs in software. Let’s see what all reasons of introduction of Defects/Bugs in the code:

Miscommunication of requirements introduces error in code Unrealistic time schedule for development Lack of designing experience Lack of coding practices experience Human factors introduces errors in code Lack of version control Buggy third-party tools Last minute changes in the requirement introduce error Poor Software testing skill

So here I will take

Continue reading →

Defect Priority

What is Defect Priority?

Defect Priority signifies how important & urgently it is to fix this defect. In other words Priority means how fast it has to be fixed. The Defect priority status is set by the project manager based on the customer requirements & based on Project Priorities the product fixes are done. Priority is related to scheduling to resolve the problem. It is a pointer towards the importance of the bug & if High priority is mentioned then the developer has to fix it at the earliest. It is related to technical aspect of the product. It reflects on how bad the bug is for the system and also largely related to Business or Marketing aspect.

Defect Priority is classified into the following categories: Show stopper: This needs to be fixed right now, everything else can wait, the build cannot be released with this defect Urgent: Needs to be fixed before any other high, medium or low defect should be fixed High: Should be fixed as early as possible Medium: May be fixed after the release / in the next release. Low: Fixing can be deferred until all other priority defects are fixed

It is also represented as

Continue reading →