1. Effective Modular Design
A modular design reduces complexity and result in easier implementation by encouraging parallel development of different parts of a system.
Functional Independence
The concept of functional independence is a direct outgrowth of modularity and the concepts of abstraction and information hiding.
If we want to design software so that each module addresses a specific subfunction of requirements and has a simple interface when viewed from other parts of the program structure at that time functional independence is achieved.

2. Effective Modular Design (Cont…)
Software with effective modularity (that is independent modules) is easier to develop because function may be compartmentalized and interfaces are simplified.
Independent modules are easier to maintain because secondary effects caused by design or code modification are limited, error propagation is reduced, and reusable modules are possible.
In short, Functional independence is a key for good design and design is the key to software quality.
Independence is measured using two criteria:
(1) Cohesion
(2) Coupling

3. Effective Modular Design (Cont…)
Cohesion
Cohesion is a measure of the relative functional strength of a module.
A cohesive module performs a single task within a software procedure.
We always strive for high cohesion, although the mid-range of the cohesion is often acceptable.
Cohesion may be represented as a “spectrum”.
At the low end of the spectrum, we encounter a module that perform a set of tasks that relate to each other loosely is called coincidentally cohesive.
A module that performs tasks that are related logically is logically cohesive.

4. Effective Modular Design (Cont…)
When a module contains tasks that are related by the fact that all must be executed with the same span of time is called temporal cohesion.
When processing elements of a module are related and must be executed in specific order, procedural cohesion exists.
When all processing elements concentrate on one area of a data structure, communicational cohesion is present.
High cohesion is characterized by a module that performs one distinct procedural task.

5. Effective Modular Design (Cont…)
(2) Coupling
Coupling is a measure of interconnection (the relative interdependence) among modules.
Coupling depends on the interface complexity between modules, the point at which entry or reference is made to a module, and what data pass across the interface.
In software design we strive for lowest possible coupling.

7. Effective Modular Design (Cont…)
In figure Modules a and d are subordinate to different modules.
Each is unrelated and therefore no direct coupling occurs.
Module c is subordinate to module a and is accesses via a conventional argument list, through which data are passed.
As long as simple argument list is present, low coupling (data coupling) is exhibited in this portion of structure.
A variation of data coupling, called stamp coupling is found when a portion of a data structure (rather than simple arguments) is passed via a module interface. This occurs between modules b and a.

8. Effective Modular Design (Cont…)
Coupling is characterized by passage of control between modules is called control coupling.
In figure a “control flag” (a variable that controls decisions in a subordinate or superordinate module) is passes between modules d and e.
When modules are tied to an environment external to software, high levels of coupling occur.
for eg. I/O couples a module to specific devices, formats, and communication protocols.
External coupling is essential but should be limited to a small number of modules with a structure.

9. Effective Modular Design (Cont…)
High coupling also occur when number of modules reference a global data area.
Common coupling, as this mode is called, is shown in figure. Modules c, g and k each access a data item in a global data area (eg. A disk file or a globally accessible memory area).
The highest degree of coupling, content coupling, occurs when one module makes use of data or control information maintained within the boundary of another module.

10. Design heuristics for effective modularity
once program structure has been developed, effective modularity can be achieved by applying the design concept. The program structure can be manipulated according to the following set of heuristics:
Evaluate the “first iteration” of the program structure to reduce coupling and improve cohesion.
Attempt to minimize structures with high fan-out; strive for fan-in as depth increases.
Evaluate module interfaces to reduce complexity and redundancy and improve consistency.

11. Design Documentation
The overall scope of the design effort is described in the design documentation.
The data design is specified.
Database structure, any external file structures, internal data structures, and a cross reference that connects data objects to specific files are all defined.
The architectural design indicates how the program architecture has been derived from the analysis model.
In addition, structure charts are used to represent the module hierarchy.

