UNIT 4

Software Testing 
Software Testing is a method to check whether the actual software product matches expected
requirements and to ensure that software product is Defect free. It involves execution of
software/system components using manual or automated tools to evaluate one or more
properties of interest. The purpose of software testing is to identify errors, gaps or missing
requirements in contrast to actual requirements.
Why Software Testing is Important?
Software Testing is Important because if there are any bugs or errors in the software, it can
be identified early and can be solved before delivery of the software product. Properly tested
software product ensures reliability, security and high performance which further results in
time saving, cost effectiveness and customer satisfaction.
What are the benefits of Software Testing?
Here are the benefits of using software testing:
 Cost-Effective: It is one of the important advantages of software testing. Testing any
IT project on time helps you to save your money for the long term. In case if the bugs
caught in the earlier stage of software testing, it costs less to fix.
 Security: It is the most vulnerable and sensitive benefit of software testing. People
are looking for trusted products. It helps in removing risks and problems earlier.
 Product quality: It is an essential requirement of any software product. Testing
ensures a quality product is delivered to customers.
 Customer Satisfaction: The main aim of any product is to give satisfaction to their
customers. UI/UX Testing ensures the best user experience.
7 Principles of Software Testing
1. Testing shows presence of defects
2. Exhaustive testing is not possible
3. Early testing
4. Defect clustering
5. Pesticide paradox
6. Testing is context dependent
7. Absence of errors fallacy
Testing in Software Engineering
As per ANSI/IEEE 1059, Testing in Software Engineering is a process of evaluating a
software product to find whether the current software product meets the required conditions
or not. The testing process involves evaluating the features of the software product for
requirements in terms of any missing requirements, bugs or errors, security, reliability and
performance.
Software Testing has different goals and objectives. The major objectives of Software testing
are as follows:
 Finding defects which may get created by the programmer while developing the
software.
 Gaining confidence in and providing information about the level of quality.
 To prevent defects.
 To make sure that the end result meets the business and user requirements.
 To ensure that it satisfies the BRS that is Business Requirement Specification and
SRS that is System Requirement Specifications.
 To gain the confidence of the customers by providing them a quality product.
Unit Testing

Unit testing involves the testing of each unit or an individual component of the software
application. It is the first level of functional testing. The aim behind unit testing is to validate
unit components with its performance.

A unit is a single testable part of a software system and tested during the development phase
of the application software.

unit testing is the first level of testing done before integration and other remaining levels of
the testing. It uses modules for the testing process which reduces the dependency of waiting
for Unit testing frameworks, stubs, drivers, and mock objects are used for assistance in unit
testing.
Here, are the key reasons to perform unit testing in software engineering:
1. Unit tests help to fix bugs early in the development cycle and save costs.
2. It helps the developers to understand the testing code base and enables them to make
changes quickly
3. Good unit tests serve as project documentation
4. Unit tests help with code re-use. Migrate both your code and your tests to your new
project. Tweak the code until the tests run again.
The pros and cons of unit testing are as follows:
Advantages
o Unit testing uses module approach due to that any part can be tested without waiting
for completion of another parts testing.
o The developing team focuses on the provided functionality of the unit and how
functionality should look in unit test suits to understand the unit API.
o Unit testing allows the developer to refactor code after a number of days and ensure
the module still working without any defect.

Disadvantages

o It cannot identify integration or broad level error as it works on units of the code.
o In the unit testing, evaluation of all execution paths is not possible, so unit testing is
not able to catch each error in a program.
o It is best suitable for conjunction with other testing activities.

The objective of Unit Testing is:

1. To isolate a section of code.

2. To verify the correctness of the code.
3. To test every function and procedure.
4. To fix bugs early in the development cycle and to save costs.
5. To help the developers to understand the code base and enable them to make changes
quickly.
6. To help with code reuse.

Types of Unit Testing:

There are 2 types of Unit Testing: Manual, and Automated.
Workflow of Unit Testing:

Unit Testing Techniques:

 There are 3 types of Unit Testing Techniques:
1. Black Box Testing: This testing technique is used in covering the unit tests for input,
user interface, and output parts.
2. White Box Testing: This technique is used in testing the functional behavior of the
system by giving the input and checking the functionality output including the internal
design structure and code of the modules.
3. Gray Box Testing: This technique is used in executing the relevant test cases, test
methods, test functions, and analyzing the code performance for the modules.
Unit Testing Tools:
Here are some commonly used Unit Testing tools:
1. Jtest
2. Junit
3. NUnit
4. EMMA
5. PHPUnit
Integration testing
Integration testing is the second level of the software testing process comes after unit testing.
In this testing, units or individual components of the software are tested in a group. The focus
of the integration testing level is to expose defects at the time of interaction between
integrated components or units.
Types of Integration Testing
Software Engineering defines variety of strategies to execute Integration testing, viz.
  Big Bang Approach:
  Incremental Approach: which is further divided into the following
  Top Down Approach
  Bottom Up Approach
  Sandwich Approach – Combination of Top Down and Bottom Up
1. Big Bang Testing
Big Bang Testing is an Integration testing approach in which all the components or modules
are integrated together at once and then tested as a unit. This combined set of components is
considered as an entity while testing. If all of the components in the unit are not completed,
the integration process will not execute.
Advantages:
 Convenient for small systems.
Disadvantages:
 Fault Localization is difficult.
 Given the sheer number of interfaces that need to be tested in this approach, some
interfaces link to be tested could be missed easily.
 Since the Integration testing can commence only after “all” the modules are designed,
the testing team will have less time for execution in the testing phase.
 Since all modules are tested at once, high-risk critical modules are not isolated and
tested on priority. Peripheral modules which deal with user interfaces are also not
isolated and tested on priority.
2. Incremental Testing
In the Incremental Testing approach, testing is done by integrating two or more modules that
are logically related to each other and then tested for proper functioning of the application.
Then the other related modules are integrated incrementally and the process continues until
all the logically related modules are integrated and tested successfully.
1. Bottom-up Integration Testing
Bottom-up Integration Testing is a strategy in which the lower-level modules are tested
first. These tested modules are then further used to facilitate the testing of higher-level
modules. The process continues until all modules at top level are tested. Once the lower-level
modules are tested and integrated, then the next level of modules are formed.
1. Stubs: 
Stubs are developed by software developers to use them in place of modules, if the respective
modules aren’t developed, missing in developing stage, or are unavailable currently while
Top-down testing of modules. A Stub simulates module which has all the capabilities of the
unavailable module. Stubs are used when the lower-level modules are needed but are
unavailable currently. 
Stubs are divided into four basic categories based on what they do : 
 Shows the traced messages,
 Shows the displayed message if any,
 Returns the corresponding values that are utilized by modules,
 Returns the value of the chosen parameters(arguments) that were used by the testing
modules.
2. Drivers: 
Drivers serve the same purpose as stubs, but drivers are used in Bottom-up integration testing
and are also more complex than stubs. Drivers are also used when some modules are missing
and unavailable at time of testing of a specific module because of some unavoidable reasons,
to act in absence of required module. Drivers are used when high-level modules are missing
and can also be used when lower-level modules are missing. 

S.No
. Stubs Drivers

Stubs are used in Top-Down Integration Drivers are used in Bottom-Up

1.
Testing. Integration Testing.

Stubs are basically known as a “called While, drivers are the “calling
2. programs” and are used in the Top-down program” and are used in bottom-up
integration testing. integration testing.
S.No
. Stubs Drivers

Stubs are similar to the modules of the

While drivers are used to invoking the
3. software, that are under development
component that needs to be tested.
process.

While drivers are mainly used in place

Stubs are basically used in the of high-level modules and in some
4.
unavailability of low-level modules. situation as well as for low-level
modules.

Whereas the drivers are used if the

Stubs are taken into use to test the
5. main module of the software isn’t
feature and functionality of the modules.
developed for testing.

The stubs are taken into concern if The drivers are taken into concern if
testing of upper-levels of the modules testing of lower-levels of the modules
6.
are done and the lower-levels of the are done and the upper-levels of the
modules are under developing process. modules are under developing process.

Stubs are used when lower-level of Drivers are used when higher-level of
modules are missing or in a partially modules are missing or in a partially
7.
developed phase, and we want to test the developed phase, and we want to test
main module. the lower(sub)- module.

