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 are different data flow testing strategies?

Data flow testing is quite important since you do not want any unreasonable things happen to your data objects which in turn can deviate the whole control flow of your program from the right track. To make a sensible data flow testing you need to use sensible and reliable data flow testing strategies.

This article is all about such data flow testing strategies. 

There are two types of machines that are used by the data flow as mentioned below:

1. Von Neumann machine architecture
2. Multi- instruction, multi- data machines architecture (MIMD)

- Before carrying out the data flow testing, it is good to assume a bug which causes problem in the control flow of the program. 

- It is not compulsory to use the typical data flow graphs, annotated ordinary control graphs can also be used for guiding the data flow testing process. 

- Data flow graph depicts all the directed links and nodes involved in the data flow.

- All the strategies for data flow testing that we are going to discuss are structural in nature and also focus up on the actions taking place on the data objects rather then just focussing on the connectivity of the software program.

Requirements of Data flow testing Strategy

- Data flow link weights are the first requirement of any data flow testing strategy. 

- All these strategies are based up on the selection of the path segments that very well satisfy at least few of the data flow characteristics common to all the data objects. 

- A data flow testing strategy is weaker than another strategy Y if all the test cases present in Y are not included in the X. Then Y is said to be a stronger strategy. 

Important Terminologies

Let us take a look at some important terminologies before moving on to the strategies:

1. Definition clear path segment: It is a path defined with respect to a variable X that consists of various links such that the X is defined only on the first link.
2. Simple path segment: In such a path one of the two nodes are visited twice.
3. Loop free path segment: This path is contrary to the simple path segment in the way that in this path every node is visited once for the maximum.
4. Du path segment: It is a path that is simple and definition clear since its last link consists of a computational use of variable X.

Different Strategies for Data Flow Testing

Below described are the different strategies for the data flow testing:

1. ADUP or all DU paths: This strategy is considered to be the strongest among all the data flow testing strategies. It takes in to account all the du paths that occur in the definitions of all the variables to their every use. This strategy is a strong data flow testing criteria also. Another advantage of this strategy is that one of its tests can satisfy many definitions at a time.
2. AU or all uses strategy: Under this strategy at least one of the definition clear paths from all the definitions of a variable has to be tested or exercised under a test. The task or burden of testing is actually reduced here i.e., the path coverage is cut down to branch coverage.
3. APU + C or all p uses/ some c uses strategy: This strategy covers up at least one definition free path to every predicate use for every definition of the function. If this is not able to over up all the definitions of the variable, then it is recommended that computational use test cases are exercised.
4. ACU + P or all c uses/ some p uses strategy: This strategy is just the opposite of the above strategy.
5. AD or all definitions strategy: It covers only the definition of the variable. 

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

Whenever you have discussed about the data flow testing you must have came across the term simple path segments while discussing about the strategies for data flow testing. Many of us are not quite clear with the concept of the simple path segments and what role have they got to play in the data flow testing. This article is all about the simple path segments and the role that they have got to play in the data flow testing. 

First we shall brief up ourselves with the concepts of the data flow testing before moving on to the topic of the simple path segments and their role. 

What is Data Flow Testing

- Data flow testing includes all those strategies that have been based up on the selection of the paths via the control flow of the program for discovering the sequence in which the events related to the object’s status take place.

- A primary bug assumed during the data flow testing is that though the control flow is generally correct, there is some fault with the software system or application since the data objects are not available when they are supposed to be or weird things happen to the data objects. 

- Even if some problem is found to preside in the control flow of the program it is initially detected by the data flow analysis. 

- One of the most aiding tool in the data flow testing are the control flow graphs which are the graphs consisting of directed links and nodes. 

- The objective of the data flow testing is to discover the deviations in the data flow. Three types of data objects have been defined namely:

1. Killed or undefined
2. Defined
3. Usage

And some nine kinds of anomalies have been defined:

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

These anomalies are detected by the means of two anomaly detection techniques namely:

1. static anomaly detection technique and
2. dynamic anomaly detection technique

All the strategies involved in the process of data flow testing are structural. Data flow testing and path testing strategies have so many things in common. But one of difference between them is made by what one takes in to account for testing. Path and data flow testing both are emphasized up on the raw connectivity of the graph but in addition to this the data flow testing also focuses up on what happens to the data objects. There are so many terminologies associated with the data flow testing and simple path segment is one of them. The others are:

1. definition clear path segment
2. loop free path segment
3. du path segment

What is Simple Path Segment

We shall now define what a simple path segment is! 

- Any path in which the same node is visited twice at the most, such a path is called a simple path segment. 

- One can easily make out why a simple path segment is called so! 