12. Design Documentation (Cont…)
The design of external and internal program interfaces is represented and a detailed design of the human/machine interface is described.
Components-separately addressable elements of software such as subordinate, functions, or procedures-are initially described.
The design specification contains a requirements cross reference.
The purpose of this cross reference (represented as a simple matrix) is (1)to establish that all requirements are satisfied by the software design and(2)to indicate which components are critical to the implementation of specific requirements.

13. Design Documentation (Cont…)
Once program structure and interfaces have been established, we can develop guidelines for testing of individual modules and integration of entire package.
Design constraints, such as physical memory limitations or the necessity for a specialized external interface, may dictate special requirements for assembling or packaging of software.
The final section of the Design Specification contains supplementary data.
Algorithm descriptions, alternative procedures, tabular data, excepts from other documents, and other relevant information are presented as a special note or as a separate appendix.

14. Testing
Once source code has been generated, software must be tested to uncover (and correct) as many errors as possible before delivery to your customer.
For that software testing techniques are available.
These techniques provide systematic guideline for designing tests that
Exercise the internal logic of software components, and
Exercise the input and output domains of the program to uncover errors in program function, behavior and performance.

15. Testing (Cont…)
During early stages of testing, a software engineer performs all tests.
However, as the testing process progresses, testing specialists may become involved.
Software is tested from two different perspectives
Internal program logic is exercised using “white box” test case design technique.
Software requirements are exercised using “black box” test case design techniques.
In both cases, the intent is to find the maximum number of errors with the minimum amount of effort and time.

16. Testing (Cont…) Different types of testing are: Unit Testing
Integration Testing
System Testing
Acceptance Testing

17. Testing (Cont…) Unit Testing Integration Testing
In this, module is tested separately and normally it is performed by programmer simultaneously with the coding of the module.
Integration Testing
After Unit Testing, the modules are integrated into sub system which is a form of our system.
Integration Testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing.

18. Testing (Cont…) System Testing
System Testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system.
Although each test has a different purpose, all work to verify that system elements have been properly integrated and perform allocated functions.

19. Testing (Cont…) Acceptance Testing
Acceptance Testing is performed in demonstration of final system to the client.
In this testing all the real life data are checked for the operation of the system.
There are two different approaches to select test cases.
Functional Testing (Black Box Testing)
Structural Testing (White Box Testing)

20. Testing Objectives Following are the testing objectives.
Testing is a process of executing a program with the intent of finding an error.
A good test case is one that has a high probability of finding an as –yet-undiscovered error.
A successful test is one that uncovers an as-yet-undiscovered error.

21. Testing Principles
A software engineer must understand the basic principles that guide software testing. Davis suggests a set of testing principles which are as follows:
All tests should be traceable to customer requirements.
The objective of software testing is to uncover errors. It follows that the most severe defects (from the customer’s point of view) are those that cause the program to fail to meet its requirements.
Tests should be planned long before testing begins.
Test planning can begin as soon as the requirements model is complete. Detailed definition of test cases can begin as soon as the design model has been solidified.
Therefore, all tests can be planned and designed before any code has been generated.

22. Testing Principles (Cont…)
The Pareto principle applies to software testing.
Stated simply, the Pareto principle implies that 80 percent of all errors uncovered during testing will likely be traceable to 20 percent of all program components.
Testing should begin “in the small” and progress toward testing “in the large”.
The first tests planned and executed generally focus on individual components. As testing progresses, focus shifts in an attempt to find errors in integrated clusters of components and ultimately in the entire system.
Exhaustive testing is not possible.
The number of path permutations for even a moderately sized program is exceptionally large. For this reason, it is impossible to execute every combination of paths during testing.

23. Testing Principles (Cont…)
To be most effective, testing should be conducted by an independent third party.
By most effective, we mean testing that has the highest probability of finding errors. The software engineer who created the system is not the best person to conduct all tests for the software.

24. Testability
Software testability is simply how easily a computer program can be tested.
The checklist that follows provides a set of characteristics that lead to testable software.
Operability: “The better it works, the more efficiently it can be tested.”
Observability: ”What you see is what you test.”
Controllability: “The better we can control the software, the more the testing can be automated and optimized.”
Decomposability: “By controlling the scope of testing, we can more quickly isolate problems and perform smarter retesting.”

