How does a DU path segment play a role in data flow testing?

Whenever you would have came across the topic of data flow testing, you surely would have heard about the term “du path segment” but still not familiar with it! This article if focussed up on the du path segments and what role it has got to play in the data flow testing. 

We will discuss the du path segments under the context of data flow testing and not as a separate topic so that it becomes easy for you to understand. 

The whole process of data flow testing is guided by a control flow graph that apart from just guiding the testing process also helps in rooting out the anomalies present in the data flow. With all the anomalies being already discovered one can now design better path selection strategies taking in to consideration these data flow anomalies. 

There are nine possible anomalies combinations as mentioned below:

1. dd: harmless but suspicious
2. dk: might be a bug
3. du: a normal case
4. kd: a normal situation
5. kk: harmless but might be containing bugs
6. ku: a bug or error
7. ud: not a bug because of re- assignment
8. uk: a normal situation
9. uu: a normal situation

For data flow testing some data object states and usage have been defined as mentioned below:

1.      Defined, initialized, created à d

2.      Killed, undefined, unreleased àk

3.      Used for:

(a)    Calculations à c

(b)   Predictions à p

Terminology associated with Data Flow Testing

Almost all the strategies that are implemented for the data flow testing are structural in nature. There are certain terminologies associated with the data flow testing as stated below:

1. Definition clear path segment
2. Loop free path segment
3. Simple path segment and lastly
4. Du path

What is a DU path Segment?

- DU path segment can be defined as a path segment which is simple and definition clear if and only if the last link or node of the path has a use of the variable x.

Let us take an example to make the concept of du path segment clearer. 

- Suppose a du path for a variable X exists between two nodes namely A and B such that the last link between the two nodes consists of a computational use of the variable X. 

- This path is definition clear and simple. 

- If there exists a node C  at the last but one position that is the path is having a predicate use and the path from the node A to node C is definition clear and does not contain any loop. 

- Several strategies have been defined for carrying out the data flow testing like:

1. ADUP or all du paths strategy
2. AU or all uses strategy
3. APU+ C or all p uses/ some c uses strategy
4. ACU +P or all c uses/ some p uses strategy
5. AD or all definitions strategy
6. APU or all predicate uses strategy
7. ACU or all computational uses strategy

Strategy for DU Path Strategy

We shall describe in detail here only the ADUP or all du paths strategy. 

- This strategy is considered to be one of the most reliable and strongest data flow testing strategy. 

- It involves the use or exercising of all the du paths included in the definition of the variables that have defined to every use of the definition.

- All the du paths suppose to be a strong criterion for testing but it does not involve as many tests as it seems.

- Simultaneously many criterion are satisfied by one test for several definitions and uses of the variables.

Explain Test plan, Test Strategy and Test Scenario?

The concept of software testing seems like an amalgam of similar terms, all mixed up in to each other. We all get confused sometimes between the different but similar sounding terms. 

For greater understanding of the software testing, one needs to know exactly what all the inclusive terms mean and how and where they are used or implemented. This piece of writing is dedicated to the cause of removal of such confusions. In this article we are going to clear three major concepts of software testing namely test plan, test strategy and test scenarios.

1. Test Plan

- It does the same as a normal plan would do i.e., detail out a systematic approach to the accomplishment of a certain task.

- For the test plan the task is the successful completion of a particular software testing. 

- A test plan gives a detailed approach of all the processes or activities to be undertaken during the testing.

- A test plan marks the work flow of the software testing mechanism. 

- A test plan states the strategy to be followed to make the software testing successful.

- It provides a means to check whether or not the software system or application meets all the requirements and specifications as mentioned by the client or the customer in the documentation. 

- The test plan is usually created by the testers.