- It is called so because it does not consists of loops in both the nodes.

- Only one node holds the loop. 

- One of the problems that are faced by the testers is of finding the simple paths. 

- This problem can be overcome by following a lower bound max- flow approach. 

- The simple path segments though being, are important in the data flow testing just like all the other path segments. 

What is specification based testing? What are its advantages and disadvantages?

Specification testing as its name suggests can be defined as the type of testing in which the software product’s performance and conformance is checked with every statement mentioned in all the available documents for reference.

- This specification based testing is carried out by specification based tester.
- The documents used for specification based checking might be user manuals, formal specifications check lists, third party documents or even advertisements.
- Specification based testing ought not to cover automatic extraction of ideas of testing from the mentioned specifications and it also not covers the use of the automated program comprehension tools.
- While carrying out the specification based testing an assumption is made in which we assume that a natural language specification exists that is to be analyzed by a human being.

The following tasks are carried out by specification tester:
- To identify the sets of reference 3 documents.
- To develop the ideas for testing those are based on contradictions and ambiguities in the documents that are being used for reference.
- To develop the list of claims and items that are to be tested based on certain assertions to be tested and are listed in the reference documents. Later the ideas are associated with each other.
- To create the matrices that are traceable and that lists the assertions and the items to be tested and test cases associated with those assertions and ideas.

One of the most important unifying features of specification based testing is that the testing starts with the reference documents and the testing strategies and cases are based on what is there in the reference documents.

The following examples will make the use of specification based testing clear:

- Undo tool in paint: does not performs as specified.
- Zoom in tool in open office presentation: does not perform as specified.
- File and folder naming function in windows XP does not perform as specified.
- New profile creation tool in fire fox.
- Function for deleing form information tool.
- Help documentations are incorrect.
- Keyboard short cuts for closing windows.
- Conflict between the dream weaver and inbox manual.

The specification based testing has got both advantages and disadvantages.

- Specification based testing though being necessary is not sufficient to guard or detect certain risks.
- One of the advantages of specification based testing is that it reduces the number of test cases.
- It proves very efficient in find most of the comer cases.

- Though the bugs discovered are very small, the cannot be discovered by testing in the real system since the command sequences that have lead to these bugs would have never been caused in the real system.

- Specification based testing states the specifications as the executable properties.
- Errors can either be in the program or in the specifications.

- Specification based testing can be defined as a process that tests a software system or application based on what its behavior should be based on its specifications.

- In specification based testing, test cases are developed based on the specifications of the software system or application.

- Tests can be developed even before the actual creation of the program and its implementation.

- Without actually writing the program, a set of input data for testing can be generated based only on the given specifications and without even knowing the implementation of the test cases.

- This generated test data will be sufficient to test a software system or program that would have been written in accordance with these specifications.

- If the specifications seem to be incomplete, the assumptions can be stated about how the specifications can be clarified and completed.

What are the important elements in search engine optimization Part I?

SEO web design is one of the most appropriate strategies to keep the competition.
A successful search engine optimization has few important elements includes a well targeted keyword focus, strong page element optimization and good quality content.

Keywords are most important element for search engines. These keywords are what search strings are matched against.The most crucial step is to find the correct keyword that can be used to optimize.

- Choosing the right keyword to optimize. It is best to focus on less competitive and highly specific keywords. The keyword should have the property of describing what is the purpose of your website. Also, check whether these keywords are relevant to your website or not.

- The website should be rich in keywords and have good keyword density. It is a measure to judge how relevant is the page.Keeping 5 to 10 keywords is termed as OK keyword density. Keyword stuffing should not be practiced.

- Quality of keywords and their position on the seb page is also very important. Keywords that appear in the heading, title are more effective than the keywords that are placed at the bottom.

- A balance has to be there between url keywords and site usability.
- The contents of page title tag are displayed during search so this is the special place where keywords can be given.

- From an SEO point of view, it is good to have as many headings with good keywords in it. The headings should not be very long as readability becomes difficult.

What are different ways to test databases?

Database testing should be kept simple. Database testing would include:

- Database Sandboxes
A sandbox is defined as a technical environment whose scope is well defined and respected. There are various types of sandboxes which can be used to work. In each sandbox, the database is copied. The new functionalities are implemented, existing functionality are refactored, validated in development sandbox and once you are satisfied with work, it gets shifted to project integration sandbox. In project integration sandbox, system is rebuild and tests are run to ensure nothing is wrong.
The advantage of sandboxes is that it helps to reduce the technical errors adversely affecting large number of people.

- Writing database tests
Writing database tests include setting up the test, running the tests using database regression testing tool and checking the results by comparing the current values against the results that you expected.