25. Testability (Cont…)
Simplicity: “The less there is to test, the more quickly we can test it.”
Stability: “The fewer the changes, the fewer the disruption to testing.”
Understandability: “The more information we have, the smarter we will test.”

26. Types of Testing Testing White Box Testing Black Box Testing
1. Graph Based Testing
Basis Path Testing
Control Structure Testing
2. Equivalence Partitioning
1. Flow Graph Notation
1. Condition Testing
3. Boundary Value Analysis
2. Cyclomatic Complexity
2. Data Flow Testing
4. Comparison Testing
3. Deriving Test Cases
3. Loop Testing
5. Orthogonal Array Testing
4. Graph Matrices
3.1 Simple loops
3.2 Nested loops
3.3 Concatenated loops
3.4 Unstructured loops

27. White Box Testing
It is also known as “Structural Testing” or “glass-box testing.”
It is a test case design method that uses the control structure of the procedural design to derive test cases.
Using white box testing methods, the s/w engineer can derive test cases that
1. guarantee that all independent paths within a module have been exercised at least once.
2. exercise all logical decisions on their true and false sides.
3. execute all loops at their boundaries and within their operational bounds.
4. exercise internal data structures to ensure their validity.

28. Black Box Testing
It is also called “behavioral testing” or “functional testing”.
It focuses on the functional requirements of the software.
That is, black box testing enables the software engineer to derive sets of input conditions that will fully exercise all functional requirements for a program.
Black box testing is not an alternative to white box techniques.
Black box testing attempts to find errors in the following categories:
(1) incorrect or missing functions
(2) interface errors
(3) errors in data structures or external database access
(4) behavior or performance errors
(5) initialization and termination errors.

29. Basis Path Testing
Basis path testing is a white box testing technique.
The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once.
Flow Graph Notation
The flow graph shows logical control flow using the notation.
The symbols or notation for the flow graph are:
1.Sequence
2. If Condition
3. While loop
4. Until
5. Switch case

30. Basis Path Testing (Cont…)
The flow graph shows logical control flow using the notation and flowchart is used to show program control structure.
We can prepare a flow graph from any flowchart.

31. Basis Path Testing (Cont…)
Following example shows flowchart and flow graph notation:
Here we are assuming that there is no compound condition in decision diamond of flowchart.
In figure 2 each circle (called a flow graph node) represents one or more procedural statements.
A sequence of process boxes and a decision diamond can map into a single node.
The arrows on the flow graph called edges or link, represents flow of control.

32. Basis Path Testing (Cont…)
An edge must terminate at a node even if the node doesn’t represent any procedural statement.
Area bounded by edges and nodes is called region.
When we count the region we should include the area outside the graph as a region.
2. Cyclomatic Complexity
Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program.
When used in the context of the basis path testing method, the value computed for cyclomatic complexity defines the number of independent paths in the basis set of a program and provides us with an upper bound for the number of tests that must be conducted to ensure that all statements have been executed at least once.

33. Basis Path Testing (Cont…)
An independent path is any path through the program that introduces at least one new set of processing statements or a new condition.
When stated in terms of a flow graph, an independent path must move along at least one edge that has not ben traversed before the path is defined.
For eg., a set of independent paths for the flow graph illustrated in figure is
path 1: 1-11
path 2:
path 3:
path 4:

34. Basis Path Testing (Cont…)
Note that each new path introduces a new edge. The path
is not considered to be an independent path because it is simply a combination of already specified paths and does not traverse any new edges.
Paths 1, 2, 3, and 4 constitute a basis set for the flow graph in figure.
That is, if tests can be designed to force execution of these paths (a basis set), every statement in the program will have been executed on its true and false sides.
Cyclomatic complexity has a foundation in graph theory.