- A typical test plan includes the following fields:

      (a)  Compliance test or design verification: performed on the product samples while the actual product is in development stage.

   (b)  Production test or manufacturing: performed during the assemblage process of the product for assuring quality and performance.       

      (c)  Commissioning test or acceptance: performed while the product is being installed.

      (d)  Repair test or servicing: performed during the product’s service life.

      (e)   Regression test: performed on an existing version of the product to ensure the working of the functionalities.

               

- The level of the design of the test plan depends on the complexity level of the software system or application. 

- For more complex systems high level test plans are created. 

- Apart from the above mentioned tests, a typical test plan must cover about the test methodologies, test coverage and test responsibilities. - It also states what all requirements are to be verified in the testing.

2. Test Strategy

- Test strategy forms an essential part of the test plan. 

- To put it simply we can say that the test strategy is nothing but a superficial sketch or outline of the actual test plan of the software development cycle. 

- A test strategy is developed just to inform the project developers about the approach that is to be followed during the testing. 

- The key components of a typical test strategy are objectives of the testing, test methods, test duration, resource requirements and test environment. 

- Test strategies give the description of the risk mitigation, tests to be carried out and not to forget the entry and exit criteria for the tests. 

- For each level of software testing, an individual test strategy is created.

3. Test Scenario

- Test scenarios form an essential component of the scenario testing. 

- These test scenarios provide a hypothetical measure to help the tester out of some complex problem encountered during the testing. 

- The main characteristics of a typical scenario are its complexity, credibility, motivational story with a reasonable outcome. 

- The scenarios are usually lengthy as compared to the length of the test cases probably because of more number of steps are present in a test scenario. 2 or more scenarios together make up a scenario file. 

How does a definition clear path play a role in data flow testing?

Definition clear path is a quite less heard term! This article is focussed up on the concept of definition clear path and what role do it plays in the data flow testing. First let us define what is a definition clear path in actual. 

"A definition clear path as it can made out from the term itself that it is a path through which other variables cannot be defined or through which other variable definitions cannot be made."

To make the meaning of definition clear path clearer we shall look up to an example:

- Suppose X be a variable declared or appearing in a software program or procedure. 

- Suppose there is a path $which\; do\; not\; contain\; any\; nodes\; with\; definition\; of\; the\; variable\; X.$

- Such a path not containing any variable definitions has been termed as a definition clear path. 

We can now define this definition clear path as a path between the two nodes namely A and B, with X being defined in A and an use in node B and there exists no other definition of variable X between the two nodes present in the path. 

Let us see another example to explore another type of definition clear path that can exist. 

- Suppose the above same variable X be defined at a node A along with an use defined at the another node B.

- Suppose the path formed by these two nodes A and B does not appears in the sub path, then such a path is also defined as a definition clear path for the X variable defined by the nodes A and B if the variable X is not defined in the sub path. 

- There is another common name for the definition clear path which is “def- clear path”. 

Now let us talk about the role that the definition clear path plays in the data flow testing. Actually in the data flow testing, there are three types of coverage that have to be provided namely:

1. Statement coverage
2. Branch coverage and lastly
3. Path coverage

Basically problems are faced with the path selection process. A definition of the variable X reaches a use if and only if there exists a sub path such that the sub path is a definition clear path with respect to the variable X. The path selection in the data flow testing is based up on the two criteria:

1. Rapps and Weyuker criteria: Under these criteria the definition clear sub paths from definitions to uses are listed.
2. Laski and Korel criteria: Under these criteria the various combinations that reach uses at a node via some sub path are listed.

How does Definition Clear Path play a role in Data Flow Testing?

- Definition clear paths have been known to make remarkable improvements in the control flow techniques for data flow testing.

- A rational is obtained for which there is a need to take in to consideration all the combinations of the sub paths. 

- The “all uses” is the most commonly preferred criteria.

- There are some paths in a program that are infeasible and it is these paths that pose a big problem in the data flow testing. 

- The path testing strategies are based up on the data flow anomalies. 

- Enough paths are required to be tested so that it is ensured that every object in the program has been initialized before use and have been used at least once during the program execution. 