- Setting up strategies for database tests
To know the state of the database, put the database in known state before running the test suite. Common strategies for doing this is to start afresh and data reinitialization. Strategies for creating test data for writing database tests are having source test data, developing and maintaining test data creation scripts and self contained test cases.

- Database testing tools
There are two kind of database testing tools needed to test RDBMS: testing tools for interface tests and the other for internal database tests. Couple of things to remember here is that testing tools should support the language that you are developing in. Secondly, database should be put in a known state. Some database tetsing tools are:
Unit Testing Tools which enable you to regression test the database.
Load testing tools which simulate high usage loads on your database letting you know whether system's architecture can stand up to that level.
Test data generator are useful when large amounts of data is needed may be for stress and load testing.

What are different startegies for black box testing?

Writing and executing test cases is an expensive task. Whatever test case is written, it should hint towards a different mode of failure. Testing strategies for black box testing are:
- Customer Requirements tests
Requirements are very important for black box testing. Each and every customer requirement should be tested. To do this, every requirement is traced to its test case and every test case to its customer requirement. The first test case is to write a most used success path ( a path that is error condition free) and proceed by planning more success paths. Some failure paths (a path that has errors in it) are also planned. Execution of tests is done so that risky requirements are tested first. It would give more time to fix the errors before the product delivery.

- Equivalence Partitioning
It is a strategy that reduces the number of test cases that are needed to be developed. The input domain is divided into classes. Test cases should be designed so that the inputs lie within these equivalence classes. For each equivalence class, set of data should be treated same by the module under test and should produce same result.

- Boundary Value Analysis
Mistakes generally occur at boundaries of the equivalence classes. Boundary value analysis guides you to create test cases at the boundaries of equivalence classes. Boundary value is defined as a value that relates to a minimum or maximum input.

- Decision Table Testing
To record business rules, decision tables are used. In decision tables, conditions represents input conditions, actions represent events that should trigger. Each column in table is a unique combination of input condition resulting in initiating an action associated with rule. Each rule or column becomes a test case.

- Failure Test Cases
The program or the application should be robust which means that it should respond properly in case or erroneous user input.

What is Software Testing? What are its goals and principles?

Software testing is a process to detect the defects and faults before it is given to the end-users. The goal of software testing is to identify them.
- Fault Identification is the process of identifying the cause of failure; they may be several.
- Fault Correction and Removal is the process of making changes to the software and system to remove the fault.

The main objectives of software testing are:
- To design a test case with high probability of finding undiscovered bugs.
- To execute the program with the intent of finding bugs.

The principles of software testing are:
- As part of traceability analysis, every test should be able to be raced back to the requirements.
- Test should be planned long before testing begins.
- Testing should begin “in small” and progress toward testing “in the large”.
- An independent third party should conduct the test.

Software Testing Strategies integrate software test case design methods into a well planned series of steps that result in the successful implementation of the software.
A test specification is developed by the leader of quality assurance group. A Test Specification is an overall strategy that defines the specific tests that should be conducted.
Software testing begins from a single component using white-box and black-box techniques to derive test cases. Once the class is tested, integration of the class through communicationand collaboration with other tested classes is tested. The main goal is to uncover as many errors as possible.

Verification Strategies - Overview of Inspections

Inspections are static analysis techniques that relies on visual examination of development products to detect errors, violations of development standards, and other problems. Types include :
- code inspection
- design inspection
- architectural inspections
- test ware inspections

The participants in inspections include inspection leader, recorder, reader, author, inspector. All participants in the review are inspectors. The author should not act as an inspection leader, reader or recorder. Other roles may be shared among the team members. Individual participants may act in more than one role. Individuals holding management positions over nay member of the inspection team shall not participate in the inspection.

Input Criteria includes:
- Statement of objectives for the inspection.
- The software product to be inspected.
- Documented inspection procedure.
- Inspection reporting forms.
- Current anomalies or issues list.
- Inspection checklists.
- Any regulations, standards, guidelines, plans, and procedures against which the software product is to be inspected.
- Hardware product specifications.
- Hardware performance data.
- Anomaly categories.
The individuals may make additional reference material available responsible for the software product when requested by the inspection leader.

The purpose of the exit criteria is to bring an unambiguous closure to the inspection meeting. The exit decision shall determine if the software product meets the inspection exit criteria and shall prescribe any appropriate re-work and verification. Specifically, the inspection team shall identify the software product disposition as one of the following:
- Accept with no or minor re-work : The software product is accepted as is or with only minor re-work.
- Accept with re-work verification : The software product is to be accepted after the inspection leader or a designated member of the inspection team verifies re-work.
- Re-inspect : Schedule a re-inspection to verify rework. At a minimum, a re-inspection shall examine the software product areas changed to resolve anomalies identified in the last inspection.