35. Basis Path Testing (Cont…)
Complexity is computed in one of three ways:
The number of regions of the flow graph correspond to the cyclomatic complexity.
Cyclomatic complexity, V(G), for a flow graph, G, is defined as
V(G) = E-N+2
where E is the number of flow graph edges, N is the number of flow graph nodes.
Cyclomatic complexity, V(G), for a flow graph, G, is also defined as
V(G) =P+1
where P is the number of predicate nodes contained in the flow graph G.

36. Basis Path Testing (Cont…)
Referring once more to the flow graph in figure, the cyclomatic complexity can be computed using each of the algorithms just noted:
The flow graph has four regions.
V(G) = 11 edges – 9 nodes + 2 = 4
V(G) = 3 predicate nodes + 1= 4
Therefore, the cyclomatic complexity of the flow graph is 4.

37. Basis Path Testing (Cont…)
3. Deriving Test Cases
The basis path testing method can be applied to a procedural design or to a source code.
The following steps can be applied to derive the basis set:
Using the design or code as a foundation, draw a corresponding flow graph.
Determine the cyclomatic complexity of the resultant flow graph.
Determine a basis set of linearly independent paths.
Prepare test cases that will force execution of each path in the basis set.

38. Basis Path Testing (Cont…)
4. Graph Matrices
It is a square matrix whose size (i.e. number of rows and columns) is equal to the number of nodes on the flow graph.
Each row and column corresponds to an identified node, and
Matrix entries correspond to connections (an edge) between nodes.
Eg.

39. Control Structure Testing
Different types of control structure testing are:
1. Condition testing
2. Data flow testing
3. Loop testing
Condition testing
Condition testing is a test case design method that exercises the logical conditions contained in a program module.
The possible types of elements in a condition include a Boolean operator, a Boolean variable, a pair of Boolean parentheses (surrounding a simple or compound condition), a relational operator, or an arithmatic expression.

40. Control Structure Testing (Cont…)
If a condition is incorrect, then at least one component of the condition is incorrect. Therefore, types of errors in a condition include the following:
Boolean operator error
Boolean variable error
Boolean parenthesis error
Relational operator error
Arithmetic expression error
The purpose of condition testing is to detect not only errors in the conditions of a program but also other errors in the program.

41. Control Structure Testing (Cont…)
Data flow testing
The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program.
As we know the statements in a program are related to each other according to the definitions and uses of variables, the data flow testing approach is effective for error detection.
However, the problems of measuring test coverage and selecting test paths for data flow testing are more difficult than the corresponding problems for condition testing.

42. Control Structure Testing (Cont…)
Loop testing
Loop testing is a white-box testing technique that focuses on the validity of loop constructs.
Four different classes of loops can be defined:
Simple Loops
Nested Loops
Concatenated loops
Unstructured Loops
The following set of tests can be applied to simple loops, where n is the maximum number of allowable passes through the loop.
Skip the loop entirely.
Only one pass through the loop.
Two passes through the loop.

43. Control Structure Testing (Cont…)
4. M passes through the loop where m<n.
5. N-1, n, n+1 passes through the loop.
Nested Loops
The testing of nested loops can not simply extend the technique of simple loops since this would grow geometrically as the level of nesting increases.
An approach that will help to reduce the number of tests:
Start at the innermost loop. Set all other loops to minimum values.
Conduct simple loop tests for the innermost loop while holding the outer loops at their minimum iteration parameter (eg. Loop counter) values. Add other tests for out-of-range or excluded values.

44. Control Structure Testing (Cont…)
3. work outward, conducting tests for the next loop, but keeping all other outer loops at minimum values and other nested loops to “typical” values.
4. Continue until all loops have been tested.
Concatenated Loops
Concatenated Loops can be tested as simple loops if each loop is independent of the others. If they are not independent then the nested approach can be used.
Unstructured Loops
This type of loop should be redesigned not tested!!!

45. Black Box Testing Graph Based Testing Equivalence Partitioning
Boundary Value Analysis
Comparison Testing
Orthogonal Array Testing
Steps for graph based testing:
Create a graph-a collection of nodes that represent objects.
Links- represent the relationship between objects.
Node weights-describe the properties of a node
Link weights-describe some characteristics of a link