- For a complete data flow testing it is required that definition clear paths are executed by the test cases from each node that contains a defined variable.

What is the entry and exit criterion for system testing?

Scientifically, the term system testing is looked up as the testing of both the components of the system i.e., software and hardware. It has been categorized as one of the software testing techniques under the category of black box testing, and so this eliminates the need of any knowledge regarding the internal structure and design of the source code.

The system testing is carried out on an integrated, complete and finished software system or artefact because after the completion of the system only, it can be checked for its ability to cooperate according to the specified conditions and requirements.

This article states the entry and exit criteria for a software system or application to undergo system testing.

About System Testing

- The system testing is all aimed at the detection of all the discrepancies, defects and constraints lurking in the software system or application.

- System testing takes up the job for dealing with the inconsistencies and flaws that are present in the system software which is in turn constituted up of integrated software and hardware components.

- System testing is carried out in concern for the detection of defects within present within the assemblages i.e., inter- assemblages representing the software system or application as a whole entity.

- You don’t have to worry if you already have your software incorporated successfully with the appropriate hardware system, it can be still served as input to the test.

- The software system itself is an integrated part of any other software or hardware system and has dealt with the system integration testing successfully can also be considered as an input for the system testing.

- Being very non similar to the integration testing and unit testing, the system testing takes the whole software system or application as one unit or module for testing.

- We can say that in a way the system testing is a means to explore the functionality of a software system.

- For carrying out system testing there are two options: either you carry it out before you software system or application is assembled or after the system has been finished and completed.

- While carrying out the system testing, you should always make sure you are strictly following the defined systematic procedures.

- Only specifically designed test cases should be used for performing system testing.

- System testing holds the responsibility for dealing with the basic and important contexts namely:
1. Functional requirement specification (FRS) and
2. System requirement specification (SRS).

- System testing does not only deal with the testing of the design of the software system but, also its features as expected by the customers and behaviour.

Entry criteria for System Testing

1. All the units must have passed the unit testing and that too with successful grades.

2. All the modules or units must have successfully passed the integration testing with good grades.

3. Their should be a resemblance between the surrounding environment and the production environment.

4. The following steps should have been followed during the system testing:

- Creation of the system test plan.
- Creation of the test cases.
- Creation of the scripts for building the environment.

Exit Criteria for System Testing

1. All the requirements specifications mentioned in the documentation have been met.

2. The issues have the severity level of 1 and 2 have been resolved.

3. The application is now working as per the expectations of the users.

4. ll the issues related to the critical defects must have been fixed and closed.

5. All the necessary documentations (like quick start guide, final publications draft etc) have been reviewed.

What is the entry and exit criterion for user acceptance testing?

The acceptance is quite an important choice for the clients or the customers. It plays a very important role when it comes to the addressal of the issues related to the acceptance of the software system or application by the client or the customer.

Like any other testing, the acceptance testing also has some of its pre defined entry and exit criteria that a software system or application needs to satisfy before it can undergo the acceptance testing process.

This article is focussed up on those entry and exit criteria only but first let us take a glimpse of what acceptance testing really is so that it becomes easy for us to understand the entry and exit criterion for the acceptance testing.

About User acceptance Testing

- For the field of software engineering, this kind of testing has been termed as the user acceptance testing since it is carried out in order to obtain confirmation from the user or the client that the developed software system or application meets its specified and agreed up on requirements and specifications.

- This confirmation is provided by the SME or the subject matter expert who is the owner of the software system or application under testing after carrying out several trials and reviews.

- The user acceptance is therefore one of the final software testing methodologies that is carried out before handing over the software system or application to its owner.

- The user acceptance testing is preferably carried out via the users of that software system or application which are in the contact of the client or mentioned in the users requirements specification document.

- As many as the formal tests required are created by the test developer or designer based on the different levels of the severity of the errors and flaws.

