UNIT-6

Software Coding and Testing

Prepared By
Prof. Mital Sarvaiya
Computer Engineering
BHGCET - Rajkot
Topics:

• Coding Standard and coding Guidelines

• Code Review
• Software Documentation
• Testing Strategies
• Testing Techniques and Test Case
• Test Suites Design
• Testing Conventional Applications
• Testing Object Oriented Applications
• Testing Web and Mobile Applications
• Testing Tools (Win runner, Load runner)
Coding Standard and coding Guidelines

Good software development organizations normally require their

programmers to adhere to some well-defined and standard style of coding
called coding standards.

• Most software development organizations formulate their own coding

standards that suit them most, and require their engineers to follow these
standards strictly
• The purpose of requiring all engineers of an organization to adhere to a
standard style of coding is the following:
• A coding standard gives a uniform appearance to the codes written by
different engineers.
• It enhances code understanding.
• It encourages good programming practices.
Coding Standard and coding Guidelines Continue…

A coding standard lists several rules to be followed such as, the way
variables are to be named, the way the code is to be laid out, error return
conventions, etc. The following are some representative coding standards
• Rules for limiting the use of global
• These rules list what types of data can be declared global and what cannot.
Naming conventions for global & local variables & constant identifiers
• A possible naming convention can be that global variable names always
start with a capital letter, local variable names are made of small
letters, and constant names are always capital letters.
Contents of the headers preceding codes for different modules
• The information contained in the headers of different modules should be
standard for an organization.
• The exact format in which the header information is organized in the
header can also be specified
Coding Standard and coding Guidelines Continue…

Error return conventions and exception handling mechanisms

• The way error conditions are reported by different functions in a program
are handled should be standard within an organization.
• For example, different functions while encountering an error condition
should either return a 0 or 1 consistently.
Coding Standard and coding Guidelines Continue…

Coding guidelines
Do not use a coding style that is too clever or too difficult to understand
Do not use an identifier for multiple purposes
The code should be well-documented
The length of any function should not exceed 10 source lines
Do not use goto statements
Coding Standard and coding Guidelines Continue…

Avoid obscure side effects

• The side effects of a function call include modification of parameters
passed by reference, modification of global variables, and I/O operations.
• An obscure side effect is one that is not obvious from a casual
examination of the code.
• Obscure side effects make it difficult to understand a piece of code.
• For example, if a global variable is changed obscurely in a called module or
some file I/O is performed which is difficult to infer from the function’s
name and header information, it becomes difficult for anybody trying to
understand the code.
Code Review

• Code Review is carried out after the module is successfully compiled and
all the syntax errors have been eliminated.
• Code Reviews are extremely cost-effective strategies for reduction in
coding errors and to produce high quality code.
Types of Review
1) Code Walk Through
2) Code Inspection
Code Review Continue…

Few classical programming errors

• Use of uninitialized variables
• Jumps into loops
• Nonterminating loops
• Incompatible assignments
• Array indices out of bounds
• Improper storage allocation and de-allocation
• Mismatches between actual and formal parameter in procedure calls
• Use of incorrect logical operators or incorrect precedence among operators
• Improper modification of loop variables
Code Review Continue…

Code Walk Through Code Inspection

• Code walk through is an informal • The aim of Code Inspection is to
code analysis technique. discover some common types of
• The main objectives of the walk errors caused due to improper
through are to discover the programming.
algorithmic and logical errors in the • In other words, during Code
code. Inspection the code is examined for
• A few members of the development the presence of certain kinds of
team are given the code few days errors.
before the walk through meeting to • For instance, consider the
read and understand code. classical error of writing a
• Each member selects some test cases procedure that modifies a
and simulates execution of the code parameter while the calling
by hand routine calls that procedure
• The members note down their with a constant actual
findings to discuss these in a walk parameter.
through meeting where the coder of • It is more likely that such an
the module is present. error will be discovered by
looking for these kinds of
mistakes in the code.
• In addition, commitment to coding
standards is also checked.
Software Documentation

When various kinds of software products are developed, various kinds of

documents are also developed as part of any software engineering process
e.g..
• Users’ manual
• Design documents
• Test documents
• Installation manual
• Software requirements specification (SRS) documents, etc.
• Different types of software documents can broadly be classified into the
following:
Software Documentation Continue…

Internal Documentation External Documentation

