UNIT 4

1. Software Testing

Software Testing is a method to assess the functionality of the software program. The process checks whether the actual software matches the expected requirements and
ensures the software is bug-free. The purpose of software testing is to identify the errors, faults, or missing requirements in contrast to actual requirements. It mainly aims
at measuring the specification, functionality, and performance of a software program or application.

Software testing can be divided into two steps:

 Verification: It refers to the set of tasks that ensure that the software correctly implements a specific function. It means “Are we building the product right?”.
 Validation: It refers to a different set of tasks that ensure that the software that has been built is traceable to customer requirements. It means “Are we building the
right product?”.

Importance of Software Testing:

 Defects can be identified early: Software testing is important because if there are any bugs they can be identified early and can be fixed before the delivery
of the software.
 Improves quality of software: Software Testing uncovers the defects in the software, and fixing them improves the quality of the software.
 Increased customer satisfaction: Software testing ensures reliability, security, and high performance which results in saving time, costs, and customer
satisfaction.
 Helps with scalability: Software testing type non-functional testing helps to identify the scalability issues and the point where an application might stop
working.
 Saves time and money: After the application is launched it will be very difficult to trace and resolve the issues, as performing this activity will incur more
costs and time. Thus, it is better to conduct software testing at regular intervals during software development.

Need for Software Testing

Software bugs can cause potential monetary and human loss. There are many examples in history that clearly depicts that without the testing phase in software
development lot of damage was incurred. Below are some examples:
 1985: Canada’s Therac-25 radiation therapy malfunctioned due to a software bug and resulted in lethal radiation doses to patients leaving 3 injured and 3
people dead.
 1994: China Airlines Airbus A300 crashed due to a software bug killing 264 people.
 1996: A software bug caused U.S. bank accounts of 823 customers to be credited with 920 million US dollars.
 1999: A software bug caused the failure of a $1.2 billion military satellite launch.
 2015: A software bug in fighter plan F-35 resulted in making it unable to detect targets correctly.
 2015: Bloomberg terminal in London crashed due to a software bug affecting 300,000 traders on the financial market and forcing the government to postpone
the 3bn pound debt sale.
 Starbucks was forced to close more than 60% of its outlet in the U.S. and Canada due to a software failure in its POS system.
 Nissan cars were forced to recall 1 million cars from the market due to a software failure in the car’s airbag sensory detectors.

Different Types Of Software Testing

Software Testing can be broadly classified into 3 types:

 Functional testing: It is a type of software testing that validates the software systems against the functional requirements. It is performed to check whether the
application is working as per the software’s functional requirements or not. Various types of functional testing are Unit testing, Integration testing, System testing,
Smoke testing, and so on.
 Non-functional testing: It is a type of software testing that checks the application for non-functional requirements like performance, scalability, portability, stress,
etc. Various types of non-functional testing are Performance testing, Stress testing, Usability Testing, and so on.
 Maintenance testing: It is the process of changing, modifying, and updating the software to keep up with the customer’s needs. It involves regression
testing that verifies that recent changes to the code have not adversely affected other previously working parts of the software.
Apart from the above classification software testing can be further divided into 2 more ways of testing:
 Manual testing: It includes testing software manually, i.e., without using any automation tool or script. In this type, the tester takes over the role of an end-user
and tests the software to identify any unexpected behavior or bug. There are different stages for manual testing such as unit testing, integration testing, system
testing, and user acceptance testing. Testers use test plans, test cases, or test scenarios to test software to ensure the completeness of testing. Manual testing also
includes exploratory testing, as testers explore the software to identify errors in it.
 Automation testing: It is also known as Test Automation, is when the tester writes scripts and uses another software to test the product. This process involves the
automation of a manual process. Automation Testing is used to re-run the test scenarios quickly and repeatedly, that were performed manually in manual testing.
Apart from Regression testing, Automation testing is also used to test the application from a load, performance, and stress point of view. It increases the test
coverage, improves accuracy, and saves time and money when compared to manual testing.

Best Practices for Software Testing

Below are some of the best practices for software testing:
 Continuous testing: Project teams test each build as it becomes available thus it enables software to be validated in real environments earlier in the
development cycle, reducing risks and improving the functionality and design.
  Involve users: It is very important for the developers to involve users in the process and open-ended questions about the functionality required in the
application. This will help to develop and test the software from the customer’s perspective.
 Divide tests into smaller parts: Dividing tests into smaller fractions save time and other resources in environments where frequent testing needs to be
conducted. This also helps teams to make better analyses of the tests and the test results.
 Metrics and Reporting: Reporting enables the team members to share goals and test results. Advanced tools integrate the project metrics and present an
integrated report in the dashboard that can be easily reviewed by the team members to see the overall health of the project.
 Don’t skip regression testing: Regression testing is one of the most important steps as it encourages the validation of the application. Thus, it should not be
skipped.
 Programmers should avoid writing tests: Test cases are usually written before the start of the coding phase so it is considered a best practice for
programmers to avoid writing test cases as they can be biased towards their code and the application.
 Service virtualization: Service virtualization simulates the systems and services that are not yet developed or are missing. Thus, enabling teams to reduce
dependency and start the testing process sooner. They can modify, and reuse the configuration to test different scenarios without having to alter the original
environment.

Benefits of Software Testing

 Product quality: Testing ensures the delivery of a high-quality product as the errors are discovered and fixed early in the development cycle.
 Customer satisfaction: Software testing aims to detect the errors or vulnerabilities in the software early in the development phase so that the detected bugs
can be fixed before the delivery of the product. Usability testing is a type of software testing that checks the application for how easily usable it is for the users
to use the application.
 Cost-effective: Testing any project on time helps to save money and time for the long term. If the bugs are caught in the early phases of software testing, it
costs less to fix those errors.
 Security: Security testing is a type of software testing that is focused on testing the application for security vulnerabilities from internal or external sources.

2. Testing Objectives

Some of the significant objectives of software testing are as follows:

 To evaluate the work products such as requirements, design, user stories, and code: The work products such as Requirement document, Design, and User
Stories should be verified before the developer picks it up for development. Identifying any ambiguity or contradicting requirements at this stage saves considerable
development and test time. The static analysis of the code (reviews, walk-thru, inspection, etc.) happens before the code integrates/is ready for testing. This idea of
testing is known as Verification. It is the process of evaluating the product during the development phase of each work product.
 To verify the fulfillment of all specified requirements: This objective reveals the fact that the essential elements of testing should be to fulfill the customer’s needs.
Testers test the product and ensure the implementation of all the specified requirements have. Developing all the test cases, regardless of the testing technique ensures
verification of the functionality for every executed test case. The Tester should also create a requirement traceability matrix (RTM), which will ensure the mapping of
all the test cases to requirements. RTM is an effective way to ensure that test cases have got the right requirement coverage.
 To validate if the test object is complete and works as per the expectation of the users and the stakeholders: Testing ensures the implementation of
