 Static Testing

Static testing is done basically to test the software work products , requirement specifications,
test plan , user manual etc. They are not executed, but tested with the set of some tools and
processes. It provides a powerful way to improve the quality and productivity of software
development.
Dynamic Testing is basically when execution is done on the software code as a technique to
detect defects and to determine quality attributes of the code. With dynamic testing methods,
software is executed using a set of inputs and its output is then compared to the the expected
results.
 Static Review and its advantages
Static Review provides a powerful way to improve the quality and productivity of software
development to recognize and fix their own defects early in the software development process.
Nowadays, all software organizations are conducting reviews in all major aspects of their work
including requirements, design, implementation, testing, and maintenance.

Advantages of Static Reviews:-

1. Types of defects that can be found during static testing are: deviations from standards,
missing requirements, design defects, non-maintainable code and inconsistent
interface specifications.
2. Since static testing can start early in the life cycle, early feedback on quality issues can be
established, e.g. an early validation of user requirements and not just late in the life cycle
during
acceptance testing.
3. By detecting defects at an early stage, rework costs are relatively low and thus a
relatively cheap improvement of the quality of software products can be achieved.
4. The feedback and suggestions document from the static testing process allows for process
improvement, which supports the avoidance of similar errors being made in the future.
  Roles and Responsibilities in a Review
There are various roles and responsibilities defined for a review process. Within a review team,
four types of participants can be distinguished: moderator, author, scribe ,reviewer and
manager.Lets discuss their roles one by one:-

1. The moderator:- The moderator (or review leader) leads the review process. His role is to
determine the type of review, approach and the composition of the review team.The moderator
also schedules the meeting, disseminates documents before the meeting, coaches other team
members, paces the meeting, leads possible discussions and stores the data that is collected.

2. The author:- As the writer of the ‘document under review’, the author’s basic goal should be
to learn as much as possible with regard to improving the quality of the document.The author’s
task is to illuminate unclear areas and to understand the defects found.

3. The scribe/ recorder :– The scribe (or recorder) has to record each defect found and any
suggestions or feedback given in the meeting for process improvement.
4. The reviewer:- The role of the reviewers is to check defects and further improvements in
accordance to the business specifications, standards and domain knowledge.
5. The manager :- Manager is involved in the reviews as he or she decides on the execution of
reviews, allocates time in project schedules and determines whether review process objectives
have been met or not.
 Phases of a formal Review
A formal review takes place in a piecemeal approach which consists of 6 main steps. Let’s
discuss about these phases one by one.

1. Planning
The review process for a particular review begins with a ‘request for review’ by the author to the
moderator (or inspection leader). A moderator is often assigned to take care of the
scheduling (dates, time, place and invitation) of the review. The project planning needs to allow
time for review and rework activities, thus providing engineers with time to thoroughly
participate in reviews. There is an entry check performed on the documents and it is decided that
which documents are to be considered or not. The document size, pages to be
checked,composition of review team, roles of each participant, strategic approach are decided
into planning phase.

2. Kick-Off
The goal of this meeting is to get everybody on the same page regarding the document under
review. Also the result of the entry and exit criteria are discussed. Basically, During the kick-off
meeting, the reviewers receive a short introduction on the objectives of the review and the
documents. Role assignments, checking rate, the pages to be checked, process changes and
possible other questions are also discussed during this meeting. Also, the distribution of the
document under review, source documents and other related documentation, can also be done
during the kick-off.

3. Preparation
In this phase, participants work individually on the document under review using the related
documents, procedures, rules and checklists provided. The individual participants identify
defects, questions and comments, according to their understanding of the document and role.
Spelling mistakes are recorded on the document under review but not mentioned during the
meeting. The annotated document will be given to the author at the end of the logging meeting.
Using checklists during this phase can make reviews more effective and efficient.

4. Review Meeting
This meeting typically consists of the following elements:-
-logging phase
-discussion phase
-decision phase.

During the logging phase the issues, e.g. defects, that have been identified during the preparation
are mentioned page by page, reviewer by reviewer and are logged either by the author or by a
scribe. This phase is for just jot down all the issues not to discuss them in detail. If an issue needs
discussion, the item is logged and then handled in the discussion phase. A detailed discussion on
whether or not an issue is a defect is not very meaningful, as it is much more efficient to simply
log it and proceed to the next one.

The issues classified as discussion items will be handled during discussion phase. Participants
can take part in the discussion by bringing forward their comments and reasoning. The
moderator also paces this part of the meeting and ensures that all discussed items either have an
outcome by the end of the meeting, or are defined as an action point if a discussion cannot be
solved during the meeting. The outcome of discussions is documented for future reference.