• It is the code perception features provided • It is provided through various
as part of the source code. types of supporting documents
• It is provided through appropriate module • such as users’ manual
headers and comments embedded in the • software requirements
source code. specification document
• It is also provided through the useful • design document
variable names, module and function • test documents, etc.
headers, code indentation, code • A systematic software
structuring, use of enumerated types and development style ensures that
constant identifiers, use of user-defined all these documents are
data types, etc. produced in an orderly
• Even when code is carefully commented, fashion.
meaningful variable names are still more
helpful in understanding a piece of code.
• Good organizations ensure good internal
documentation by appropriately
formulating their coding standards and
guidelines.
Testing Strategies

Software Testing Strategy

Testing Strategies Continue…

• Unit Testing, Integration Testing, Validation Testing, System Testing

Unit Testing Integration Testing Validation Testing System Testing

• It concentrate on • It focus is on • Software is • The software and
each unit of the design and validated against other software
software as construction of requirements elements are
implemented in software established as a tested as a whole
source code architecture part of • Software once
• It focuses on each • Integration testing requirement validated, must be
component is the process of modeling combined with
individual, testing the • It give assurance other system
ensuring that it interface between that software elements e.g.
functions two software meets all hardware, people,
properly as a unit. units or modules informational, database etc…
functional, • It verifies that all
behavioral and elements mesh
performance properly and that
requirements overall system
function /
performance is
achieved.
Testing Strategies Continue…

1)Unit Testing
• Unit is the smallest part of a software system which is testable.
• It may include code files, classes and methods which can be tested
individually for correctness.
• Unit Testing validates small building block of a complex system before
testing an integrated large module or whole system
• The unit test focuses on the internal processing logic and data
structures within the boundaries of a component.
• The module is tested to ensure that information properly flows into and
out of the program unit
• Local data structures are examined to ensure that data stored
temporarily maintains its integrity during execution
Testing Strategies Continue…

• All independent paths through the control structures are exercised to

ensure that all statements in module have been executed at least once
• Boundary conditions are tested to ensure that the module operates
properly at boundaries established to limit or restricted processing
• All error handling paths are tested
Testing Strategies Continue…

In such case the missing software is replaced by Stubs and Drivers and
simulate the interface between the software components in a simple manner
Testing Strategies Continue…

2) Integration Testing
Integration testing is the process of testing the interface between two
software units or modules
It can be done in 3 ways
Big Bang Approach Top Down Approach Bottom Up Approach

• Combining all the • Testing take place • Testing take place

modules once and from top to bottom from bottom to up
verifying the • High level modules are • Lowest level modules
functionality after tested first and then are tested first and
completion of low-level modules and then high-level
individual module finally integrated the modules and finally
testing low level modules to integrated the high
high level to ensure the level modules to low
system is working as level to ensure the
intended system is working as
• Stubs are used as a intended
temporary module, if • Drivers are used as a
a module is not ready temporary module, if
for integration testing a module is not ready
for integration testing
Testing Strategies Continue…

● Regression Testing
• Repeated testing of an already tested program, after modification, to
discover any defects introduced or uncovered as a result of the changes in
the software being tested
• Regression testing is done by re-executing the tests against the modified
application to evaluate whether the modified code breaks anything
which was working earlier
• Anytime we modify an application, we should do regression testing
• It gives confidence to the developers that there is no unexpected side
effects after modification
Testing Strategies Continue…

When to do regression testing?

• When new functionalities are added to the application
– E.g. A website has login functionality with only Email. Now the new
features look like “also allow login using Facebook”
• When there is a change requirement
– Forgot password should be removed from the login page
• When there is a defect fix
– E.g. assume that “Login” button is not working and tester reports a
bug. Once the bug is fixed by developer, tester tests using this
approach
• When there is a performance issue
– E.g. loading a page takes 15 seconds. Reducing load time to 2 seconds
• When there is an environment change
– E.g. Updating database from MySQL to Oracle
Testing Strategies Continue…

● Smoke Testing
• Smoke Testing is an integrated testing approach that is commonly used
when product software is developed
• This test is performed after each Build Release
• Smoke testing verifies – Build Stability
• This testing is performed by “Tester” or “Developer”
• This testing is executed for Integration Testing, System Testing &
Acceptance Testing
• What to Test?
– All major and critical functionalities of the application is tested
– It does not go into depth to test each functionalities
– This does not incudes detailed testing for the build
Testing Strategies Continue…

• It test the build just to check if any major or critical functionalities are
broken
• If there are smoke or Failure in the build after Test, build is rejected and
developer team is reported with the issue
Testing Strategies Continue…

