Cause-Effect Graphing is a black box testing - Explain?

So many testing techniques have been categorized under the black box testing and the cause effect graphing is one of them and that is what the whole article is all about.

- A directed graph created for the purpose of mapping of the set of causes to a set of effects is nothing but a cause effect graph.
- The causes mapped in the graph are merely the input to a software system or application and the effects can be thought of as the corresponding outputs.
- The right of the cause effect graph houses all the effects with their corresponding nodes and the left side shelters all the causes and along with their corresponding nodes.
- A graph representing causes and effects in such a way is said to be a typical cause effect graph.
- It may also make use of certain intermediate nodes for the representation of the relation between the input and the output using the logical operators like AND, OR etc.
- The constraints can be effectively added to the effects and causes in the graph and these represented as the labelled edges using a dashed line along with the symbol of the constraint.

Constraint Symbols for the Causes:
1. E – exclusive
2. OaOO – one and only one
3. I – at least one

- The first constraint is used to state that at any instant any two causes (say cause 1 and cause 2) cannot be true simultaneously.
- The second constraint i.e., the inclusive constraint is used to state that at least one of the two or more numbers of causes must be true.
- The third constraint “one and only one” is used to state that the only one among all the constraints can be true.

Constraints for the Effects

1. R – requires
2. M – mask

- These are the only two valid constraints for the effects.
- The first one states that if one of the causes is true, then it implies that the other one also must be true and it also states that only one of the two constraints can be true and other can be false.
- The second constraint i.e., the mask constraint states just the opposite of the first constraint i.e., if one of the effects is true, then the other must be false.

"One point to be noted here is that the mask constraint only relates to the effects rather than relating to the causes like other constraints."

The direction of the graph is represented as shown below:
Causes -> Intermediate nodes -> Effects

Normal Forms of Cause Effect Graph

The cause effect graph is always rearranged in such a way that at any point between any input and output there lays only one node. Two normal forms of the cause effect graph have been identified:

- Conjunctive normal form
- Disjunctive normal form

When is Cause Effect Graphing performed?

One of the main purposes of the cause effect graph is the generation of the reduced decision table. The cause effect graphing is performed after the following tasks have been completed:

1. All the requirements have been reviewed to check out for any ambiguity.
2. All the requirements have been reviewed for their content.
3. It has been ensured that the requirements are complete and correct.

Cause effect graphing is basically used for hardware testing, but now it has been adopted for the use in the software testing.

It takes in to consideration only the desired external behaviour of the system and therefore it has been categorized as a black box testing technique and only selects the test cases that represent a logical relation between the causes and effects for the production of the test cases.

User Interface Analysis and Design - Testing Interface Mechanisms

There are interface mechanisms through which the interaction between the user and the web application occurs. There are some testing interface mechanisms described below:
- Links are tested to ensure that proper content object or function is reached. External link testing should occur throughout the life of the web application. Links within content object are also tested. Part of a support strategy should be regularly scheduled link tests.

- Client side scripting should be repeated whenever a new version of a popular browser is released. Compatibility testing should be done to ensure that the scripting language that is chosen is working properly in environmental configuration that support the web application.

- Forms testing is done at two levels:
At macroscopic level, tests ensure that labels correctly identify fields within the form; server is receiving the information that is contained within the form; defaults are used when user is not selecting from pull down menu or set of buttons; browser functions do not corrupt data and error checking script is working properly.
At targeted level, tests ensure that form fields are of proper width and data types; appropriate pull-down menus option are specified; tab key is performing in the right manner and browser auto fill features do not lead to data input errors.

- Dynamic HTML in web applications are tested to ensure that the dynamic display is working fine.

- Pop up windows are tested to ensure that a pop up window is properly positioned and sized; the design of pop up window is consistent with the aesthetic design of interface; scroll bars are working properly.

- Streaming Content is tested to ensure that they are up to date, properly displayed and restarted without difficulty.

- Cookies are tested at both server and client side. On server side, tests are conducted to ensure cookie is properly constructed and transmitted to client side. Proper persistence of cookie is tested to ensure that the expiration date is correct. On client side, tests are conducted to ensure whether web applications properly attaches existing cookies to specific request.

Overview of User Acceptance testing - what does it mean and what are its forms.

User Acceptance Testing is often the final step before rolling out the application. Usually the end users who will be using the applications test the application before ‘accepting’ the application.
A formal product evaluation performed by a customer as a condition of purchase. The testing can be based upon the User Requirements Specification to which the system should conform. Use Acceptance testing is black box testing.

USER : System developers cannot do it, as although they are expert in writing software, they are unlikely to know anything about the realities of running the organisation, other then what they have acquired from requirements specifications, and similar documents.

Acceptance : The acceptance of a system means you are confident it will give benefit to the organisation. It does not mean that it only meets the original specification as requested.

Testing : Whenever people are asked what testing is, many of them say it is to prove the system works.
The point of UAT is for business users to try and make a system fail, taking into account the real organisation it will be working in.

User Acceptance testing can be in the form of :
Alpha Testing - Tests are conducted at the development site by the end users. Environment can be controlled a little bit in this case.
Beta Testing - Tests are conducted at customer site and development team do not have any control on the test environment.