Verification Strategies - Overview to Walkthroughs.

Walkthrough is a static analysis technique in which a designer or programmer leads members of the development team and other interested parties through a segment of documentation or code, and the participants ask questions and make comments about possible errors, violation of development standards, and other problems.
the objectives of Walkthrough can be summarized as follows:
- Detect the errors early.
- Train and exchange technical information among project teams which participate in the walkthrough.
- Increase the quality of the project, thereby improving morale of the team members.
The participants in walkthroughs assume the role of a walk-through leader, recorder, author and a team member.
To consider a review as a systematic walk-through, a team of at least two members shall be assembled. Roles may be shared among the tam members. the walk-through leader or the author may serve as the recorder. The walk-through leader may be the author.
Individuals holding management positions over any member of the walk-through team shall not participate in the walk-through.

Input to the walk-through includes:
- A statement of objectives for the walk-through.
- The software product being examined.
- Standards that are in effect for the acquisition, supply, development, operation and/or maintenance of the software product.
- Any regulations, standards, guidelines, plans, and procedures against which the software product is to be inspected.
- Anomaly categories.

The walk-through shall be considered complete when
- The entire software product has been examined.
- Recommendations and required actions have been recorded.
- The walk-through output has been completed.

Verification Strategies - Reviews - Design Review and Code Review

Design Review: A process or meeting during which a system, hardware, or software design is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include critical design review, preliminary design review and system design review.Quality assurance team member leads design review. members from development team and QA team participate in the review.

Input Criteria: Design document is an essential document for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewers comments and suggestions and the re-verification whether they are incorporated in the documents.

Code Review: A meeting at which software code is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. QA team member(in case the QA team is only involved in black box testing then the development team lead chairs the review team) leads code review. Members from development team and QA team participate in the review.

Input Criteria: The Coding Standards Document and the Source file are the essential documents for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewer's comments and suggestions and the re-verification whether they are incorporated in the documents.

Verification Strategies - Reviews - Technical Reviews and Requirement Review

Technical reviews confirm that product conforms to specifications, adheres to regulations, standards, guidelines, plans, changes are properly implemented, changes affect only those system areas identified by the change specification.
The main objectives of technical reviews are as follows:
- Ensure that the software confirms to the organization standards.
- Ensure that any changes in the development procedures are implemented as per the organization pre-defined standards.

In technical reviews, the following software products are reviewed:
- Software requirements specification.
- Software design description.
- Software test documentation.
- Software user documentation.
- Installation procedure.
- Release notes.
The participants of the review play the roles of decision-maker, review leader, recorder, technical staff.

Requirement Review : A process or meeting during which the requirements for a system, hardware item or software item are presented to project personnel, managers, users, customers, or other interested parties for comment or approval. Types include system requirements review, software requirements review. Product management leads the requirement review. Members from every affected department participates in the review.

Input Criteria: Software requirement specification is the essential document for the review. A checklist can be used for the review.
Exit Criteria: It includes the filled and completed checklist with the reviewers comments and suggestions and the re-verification whether they are incorporated in the documents.

What is Verification and different strategies of Verification - Reviews and Management Reviews

Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase.
Verification process helps in detecting defects early and preventing their leakage downstream. Thus, the higher cost of later detection and re-work is eliminated.

The different strategies in Verification are:

Review

A process or meeting during which a work product or set of work products is presented to project personnel, managers, users, customers, or other interested parties for comment or approval. The main goal of reviews is to find defects. reviews are a good compliment for testing to help assure quality. Few purposes of SQA reviews are assuring the quality of deliverable's before the project moves to the next stage. Once a deliverable has been reviewed, revised as required, and approved, it can be used as a basis for the next stage in the life cycle.
Types of reviews include management reviews, technical reviews, inspections, walk-through and audit.

- Management Reviews :
These reviews are performed by those directly responsible for the system in order to monitor progress, determine status of plans and schedules, confirm requirements and their system allocation. The main objectives of management reviews are:
* Validate from a management perspective that the project is making progress according to the project plan.
* Ensure that the deliverables are ready for management attention.
* Resolve issues that require management attention.
* Identify any project bottlenecks.
* Keeping the project in control.
Support decisions are made during such reviews include corrective actions i.e. changes in the allocation of resources or changes to the scope of the project.
In management reviews, audit reports, contingency plans, installation plans, risk management plans, software q/a are reviewed.
The participants of the review play the roles of decision maker, review laeder, recorder, management staff and technical staff.