- Typically, for an ideal acceptance testing the test designer should handle the creation of the formal system and integration test cases for the same software system or application.

- The user acceptance testing serves as a means of final verification of the well functioning of the software system or application by creating the real world conditions for the its usage as it will used by the customer and required business function under process.

- The system needs to perform as intended because then only it can be subjected to its reasonable extrapolation in the process of product at the same level of the stability and reliability.

- Unlike other software testing methodologies, the test cases of the user acceptance testing do not serve to identify the simple problems, errors and show stopper defects (system crashes, failures and hangs etc).

- It is so because all such defects are fixed by the testers and developers in the earlier stages of the software testing life cycle.

- There is another reason for this testing to be performed which is to give confidence and assurance to the client or the customer that the system will perform well in the production phase.

- Some contractual or legal requirements are also signed at the end of the acceptance testing.

Entry Criterion for User Acceptance Testing

1. The transition meeting of the integration testing must be signed off.
2. The functional requirements and the business requirements have been met and verified in the integration testing.
3. The test cases for the user acceptance testing are ready to be executed.
4. The test environment for the UAT should be ready.
5. Required access of the resources for testing should be granted.
6. All the critical bugs have been previously addressed.
7. The reports of the previous testing should be handed over to the client.

Exit Criterion for User Acceptance Testing
1. No defects are found.
2. Defects with the medium priority are found.
3. There is no hindrance in the business process.
4. The UAT meeting is signed off.

What is the entry and exit criterion for unit testing?

First let us brief up ourselves with what the concepts of the unit testing and then we shall proceed further in discussing about the entry and exit criterion for unit testing.

About Unit Testing

- Unit testing is a self explanatory term.

- It involves the testing of the smallest units or modules of the software system or application in order to determine whether or not they are working properly and in the desired manner.

- Since this testing methodology is employed for testing the smallest individual unit of the software system or application, hence it got the name “unit testing”.

- If the program or application has been developed using procedural programming oriented language then the entire module is treated as units in the unit testing or else in general, the individual procedures and functions are the units.

- For the applications and softwares in which objected oriented programming has been implemented, the entire application’s interface.

- The test cases for the unit testing are created by the white box testers since they have an in depth knowledge of the software system or application.

- Sine the units are tested in isolation with the other units and independently, hence the test cases created for unit testing are also independent in nature.

Unit Test Case

- A unit test case can be assisted in unit testing by using substitutes like those mentioned below:
1. Mock objects
2. Methods stubs
3. Test harnesses
4. Fakes and so on.

- The test cases for the unit testing are both written and executed by the software developers.

- This ensures that the source code is at par with the design and architecture of the software system or application and works as accordingly as specified.

- The test cases can be implemented in two ways i.e., manually or through the use of automation tools as a part of build automation.

Entry Criterion for Unit Testing

- The functional specifications requirements of the software system or application under test need to be frozen.

- The technical design specifications need to complete and approved. They should have been released.

- The system specifications document also should be complete, approved and released.

- No issue should be pending in the query issue register regarding the requirements under the unit testing.

What else unit testing involves?

- Apart from just testing the modules, the unit testing involves the verification of the requirement specifications in regard with the finalized design and functional specifications requirements.

- For harnessing the maximum benefits of the unit testing, all of the requirements specifications should be signed off.

- Unit testing is said to be complete when the source code is complete and that too according to the specifications.

- All the design specifications should meet the design standards and the entire unused variable, code files should have been removed from them.

- The code documentation including the commenting and AOT documentation must also be complete and approved.

- To put it simple the code should be in such a state so as to be released to the customers or the clients.

Exit Criterion for Unit Testing

- All the units have successfully passed the unit test.

- The code is complete according to the requirements.

- No elements and features are missing.

- The possible errors and warnings have been resolved. This criterion is optional since most of the times it’s not possible to remove all of the errors.

- Code optimization for all the three tiers has been done.