Advantages:
 Fault localization is easier.
 No time is wasted waiting for all modules to be developed unlike Big-bang approach
Disadvantages:
 Critical modules (at the top level of software architecture) which control the flow of
application are tested last and may be prone to defects.
 An early prototype is not possible
 2. Top-down Integration Testing
Top Down Integration Testing is a method in which integration testing takes place from top
to bottom following the control flow of software system. The higher level modules are tested
first and then lower level modules are tested and integrated in order to check the software
functionality. Stubs are used for testing if some modules are not ready.

Advantages:
 Fault Localization is easier.
 Possibility to obtain an early prototype.
 Critical Modules are tested on priority; major design flaws could be found and fixed
first.
Disadvantages:
 Needs many Stubs.
 Modules at a lower level are tested inadequately.
Sandwich Testing
Sandwich Testing is a strategy in which top level modules are tested with lower-level
modules at the same time lower modules are integrated with top modules and tested as a
system. It is a combination of Top-down and Bottom-up approaches therefore it is called
Hybrid Integration Testing. It makes use of both stubs as well as drivers.
Acceptance Testing
It is a formal testing according to user needs, requirements and business processes conducted
to determine whether a system satisfies the acceptance criteria or not and to enable the
users, customers, or other authorized entities to determine whether to accept the system or
not.
Acceptance Testing is the last phase of software testing performed after System Testing and
before making the system available for actual use. 
Objectives of Acceptance Testing:
1. Verify compliance with customer requirements
2. Ensure product functionality and performance
3. Provide evidence of product quality and reliability
4. Identify and resolve any issues before product release
5. Establish confidence in the product among stakeholders.
Types of Acceptance Testing:
1. User Acceptance Testing (UAT): User acceptance testing is used to determine
whether the product is working for the user correctly. Specific requirements which are
 quite often used by the customers are primarily picked for the testing purpose. This is
also termed as End-User Testing.
2. Business Acceptance Testing (BAT): BAT is used to determine whether the product
meets the business goals and purposes or not. BAT mainly focuses on business profits
which are quite challenging due to the changing market conditions and new
technologies so the current implementation may have to being changed which results
in extra budgets.
3. Contract Acceptance Testing (CAT): CAT is a contract that specifies that once the
product goes live, within a predetermined period, the acceptance test must be
performed and it should pass all the acceptance use cases.
4. Regulations Acceptance Testing (RAT): RAT is used to determine whether the
product violates the rules and regulations that are defined by the government of the
country where it is being released. This may be unintentional but will impact
negatively on the business. Generally, the product or application that is to be released
in the market, must go under RAT, as different countries or regions have different
rules and regulations defined by its governing bodies.
5. Operational Acceptance Testing (OAT): OAT is used to determine the operational
readiness of the product and is non-functional testing. It mainly includes testing of
recovery, compatibility, maintainability, reliability, etc. OAT assures the stability of
the product before it is released to production.
6. Alpha Testing: Alpha testing is used to determine the product in the development
testing environment by a specialized testers team usually called alpha testers.
7. Beta Testing: Beta testing is used to assess the product by exposing it to the real end-
users, usually called beta testers in their environment. Feedback is collected from the
users and the defects are fixed. Also, this helps in enhancing the product to give a rich
user experience.
Use of Acceptance Testing:
 To find the defects missed during the functional testing phase.
 How well the product is developed.
 A product is what the customers need.
 Feedback help in improving the product performance and user experience.
 Minimize or eliminate the issues arising from the production.
Advantages of Acceptance Testing:
 This testing helps the project team to know the further requirements from the users
directly as it involves the users for testing.
 Automated test execution.
 It brings confidence and satisfaction to the clients as they are directly involved in the
testing process.
  It is easier for the user to describe their requirement.
 It covers only the Black-Box testing process and hence the entire functionality of the
product will be tested.
Disadvantages of Acceptance Testing:
 Users should have basic knowledge about the product or application.
 Sometimes, users don’t want to participate in the testing process.
 The feedback for the testing takes long time as it involves many users and the
opinions may differ from one user to another user.
 Development team is not participated in this testing process.