requirements along with the assurance that they work as per the expectation of users. This idea of testing is called Validation. It is the process of checking the product
after development. Validation can be a manual or automation. It usually employs various types of testing techniques, i.e., Black Box, White Box, etc. Generally,
testers perform validation, whereas customers can also validate the product as part of User acceptance testing. Every business considers the customer as the king.
Thus the customer's satisfaction is a predominant need for any business. For example, customer satisfaction and loyalty in online shopping and e-commerce
environments is a useful indicator for long-term business success.
 To build confidence in the quality level of the test object: One of the critical objectives of software testing is to improve software quality. High-Quality software
means a lesser number of defects. In other words, the more efficient the testing process is, the fewer errors you will get in the end product. Which, in turn, will
increase the overall quality of the test object. Excellent quality contributes to a significant increase in customer satisfaction as well as lower maintenance costs.
 To prevent defects in the software product: One of the objectives of software testing is to avoid the mistakes in the early stage of the development. Early detection
of errors significantly reduces the cost and effort. The prevention of defects involves doing a root cause analysis of the defects found previously and after that, taking
specific measures to prevent the occurrence of those types of errors in the future. Efficient testing helps in providing an error-free application. If you prevent defects,
it will result in reducing the overall defect count in the product, which further ensures a high-quality product to the customer.
 To find defects in the software product: Another essential objective of software testing is to identify all defects in a product. The main motto of testing is to find
maximum defects in a software product while validating whether the program is working as per the user requirements or not. Defects should be identified as early in
the test cycle as possible. E.g., a defect found in the UAT phase will be much costlier to fix than the same defect found in the Sprint testing phase.
 To provide sufficient information to stakeholders to allow them to make informed decisions, especially regarding the level of quality of the test object: The
purpose of testing is to provide complete information to the stakeholders about technical or other restrictions, risk factors, ambiguous requirements, etc. It can be in
the form of test coverage, testing reports covering details like what is missing, what went wrong. The aim is to be transparent and make stakeholders fully understand
the issues affecting quality.
 To reduce the level of risk of insufficient software quality: The possibility of loss is also known as risk. The objective of software testing is to reduce the
occurrence of the risk. Each software project is unique and contains a significant number of uncertainties from different perspectives, such as market launch time,
budget, the technology chosen, implementation, or product maintenance. If we do not control these uncertainties, it will impose potential risks not only during the
development phases but also during the whole life cycle of the product. So, the primary objective of software testing is to integrate the Risk management process to
identify any risk as soon as possible in the development process.
 To comply with contractual, legal, or regulatory requirements or standards, and to verify the test object’s compliance with such requirements or standards:
This objective ensures that software developed for a specific region must follow the legal rules and regulations of that region. Moreover, the software product must be
 compatible with the national and international standards of testing. We have ISO/IEC/IEEE 29119 standards that deal with the software testing concept. E.g., each
country has laws specific to accessibility requirements which must be fulfilled to avoid legal implications. The European Union has strict rules on how the Personal
Identifiable Information (PII) like Social security number etc. should be handled. Failure to adhere to such requirements will lead to failure of the product, no matter
how defect-free it has been working!

3. Unit Testing

Unit testing is a type of software testing that focuses on individual units or components of a software system. The purpose of unit testing is to validate that each unit of
the software works as intended and meets the requirements. Developers typically perform unit testing, and it is performed early in the development process before the
code is integrated and tested as a whole system.

Unit tests are automated and are run each time the code is changed to ensure that new code does not break existing functionality. Unit tests are designed to validate the
smallest possible unit of code, such as a function or a method, and test it in isolation from the rest of the system. This allows developers to quickly identify and fix any
issues early in the development process, improving the overall quality of the software and reducing the time required for later testing.

 Unit Testing is a software testing technique using which individual units of software i.e. group of computer program modules, usage procedures, and
operating procedures are tested to determine whether they are suitable for use or not.
 It is a testing method using which every independent module is tested to determine if there is an issue by the developer himself. It is correlated with the
functional correctness of the independent modules.
 Unit Testing is defined as a type of software testing where individual components of a software are tested. Unit Testing of the software product is carried out
during the development of an application.
 An individual component may be either an individual function or a procedure. The developer typically performs Unit Testing. In SDLC or V Model, Unit
testing is the first level of testing done before integration testing.
 Unit testing is a type of testing technique that is usually performed by developers. Although due to the reluctance of developers to test, quality assurance
engineers also do unit testing.

Objective of Unit Testing

The objective of Unit Testing is:
 To isolate a section of code.
 To verify the correctness of the code.
 To test every function and procedure.
 To fix bugs early in the development cycle and to save costs.
 To help the developers understand the code base and enable them to make changes quickly.
 To help with code reuse.

Workflow of Unit Testing

Unit Testing Techniques

There are 3 types of Unit Testing Techniques. They are
 Black Box Testing: This testing technique is used in covering the unit tests for input, user interface, and output parts.
 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.
 Gray Box Testing: This technique is used in executing the relevant test cases, test methods, and test functions, and analyzing the code performance for the
modules.

Unit Testing Tools

Here are some commonly used Unit Testing tools:
 Jtest, Junit, NUnit, EMMA, PHPUnit

Advantages of Unit Testing

 Unit Testing allows developers to learn what functionality is provided by a unit and how to use it to gain a basic understanding of the unit API.
 Unit testing allows the programmer to refine code and make sure the module works properly.
 Unit testing enables testing parts of the project without waiting for others to be completed.
 Early Detection of Issues: Unit testing allows developers to detect and fix issues early in the development process before they become larger and more difficult to
fix.
 Improved Code Quality: Unit testing helps to ensure that each unit of code works as intended and meets the requirements, improving the overall quality of the
software.
 Increased Confidence: Unit testing provides developers with confidence in their code, as they can validate that each unit of the software is functioning as
expected.
 Faster Development: Unit testing enables developers to work faster and more efficiently, as they can validate changes to the code without having to wait for the
full system to be tested.
 Better Documentation: Unit testing provides clear and concise documentation of the code and its behavior, making it easier for other developers to understand and
maintain the software.
 Facilitation of Refactoring: Unit testing enables developers to safely make changes to the code, as they can validate that their changes do not break existing
functionality.
  Reduced Time and Cost: Unit testing can reduce the time and cost required for later testing, as it helps to identify and fix issues early in the development process.

Disadvantages of Unit Testing

 The process is time-consuming for writing the unit test cases.
 Unit Testing will not cover all the errors in the module because there is a chance of having errors in the modules while doing integration testing.
 Unit Testing is not efficient for checking the errors in the UI(User Interface) part of the module.
 It requires more time for maintenance when the source code is changed frequently.
 It cannot cover the non-functional testing parameters such as scalability, the performance of the system, etc.
 Time and Effort: Unit testing requires a significant investment of time and effort to create and maintain the test cases, especially for complex systems.
 Dependence on Developers: The success of unit testing depends on the developers, who must write clear, concise, and comprehensive test cases to validate the