- There is no error in the performance optimization.

- All label files have been created.

- All unused files have been removed.

- Redundant code is removed.

What is the entry and exit criterion for production verification testing?

Some entry and exit criteria have been predefined for all the software testing methodologies and in the same way some criterion have been defined for the production verification testing also.

For a software system or application to process from one phase of the software testing life cycle to the other one, it has to satisfy all the exit criteria of the previous software testing methodology and entry criteria of the software testing methodology that it is about to undergo.

So this article states the entry and exit criteria for the production verification testing and before that we have given a discussion about the production verification testing.

About Production Verification Testing

- Production verification is also an important part of the software testing life cycle like all the other software testing methodologies and is carried out after the successful completion of the user acceptance testing phase.

- The entire production verification testing deals with the simulation of the cutover of the whole production process as close to the true value as possible.

- Production verification testing also serves as an opportunity for the conduction of a full real like full dress rehearsal of the changes in the business requirements if any.

- The production verification is not like the parallel testing since there is a difference of the goal.

- The goal of the production verification testing is to verify that the data is being processed properly by the software system or application rather than comparing the results of the data handling of the new software system software or application with the current one as in the case of parallel testing.

- This software testing methodology has been designed for the verification of the following aspects:
a) Proper running of any batch processes against the actual data values of the production process.
b) Business process flows
c) Proper functioning of the data entry functions

Here we list some of the entry and exit criteria of the production verification testing:

Entry Criteria for Production Verification Testing

- For the production verification testing to commence it is important that the documentation of the previous testings is produced and the issues and faults that were discovered then are fixed and closed.

- If there is a final opportunity for the determination of whether or not the software system or application is ready for the release, it is the production verification testing.

- The completion of the User acceptance testing is over and has been approved by all the involved parties.

- The documentation of the known defects is ready.

- The documentation of the migration package has been completed, reviewed and approved by all the parties and without fail by the production systems manager.

- For the production verification testing, the testers need to remove or uninstall the software system or application from the testing environment and re-install it again as it will be installed in the case of the production implementation.

Exit Criteria for Production Verification Testing

- The processing of the migration package is complete.

- Apart from just the simulation of the actual production cut over, the real business activities are also simulated during the phase of the production verification testing.

- Since it is the full rehearsal of the production phase and business activities, it should serve the purpose of the identification of the unexpected changes or anomalies presiding in the existing processes as a result of the production of the new software system or application which is currently under the test.

- The installation testing has been performed and its documentation is ready and signed off.

- The documentation of the mock testing has been approved and reviewed.

- A record of the system changes has been prepared and approved.

What is the entry and exit criterion for integration testing?

Integration testing as we know is the second main software testing methodology in the software testing life cycle or STLC after unit testing. It is succeeded by the system testing and system integration testing substantially.

Like for every other testing methodology, a software system or application can undergo testing only after passing some pre- defined entry criteria and for exiting the testing phase also it needs to pass some pre- defined exit criteria in integration.

This article is focussed up on the entry and exit criterion for the integration testing. But, let us brief up ourselves with the concepts of integration testing so that it becomes easy for us to define with the entry and exit criteria defined for integration testing.

About Integration Testing

- Integration testing is sometimes abbreviated as I & T i.e., integration and testing.

- Integration testing has been named so because it involves the integration of the software system or application modules before carrying out the testing on them.

- Thus, we can say that the it is contrary to the unit testing since here it involves the testing of the system modules as groups of two or more modules rather than carrying out testing on them as individual modules like in the case of unit testing.

- Integration testing is often carried out after the unit testing but before the validation testing.

- Only those individual system modules which have passed the unit testing with successful grades can be considered as a valid input for the test cases created for the integration testing.

- Though, in some cases there might be some exception if error present in any individual module can only be rectified in the later stages of the testing cycle.

- When the groups or aggregates of the modules pass the integration testing, then only they can be moved further for the system testing and system integration testing.