Regression Testing
Regression testing refers to a type of software testing that is used to verify any modification
or update in a software without affecting the overall working functionality of the said
software.
Regression testing is performed when there is a code change in a software application. 
When to do regression testing?
 When a new functionality is added to the system and the code has been modified to
absorb and integrate that functionality with the existing code.
 When some defect has been identified in the software and the code is debugged to fix
it.
 When the code is modified to optimize it’s working.
Advantages of Regression Testing:
 It ensures that no new bugs have been introduced after adding new functionalities to
the system.
 As most of the test cases used in Regression Testing are selected from the existing test
suite and we already know their expected outputs. Hence, it can be easily automated
by the automated tools.
 It helps to maintain the quality of the source code.
Disadvantages of Regression Testing:
 It can be time and resource consuming if automated tools are not used.
 It is required even after very small changes in the code.

Performance Testing Functional Testing

Objective Validates performance Validates behaviour

Focus Area User expectations User requirements

Test data input Performance requirements Functional Requirements

Test Execution Sequence Done after functional testing Done before performance testing

Testing Approach Automation preferred Manual or Automated or

Crowdsource

Production test environment Preferred Not mandatory

emulation

Infrastructural requirements High Minimal

Time taken for testing Less More

Impact of functional No Yes

Requirement changes 

Testing Tools examples LoadRunner, Jmeter Selenium, QTP, WinRunner

Sl
Functional Testing Performance Testing
NO
1 To verify the accuracy of the software with To verify the behaviour of the system at
definite inputs against expected output various load conditions
2 It can be manual or automated It can be performed effectively if automated
3 One user performing all the operations Several users performing desired operations
4 Involvement required from Customer, Involvement required from Customer, Tester,
Tester, and Developer Developer, DBA and N/W Management team
5 Production sized test environment not Requires close to production test environment
mandatory and H/W requirements are & several H/W facilities to populate the load
minimal
 Basis Fault Error Failure

Definition

Failure is the
accumulation of
several defects that
A Fault is a state that causes An Error is a mistake ultimately lead to
the software to fail and made in the code due Software failure and
therefore it does not achieve to which compilation results in the loss of
its necessary function. or execution fails, information in critical
modules thereby
making the system
unresponsive.

The failure is found by

Developers and
the test engineer during
Raised by Human mistakes lead to fault. automation test
the development cycle
engineers
of SDLC

 Syntactic Error
 UI screen error
 Business Logic Faults  Error handling
 Functional and Logical error
Faults  Flow control
Different types  Graphical User error
NA
Interface (GUI) Faults  Calculation
 Performance Faults error
 Security Faults  Hardware error
 Hardware Faults

Reasons behind  Wrong design of the  Error in code.

data definition  Inability to  Environment
processes. compile/execut variables
 An irregularity in e a program
 System Errors
Logic or gaps in the  Ambiguity in
software lead to the code logic  Human Error
non-functioning of the  Misunderstandi
 Basis Fault Error Failure

ng of
requirements
software.  Faulty design
and architecture
 Logical error

 Confirmation
of Re-testing
 Conduct peer the process end
reviews and to end,
 Peer review of the Test
code-reviews  Carefully
documents and
requirements.  Need for review the
Way to prevent validation of requirements as
 Verifying the well as the
the reasons bug fixes and
correctness of software specifications.
enhancing the
design and coding.
overall quality  Categorizing
of the software. and evaluating
the errors and
issues.

White box Testing

White box testing techniques analyze the internal structures the used data structures, internal
design, code structure, and the working of the software rather than just the functionality as in
black box testing. It is also called glass box testing or clear box testing or structural testing.
White Box Testing is also known as transparent testing, open box testing. 
Reasons for white box testing
o It identifies internal security holes.
o To check the way of input inside the code.
o Check the functionality of conditional loops.
o To test function, object, and statement at an individual level.
Advantages of White box testing
o White box testing optimizes code so hidden errors can be identified.
o Test cases of white box testing can be easily automated.
 o This testing is more thorough than other testing approaches as it covers all code paths.