code.
 Difficulty in Testing Complex Units: Unit testing can be challenging when dealing with complex units, as it can be difficult to isolate and test individual units in
isolation from the rest of the system.
 Difficulty in Testing Interactions: Unit testing may not be sufficient for testing interactions between units, as it only focuses on individual units.
 Difficulty in Testing User Interfaces: Unit testing may not be suitable for testing user interfaces, as it typically focuses on the functionality of individual units.
 Over-reliance on Automation: Over-reliance on automated unit tests can lead to a false sense of security, as automated tests may not uncover all possible issues or
bugs.
 Maintenance Overhead: Unit testing requires ongoing maintenance and updates, as the code and test cases must be kept up-to-date with changes to the software.

4. Integration Testing

Integration testing is the process of testing the interface between two software units or modules. It focuses on determining the correctness of the interface. The purpose
of integration testing is to expose faults in the interaction between integrated units. Once all the modules have been unit-tested, integration testing is performed.

Integration testing is a software testing technique that focuses on verifying the interactions and data exchange between different components or modules of a software
application. The goal of integration testing is to identify any problems or bugs that arise when different components are combined and interact with each other. Integration
testing is typically performed after unit testing and before system testing. It helps to identify and resolve integration issues early in the development cycle, reducing the
risk of more severe and costly problems later on.
Integration testing can be done by picking module by module. This can be done so that there should be a proper sequence to be followed. And also if you don’t want to
miss out on any integration scenarios then you have to follow the proper sequence. Exposing the defects is the major focus of the integration testing and the time of
interaction between the integrated units.

Integration test approaches

There are four types of integration testing approaches. Those approaches are the following:

1. Big-Bang Integration Testing

It is the simplest integration testing approach, where all the modules are combined and the functionality is verified after the completion of individual module testing. In
simple words, all the modules of the system are simply put together and tested. This approach is practicable only for very small systems. If an error is found during the
integration testing, it is very difficult to localize the error as the error may potentially belong to any of the modules being integrated. So, debugging errors reported during
Big Bang integration testing is very expensive to fix.
Big-bang integration testing is a software testing approach in which all components or modules of a software application are combined and tested at once. This approach
is typically used when the software components have a low degree of interdependence or when there are constraints in the development environment that prevent testing
individual components. The goal of big-bang integration testing is to verify the overall functionality of the system and to identify any integration problems that arise when
the components are combined. While big-bang integration testing can be useful in some situations, it can also be a high-risk approach, as the complexity of the system and
the number of interactions between components can make it difficult to identify and diagnose problems.
Advantages:
 It is convenient for small systems.
 Simple and straightforward approach.
 Can be completed quickly.
 Does not require a lot of planning or coordination.
 May be suitable for small systems or projects with a low degree of interdependence between components.
Disadvantages:
 There will be quite a lot of delay because you would have to wait for all the modules to be integrated.
 High-risk critical modules are not isolated and tested on priority since all modules are tested at once.
 Not Good for long projects.
 High risk of integration problems that are difficult to identify and diagnose.
 This can result in long and complex debugging and troubleshooting efforts.
 This can lead to system downtime and increased development costs.
 May not provide enough visibility into the interactions and data exchange between components.
 This can result in a lack of confidence in the system’s stability and reliability.
 This can lead to decreased efficiency and productivity.
 This may result in a lack of confidence in the development team.
 This can lead to system failure and decreased user satisfaction.

2. Bottom-Up Integration Testing

In bottom-up testing, each module at lower levels are tested with higher modules until all modules are tested. The primary purpose of this integration testing is that each
subsystem tests the interfaces among various modules making up the subsystem. This integration testing uses test drivers to drive and pass appropriate data to the lower-
level modules.
Advantages:
 In bottom-up testing, no stubs are required.
 A principal advantage of this integration testing is that several disjoint subsystems can be tested simultaneously.
 It is easy to create the test conditions.
  Best for applications that uses bottom up design approach.
 It is Easy to observe the test results.
Disadvantages:
 Driver modules must be produced.
 In this testing, the complexity that occurs when the system is made up of a large number of small subsystems.
 As Far modules have been created, there is no working model can be represented.

3. Top-Down Integration Testing

Top-down integration testing technique is used in order to simulate the behaviour of the lower-level modules that are not yet integrated. In this integration testing, testing
takes place from top to bottom. First, high-level modules are tested and then low-level modules and finally integrating the low-level modules to a high level to ensure the
system is working as intended.
Advantages:
 Separately debugged module.
 Few or no drivers needed.
 It is more stable and accurate at the aggregate level.
 Easier isolation of interface errors.
 In this, design defects can be found in the early stages.
Disadvantages:
 Needs many Stubs.
 Modules at lower level are tested inadequately.
 It is difficult to observe the test output.
 It is difficult to stub design.

4. Mixed Integration Testing

A mixed integration testing is also called sandwiched integration testing. A mixed integration testing follows a combination of top down and bottom-up testing
approaches. In top-down approach, testing can start only after the top-level module have been coded and unit tested. In bottom-up approach, testing can start only after the
bottom level modules are ready. This sandwich or mixed approach overcomes this shortcoming of the top-down and bottom-up approaches. It is also called the hybrid
integration testing. also, stubs and drivers are used in mixed integration testing.
Advantages:
 Mixed approach is useful for very large projects having several sub projects.
 This Sandwich approach overcomes this shortcoming of the top-down and bottom-up approaches.
 Parallel test can be performed in top and bottom layer tests.
Disadvantages:
 For mixed integration testing, it requires very high cost because one part has a Top-down approach while another part has a bottom-up approach.
 This integration testing cannot be used for smaller systems with huge interdependence between different modules.
Applications of Integration Testing
 Identify the components: Identify the individual components of your application that need to be integrated. This could include the frontend, backend, database,
and any third-party services.
 Create a test plan: Develop a test plan that outlines the scenarios and test cases that need to be executed to validate the integration points between the different
components. This could include testing data flow, communication protocols, and error handling.
 Set up test environment: Set up a test environment that mirrors the production environment as closely as possible. This will help ensure that the results of your
integration tests are accurate and reliable.
 Execute the tests: Execute the tests outlined in your test plan, starting with the most critical and complex scenarios. Be sure to log any defects or issues that you
encounter during testing.
 Analyze the results: Analyze the results of your integration tests to identify any defects or issues that need to be addressed. This may involve working with
developers to fix bugs or make changes to the application architecture.
 Repeat testing: Once defects have been fixed, repeat the integration testing process to ensure that the changes have been successful and that the application still
works as expected.

5. System Testing

System testing is a type of software testing that evaluates the overall functionality and performance of a complete and fully integrated software solution. It tests if the
system meets the specified requirements and if it is suitable for delivery to the end-users. This type of testing is performed after the integration testing and before the
acceptance testing.