3) Validation Testing
• The process of evaluating software to determine whether it satisfies
specified business requirements (client’s need).
• It provides final assurance that software meets all informational,
functional, behavioral, and performance requirements
• When custom software is build for one customer, a series of acceptance
tests are conducted to validate all requirements
• It is conducted by end user rather then software engineers
• If software is developed as a product to be used by many customers, it is
impractical to perform formal acceptance tests with each one
• Most software product builders use a process called alpha and beta testing
to uncover errors that only the end user seems able to find
Testing Strategies Continue…

● Alpha Test
• The alpha test is conducted at the developer’s site by a representative
group of end users
• The software is used in a natural setting with the developer “looking over
the shoulders” of the users and recording errors and usage problems
• The alpha tests are conducted in a controlled environment
● Beta Test
• The beta test is conducted at one or more end-user sites
• Developers are not generally present
• Beta test is a “live” application of the software in an environment that
can not be controlled by the developer
• The customer records all problems and reports to the developers at
regular intervals
• After modifications, software is released for entire customer base
Testing Strategies Continue…

4) System Testing
• In system testing the software and other system elements are tested.
• To test computer software, you spiral out in a clockwise direction along
streamlines that increase the scope of testing with each turn.
• System testing verifies that all elements mesh properly and overall
system function/performance is achieved.
• System testing is actually a series of different tests whose primary
purpose is to fully exercise the computer-based system.
Testing Techniques and Test Case

Software Testing Techniques help you design better test cases. Since
exhaustive testing is not possible; Manual Testing Techniques help reduce the
number of test cases to be executed while increasing test coverage. They help
identify test conditions that are otherwise difficult to recognize.

In this tutorial, you will learn 5 important software testing techniques:

• Boundary Value Analysis (BVA)
• Equivalence Class Partitioning
• Decision Table based testing.
• State Transition
• Error Guessing
Testing Techniques and Test Case Continue…

1) Boundary Value Analysis (BVA):

Boundary value analysis is based on testing at the boundaries between

partitions. It includes maximum, minimum, inside or outside boundaries,
typical values and error values.
This black box testing technique complements equivalence partitioning. This
software testing technique base on the principle that, if a system works well
for these particular values then it will work perfectly well for all values which
comes between the two boundary values.

Example
Input condition is valid between 1 to 10 Boundary values 0,1,2 and 9,10,11
Testing Techniques and Test Case Continue…

2)Equivalence Class Partitioning:

Equivalent Class Partitioning allows you to divide set of test condition into a
partition which should be considered the same. This software testing method
divides the input domain of a program into classes of data from which test
cases should be designed.
The concept behind this technique is that test case of a representative value of
each class is equal to a test of any other value of the same class. It allows you
to Identify valid as well as invalid equivalence classes.
Example:
Input conditions are valid between
• 1 to 10 and 20 to 30
Testing Techniques and Test Case Continue…

Hence there are five equivalence classes

• ---to 0 (invalid)
• 1 to 10 (valid)
• 11 to 19 (invalid)
• 20 to 30 (valid)
• 31 to --- (invalid)
You select values from each class, i.e.,
• -2, 3, 15, 25, 45
Testing Techniques and Test Case Continue…

3)Decision Table Based Testing.

A decision table is also known as to Cause-Effect table. This software testing
technique is used for functions which respond to a combination of inputs or
events. For example, a submit button should be enabled if the user has entered
all required fields.

Following are steps to create a decision table:

• Enlist the inputs in rows
• Enter all the rules in the column
• Fill the table with the different combination of inputs
• In the last row, note down the output against the input combination.
Testing Techniques and Test Case Continue…
Testing Techniques and Test Case Continue…

4) State Transition:
In State Transition technique changes in input conditions change the state of
the Application Under Test (AUT). This testing technique allows the tester to
test the behavior of an AUT. The tester can perform this action by entering
various input conditions in a sequence. In State transition technique, the
testing team provides positive as well as negative input test values for
evaluating the system behavior.

Guideline for State Transition:

• State transition should be used when a testing team is testing the
application for a limited set of input values.
• The technique should be used when the testing team wants to test sequence
of events which happen in the application under test.
Testing Techniques and Test Case Continue…
Testing Techniques and Test Case Continue…

Error Guessing:
is a software testing technique based on guessing the error which can prevail
in the code. The technique is heavily based on the experience where the test
analysts use their experience to guess the problematic part of the testing
application. Hence, the test analysts must be skilled and experienced for better
error guessing.
Test Suites Design