o It can be started in the SDLC phase even without GUI.
Disadvantages of White box testing
o White box testing is too much time consuming when it comes to large-scale
programming applications.
o White box testing is much expensive and complex.
o It can lead to production error because it is not detailed by the developers.
o White box testing needs professional programmers who have a detailed knowledge
and understanding of programming language and implementation.
Black-Box Testing
Black box testing is a type of software testing in which the functionality of the software
is not known. The testing is done without the internal knowledge of the products.
Black box testing can be done in the following ways: 
1. Syntax-Driven Testing – This type of testing is applied to systems that can be
syntactically represented by some language. For example- compilers, language that can
be represented by context-free grammar. In this, the test cases are generated so that each
grammar rule is used at least once. 
2. Equivalence partitioning – It is often seen that many types of inputs work similarly so
instead of giving all of them separately we can group them and test only one input of each
group. The idea is to partition the input domain of the system into several equivalence
classes such that each member of the class works similarly, i.e., if a test case in one class
results in some error, other members of the class would also result in the same error.
Tools Used for Black Box Testing:
1. Appium
2. Selenium
3. Microsoft Coded UI
4. Applitools
5. HP QTP.
 Features of black box testing:
1. Independent testing: Black box testing is performed by testers who are not involved
in the development of the application, which helps to ensure that testing is unbiased
and impartial.
2. Testing from a user’s perspective: Black box testing is conducted from the
perspective of an end user, which helps to ensure that the application meets user
requirements and is easy to use.
 3. No knowledge of internal code: Testers performing black box testing do not have
access to the application’s internal code, which allows them to focus on testing the
application’s external behavior and functionality.
4. Requirements-based testing: Black box testing is typically based on the
application’s requirements, which helps to ensure that the application meets the
required specifications.
5. Different testing techniques: Black box testing can be performed using various
testing techniques, such as functional testing, usability testing, acceptance testing, and
regression testing.
6. Easy to automate: Black box testing is easy to automate using various automation
tools, which helps to reduce the overall testing time and effort.
7. Scalability: Black box testing can be scaled up or down depending on the size and
complexity of the application being tested.
8. Limited knowledge of application: Testers performing black box testing have
limited knowledge of the application being tested, which helps to ensure that testing is
more representative of how the end users will interact with the application.
Advantages of Black Box Testing:
 The tester does not need to have more functional knowledge or programming skills to
implement the Black Box Testing.
 It is efficient for implementing the tests in the larger system.
 Tests are executed from the user’s or client’s point of view.
 Test cases are easily reproducible.
 It is used in finding the ambiguity and contradictions in the functional specifications.
Disadvantages of Black Box Testing:
1. There is a possibility of repeating the same tests while implementing the testing
process.
2. Without clear functional specifications, test cases are difficult to implement.
3. It is difficult to execute the test cases because of complex inputs at different stages
of testing.
4. Sometimes, the reason for the test failure cannot be detected.
5. Some programs in the application are not tested.
6. It does not reveal the errors in the control structure.
7. Working with a large sample space of inputs can be exhaustive and consumes a lot
of time.

Difference between white-box testing and black-box testing

Following are the significant differences between white box testing and black box testing:
White-box testing Black box testing

The developers can perform white box The test engineers perform the black box testing.
testing.

To perform WBT, we should understand the To perform BBT, there is no need to understand the
programming languages. programming languages.

In this, we will investigate the source code In this, we will verify the functionality of the application
and test the logic of the code. based on the requirement specification.

In this, the developer should know about the In this, there is no need to know about the internal design
internal design of the code. of the code.

Test Suite Preparations

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, InProgress 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.
A TEST SUITE is a collection of test cases. In automated testing, it can mean a collection
of test scripts. In a test suite, the test cases / scripts are organized in a logical order. For
example, the test case for registration will precede the test case for login.
Test Suite - Diagram:
An example of a test suite for purchasing a product could comprise of the following test
cases:
 Test Case 1: Login
 Test Case 2: Add Products
 Test Case 3: Checkout
 Test Case 4: Logout