System Testing is a type of software testing that is performed on a completely integrated system to evaluate the compliance of the system with the corresponding
requirements. In system testing, integration testing passed components are taken as input.
 The goal of integration testing is to detect any irregularity between the units that are integrated. System testing detects defects within both the integrated units
and the whole system. The result of system testing is the observed behavior of a component or a system when it is tested.
 System Testing is carried out on the whole system in the context of either system requirement specifications or functional requirement specifications or the
context of both. System testing tests the design and behavior of the system and also the expectations of the customer.
 It is performed to test the system beyond the bounds mentioned in the software requirements specification (SRS). System Testing is performed by a testing
team that is independent of the development team and helps to test the quality of the system impartial.
 It has both functional and non-functional testing. System Testing is a black-box testing. System Testing is performed after the integration testing and before
the acceptance testing.

System Testing Process

System Testing is performed in the following steps:
  Test Environment Setup: Create testing environment for the better quality testing.
 Create Test Case: Generate test case for the testing process.
 Create Test Data: Generate the data that is to be tested.
 Execute Test Case: After the generation of the test case and the test data, test cases are executed.
 Defect Reporting: Defects in the system are detected.
 Regression Testing: It is carried out to test the side effects of the testing process.
 Log Defects: Defects are fixed in this step.
 Retest: If the test is not successful then again test is performed.

Types of System Testing

 Performance Testing: Performance Testing is a type of software testing that is carried out to test the speed, scalability, stability and reliability of the software
product or application.
 Load Testing: Load Testing is a type of software Testing which is carried out to determine the behavior of a system or software product under extreme load.
 Stress Testing: Stress Testing is a type of software testing performed to check the robustness of the system under the varying loads.
 Scalability Testing: Scalability Testing is a type of software testing which is carried out to check the performance of a software application or system in
terms of its capability to scale up or scale down the number of user request load.

Tools used for System Testing

 JMeter, Gallen Framework, Selenium, HP Quality Center/ALM, IBM Rational Quality Manager, Microsoft Test Manager, Selenium, Appium, LoadRunner,
Gatling

Advantages of System Testing

 The testers do not require more knowledge of programming to carry out this testing.
 It will test the entire product or software so that we will easily detect the errors or defects which cannot be identified during the unit testing and integration
testing.
 The testing environment is similar to that of the real time production or business environment.
 It checks the entire functionality of the system with different test scripts and also it covers the technical and business requirements of clients.
 After this testing, the product will almost cover all the possible bugs or errors and hence the development team will confidently go ahead with acceptance
testing
 Verifies the overall functionality of the system.
 Detects and identifies system-level problems early in the development cycle.
 Helps to validate the requirements and ensure the system meets the user needs.
 Improves system reliability and quality.
 Facilitates collaboration and communication between development and testing teams.
 Enhances the overall performance of the system.
 Increases user confidence and reduces risks.
 Facilitates early detection and resolution of bugs and defects.
 Supports the identification of system-level dependencies and inter-module interactions.
 Improves the system’s maintainability and scalability.

Disadvantages of System Testing

 This testing is time consuming process than another testing techniques since it checks the entire product or software.
 The cost for the testing will be high since it covers the testing of entire software.
 It needs good debugging tool otherwise the hidden errors will not be found.
 Can be time-consuming and expensive.
 Requires adequate resources and infrastructure.
 Can be complex and challenging, especially for large and complex systems.
 Dependent on the quality of requirements and design documents.
 Limited visibility into the internal workings of the system.
 Can be impacted by external factors like hardware and network configurations.
 Requires proper planning, coordination, and execution.
 Can be impacted by changes made during development.
 Requires specialized skills and expertise.
 May require multiple test cycles to achieve desired results.

6. Acceptance Testing

Acceptance Testing is a method of software testing where a system is tested for acceptability. The major aim of this test is to evaluate the compliance of the system with
the business requirements and assess whether it is acceptable for delivery or not.

Standard Definition of Acceptance Testing

It is 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.

Types of Acceptance Testing

  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 testing purposes. This is also termed as End-User Testing.
 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.
 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. Here is a contract termed a Service Level Agreement (SLA), which includes
the terms where the payment will be made only if the Product services are in-line with all the requirements, which means the contract is fulfilled.
Sometimes, this contract happens before the product goes live. There should be a well-defined contract in terms of the period of testing, areas of
testing, conditions on issues encountered at later stages, payments, etc.
 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, has to go under RAT, as different countries or regions have different rules and regulations defined by
its governing bodies. If any rules and regulations are violated for any country then that country or the specific region then the product will not be
released in that country or region. If the product is released even though there is a violation then only the vendors of the product will be directly
responsible.
 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.
 Alpha Testing: Alpha testing is used to determine the product in the development testing environment by a specialized testers team usually called
alpha testers.
 Beta Testing: Beta testing is used to assess the product by exposing it to the real end-users, typically 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 actually 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 a 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.

7. Regression Testing

Regression Testing is the process of testing the modified parts of the code and the parts that might get affected due to the modifications to ensure that no new errors have
been introduced in the software after the modifications have been made. Regression means the return of something and in the software field, it refers to the return of a
bug.

When to do regression testing?

 When 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 its working.

Process of Regression testing

Firstly, whenever we make some changes to the source code for any reason like adding new functionality, optimization, etc. then our program when executed fails in the
previously designed test suite for obvious reasons. After the failure, the source code is debugged to identify the bugs in the program. After identification of the bugs in the
source code, appropriate modifications are made. Then appropriate test cases are selected from the already existing test suite which covers all the modified and affected
parts of the source code. We can add new test cases if required. In the end, regression testing is performed using the selected test cases.
Techniques for the selection of Test cases for Regression Testing
 Select all test cases: In this technique, all the test cases are selected from the already existing test suite. It is the simplest and safest technique but not very
efficient.
 Select test cases randomly: In this technique, test cases are selected randomly from the existing test suite, but it is only useful if all the test cases are equally
good in their fault detection capability which is very rare. Hence, it is not used in most of the cases.
 Select modification traversing test cases: In this technique, only those test cases are selected that cover and test the modified portions of the source code and
the parts that are affected by these modifications.
 Select higher priority test cases: In this technique, priority codes are assigned to each test case of the test suite based upon their bug detection capability,
customer requirements, etc. After assigning the priority codes, test cases with the highest priorities are selected for the process of regression testing. The test
case with the highest priority has the highest rank. For example, a test case with priority code 2 is less important than a test case with priority code 1.

Tools for Regression testing

In regression testing, we generally select the test cases from the existing test suite itself and hence, we need not compute their expected output, and it can be easily
automated due to this reason. Automating the process of regression testing will be very effective and time-saving. The most commonly used tools for regression testing
are:
 Selenium, WATIR (Web Application Testing In Ruby), QTP (Quick Test Professional), RFT (Rational Functional Tester), Winrunner, Silktest

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.

