1. coupling and cohesion
2. verification and validation
3. pattern based software design
4. black box testing and white box testing
5.architectural styles
6. cyclomatic complexity
7. basis path testing
8. Software quality assurance
1. coupling and cohesion
Coupling is an indication of
interconnection among modules in a software structure. 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,
you should strive for the lowest possible coupling. Simple connectivity among
modules results in software that is easier to understand and less prone to a
“ripple effect”, caused when errors occur at one location and propagate
throughout a system
Type of coupling
1. Data coupling
2. Stamp coupling
3. Control coupling
4. External coupling
5. Comman coupling
6. Context coupling
A cohesive module performs a single task,
requiring little interaction with other components in other parts of a program.
Stated simply, a cohesive module should (ideally) do just one thing. Although
you should always strive for high cohesion (i.e., single-mindedness), it is
often necessary and advisable to have a software component perform multiple
functions.
Type of cohesive
1. functional cohesive
2. sequence cohesive
3. communication cohesive
4. procedural cohesive
5. temporal cohesive
2. verification and
validation
|
Verification |
Validation |
|
It includes checking documents, design, codes and
programs. |
It includes testing and validating the actual product. |
|
Verification is the static testing. |
Validation is the dynamic testing. |
|
It does not include
the execution of the code. |
It includes the execution of the code. |
|
Methods used in verification are reviews, walkthroughs,
inspections and desk-checking. |
Methods used in validation are Black Box Testing, White
Box Testing and non-functional testing. |
|
It checks whether the software conforms to specifications
or not. |
It checks whether the software meets the requirements and
expectations of a customer or not. |
|
It can find the bugs in the early stage of the
development. |
It can only find the bugs that could not be found by the
verification process. |
|
The goal of verification is application and software
architecture and specification. |
The goal of validation is an actual product. |
|
Quality assurance team does verification. |
Validation is executed on software code with the help of
testing team. |
|
It comes before validation. |
It comes after verification. |
|
It consists of checking of documents/files and is
performed by human. |
It consists of execution of program and is performed by
computer. |
3. pattern based software
design
Design patterns are used to represent some of the best
practices adapted by experienced object-oriented software developers. A
design pattern systematically names, motivates, and explains a general design
that addresses a recurring design problem in object-oriented systems. It
describes the problem, the solution, when to apply the solution, and its
consequences.
4. black box testing and
white box testing
Software Testing can be majorly classified
into two categories:
1. Black Box Testing is a software testing method in which
the internal structure/ design/ implementation of the item being tested is not
known to the tester
2. White Box Testing is a software testing method in which
the internal structure/ design/ implementation of the item being tested is
known to the tester.
Differences
between Black Box Testing vs White Box Testing:
|
Black Box Testing |
White Box Testing |
|
It is a way of software testing in which the internal
structure or the program or the code is hidden and nothing is known about it. |
It is a way of testing the software in which the tester
has knowledge about the internal structure or the code or the program of the
software. |
|
It is mostly done by software testers. |
It is mostly done by software developers. |
|
It can be referred as outer or external software testing. |
It is the inner or the internal software testing. |
|
It is functional test of the software. |
It is structural test of the software. |
|
This testing can be initiated on the basis of requirement
specifications document. |
This type of testing of software is started after detail
design document. |
|
No knowledge of programming is required. |
It is mandatory to have knowledge of programming. |
|
It is the behavior testing of the software. |
It is the logic testing of the software. |
|
It is applicable to the higher levels of testing of
software. |
It is generally applicable to the lower levels of software
testing. |
|
It is also called closed testing. |
It is also called as clear box testing. |
|
It is least time consuming. |
It is most time consuming. |
|
It is not suitable or preferred for algorithm testing. |
It is suitable for algorithm testing. |
|
Example: search
something on google by using keywords |
Example: by
input to check and verify loops |
|
Types of Black Box Testing: ·
A.
Functional Testing ·
B.
Non-functional testing ·
C.
Regression Testing |
Types of White Box Testing: ·
A. Path
Testing ·
B. Loop
Testing ·
C.
Condition testing |
5.architectural
styles
The architectural style is a very specific solution to a
particular software, which typically focuses on how to organize the
code created for the software. ... The architectural pattern is the description
of relationship types and elements along with a set of constraints to
implementing a software system.
The
software needs the architectural design to represents the design of software.
IEEE defines architectural design as “the process of defining a collection of
hardware and software components and their interfaces to establish the
framework for the development of a computer system.” The software that is built
for computer-based systems can exhibit one of these many architectural
styles.
Each style will describe a system category that consists of :
·
A
set of components(eg: a database, computational modules) that will perform a function
required by the system.
·
The
set of connectors will help in coordination, communication, and cooperation
between the components.
·
Conditions
that how components can be integrated to form the system.
·
Semantic
models that help the designer to understand the overall properties of the
system.
5. cyclomatic complexity
Cyclomatic complexity is a software metric used
to indicate the complexity of a program. It is a quantitative
measure of the number of linearly independent paths through a program's source
code
Cyclomatic complexity is computed using
the control-flow graph of the program: the nodes of the graph correspond
to indivisible groups of commands of a program, and a directed edge
connects two nodes if the second command might be executed immediately after
the first command. Cyclomatic complexity may also be applied to
individual functions, modules, methods or classes within a
program.
One testing strategy, called basis path testing by
McCabe who first proposed it, is to test each linearly independent path through
the program; in this case, the number of test cases will equal the cyclomatic
complexity of the program
6. basis path testing
Basis
Path Testing is
a white-box
testing technique
based on the control structure of a program or a module. Using this structure,
a control flow graph is prepared and the various possible paths present in the
graph are executed as a part of testing. Therefore, by definition,
Basis
path testing is a technique of selecting the paths in the control flow graph,
that provide a basis set of execution paths through the program or module.
Since
this testing is based on the control structure of the program, it requires
complete knowledge of the program’s structure. To design test cases using this
technique, four steps are followed :
1. Construct the Control Flow
Graph
2. Compute the Cyclomatic
Complexity of the Graph
1.
Control Flow Graph –
A control flow graph (or simply, flow graph) is a directed graph which
represents the control structure of a program or module. A control flow graph
(V, E) has V number of nodes/vertices and E number of edges in it. A control
graph can also have :
·
Junction Node – a node with more than one arrow
entering it.
·
Decision Node – a node with more then one arrow
leaving it.
·
Region – area
bounded by edges and nodes (area outside the graph is also counted as a
region.).
2.Cyclomatic
Complexity –
The cyclomatic complexity V(G) is said to be a measure of the logical
complexity of a program. It can be calculated using three different formulae :
1. Formula based on edges and
nodes :
V(G) = e - n + 2*P
Where,
e is number of edges,
n is number of vertices,
P is number of connected components.
For example, consider
first graph given above,
where, e = 4, n = 4 and p = 1
So,
Cyclomatic complexity V(G)
= 4 - 4 + 2 * 1
= 2
2. Formula based on Decision Nodes
:
V(G) = d + P
where,
d is number of decision nodes,
P is number of connected nodes.
For example, consider
first graph given above,
where, d = 1 and p = 1
So,
Cyclomatic Complexity V(G)
= 1 + 1
= 2
3. Formula based on Regions :
V(G) = number of regions in
the graph
For example, consider
first graph given above,
Cyclomatic complexity V(G)
= 1 (for Region 1) + 1 (for
Region 2)
= 2
.
7. Software quality
assurance
Software
Quality Assurance (SQA) is simply a way to assure quality in the software.
It is the set of activities which ensure processes, procedures as well as
standards are suitable for the project and implemented correctly.
Software
Quality Assurance is a process which works parallel to development of software.
It focuses on improving the process of development of software so that problems
can be prevented before they become a major issue. Software Quality Assurance
is a kind of Umbrella activity that is applied throughout the software
process.
Software
Quality Assurance has:
1. A quality management
approach
2. Formal technical
reviews
3. Multi testing
strategy
4. Effective software
engineering technology
5. Measurement and reporting
mechanism
Major
Software Quality Assurance Activities:
1. SQA Management Plan:
Make a plan for how you will carry out the sqa through out the project. Think
about which set of software engineering activities are the best for project.
check level of sqa team skills.
2. Set The Check Points:
SQA team should set checkpoints. Evaluate the performance of the project on the
basis of collected data on different check points.
3. Multi testing Strategy:
Do not depend on a single testing approach. When you have a lot of testing
approaches available use them.
4. Measure Change Impact:
The changes for making the correction of an error sometimes re introduces more
errors keep the measure of impact of change on project. Reset the new change to
change check the compatibility of this fix with whole project.
5. Manage Good Relations:
In the working environment managing good relations with other teams involved in
the project development is mandatory. Bad relation of sqa team with programmers
team will impact directly and badly on project. Don’t play politics.