Alpha testing
Alpha testing is the initial phase of validating whether a new product will perform as
expected. Alpha tests are carried out early in the development process by internal staff and
are followed up with beta tests, in which a sampling of the intended audience tries the
product out.
Alpha Testing is a type of software testing performed to identify bugs before releasing the
product to real users or to the public. Alpha Testing is one of the user acceptance testing.
Alpha testing is commonly performed by homestead software engineers or quality assurance
staff. It is the last testing stage before the software is released into the real world. 
Advantages of alpha testing include:
1. Early identification of bugs and issues: Alpha testing allows for the early
identification of bugs and issues, providing an opportunity to fix them before they
reach end-users.
2. Improved quality: By identifying and fixing bugs and issues early in the
development process, alpha testing helps to improve the overall quality of the
software.
3. Increased user satisfaction: Alpha testing helps to ensure that the software meets the
needs of the target audience, leading to increased user satisfaction.
 4. Faster resolution of problems: Alpha testing allows for the rapid resolution of
problems, reducing the likelihood of further issues down the line.
5. Cost savings: By identifying and fixing issues early in the development process,
alpha testing can help to save time and money by avoiding the need for more
extensive testing and bug fixing later.
Objective of Alpha Testing:
1. The objective of alpha testing is to refine the software product by finding the bugs
that were not discovered during the previous tests.
2. The objective of alpha testing is to give better insight into the software’s reliability at
the early stages of development.
3. The main objective of alpha testing is to identify and resolve critical bugs and issues
in the software before it is released to the public. The goal is to assess the software’s
overall quality, functionality, usability, performance, and stability in a controlled
environment, and to ensure that it meets the needs and expectations of the target
audience.
4. Overall, the objective of alpha testing is to improve the quality of the software, ensure
that it meets the needs of the target audience, and reduce the risk of issues and bugs
affecting end-users after the software has been released.
Alpha Testing Process:
1. Review the design specification and functional requirements.
2. Develop comprehensive test cases and test plans.
3. Execute test plan
4. Log defects
5. Retest once the issues have been fixed
Phases of Alpha Testing:
There are two phases in alpha testing:
1st Phase: The first phase of testing is done by in-house developers or software engineers.
They either use hardware-aided debuggers or debugger software. The aim is to catch bugs
quickly. Usually while alpha testing, a tester comes across to lots of bugs, crashes, missing
features, and docs. 
2nd Phase: The second phase of alpha testing is done by software quality assurance staff for
additional testing in an environment. It includes a black box as well as white box testing.
The phases of alpha testing typically include:
1. Planning: This phase involves defining the scope, objectives, and schedule for the
alpha testing process. It also includes identifying the target audience, the test
environment, and the resources required for the testing.
2. Preparation: This phase involves setting up the test environment, configuring the test
cases, and preparing the test data. It also includes creating the test scripts and building
the test infrastructure.
 3. Execution: This phase involves running the test cases and collecting the test results.
Testers will report any bugs or issues they encounter, and the development team will
work to fix them.
4. Evaluation: This phase involves analyzing the test results and determining whether
the software meets the requirements and performs as expected. It also includes
identifying areas of improvement and making recommendations for further testing.
5. Reporting: This phase involves documenting the test results and providing a report to
the development team and stakeholders. It also includes presenting the findings and
recommendations for future testing and development.
6. Closure: This phase involves wrapping up the testing process and releasing the
software for further testing or for release to the end-users.
Disadvantages of Alpha Testing:
 It will need a longer time for test plan execution if the project is large.
 Sometimes, the defects in the products can be unknown during this alpha testing.
 It is difficult to test the entire product since it is still under development.
 For smaller projects, time spent on alpha testing is not worthy enough.
 It does not carry out reliability and security testing.
 This test will only cover the business requirements mentioned by the client. The
project team will not go through the deep testing of each and every module.
 It requires a separate lab environment for testing.  
Beta Testing
Beta testing is a type of User Acceptance Testing among the most crucial testing, which
performed before the release of the software. Beta Testing is a type of Field Test. This testing
performs at the end of the software testing life cycle. This type of testing can be considered as
external user acceptance testing. It is a type of salient testing. Real users perform this testing.
This testing executed after the alpha testing. In this the new version, beta testing is released to
a limited audience to check the accessibility, usability, and functionality, and more.

Advantages of Beta Testing

 1. Beta testing focuses on the customer's satisfaction.