8. Testing for Functionality and Testing for Performance

Functional testing and performance testing are one of the two testing and QA that entitle developers and performance engineers to guarantee the quality of code.

Performance Testing
Performance testing is a type of software testing that ensures software applications perform as expected under load. It is a testing technique used to determine system
performance in terms of sensitivity, reactivity, and stability under specific workload conditions.
Performance testing is a type of software testing that focuses on evaluating a system’s or application’s performance and scalability. Performance testing aims to identify
bottlenecks, measure system performance under varying loads and conditions, and ensure that the system can handle the expected number of users or transactions.

Functional Testing
Functional testing is a type of testing that ensures that each function of a software application operates to the requirements and specifications. This testing is not concerned
with the application’s source code. Each software application functionality is tested by providing appropriate test input, anticipating the output, and comparing the actual
output to the expected output. This testing focuses on the Application Under Test’s user interface, APIs, database, security, client or server application, and functionality.
Manual or automated functional testing is available.

Difference between Performance testing and Functional testing:

Aspect Functional Testing Performance Testing

Verifies that software functions as intended and meets specified Evaluates the system’s performance under various conditions like load, stress,
Purpose requirements. and scalability.

Focus Tests individual functions or features to ensure correct behavior. Measures responsiveness, speed, and stability of the entire system.

Scope Includes unit testing, integration testing, system testing, etc. Involves load testing, stress testing, scalability testing, etc.

Testing Criteria Validates functionality, user interface, data handling, etc. Assesses speed, reliability, scalability, and resource usage.

Unit testing, integration testing, system testing, acceptance

Load testing, stress testing, endurance testing, scalability testing, etc.
Examples testing, etc.

Key Metrics Pass/fail based on functional requirements. Response time, throughput, resource utilization, error rates, etc.

Users’
Concerned with what the system does. Concerned with how well the system performs under different conditions.
Perspective

Tools Selenium, JUnit, TestNG, etc. Apache JMeter, LoadRunner, Gatling, etc.

9. TopDown and BottomUp Testing Strategies

Top Down Testing : Top Down Integration testing which is also known as Incremental integration testing. In this Top Down approach the higher level modules are
tested first after higher level modules the lower level modules are tested. Then these modules undergo for integration accordingly. Here the higher level modules refers to
main module and lower level modules refers to submodules. This approach uses Stubs which are mainly used to simulate the submodule, if the invoked submodule is not
developed this Stub works as a momentary replacement.

Features of Top Down Integration Testing :

 System-centric approach: Testing focuses on the system as a whole, starting from top-level components.
 Early testing of higher-level functionality: Testing higher-level functionality is prioritized to identify major issues early.
 High-level test cases used: Test cases are designed to cover the functionality and interactions of higher-level modules.
 Mock objects/stubs used: Placeholder objects or stubs simulate lower-level components during testing.
 Testing becomes progressively detailed: More specific tests are performed as lower-level components are integrated.
 Efficient approach: Testing higher-level functionality first allows for a quick evaluation of system behavior.
 Risk-based testing: Critical and risky areas of the system are tested early to mitigate potential risks.

2. Bottom Up Testing : Bottom Up Integration testing is another approach of Integration testing. In this Bottom Up approach the lower level modules are tested first after
lower level modules the higher level modules are tested. Then these modules undergo for integration accordingly. Here the lower level modules refers to submodules and
higher level modules refers to main modules. This approach uses test drivers which are mainly used to initiate and pass the required data to the sub modules means from
higher level module to lower level module if required. The below figure represents the Top Down and Bottom up Integration testing approach.

Features of Bottom Up Integration Testing :

 Component-Centric: Bottom-up integration testing focuses on testing individual components first before integrating them into larger subsystems.
 Early Detection: This approach enables early detection of defects in individual components, which can be corrected before integration.
 Independent Testing: Each component is tested independently, ensuring that it functions correctly in isolation.
 Incremental Testing: Testing proceeds incrementally from lower-level to higher-level components.
 Parallel Development: This approach enables parallel development of components by different teams.
 Efficient Testing: Bottom-up integration testing can be an efficient approach.
 Risk-Based Testing: Risk-based testing can be applied in bottom-up integration testing to prioritize the testing of high-risk components.

Difference between Top Down Integration Testing and Bottom Up Integration Testing :
TOP DOWN TESTING BOTTOM UP TESTING

Top Down Integration testing is one of the approach of Integration testing in which Bottom Up Integration testing is one of the approach of Integration testing in
integration testing takes place from top to bottom means system integration begins which integration testing takes place from bottom to top means system
with top level modules. integration begins with lowest level modules.

In this testing the higher level modules are tested first then the lower level modules In this testing the lower level modules are tested first then the higher level
are tested and then the modules are integrated accordingly. modules are tested and then the modules are integrated accordingly.

In this testing stubs are used for simulate the submodule if the invoked submodule is In this testing drivers are used for simulate the main module if the main module
not developed means Stub works as a momentary replacement. is not developed means Driver works as a momentary replacement.
 Top Down Integration testing approach is beneficial if the significant defect occurs Bottom Up Integration testing approach is beneficial if the crucial flaws
toward the top of the program. encounters towards the bottom of the program.

In Top Down Integration testing approach the main module is designed at first then In Bottom Up Integration testing approach different modules are created first
the submodules/subroutines are called from it. then these modules are integrated with the main function.

It is implemented on Structure/procedure-oriented programming languages. It is implemented on Object-oriented programming languages.

The complexity of this testing is simple. The complexity of this testing is complex and highly data intensive.

It works on big to small components. It works on small to big components.

In this approach Stub modules must be produced. In this approach, Driver modules must be produced.

In terms of cost, Top Down testing is more expensive because it requires the complete Bottom Up testing is less expensive as compared to Top Down because it allows
system for testing. early identification and resolution of the model issues.

10. Test Drivers and Test Stubs

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.

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.

Ex : Suppose, you are told to test a website whose corresponding primary modules are, where each of them is interdependent on each other, as follows:
 Module-A : Login page website,
 Module-B : Home page of the website
 Module-C : Profile setting
 Module-D : Sign-out page
It’s always considered good practice to begin development of all modules parallelly because as soon as each gets developed they can be integrated and could be tested
further as per their corresponding interdependencies order with a module. But in some cases, if any one of them is in developing stage or not available in the testing
process of a specific module, stubs or drivers could be used instead.
Assume Module-A is developed. As soon as it’s developed, it undergoes testing, but it requires Module-B, which isn’t developed yet. So in this case, we can use
the Stubs or Drivers that simulate all features and functionality that might be shown by actual Module-B. So, we can conclude that Stubs and drivers are used to fulfill
the necessity of unavailable modules. Similarly, we may also use Stubs or Drivers in place of Module-C and Module-D if they are too not available.

