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.

How to test software requirements specification?

Software requirements specifications is often called “SRS” in its short form. We
can simply put it as a specific requirement for a software system or application.

PURPOSE OF SOFTWARE REQUIREMENTS SPECIFICATION

- These requirements specifications give a view of how exactly the system should and how it should behave.
- The software requirements specification comes with a set of cases describing all the possible interactions of the users with the software system or application.
- Such test cases have been termed as ‘use cases”.
- The software requirements specifications contains both kinds of requirements i.e., functional requirements as well as non functional requirements.
- Software requirements specification is an important sub field under the software engineering field.
- The software requirement specification provides a way to enlist all the requirements necessary for the development of the software project in one place.
- It deals with the following issues with regard to the software system or application:


1. Specification
2. Elicitation
3. Analysis and
4. Validation


OVERVIEW OF SOFTWARE REQUIREMENT SPECIFICATION

1.Introduction
This mentions the purpose of the software along with its scope, definitions, a brief overview and a set of references.

2.Overall Description
This section of the SRS describes the perspective, functions, user characteristics, constraints, dependencies and assumptions of the software application.

3. Specific Requirements
This is the most important part of an SRS and includes description of functions, interfaces, logical data base requirements, performance requirements, design constraints and key features.

HOW TO PRODUCE AN EFFECTIVE SOFTWARE REQUIREMENTS SPECIFICATION?

- For producing an effective software requirements specification, you need to test it.
- Therefore a software requirements specification testing has been designed.
- It is popularly known as requirements analysis.
- Requirements analysis analyzes all those tasks that help in identifying the requirement specifications of the software system as well as the requirements specifications itself.
- This actually forms the initial stage of the requirements engineering which is again concerned with the above listed activities.
- The analysis of the requirements specification is crucial for any software system or application.
- All the identified requirements should have the following properties:


1.Actionable
2.Can be documented
3.Testable
4.Traceable
5.Measurable and
6.Defined


PHASES OF SOFTWARE REQUIREMENTS SPECIFICATION TESTING
The software requirements specification testing comprises of the following three phases:

#1. Elicitation of the Requirements:
- This phase involves the identification of the requirements of the consumers.
- This process of communicating with the users and gathering requirements is very well known as requirements gathering.

#2. Analysis of the Requirements:
- This phase involves the determination of the clarity, completeness, ambiguity, contradiction of the requirements.
- If issues are found, they are resolved.

#3. Recording of the Requirements
- There are various ways in which the requirements might be documented.
- Whatever the way maybe, it should be clear and concise.
- Some commonly used methods are: natural language documents, user stories, process specifications and use cases.

How to define a task set for a software project?

The process model is defined by a set of tasks which enables the software team to define, develop and support computer software irrespective of whether the software team uses an incremental model, linear sequential method, an evolutionary model. Nearly every project will have a different task set which means that no single task is appropriate for all projects.

The set of tasks that a simple project uses or needs is different from the set of tasks that is needed by a large complex system. A collection of task sets should be defined to meet the needs of different types of projects by the software process that is effective.

The task set that is developed should be distributed on a project time line. Task set depends on the type of the project and the rigor with which the software team decides to do the work. Different kind of projects encountered by software organizations are:

- Application enhancement projects
- Content development projects
- New application development projects
- Application maintenance projects
- Re-engineering projects

The factors that affect the choice of the task set for a single project type are:
- project size.
- number of potential users.
- critical nature of mission.
- longevity of the application.
- requirements stability.
- maturity of applicable technology.
- embedded and non-embedded characteristics.
- performance constraints.
- project staff.
- re-engineering factors.

For example, in concept development projects, major tasks followed are:
- Concept scoping
- Preliminary concept planning
- Technology risk assessment
- Concept proof
- Implementation concept
- Customer reaction

Requirement Model - Obtained during Elaboration phase

During elaboration, the information that is obtained from inception and elicitation are refined and expanded to produce two models:
- Requirements Model
- Analysis Model

The requirement model provides a model of the system or problem domain. It consists of three things:

Use Case Model
Use case model describes what the system does. It serves as a contract between the customers, end users and developers. The Use CaseModel consists of two parts, namely, the use case diagrams and use case specifications.
The use case diagram shows the functionality that the system provides and which users will communicate with the system. It consists of actors and use cases.
The use case specifications are textual documents that specify properties of the use cases.

Supplementary Specifications
Requirements that do not map to a specific use case are part of supplementary specifications. These requirements may be non functional or system constraints. Non functional requirements includes maintainability of the source codes, usability, reliability, performance, and supportability. System constraints restricts our choices for constructing a solution.

Glossary
It defines a common terminology for all models. This is used by the developers to establish a common dialect with customers and end-users.

What are Formal Technical Reviews (FTR)? What is the aim and guidelines for formal technical reviews?

When tasks are performed in software process, the result is a work product. These results contribute to the development of quality software.
A formal technical review (FTR) is a software quality assurance activity performed by software engineers with the following objectives:
- uncover errors in function, logic or implementation of the software.
- verify that the software meets its requirements.
- ensure that the software has been developed according to the standards.
- achieve uniform software.
- make projects manageable.