46. Black Box Testing (Cont…)
Symbolic representation of a graph is as below:
Node weight
Direct link
(link weight)
Object #2
Object #1
Parallel Links
Undirected Link
Object #3

47. Black Box Testing (Cont…)
Software engineer derives test cases by traversing the graph and covering each of the relationships show. These test cases are designed in an attempt to find errors in any of the relationships.
Equivalence partitioning
Black box technique that divides the input domain into classes of data from which test cases can be derived.
Idea is to partition the input space into a number of equivalence classes such that one could expect, based on the specification, that every element of a given class would be “handled” (i.e mapped to an output) in the same manner (either correctly or incorrectly).

48. Black Box Testing (Cont…)
Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member.
Test cases should be chosen from each partition.
Partition system inputs and outputs into equivalence sets.
If an input should be between 4 & 10.choose
1 number<4,
1 number between 4-10 and
1 number>10

49. Black Box Testing (Cont…)
Equivalence partitioning Guidelines
If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
If an input condition specifies value, one valid and two invalid equivalence classes are defined.
If an If an input condition specifies a member of a set, one valid and two invalid equivalence classes are defined.
If an input condition is Boolean, one valid and two invalid equivalence classes are defined.

50. Black Box Testing (Cont…)
Boundary Value Analysis (BVA)
A technique based on identifying and generating test cases to explore boundary conditions.
Boundary conditions are an extremely rich source of errors.
Natural language based specifications of boundaries are often ambiguous as in “for input values of x between 0 & 40,….”
May be applied to both input and output conditions.
Also applicable to white box testing.

51. Black Box Testing (Cont…)
Guidelines for Boundary Value Analysis (BVA)
If input condition specifies a range bounded by values a & b, test cases should include a & b, values just above & just below a & b.
An input condition specifies a number of values, test cases should be exercise the minimum & maximum numbers, as well as values just above and just below the minimum and maximum values.
Apply guidelines 1 & 2 to output conditions,
eg. Assume that a temperature vs. pressure table is required as output from an engineering analysis program. Test cases should be designed to produce the minimum and maximum allowable number of table entries.

52. Black Box Testing (Cont…)
If internal program data structures have boundaries (eg. An array has a defined limit of 100 entries), be certain to design a test case to exercise the data structure at its boundary.
Comparison Testing
There are some situations in which the reliability of software is absolutely critical.
In such applications redundant hardware and software are often used to minimize the possibility of error.
When redundant software is developed, separate software engineering teams develop independent versions of an application using the same specification.

53. Black Box Testing (Cont…)
In such situations, each version can be tested with the same test data to ensure that all provide identical output.
Then all versions are executed in parallel with real-time comparison of results to ensure consistency.
Comparison testing is not foolproof.
If the specification from which all versions have been developed is in error, all versions will likely reflect the error.
In addition, if each of the independent versions produces identical but incorrect results, condition testing will fail to detect the error.
It is also known as back-to-back testing.

54. Black Box Testing (Cont…)
Orthogonal Array Testing
Orthogonal array testing can be applied to problems in which the input domain is relatively small but too large to accommodate exhaustive testing.
The orthogonal array testing method is particularly useful in finding errors associated with region faults-an error category associated with faulty logic within a software component.

55. Verification and validation
Software testing is one element of a broader topic that is often referred to as verification and validation (V&V).
Verification: refers to the set of activities that ensure that software correctly implements a specific function.
Validation: refers to a different set of activities that ensure that the software that has been built is traceable to customer requirements.
Boehm states this another way:
Verification: ”Are we building the product right?”
Validation: “Are we building the right product?”
The definition of V&V encompasses many of the activities that we have referred to as software quality assurance (SQA).

56. Verification and validation (Cont…)
V&V encompasses a wide array of SQA activities that include formal technical reviews, quality and configuration audits, performance monitoring, simulation, feasibility study, documentation Review, database review, algorithm analysis, development testing.
Although testing plays an extremely important role in V&V, many other activities are also necessary.