At the end of the meeting, a decision on the document under review has to be made by the
participants, sometimes based on formal exit criteria. The most important exit criterion is the
average number of critical and major defects found per page. If the number of defects found per
page exceeds a certain level, the document must be reviewed again, after it has been reworked. If
the document complies with the exit criteria, the document will be checked during follow-up by
the moderator or one or more participants. Subsequently, the document can leave or exit the
review process.

5. Rework
Based on the defects detected and improvements suggested in the review meeting, the author
improves the document under review. In this phase the author would be doing all the rework to
ensure that defects detected should fixed and corrections should be properly implied.Changes
that are made to the document should be easy to identify during follow-up, therefore the author
has to indicate where changes are made.

6. Follow-Up
After the rework, the moderator should ensure that satisfactory actions have been taken on all
logged defects, improvement suggestions and change requests.If it is decided that all
participants will check the updated document, the moderator takes care of the distribution and
collects the feedback.In order to control and optimize the review process, a number of
measurements are collected by the moderator at each step of the process. Examples of such
measurements include number of defects found, number of defects found per page, time spent
checking per page, total review effort, etc. It is the responsibility of the moderator to ensure that
the information is correct and stored for future analysis.

 Types of Review
1. Walkthrough
A walkthrough is conducted by the author of the ‘document under review’ who takes the
participants through the document and his or her thought processes, to achieve a common
understanding and to gather feedback. This is especially useful if people from outside the
software discipline are present, who are not used to, or cannot easily understand software
development documents. The content of the document is explained step by step by the author, to
reach consensus on changes or to gather information.The participants are selected from different
departments and backgrounds If the audience represents a broad section of skills and disciplines,
it can give assurance that no major defects are ‘missed’ in the walk-through. A walkthrough is
especially useful for higher-level documents, such as requirement specifications and architectural
documents.

The specific goals of a walkthrough are:-

• to present the document to stakeholders both within and outside the software discipline, in
order to gather information regarding the topic under documentation.
• to explain and evaluate the contents of the document.
• to establish a common understanding of the document.
• to examine and discuss the validity of proposed solutions and the possible alternatives.

2. Technical review
A technical review is a discussion meeting that focuses on technical content of a document. it is
led by a trained moderator, but also can be led by a technical expert.Compared to inspections,
technical reviews are less formal and there is little or no focus on defect identification on the
basis of referenced documents. The experts that are needed to be present for a technical review
can be architects, chief designers and key users. It is often performed as a peer review without
management participation.

The specific goals of a technical review are:

• evaluate the value of technical concepts and alternatives in the product and project
environment.
• establish consistency in the use and representation of technical concepts.
• ensuring at an early stage, that technical concepts are used correctly;
• inform participants of the technical content of the document.

3. Inspection
Inspection is the most formal review type.It is usually led by a trained moderator (certainly not
by the author).The document under inspection is prepared and checked thoroughly by the
reviewers before the meeting, comparing the work product with its sources and other referenced
documents, and using rules and checklists. In the inspection meeting the defects found are
logged.Depending on the organization and the objectives of a project, inspections can be
balanced to serve a number of goals.

The specific goals of a Inspection are:

• help the author to improve the quality of the document under inspection.
• remove defects efficiently, as early as possible.
• improve product quality, by producing documents with a higher level of quality.
• create a common understanding by exchanging information among the inspection participants.
Dynamic Testing

Dynamic Testing is a software testing method used to test the dynamic behaviour of software
code. The main purpose of dynamic testing is to test software behaviour with dynamic variables
or variables which are not constant and finding weak areas in software runtime environment. The
code must be executed in order to test the dynamic behavior.

We all know that Testing is verification and validation, and it takes 2 Vs to make testing
complete. Out of the 2 Vs, Verification is called a Static testing and the other "V", Validation is
known as Dynamic testing.

Dynamic Testing Example

Let's understand How to do Dynamic Testing with an example:

Suppose we are testing a Login Page where we have two fields say "Username" and "Password"
and the Username is restricted to Alphanumeric.

When the user enters Username as "Guru99", the system accepts the same. Where as when the
user enters as Guru99@123 then the application throws an error message. This result shows that
the code is acting dynamically based on the user input.

131.5K
Super League Gaming's Michael Ullman Previews the Logitech G Challenge

Next
Stay

Dynamic testing is when you are working with the actual system by providing an input and
comparing the actual behavior of the application to the expected behavior. In other words,
working with the system with the intent of finding errors.

So based on the above statements we can say or conclude that dynamic testing is a process of
validating software applications as an end user under different environments to build the right
software.

What does dynamic testing do?