Each formal technical review is conducted as a meeting and is considered successful only if it is properly planned, controlled and attended.
The purpose of formal technical review serves as a training ground for junior engineers and to promote backup and continuity.
Constraints of formal technical review meeting’s include 3-5 people involvement, advanced preparation not more than 2 hours for each person, the duration of the review meeting should be less than 2 hours and focus on a specific part of a software product.

There are few guidelines while conducting formal technical reviews. They are:
- Work product should be reviewed and not the developer.
- Make a practice to write down notes while conducting reviews.
- Agenda should be planned.
- Minimize the debate and discussions.
- Keep the number of participants to a minimum and insist on preparing for the review.
- The defect areas should be pointed but no solution should be provided.
- A checklist that is to be reviewed is provided.
- Schedule the reviews as part of the software process and ensure that resources are provided for each reviewer
- Check the effectiveness of review.

The System Engineering Hierarchy - System Modeling

Good system engineering begins with a clear understanding of context - the world view - and then progressively narrows focus until technical details are understood. System engineering encompasses a collection of top-down and bottom-up methods to navigate the hierarchy.
System engineering process begins with a world of view which is refined to focus more fully on a specific domain of interest. Within a specific domain, the need for targeted system elements is analyzed. Finally, the analysis, design, and construction of targeted system element is initiated. Broad context is established at the top of the hierarchy and at the bottom, detailed technical activities are conducted. It is important for a system engineer narrows the focus of work as one moves downward in the hierarchy.

System modeling is an important element of system engineering process. System engineering model accomplishes the following:
- define processes.
- represent behavior of the process.
- define both exogenous and endogenous input to model.
- represent all linkages.

Some restraining factors that are considered to construct a system model are:
- Assumptions that reduce number of possible permutations and variations thus enabling a model to reflect the problem in a reasonable manner.
- Simplifications that enable the model to be created in a timely manner.
- Limitations that help to bound the system.
- Constraints that will guide the manner in which the model is created and the approach taken when the model is implemented.
- Preferences that indicate the preferred architecture for all data, functions , and technology.
The resultant system model may call for a completely automated or semi automated or a non automated solution.

What is an architectural style and pattern?

There are many architectural styles associated with the software that is built for computer based systems. The style describes a system category that encompasses:
- set of components.
- set of connectors enabling communication, coordination and cooperation among components.
- constraints.
- semantic models enabling a designer to understand overall properties of a system.

Architectural style is a transformation which is imposed on the design of an entire system. The intent is to establish a structure for all components of the system. When an existing architecture is re engineered, fundamental changes to the structure of the software results.
Architectural pattern imposes a transformation on the design of an architecture. Differences between pattern and style are:
- Scope of pattern is less broad.
- Pattern imposes a rule on architecture describing how software will handle some aspect of its functionality.
- Architectural patterns tend to address specific behavioral issues within context of architectural.
Patterns can be used in conjunction with an architectural style to establish the shape the overall structure of a system.

Relationships And Relationship Sets

A relationship is an association between several entities.
A relationship set is a set of relationships of the same type.
A relationship type R among n entity types E1, E2,....., En defines a set of associations or a relationship set among entities from these types.
In ER diagrams, relationship types are displayed as diamond-shaped boxes, which are connected by straight lines to the rectangular boxes representing the participating entity types. The relationship name is displayed in the diamond-shaped box.

RELATIONSHIP DEGREE : The degree of a relationship type is the number of participating entity types. A relationship type of degree two is called binary, and one with degree three is called ternary.




ROLE NAMES and RECURSIVE RELATIONSHIPS :
Role names signifies the role that a participating entity from the entity type plays in each relationship instance, and helps to explain what the relationship means.
Role names are not necessary in relationship types where all the participating entity types are distinct, since each entity type name can be used as a role name. However, in some cases, the same entity type participates more than once in a relationship type in different roles. In such cases the role name becomes essential for distinguishing the meaning of each participation. Such relationships are called recursive relationships.


MAPPING CONSTRAINTS :
An E-R scheme may define certain constraints to which the contents of a database must conform.
* Mapping Cardinality : It expresses the number of entities to which another entity can be associated via a relationship. For binary relationship sets between entity sets A and B, the mapping cardinality must be one of:
1. One-to-one: An entity in A is associated with at most one entity in B, and an entity in B is associated with at most one entity in A.
2. One-to-many: An entity in A is associated with any number in B. An entity in B is associated with at most one entity in A.
3. Many-to-one: An entity in A is associated with at most one entity in B. An entity in B is associated with any number in A.
4. Many-to-many: Entities in A and B are associated with any number from each other.
The appropriate mapping cardinality for a particular relationship set depends on the real world being modeled.
* Existence Dependencies: if the existence of entity X depends on the existence of entity Y, then X is said to be existence dependent on Y. (Or we say that Y is the dominant entity and X is the subordinate entity.)
For example,
o Consider account and transaction entity sets, and a relationship log between them.
o This is one-to-many from account to transaction.
o If an account entity is deleted, its associated transaction entities must also be deleted.
o Thus account is dominant and transaction is subordinate.