• Test suite is a container that has a set of tests which helps testers in
executing and reporting the test execution status. It can take any of the
three states namely Active, In progress and completed.
• A Test case can be added to multiple test suites and test plans. After
creating a test plan, test suites are created which in turn can have any
number of tests.
• Test suites are created based on the cycle or based on the scope. It can
contain any type of tests, viz - functional or Non-Functional.
Test Suites Design Continue…

Test Suite - Diagram:

Testing Conventional Applications

Views of Test Objects:

Testing Conventional Applications Continue…

!)Black-box
Also known as specification-based testing
• Tester has access only to running code and the specification it is
supposed to satisfy
• Test cases are written with no knowledge of internal workings of the
code
• No access to source code
• So test cases don’t worry about structure
• Emphasis is only on ensuring that the contract is met
Advantage
• Scalable; not dependent on size of code
• Testing needs no knowledge of implementation
• Tester and developer can be truly independent of each other
• Tests are done with requirements in mind
• Does not excuse inconsistencies in the specifications
• Test cases can be developed in parallel with code
Testing Conventional Applications Continue…
Two techniques are used
Equivalence Partitioning
• Input data for a program unit usually falls into a number of partitions,
e.g. all negative integers, zero, all positive numbers
• Each partition of input data makes the program behave in a similar
way
• Two test cases based on members from the same partition is likely to
reveal the same bugs
Boundary Value Analysis (BVA)
• It arises from the fact that most program fail at input boundaries
• Boundary testing is the process of testing between extreme ends or
boundaries between partitions of the input values.
• In Boundary Testing, Equivalence Class Partitioning plays a good role
• Boundary Testing comes after the Equivalence Class Partitioning
• The basic idea in boundary value testing is to select input variable values
at their:
Testing Conventional Applications Continue…

Testing can either be done manually or using an automated testing tool:

• Manual - This testing is performed without taking help of automated
testing tools. The software tester prepares test cases for different sections
and levels of the code, executes the tests and reports the result to the
manager.
– Manual testing is time and resource consuming. The tester needs to
confirm whether or not right test cases are used. Major portion of
testing involves manual testing.
• Automated This testing is a testing procedure done with aid of automated
testing tools. The limitations with manual testing can be overcome using
automated test tools.
Testing Conventional Applications Continue…

!!)White-Box
Also known as structural testing
• White Box Testing is a software testing method in which the internal
structure/design/implementation of the module being tested is known to
the tester
• Focus is on ensuring that even abnormal invocations are handled
gracefully
• Using white-box testing methods, you can derive test cases that
– Guarantee that all independent paths within a module have been
exercised at least once
– Exercise all logical decisions on their true and false sides
– Execute all loops at their boundaries
– Exercise internal data structures to ensure their validity
Testing Conventional Applications Continue…

White-box testing strategies:

Statement coverage
Branch coverage
Path coverage
!!!)Grey Box Testing
• Combination of white box and black box testing
• Tester has access to source code, but uses it in a restricted manner
• Test cases are still written using specifications based on expected outputs
for given input
• These test cases are informed by program code structure
Testing Object Oriented Applications

Unit Testing in the OO Context

The concept of the unit testing changes in object-oriented software
• Encapsulation drives the definition of classes and objects
– Means, each class and each instance of a class (object) packages
attributes (data) and the operations (methods or services) that
manipulate these data
– Rather than testing an individual module, the smallest testable unit
is the encapsulated class
• Unlike unit testing of conventional software,
– which focuses on the algorithmic detail of a module and the data that
flows across the module interface,
– class testing for OO software is driven by the operations
encapsulated by the class and the state behavior of the class
Testing Web and Mobile Applications

• WebApp testing is a collection of related activities with a single goal to

uncover errors in WebApp content, function, usability, navigability,
performance, capacity, and security
• To accomplish this, a testing strategy that encompasses both reviews and
executable testing is applied.
Dimensions of Quality
• Content is evaluated at both a syntactic and semantic level.
• At the syntactic level spelling, punctuation, and grammar are assessed
for text-based documents.
• At a semantic level correctness of information presented, Consistency
across the entire content object and related objects, and lack of ambiguity
are all assessed.
Testing Tools (Win runner, Load runner)
Testing Tools (Win runner, Load runner) Continue…

Working with Load Runner:

Testing Tools (Win runner, Load runner) Continue…
Testing Tools (Win runner, Load runner) Continue…

Working with Win Runner

Testing Tools (Win runner, Load runner) Continue…
Thank You(^_^)