2. It helps to reduce the risk of product failure via user validations.
3. Beta testing helps to get direct feedback from users.
4. It helps to detect the defect and issues in the system, which is overlooked and
undetected by the team of software testers.
5. Beta testing helps the user to install, test, and send feedback regarding the developed
software.
Disadvantages of Beta Testing
1. In this type of testing, a software engineer has no control over the process of the
testing, as the users in the real-world environment perform it.
2. This testing can be a time-consuming process and can delay the final release of the
product.
3. Beta testing does not test the functionality of the software in depth as software still in
development.
4. It is a waste of time and money to work on the feedback of the users who do not use
the software themselves properly.
Difference between Alpha and Beta Testing
Alpha Testing Beta Testing

Alpha testing performed by Testers who are Beta testing is performed by Clients or End Users
usually internal employees of the organization who are not employees of the organization

Beta testing is performed at a client location or end

Alpha Testing performed at developer’s site
user of the product

Reliability and Security Testing are not Reliability, Security, Robustness are checked during
performed in-depth Alpha Testing Beta Testing

Alpha testing involves both the white box and

Beta Testing typically uses Black Box Testing
black box techniques

Beta testing does not require any lab environment or

Alpha testing requires a lab environment or
testing environment. The software is made available
testing environment
to the public and is said to be real time environment

Long execution cycle may be required for Only a few weeks of execution are required for Beta
Alpha testing testing

Most of the issues or feedback is collected from

Critical issues or fixes can be addressed by
Beta testing will be implemented in future versions
developers immediately in Alpha testing
of the product

Alpha testing is to ensure the quality of the Beta testing also concentrates on the quality of the
 product, but gathers users input on the product and
product before moving to Beta testing
ensures that the product is ready for real time users.

Static Testing
Static Testing is a type of a Software Testing method which is performed to check the defects
in software without executing the code of the software application.
Static Testing Techniques: There are mainly two type techniques used in Static Testing:

1. Review: In static testing review is a process or technique that is performed to find the
potential defects in the design of the software. It is process to detect and remove errors and
defects in the different supporting documents like software requirements specifications.
People examine the documents and sorted out errors, redundancies and ambiguities. Review
is of four types:
 Informal: In informal review the creator of the documents put the contents in front of
audience and everyone gives their opinion and thus defects are identified in the early
stage.
 Walkthrough: It is basically performed by experienced person or expert to check the
defects so that there might not be problem further in the development or testing phase.
 Peer review: Peer review means checking documents of one-another to detect and fix
the defects. It is basically done in a team of colleagues.
 Inspection: Inspection is basically the verification of document the higher authority
like the verification of software requirement specifications (SRS).
2. Static Analysis: Static Analysis includes the evaluation of the code quality that is written
by developers. Different tools are used to do the analysis of the code and comparison of the
same with the standard. 
Static Analysis is of three types:
 Data Flow: Data flow is related to the stream processing.
 Control Flow: Control flow is basically how the statements or instructions are
executed.
 Cyclomatic Complexity: Cyclomatic complexity defines the number of independent
paths in the control flow graph made from the code or flowchart so that minimum
number of test cases can be designed for each independent path.
Why we need Static Testing?
We required Static testing whenever we encounter the following situation while testing an
application or the software:
 Dynamic Testing is time-consuming
 Flaws at earlier stages/identification of Bugs
 Dynamic Testing is expensive
 Increased size of the software
Formal Technical Review (FTR)
Formal Technical Review (FTR) is a software quality control activity performed by software
engineers.
Objectives of formal technical review (FTR): Some of these are:
1. Useful to uncover error in logic, function and implementation for any representation
of the software.
2. The purpose of FTR is to verify that the software meets specified requirements.
3. To ensure that software is represented according to predefined standards.
4. It helps to review the uniformity in software that is development in a uniform manner.
5. To makes the project more manageable.
Review guidelines: -
Guidelines for the conducting of formal technical reviews should be established in advance.
These guidelines must be distributed to all reviewers, agreed upon, and then followed. A
review that is unregistered can often be worse than a review that does not minimum set of
guidelines for FTR.
1. Review the product, not the manufacture (producer).
2. Take written notes (record purpose)
3. Limit the number of participants and insists upon advance preparation.
4. Develop a checklist for each product that is likely to be reviewed.
5. Allocate resources and time schedule for FTRs in order to maintain time schedule.
6. Conduct meaningful training for all reviewers in order to make reviews effective.
7. Reviews earlier reviews which serve as the base for the current review being
conducted.
8. Set an agenda and maintain it.
9. Separate the problem areas, but do not attempt to solve every problem notes.
Phases of Formal Review:

Walk Through
The walkthrough is a review meeting process but it is different from the  Inspection, as it
does not involve any formal process i.e. it is a nonformal process. Basically, the walkthrough
[review meeting process] is started by the Author of the code.
In the walkthrough, the code or document is read by the author, and others who are present in
the meeting can note down the important points or can write notes on the defects and can give
suggestions about them. The walkthrough is an informal way of testing, no formal authority
is been involved in this testing.
Objectives of Walkthrough: 
Following are some of the objectives of the walkthrough.
 To detect defects in developed software products.
 To fully understand and learn the development of software products.
 To properly explain and discuss the information present in the document.
 To verify the validity of the proposed system.
 To give suggestions and report them appropriately with new solutions and ideas.
 To provide an early “proof of concept”.
Advantages
 Incorporates multiple perspectives
 Fosters communication between the team
  Increases the knowledge of the entire team related to the code in question
Disadvantages
 Areas where questions are not raised may go unnoticed
 Lack of diversity, as the author leads the meeting and everyone merely verifies if what
is being said matches the code
 Meetings can be time-consuming
Software Inspection
Software inspection is a process in which other developers or team members review the code
written by a developer to identify potential errors or areas for improvement. This process can
help improve the overall quality of the software by identifying and resolving faults early in
the development process.
There are several ways that software inspection can improve software quality:
1. Identifying and resolving defects early: By identifying and resolving defects early
in the development process, inspection can prevent costly rework and delays later in
the project.
2. Enhancing code readability: Inspection can help improve the readability of the code,
making it easier for other developers to understand and maintain.
3. Improving team collaboration: Inspection can help improve team collaboration by
encouraging developers to share their ideas and knowledge.
4. Enhancing code maintainability: Inspection can help identify areas where code is
difficult to maintain and suggest improvements to make it more maintainable.
5. Improving code efficiency: Inspection can help identify areas where code is
inefficient and suggest improvements to make it more efficient.
6. Enhancing security: Inspection can help identify security vulnerabilities in the code
and suggest improvements to make the software more secure.
7. Improving the overall quality of the software: By identifying and resolving defects
early in the development process, inspection can help improve the overall quality of
the software and ensure that it meets the needs of its users.
Disadvantages of Software Inspection:
1. It is a time-consuming process.
2. Software inspection requires discipline.
3. Time-consuming: Software inspection can be time-consuming, especially for large
and complex systems, as it involves a thorough review of the code.
4. Dependence on human interpretation: Software inspection is often dependent on
human interpretation, which can lead to inconsistencies and errors.
5. Can be subject to bias: Reviewers might have their own biases, which can affect their
interpretation of the code and the defects they identify.
6. Limited scope: Software inspection is limited to the code that is reviewed, and may
not identify all defects in the system.
7. Limited to detecting syntax errors: Software inspection is not able to detect all types
of errors, particularly semantic errors, which are caused by incorrect logic or design.
8. Can be costly: Software inspection can be costly, especially if it requires the
involvement of external experts or specialized tools.
9. Can be tedious and demotivating: Reviewing code can be tedious, and constant
reviews can demotivate the team members.
10. Can lead to a lack of creativity: Software inspection can stifle creativity, as developers
may feel constrained by the need to conform to established standards and practices.
Coding Standards and Guidelines
coding standards are given below:
1. Limited use of global:
These rules talk about which types of data that can be declared global and the data
that can’t be.

2. 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

3. 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.

4. 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.

5. 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 guidelines are given below:
1. 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.

2. 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.

3. Code should be well documented:

The code should be properly commented for understanding easily. Comments
regarding the statements increase the understandability of the code.

4. 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.

5. 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.

Advantages of Coding Guidelines:

 Coding guidelines increase the efficiency of the software and reduces the
development time.
 Coding guidelines help in detecting errors in the early phases, so it helps to reduce the
extra cost incurred by the software project.
 If coding guidelines are maintained properly, then the software code increases
readability and understandability thus it reduces the complexity of the code.
 It reduces the hidden cost for developing the software.