- The reliability requirements, performance requirements and the functional requirements that have been specified for the major design items are what are tested by the integration testing.

- By major design items, here we mean the group of units or modules or assemblages.

- These assemblages or groups of units are put together via their interfaces by implementing the black box testing techniques and the faults and errors are simulated according to the proper defined parameters and the input data values.

- The inter process communication occurring as a result of the integration between the several unit groups is also tested apart from just testing the above mentioned requirements.

- The implementation of these small sub systems takes place through the interface of the input.

- A verified base is prepared on which the various assemblages are placed which is then used as a support to the integration testing test cases for the testing of the other assemblages.

- This approach has been termed as the “building block approach”. Integration testing can be implemented via any of the below mentioned approaches:
1. Big bang approach
2. Usage model testing
3. Top down approach
4. Bottom up approach
5. Sandwich testing

Entry criteria for Integration testing

- The system units or modules needed for the integration must be ready to be integrated.
- Unit testing must have been completed and closed.
- All the issues discovered during the unit testing must have been addressed and closed.
- The test scripts for the integration testing should be ready.
- The testing should be commenced as per the schedule and the plan.
- The test environment should be ready.

Exit criteria for Integration testing

- Issues discovered during the integration testing must be addressed, fixed and closed..
- 10 percent of the benchmark as decided by the QA people is supposed to be allowed for the issues that outstand.
- All the test cases must be executed and passed.
- Transition meeting should be signed off.

What is the entry and exit criterion for regression testing?

Regression testing is a very common software testing methodology and its importance is not hidden from us. Regression testing forms a part of software testing life cycle of every software system or application and project is finalised before running it at least once under the regression testing.

Like the other software testing methodologies the regression has also defined some entry and exit criteria for itself that a software system or application needs to fulfill satisfactorily to undergo regression testing.

But first we will state a brief discussion regarding the regression testing since then it will be easy for us to recognize the entry and exit criteria for the regression testing.

About Regression Testing

- Regression testing is just like the validation testing and is aimed at providing a repeatable and consistent validation of all the changes that have been made to the software system or application under its development or after its completion or after being modified.

- There are chances that at the fixation of a defect new faults and errors might be introduced in to the code of the software system or application that may cause further problems in the functioning of the software system or application.

- An uncertainty is introduced up to some level regarding the ability of the software system or application to make repetition of everything that went right till the encounter of the point of failure.

- To put it simply we can say that the regression testing is nothing but the retesting of the whole software system or application or a selected part of it that has underwent some changes or has been modified for assuring that the encountered fault does not re- occur and none of the previously properly working components of the system like features and functions do not fail as the affect of the introduced modifications.

How to conduct regression testing?

There are many options for conducting regression testing.

- It can either be conducted at the end of the development process of the software system or application.
- It can also be carried out in parallel with the substantial completion of the other software testing methodologies in different phases of the software testing life cycle.

Importance of Regression Testing

- In general, the regression testing is thought of as a quality check tool which controls the quality of the software system or application in regard to the changes made to that particular software system or application and ensures that it does not affects the working of the other previously working components.

- One extremely important point to be noted is that the regression testing is not about testing whether the discovered bugs and errors have been fixed or not but it is all about testing the software system or application up to the point at which the system is not affected by the changes made to fix the bugs.

Entry and Exit criterion for Regression testing

Now we list some of the entry criteria that an application needs to satisfy for undergoing regression testing:
1. The documentation of the defect or the bug is ready and the defect or the bug is repetitive.
2. For the purpose of the identification and tracking of the regression testing efforts, a defect tracking record or a change control has been opened.
3. The creation, review and approval of the tests that are specific to the defect have been done.

There is an only one exit criterion for the regression testing which is that the software system or application should not show any negative result i.e., malfunctioning of any component that was previously working alright before any new changes were introduced to the software system or application for fixing the bug.