The main aim of the Dynamic tests is to ensure that software works properly during and after the
installation of the software ensuring a stable application without any major flaws( this statement
is made because no software is error free, testing only can show presence of defects and not
absence)
The main purpose of the dynamic test is to ensure consistency to the software; lets discuss this
with an example.

In a Banking Application, we find different screens like My Accounts Section, Funds Transfer,
Bill Pay, etc.. All these screens contain amount field which accepts some characters.

Let's say My Accounts field displays amount as 25,000 and Funds Transfer as $25,000 and Bill
pay screen as $25000 though the amount is the same, the way amount is displayed is not the
same hence making the software nonconsistent.

Consistency is not only limited to the functionality it also refers to different standards like
performance, usability, compatibity etc, hence it becomes very important to perform Dynamic
Testing.

Types of Dynamic Testing

Dynamic Testing is classified into two categories

 White Box Testing

 Black Box Testing

The below pictorial representation gives us an idea about types of Dynamic Testing, Levels of
Testing, etc.
Let us discuss briefly each type of testing and it's intended purpose

White Box Testing - White Box Testing is a software testing method in which the internal
structure/ design is known to the tester. The main aim of White Box testing is to check on how
System is performing based on the code. It is mainly performed by the Developers or White Box
Testers who has knowledge on the programming.

Black Box Testing - Black Box Testing is a method of testing in which the internal structure/
code/design is NOT known to the tester. The main aim of this testing to verify the functionality
of the system under test and this type of testing requires to execute the complete test suite and is
mainly performed by the Testers, and there is no need of any programming knowledge.

The Black Box Testing is again classified into two types.

They are
  Functional Testing
 Non-Functional Testing

Functional Testing:

Functional testing is performed to verify that all the features developed are according to the
functional specifications, and it is performed by executing the functional test cases written by the
QA team, in functional testing phase, system is tested by providing input, verifying the output
and comparing the actual results with the expected results.

There are different Levels of Functional Testing out of which the most important are

 Unit Testing – Generally Unit is a small piece of code which is testable, Unit Testing is
performed at individual unit of software and is performed by developers
 Integration Testing - Integration Testing is the testing which is performed after Unit
Testing and is performed by combining all the individual units which are testable and is
performed either by developers or testers
 System Testing - System Testing is a performed to ensure whether the system performs
as per the requirements and is generally performed when the complete system is ready, it
is performed by testers when the Build or code is released to QA team
 Acceptance Testing - Acceptance testing is performed to verify whether the system has
met the business requirements and is ready to use or ready for deployment and is
generally performed by the end users.

Non- Functional Testing: Non-Functional testing is a testing technique which does not focus on
functional aspects and mainly concentrates on the nonfunctional attributes of the system such as
memory leaks, performance or robustness of the system. Non-Functional testing is performed at
all test levels.

There are many Non-Functional Testing Techniques out of which the most important are

 Performance Testing – Performance Testing is performed to check whether the response

time of the system is normal as per the requirements under the desired network load.
 Recovery Testing - Recovery testing is a method to verify on how well a system is able
to recover from crashes and hardware failures.
 Compatibility Testing – Compatibility testing is performed to verify how the system
behaves across different environments.
 Security testing – Security testing is performed to verify the robustness of the
application, i.e to ensure that only the authorizes users/roles are accessing the system
 Usability testing – Usability testing is a method to verify the usability of the system by
the end users to verify on how comfortable the users are with the system.

Dynamic Testing Techniques

Dynamic Testing Techniques in STLC consists of different tasks like Requirements Analysis
for the tests, Test Planning, Test case design and implementation, Test environment setup, Test
case execution, Bug reporting and finally Test closure. All the tasks in dynamic testing
techniques are dependent on the completion of the previous task in the testing process.

In STLC, we can say that actual Dynamic Testing Process starts from Test Case Design, let's
discuss each activity in details.

Before getting into the process lets discuss the strategy that needs to be followed for Dynamic
Testing.

Test Strategy should mainly focus on the resources available and the timeframe. Based on these
factors, the objective of the testing, the scope of testing, phases or cycles of testing, type of
environment, assumptions or challenges that might be faced, risks, etc. has to be documented.

Once the strategy is defined and is accepted by the management then the actual process test case
design starts

What is Test design and Implementation

In this phase we identify the,

  Features to be tested
 Derive the Test Conditions
 Derive the coverage Items
 Derive the Test Cases

Test Environment Setup

We have to ensure that Testing Environment should always be similar to the Production
environment, in this phase we have to install the build and manage the test machines.

Test Execution

During this phase, test cases are actually executed.

Bug report captured

Based on the Execution if the Expected and Actual Results are not same then the Test case has to
be marked as Fail and a Bug should be logged.