Do both drivers and Stubs serve the same functionality? Yes, we can say both serve the same feature and are used in the absence of a module(M1) that has
interdependencies with an other module(M2) that is need to be test, so we use drivers or stubs in order to fulfill module(M1)’s unavailability’s and to serve its
functionality.

Difference between Stubs and Drivers :

Stubs Drivers

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

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

Stubs are similar to the modules of the software, that are under development
While drivers are used to invoking the component that needs to be tested.
process.

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

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

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

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

11. Structural Testing (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 or
open box testing.
White box testing is a software testing technique that involves testing the internal structure and workings of a software application. The tester has access to the source
code and uses this knowledge to design test cases that can verify the correctness of the software at the code level.
White box testing is also known as structural testing or code-based testing, and it is used to test the software’s internal logic, flow, and structure. The tester creates test
cases to examine the code paths and logic flows to ensure they meet the specified requirements.

Process of White Box Testing

 Input: Requirements, Functional specifications, design documents, source code.
 Processing: Performing risk analysis to guide through the entire process.
 Proper test planning: Designing test cases to cover the entire code. Execute rinse-repeat until error-free software is reached. Also, the results are communicated.
 Output: Preparing final report of the entire testing process.

Testing Techniques
1. Statement Coverage
In this technique, the aim is to traverse all statements at least once. Hence, each line of code is tested. In the case of a flowchart, every node must be traversed at least
once. Since all lines of code are covered, it helps in pointing out faulty code.

2. Branch Coverage:
In this technique, test cases are designed so that each branch from all decision points is traversed at least once. In a flowchart, all edges must be traversed at least once.

4 test cases are required such that all branches of all decisions are covered, i.e, all edges of the flowchart are covered

3. Condition Coverage
In this technique, all individual conditions must be covered as shown in the following example:
 READ X, Y
 IF(X == 0 || Y == 0)
 PRINT ‘0’
 #TC1 – X = 0, Y = 55
 #TC2 – X = 5, Y = 0

4. Multiple Condition Coverage

In this technique, all the possible combinations of the possible outcomes of conditions are tested at least once. Let’s consider the following example:
 READ X, Y
 IF(X == 0 || Y == 0)
 PRINT ‘0’
 #TC1: X = 0, Y = 0
 #TC2: X = 0, Y = 5
 #TC3: X = 55, Y = 0
 #TC4: X = 55, Y = 5

5. Basis Path Testing

In this technique, control flow graphs are made from code or flowchart and then Cyclomatic complexity is calculated which defines the number of independent paths so
that the minimal number of test cases can be designed for each independent path. Steps:
 Make the corresponding control flow graph
 Calculate the cyclomatic complexity
 Find the independent paths
 Design test cases corresponding to each independent path
 V(G) = P + 1, where P is the number of predicate nodes in the flow graph
 V(G) = E – N + 2, where E is the number of edges and N is the total number of nodes
 V(G) = Number of non-overlapping regions in the graph
 #P1: 1 – 2 – 4 – 7 – 8
 #P2: 1 – 2 – 3 – 5 – 7 – 8
 #P3: 1 – 2 – 3 – 6 – 7 – 8
  #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8

6. Loop Testing
Loops are widely used and these are fundamental to many algorithms hence, their testing is very important. Errors often occur at the beginnings and ends of loops.

 Simple loops: For simple loops of size n, test cases are designed that:
 Skip the loop entirely
 Only one pass through the loop
 2 passes
 m passes, where m < n
 n-1 ans n+1 passes
 Nested loops: For nested loops, all the loops are set to their minimum count, and we start from the innermost loop. Simple loop tests are conducted for the
innermost loop and this is worked outwards till all the loops have been tested.
 Concatenated loops: Independent loops, one after another. Simple loop tests are applied for each. If they’re not independent, treat them like nesting.

White Testing is performed in 2 Steps

1. Tester should understand the code well
2. Tester should write some code for test cases and execute them

Tools required for White box testing:

 PyUnit, Sqlmap, Nmap, Parasoft Jtest, Nunit, VeraUnit, CppUnit, Bugzilla, Fiddler, JSUnit.net, OpenGrok, Wireshark

Features of White box Testing

 Code coverage analysis: White box testing helps to analyze the code coverage of an application, which helps to identify the areas of the code that are not being
tested.
 Access to the source code: White box testing requires access to the application’s source code, which makes it possible to test individual functions, methods, and
modules.
 Knowledge of programming languages: Testers performing white box testing must have knowledge of programming languages like Java, C++, Python, and PHP
to understand the code structure and write tests.
 Identifying logical errors: White box testing helps to identify logical errors in the code, such as infinite loops or incorrect conditional statements.
 Integration testing: White box testing is useful for integration testing, as it allows testers to verify that the different components of an application are working
together as expected.
 Unit testing: White box testing is also used for unit testing, which involves testing individual units of code to ensure that they are working correctly.
 Optimization of code: White box testing can help to optimize the code by identifying any performance issues, redundant code, or other areas that can be improved.
 Security testing: White box testing can also be used for security testing, as it allows testers to identify any vulnerabilities in the application’s code.
 Verification of Design: It verifies that the software’s internal design is implemented in accordance with the designated design documents.
 Check for Accurate Code: It verifies that the code operates in accordance with the guidelines and specifications.
 Identifying Coding Mistakes: It finds and fix programming flaws in your code, including syntactic and logical errors.
 Path Examination: It ensures that each possible path of code execution is explored and test various iterations of the code.
 Determining the Dead Code: It finds and remove any code that isn’t used when the programme is running normally (dead code).

Advantages of Whitebox Testing

 Thorough Testing: White box testing is thorough as the entire code and structures are tested.
 Code Optimization: It results in the optimization of code removing errors and helps in removing extra lines of code.
 Early Detection of Defects: It can start at an earlier stage as it doesn’t require any interface as in the case of black box testing.
 Integration with SDLC: White box testing can be easily started in Software Development Life Cycle.
 Detection of Complex Defects: Testers can identify defects that cannot be detected through other testing techniques.
 Comprehensive Test Cases: Testers can create more comprehensive and effective test cases that cover all code paths.
 Testers can ensure that the code meets coding standards and is optimized for performance.

Disadvantages of White box Testing

 Programming Knowledge and Source Code Access: Testers need to have programming knowledge and access to the source code to perform tests.
 Overemphasis on Internal Workings: Testers may focus too much on the internal workings of the software and may miss external issues.
 Bias in Testing: Testers may have a biased view of the software since they are familiar with its internal workings.
 Test Case Overhead: Redesigning code and rewriting code needs test cases to be written again.
 Dependency on Tester Expertise: Testers are required to have in-depth knowledge of the code and programming language as opposed to black-box testing.
 Inability to Detect Missing Functionalities: Missing functionalities cannot be detected as the code that exists is tested.
 Increased Production Errors: High chances of errors in production.

12. Functional Testing (Black Box Testing)

Black-box testing is a type of software testing in which the tester is not concerned with the internal knowledge or implementation details of the software but rather focuses
on validating the functionality based on the provided specifications or requirements.

Types Of Black Box Testing

The following are the several categories of black box testing:
 Functional Testing
 Regression Testing
 Nonfunctional Testing (NFT)

Functional Testing:
Functional testing is defined as a type of testing that verifies that each function of the software application works in conformance with the requirement and specification.
This testing is not concerned with the source code of the application. Each functionality of the software application is tested by providing appropriate test input, expecting
the output, and comparing the actual output with the expected output. This testing focuses on checking the user interface, APIs, database, security, client or server
application, and functionality of the Application Under Test. Functional testing can be manual or automated. It determines the system’s software functional requirements.

Regression Testing:
Regression Testing is the process of testing the modified parts of the code and the parts that might get affected due to the modifications to ensure that no new errors have
been introduced in the software after the modifications have been made. Regression means the return of something and in the software field, it refers to the return of a
bug. It ensures that the newly added code is compatible with the existing code. In other words, a new software update has no impact on the functionality of the software.
This is carried out after a system maintenance operation and upgrades.

Nonfunctional Testing:
Non-functional testing is a software testing technique that checks the non-functional attributes of the system. Non-functional testing is defined as a type of software
testing to check non-functional aspects of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed
by functional testing. Non-functional testing is as important as functional testing. Non-functional testing is also known as NFT. This testing is not functional testing of
software. It focuses on the software’s performance, usability, and scalability.

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 to find the ambiguity and contradictions in the functional specifications.

Disadvantages of Black Box Testing

 There is a possibility of repeating the same tests while implementing the testing process.
 Without clear functional specifications, test cases are difficult to implement.
 It is difficult to execute the test cases because of complex inputs at different stages of testing.
 Sometimes, the reason for the test failure cannot be detected.
 Some programs in the application are not tested.
 It does not reveal the errors in the control structure.
 Working with a large sample space of inputs can be exhaustive and consumes a lot of time.

Black Box and White Box Testing

Black box testing is a testing technique in which the internal workings of the software are not known to the tester. The tester only focuses on the input and output of the
software. Whereas, White box testing is a testing technique in which the tester has knowledge of the internal workings of the software, and can test individual code
snippets, algorithms and methods.
 Testing objectives: Black box testing is mainly focused on testing the functionality of the software, ensuring that it meets the requirements and specifications.
White box testing is mainly focused on ensuring that the internal code of the software is correct and efficient.
 Knowledge level: Black box testing does not require any knowledge of the internal workings of the software, and can be performed by testers who are not
familiar with programming languages. White box testing requires knowledge of programming languages, software architecture and design patterns.
 Testing methods: Black box testing uses methods like equivalence partitioning, boundary value analysis, and error guessing to create test cases. Whereas,
white box testing uses methods like control flow testing, data flow testing and statement coverage.
 Scope: Black box testing is generally used for testing the software at the functional level. White box testing is used for testing the software at the unit level,
integration level and system level.

13. Test Data Suit Preparation

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.

14. Alpha and Beta Testing of Products

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 tests. It is the first stage of software testing, during which the internal development team tests the program before making it available to clients or people
outside the company.

Key points to remember:

 Work Done by Developers: The internal development team, which consists of developers and testers, usually conducts alpha testing in a controlled setting.
 Goal: Finding and fixing bugs, flaws, and usability issues is the main goal before releasing the product for external users or wider testing.
 Little User Engagement: Alpha testers are few in number and frequently comprise members of the development team or those intimately connected to the
project.
 Environment: Alpha testing is typically carried out in a development environment or laboratory that resembles actual settings.

What is Beta Testing?

Beta Testing is performed by real users of the software application in a real environment. Beta testing is one type of User Acceptance Testing. A pre-release version of the
product is made available for testing to a chosen set of external users or customers during the second phase of software testing.
Key Points to remember:
 Actions Taken by Users: Customers or other users outside the development team participate in beta testing. The software is available to these users prior to its
official release.
 Goal: The primary objective is to get input from actual users in order to find any bugs, usability difficulties, or areas that need to be improved before the
product is formally released.
 Greater User Participation: In order to capture a variety of viewpoints, a larger number of users—including a varied range, can serve as beta testers.
 Environment: Real-world settings are used for beta testing to simulate how users will interact with the program while performing daily duties.

Difference between Alpha and Beta Testing:

The difference between Alpha and Beta Testing is as follows:
Parameters Alpha Testing Beta Testing

Alpha testing involves both the white box and black

Beta testing commonly uses black-box testing.
Involvment box testing.

Alpha testing is performed by testers who are usually

Beta testing is performed by clients who are not part of the organization.
Performed by internal employees of the organization.

Performed at Alpha testing is performed at the developer’s site. Beta testing is performed at the end-user of the product.

Reliability and Reliability and security testing are not checked in

Reliability, security and robustness are checked during beta testing.
Security alpha testing.

Alpha testing ensures the quality of the product before Beta testing also concentrates on the quality of the product but collects users input on
Ensures forwarding to beta testing. the product and ensures that the product is ready for real time users.

Requirement Alpha testing requires a testing environment or a lab. Beta testing doesn’t require a testing environment or lab.

Execution Alpha testing may require a long execution cycle. Beta testing requires only a few weeks of execution.

Developers can immediately address the critical issues Most of the issues or feedback collected from the beta testing will be implemented in
Issues or fixes in alpha testing. future versions of the product.

Test Cycles Multiple test cycles are organized in alpha testing. Only one or two test cycles are there in beta testing.

13. Static Testing Strategies: Formal Technical Reviews (Peer Reviews),

Formal Technical Review (FTR) is a software quality control activity performed by software engineers. It is an organized, methodical procedure for assessing and raising
the standard of any technical paper, including software objects. Finding flaws, making sure standards are followed, and improving the product or document under review’s
overall quality are the main objectives of a fault tolerance review (FTR). Although FTRs are frequently utilized in software development, other technical fields can also
employ the concept.

Objectives of formal technical review (FTR)

 Detect Identification: Identify defects in technical objects by finding and fixing mistakes, inconsistencies, and deviations.
 Quality Assurance: To ensure high-quality deliverables, and confirm compliance with project specifications and standards.
 Risk Mitigation: To stop risks from getting worse, proactively identify and manage possible threats.
 Knowledge Sharing: Encourage team members to work together and build a common knowledge base.
 Consistency and Compliance: Verify that all procedures, coding standards, and policies are followed.
 Learning and Training: Give team members the chance to improve their abilities through learning opportunities.
In addition, the purpose of FTR is to enable junior engineers to observe the analysis, design, coding, and testing approach more closely. FTR also works to promote
backup and continuity to become familiar with parts of the software they might not have seen otherwise. FTR is a class of reviews that include walkthroughs, inspections,
round-robin reviews, and other small-group technical assessments of software. Each FTR is conducted as a meeting and is considered successful only if it is properly
planned, controlled, and attended.
Example
Suppose during the development of the software without FTR design cost 10 units, coding cost 15 units and testing cost 10 units then the total cost till now is 35 units
without maintenance but there was a quality issue because of bad design so to fix it we have to redesign the software and final cost will become 70 units. that is why FTR
is so helpful while developing the software.
The Review Meeting
Each review meeting should be held considering the following constraints- Involvement of people:
 Between 3, 4, and 5 people should be involved in the review.
 preparation should occur, but it should be very short that is at the most 2 hours of work for every person.
 The short duration of the review meeting should be less than two hours. Given these constraints, it should be clear that an FTR focuses on specific (and small)
parts of the overall software.
At the end of the review, all attendees of FTR must decide what to do.
 Accept the product without any modification.
 Reject the project due to serious error (Once corrected, another app needs to be reviewed), or
 Accept the product provisional (minor errors are encountered and should be corrected, but no additional review will be required).
The decision was made, with all FTR attendees completing a sign indicating their participation in the review and their agreement with the findings of the review team.
Review reporting and record-keeping:
 During the FTR, the reviewer actively records all issues that have been raised.
 At the end of the meeting all these issues raised are consolidated and a review list is prepared.
 Finally, a formal technical review summary report is prepared.
A review summary report answers three questions:
 What was reviewed?
 Who reviewed it?
 What were the findings and conclusions?
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. An unregistered review can often be worse than a review that does not minimum set of guidelines for FTR.
  Review the product, not the manufacturer (producer): FTR includes people and egos. while properly conducted FTR will give all participants a good feeling
of accomplishment, and when conducted improperly, the FTR team will be pointed out clearly. the meeting tone will be only loose and constructive, the review
team leader will ensure that the proper way of communication will be happening or not into the team or it will get out of control.
 Set an agenda and maintain it: one of the measure keys in the meeting is drift. FTR will always keep on track and schedule. the review leader is making and
maintaining the meeting schedule and should not be afraid that many people drift sets in.
 Limit debate and rebuttal: whenever the issue is raised by the reviewer there will not be an impact on a universal agreement. rather than spending time with the
questions, then issues will be further discussed off-line.
 Enunciate problem areas, but don’t attempt to solve every problem noted: A review is not a problem-solving session. The solution to a problem can often be
accomplished for the producer alone or with the help of only one other individual. problem-solving should be postponed for a while until after the review meeting.
 Take written notes (record purpose): it is a good idea to take notes on the wallboard so that will be wording, and priorities can be assessed by other reviewers as
information is recorded.
 Limit the number of participants and insist upon preparation: two heads are better than one, but 14 are not needed to be better than 4. We will keep the
number of people involved to a minimum, all review teams must prepare in advance, and written comments will be requested by the review leader.
 Develop a checklist for each product that is likely to be reviewed: A checklist will help to structure of Review meeting and for the review leader and help to
focus the reviewer on the important issues. checklist should be developed by the analysis, design, code, and even test documents.
 Allocate resources and schedule for FTRs to maintain schedule: it’s effective to review, they should be effective and it should be a task during the software
engineering process. In addition, the time should be scheduled for modification that occurs as a result of an FTR.
 Conduct meaningful training for all reviewers to make reviews effective: To be effective for all the reviews at first some have received formal training. it will
stress both process-related and the human psychological side of the reviews. for every person who is to participate in reviews which is a one-month learning curve
of 20 people.
 Review earlier reviews that serve as the base for the current review being conducted: it can be beneficial in uncovering problems with the review process
itself. the first product to be reviewed should be the guidelines themselves because many variables have a successful review, a software organization should
experiment to find approaches that work best in a local context. porter and his colleagues provide excellent guidance for this type of experiment.

14. 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.
As there is an informal way of testing involved so there is no need for a moderator while performing a walkthrough. We can call a walkthrough an open-ended discussion,
it does not focus on the documentation. Defect tracking is one of the challenging tasks in the walkthrough.

Advantages and 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”.

15. Code Inspection

The development of any software application/product goes through SDLC (Software Development Life Cycle) where every phase is very important and needs to be
followed accordingly to develop a quality software product. Inspection is such an important element which have a great impact on the software development process.
The software development team not only develops the software application rather during the coding phase of software development they check for any error in the code of
the software which is called code verification. This code verification checks the software code in all aspects and finds out the errors that exist in the code. Generally, there
are two types of code verification techniques available i.e.
 Dynamic technique – It is performed by executing some test data and the outputs of the program are monitored to find errors in the software code.
 Static technique – It is performed by executing the program conceptually and without any data. Code reading, static analysis, symbolic execution, code
inspection, reviews, etc. are some of the commonly used static techniques.
Code Inspection :
Code inspection is a type of Static testing that aims to review the software code and examine for any errors. It helps reduce the ratio of defect multiplication and avoids
later-stage error detection by simplifying all the initial error detection processes. This code inspection comes under the review process of any application.
How does it work?
 Moderator, Reader, Recorder, and Author are the key members of an Inspection team.
 Related documents are provided to the inspection team who then plan the inspection meeting and coordinate with inspection team members.
 If the inspection team is not aware of the project, the author provides an overview of the project and code to inspection team members.
 Then each inspection team performs code inspection by following some inspection checklists.
 After completion of the code inspection, conduct a meeting with all team members and analyze the reviewed code.
Purpose of code inspection :
1. It checks for any error that is present in the software code.
2. It identifies any required process improvement.
3. It checks whether the coding standard is followed or not.
4. It involves peer examination of codes.
5. It documents the defects in the software code.
Advantages Of Code Inspection :
 Improves overall product quality.
 Discovers the bugs/defects in software code.
 Marks any process enhancement in any case.
 Finds and removes defective efficiently and quickly.
  Helps to learn from previous defeats.
Disadvantages of Code Inspection:
 Requires extra time and planning.
 The process is a little slower.

16. Compliance with Design and Coding Standards

Different modules specified in the design document are coded in the Coding phase according to the module specification. The main goal of the coding phase is to code
from the design document prepared after the design phase through a high-level language and then to unit test this code.
Good software development organizations want their programmers to maintain to some well-defined and standard style of coding called coding standards. They usually
make their own coding standards and guidelines depending on what suits their organization best and based on the types of software they develop. It is very important for
the programmers to maintain the coding standards otherwise the code will be rejected during code review.
Purpose of Having Coding Standards:
 A coding standard gives a uniform appearance to the codes written by different engineers.
 It improves readability, and maintainability of the code and it reduces complexity also.
 It helps in code reuse and helps to detect error easily.
 It promotes sound programming practices and increases efficiency of the programmers.
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. On the other hand, Coding guidelines give some general suggestions regarding the coding style that to be followed for the betterment of
understandability and readability of the code. Some of the coding guidelines are given below :

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

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.