UNIT-5

CODING AND TESTING

Coding Standards
• 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.
• 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.
• Some of the coding standards are given below:
• Limited use of globals: These rules tell about which types of data that
can be declared global and the data that can't be.
• Standard headers for different modules: For better understanding
and maintenance of the code, the header of different modules should
follow some standard format and information. The header format must
contain below things that is being used in various companies:
• Name of the module
• Date of module creation
• Author of the module
• Modification history
• Synopsis of the module about what the module does
• Different functions supported in the module along with their input output
parameters
• Global variables accessed or modified by the module.
• Naming conventions for local variables, global variables, constants and
functions: Some of the naming conventions are given below:
• Meaningful and understandable variables name helps anyone to understand the reason of using it.
• Local variables should be named using camel case lettering starting with small letter (e.g. localData)
whereas Global variables names should start with a capital letter (e.g. GlobalData). Constant names
should be formed using capital letters only (e.g. CONSDATA).
• It is better to avoid the use of digits in variable names.
• The names of the function should be written in camel case starting with small letters.
• The name of the function must describe the reason of using the function clearly and briefly.
• Indentation: Proper indentation is very important to increase the readability of the code.
For making the code readable, programmers should use White spaces properly. Some of
the spacing conventions are given below:

• There must be a space after giving a comma between two function arguments.
• Each nested block should be properly indented and spaced.
• Proper Indentation should be there at the beginning and at the end of each block in the program.
• All braces should start from a new line and the code following the end of braces also start from a new
line.
• Error return values and exception handling conventions: All functions that
encountering an error condition should either return a 0 or 1 for simplifying the debugging
CODING GUIDLINES
• Avoid using a coding style that is too difficult to understand: Code should be easily
understandable. The complex code makes maintenance and debugging difficult and
expensive.
• Avoid using an identifier for multiple purposes: Each variable should be given a
descriptive and meaningful name indicating the reason behind using it. This is not possible
if an identifier is used for multiple purposes and thus it can lead to confusion to the reader.
Moreover, it leads to more difficulty during future enhancements.
• Code should be well documented: The code should be properly commented for
understanding easily. Comments regarding the statements increase the understandability of
the code.
• Length of functions should not be very large: Lengthy functions are very difficult to
understand. That's why functions should be small enough to carry out small work and
lengthy functions should be broken into small ones for completing small tasks.
• Try not to use GOTO statement: GOTO statement makes the program unstructured, thus
it reduces the understandability of the program and also debugging becomes difficult.
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
• Code walk
• It through is an informal code analysis technique.
• The main objectives of the walk through are to discover the algorithmic and logical errors in the
code.
• A few members of the development team are given the code few days before the walk through
meeting to read and understand code.
• Each member selects some test cases and simulates execution of the code by hand
• The members note down their findings to discuss these in a walk through meeting where the
coder of the module is present.
• Code Inspection
• The aim of Code Inspection is to discover some common types of
errors caused due to improper programming.
• In other words, during Code Inspection the code is examined for the
presence of certain kinds of errors.
• For instance, consider the classical error of writing a procedure that modifies a
parameter while the calling routine calls that procedure with a constant actual
parameter.
• It is more likely that such an 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 doc
• Design doc
• Installation manual
• Manual doc
• SRS
types of software documents
• Internal
• It is the code perception features provided as part of the source code.
• It is provided through appropriate module headers and comments
embedded in the source code.
• It is also provided through the useful variable names, module and
function headers, code indentation, code structuring, use of enumerated
types and constant identifiers, use of user-defined data types, etc.
• Even when code is carefully commented, 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.
• External
• It is provided through various types of supporting documents
• such as users’ manual
• software requirements specification document
• design document
• test documents, etc.
• A systematic software development style ensures that all these
documents are produced in an orderly fashion.
Software Testing
• Testing is the process of exercising a program with the specific intent
of finding errors prior to delivery to the end user.
• Don’t view testing as a “safety net” that will catch all errors that
occurred because of weak software engineering practice.
• Who Test the Software
• Developer: Understands the system but, will test "gently“ and, is
driven by "delivery“.
• Tester : Must learn about the system, but, will attempt to break it and,
is driven by quality
Verification & Validation
• Are we building the product
• The objective of Verification is to make sure that the product being
develop is as per the requirements and design specifications.
• Are we building the right product?
• The objective of Validation is to make sure that the product actually
meet up the user’s requirements, and check whether the specifications
were correct in the first place.
 varification validation
• Process of evaluating products of a • Process of evaluating software at
development phase to find out the end of the development to
whether they meet the specified determine whether software meets
requirements. the customer expectations and
requirements.
• Activities involved: Reviews, • Activities involved: Testing like
Meetings and Inspections black box testing, white box testing,
• Carried out by QA team gray box testing
• Execution of code is not comes • Carried out by testing team
under Verification • Execution of code is comes under
Validation
• Explains whether the outputs are
according to inputs or not • Describes whether the software is
accepted by the user or not
• Cost of errors caught is less • Cost of errors caught is high
Software Testing Strategy
• Unit Testing
• It concentrate on each unit of the software as implemented in source code
• It focuses on each component individual, ensuring that it functions
properly as a unit.
• Integration Testing
• It focus is on design and construction of software architecture.
• Integration testing is the process of testing the interface between two
software units or modules
• Validation Testing
• Software is validated against requirements established as a part of
requirement modeling
• It give assurance that software meets all informational, functional,
behavioral and performance requirements
• System Testing
• The software and other software elements are tested as a whole
• Software once validated, must be combined with other system
elements e.g. hardware, people, database etc…
• It verifies that all elements mesh properly and that overall system
function / performance is achieved.
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
• 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
• Let’s take an example to understand it in a better way.
• Suppose there is an application consisting of three modules say,
module A, module B & module C.
• Developer has design in such a way that module B depends on
module A & module C depends on module B
• The developer has developed the module B and now wanted to test
it.
• But the module A and module C has not been developed yet.
• In that case to test the module B completely we can replace the
module A by Driver and module C by stub
• Driver
• Driver and/or Stub software must be developed for each unit test
• A driver is nothing more than a "main program"
• It accepts test case data
• Passes such data to the component and
• Prints relevant results.
• Driver
• Used in Bottom up approach
• Lowest modules are tested first.
• Simulates the higher level of components
• Dummy program for Higher level component
• Stub
• Stubs serve to replace modules that are subordinate (called by) the
component to be tested.
• A stub or "dummy subprogram"
• Uses the subordinate module's interface
• May do minimal data manipulation
• Prints verification of entry and
• Returns control to the module undergoing testing
• Stubs
• Used in Top down approach
• Top most module is tested first
• Simulates the lower level of components
• Dummy program of lower level components
Integration Testing
• Integration testing is the process of testing the interface between two software
units or modules
• Big Bang: Combining all the modules once and verifying the functionality after
completion of individual module testing .
• Top –down : Testing take place from top to bottom
• High level modules are tested first and then low-level modules and finally
integrated the low level modules to high level to ensure the system is working as
intended
• Stubs are used as a temporary module, if a module is not ready for integration
testing
• Bottom- up: Testing take place from bottom to up
• Lowest level modules are tested first and then high-level modules and finally
integrated the high level modules to low level to ensure the system is working as
intended
• Drivers are used as a temporary module, if a module is not ready for integration
testing.
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
• 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
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
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
• Alpha
• 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
• 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
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.
• Types of System Testing
• Recovery Testing
• Security Testing
• Stress Testing
• Performance Testing
• Deployment Testing