Chapter 1: - Fundamentals of Testing

❖ What is Testing?
Testing is the process of verifying and validating that a software or application is bug free,
meets the technical requirements as guided by its design and development and meets the user
requirements effectively and efficiently with handling all the exceptional and boundary
cases.
The process of software testing aims not only at finding faults in the existing software but
also at finding measures to improve the software in terms of efficiency, accuracy, and
usability. It mainly aims at measuring the specification, functionality, and performance of a
software program or application.

❖ What is Debugging?
Debugging is the process of identifying and resolving errors, or bugs, in a software system. It
is an important aspect of software engineering because bugs can cause a software system to
malfunction, and can lead to poor performance or incorrect results. Debugging can be a time-
consuming and complex task, but it is essential for ensuring that a software system is
functioning correctly.

Advantages of Debugging:
➢ Improved system quality: By identifying and resolving bugs, a software system can
be made more reliable and efficient, resulting in improved overall quality.
➢ Reduced system downtime: By identifying and resolving bugs, a software system
can be made more stable and less likely to experience downtime, which can result in
improved availability for users.
➢ Increased user satisfaction: By identifying and resolving bugs, a software system
can be made more user-friendly and better able to meet the needs of users, which can
result in increased satisfaction.
➢ Reduced development costs: By identifying and resolving bugs early in the
development process, it can save time and resources that would otherwise be spent on
fixing bugs later in the development process or after the system has been deployed.
 ➢ Increased security: By identifying and resolving bugs that could be exploited by
attackers, a software system can be made more secure, reducing the risk of security
breaches.
➢ Facilitates change: With debugging, it becomes easy to make changes to the software
as it becomes easy to identify and fix bugs that would have been caused by the
changes.
➢ Better understanding of the system: Debugging can help developers gain a better
understanding of how a software system works, and how different components of the
system interact with one another.
➢ Facilitates testing: By identifying and resolving bugs, it makes it easier to test the
software and ensure that it meets the requirements and specifications.

Disadvantages of Debugging:
➢ Time-consuming: Debugging can be a time-consuming process, especially if the bug
is difficult to find or reproduce. This can cause delays in the development process and
add to the overall cost of the project.
➢ Requires specialized skills: Debugging can be a complex task that requires
specialized skills and knowledge. This can be a challenge for developers who are not
familiar with the tools and techniques used in debugging.
➢ Can be difficult to reproduce: Some bugs may be difficult to reproduce, which can
make it challenging to identify and resolve them.
➢ Can be difficult to diagnose: Some bugs may be caused by interactions between
different components of a software system, which can make it challenging to identify
the root cause of the problem.
➢ Can be difficult to fix: Some bugs may be caused by fundamental design flaws or
architecture issues, which can be difficult or impossible to fix without significant
changes to the software system.
➢ Limited insight: In some cases, debugging tools can only provide limited insight into
the problem and may not provide enough information to identify the root cause of the
problem.
➢ Can be expensive: Debugging can be an expensive process, especially if it requires
additional resources such as specialized debugging tools or additional development
time.
❖ Differences Between Testing and Debugging.
Parameters Testing Debugging

Basics It is the process using which we It is the process using which we correct the
find errors and bugs. bugs that we found during the testing
process.

Code We can identify the failure of We use this process to provide the code
Failure any implemented code using failure with an absolution.
this process.

Errors Errors get displayed in this Errors get deducted and dissolved in this
 process. process.

Performer A tester performs testing on any Either a developer or a programmer

given software or application. performs this step of debugging in an
application or software.

Design One does not need any design Design knowledge is a prerequisite to
Knowledge knowledge to perform testing. debugging.

Insiders and Both- insiders and outsiders can Only an insider can perform debugging.
Outsiders perform testing. No outsider can perform it on the intended
software.

Basis of The process of testing is based The process of debugging is based on

Operation on various levels of testing- various types of bugs present in a system.
system testing, integration
testing, unit testing, etc.

SDLC It is a stage of SDLC (Software It’s not at all an aspect of the SDLC. It
Development Life Cycle). rather occurs as a consequence of the
process of testing.

Steps This process consists of both- This process seeks to match the available
validation as well as verification symptoms with the cause. Only then it
of the errors. leads to the correction of the errors.

❖ Verification and Validation

Verification:- Verification is the process of checking that a software achieves its goal
without any bugs. It is the process to ensure whether the product that is developed is right or
not. It verifies whether the developed product full fills the requirements that we have.
Verification is static testing.
Verification means Are we building the product, right?
 Validation: - Validation is the process of checking whether the software product is up to
the mark or in other words product has high level requirements. It is the process of checking
the validation of product i.e. it checks what we are developing is the right product. it is
validation of actual and expected product. Validation is the dynamic testing.
Validation means Are we building the right product?

❖ Differences Between Verification and Validation.

Verification Validation

We check whether we are developing the We check whether the developed product is
right product or not right.
Verification is also known as static testing. Validation is also known as dynamic testing.
Verification includes different methods like Validation includes testing like functional
Inspections, Reviews. testing, system testing, integration, and User
acceptance testing.
The execution of code does not happen in the In validation testing, the execution of code
verification testing. happens.

Verification testing is executed by the Quality Validation testing is executed by the testing
assurance team to make sure that the product team to test the application.
is developed according to customers'
requirements.
Verification is done before the validation After verification testing, validation testing
testing. takes place.
Verification is about process, standard and Validation is about the product.
guideline.

❖ Root Cause Analysis

It is method of problem solving used for identifying the root causes of faults or problems. If
root cause of defect is not determined and resolved then there are chances of re-occurrence
of defects. Therefore, RCA is very much essential and required tool to identify root cause
i.e. true cause of defects.

1. Define Problem or defect:

Defining defect simply means to identify or determine defect if present in a system. It

includes what exactly is happening, what are particular symptoms of it, what are issues that
you observe, its severity, etc.
 2. Collect Data regarding defect:

Collecting data simply means collecting all information and data regarding defect. It must
include its impact, proof that defect exists, how much time defect existed, is it a reoccu rring
defect. One should also communicate with customers or employees. Before identifying root
cause, one needs to analyse defect or problem completely. One needs to gather all required
information or evidence.

3. Identify Root Cause of defect:

Identifying root cause simply means to identify main cause that is causing defect to arise. It
must include why does defect exists and what’s main reason for its existence. Several tools
are available nowadays to identify root cause of defect. One need to choose correct tool that
will lead to effective result. To identify root causes, brainstorming session should also be
performed session. It is basically a technique by which various efforts are made to define a
specific problem or defect. There might be more than one root cause of defect. So, one
needs to identify as many causes as possible.

4. Implement Root Cause Corrective Action (RCCA) :

After identifying root cause, one to take some measures and actions to resolve or eliminate
defect. Main focus should be on eliminating root cause of problem or defect so that it does
not occur in future. One needs to identify some effective measures and corrective actions
that are required to be taken. Before choosing any method, make sure that it does not cause
any other side effect or problem in system.

5. Implement Root Cause Prevention Action (RCPA) :

One needs to make some plan regarding defect reoccurrence. Defect should not reoccur in
future therefore, one needs to improve skill, perform tasks in proper way, follow proper
documents of preventive actions.

❖ Cost of Quality :
It is the most established, effective measure of quantifying and calculating the business value
of testing. There are four categories to measure cost of quality: Prevention costs, Detection
costs, Internal failure costs, and External failure costs.

These are explained as follows below.

➢ Prevention costs: - include cost of training developers on writing secure and easily
maintainable code
➢ Detection costs: - include the cost of creating test cases, setting up testing
environments, revisiting testing requirements.
➢ Internal failure costs: - include costs incurred in fixing defects just before delivery.
 ➢ External failure costs: - include product support costs incurred by delivering poor
quality software.

Psychology of Testing
In software testing, psychology plays an extremely important role. It is one of those factors
that stay behind the scene, but has a great impact on the end result. Categorized into three
sections, the psychology of testing enables smooth testing as well as makes the process
hassle-free. It is mainly dependent on the mindset of the developers and testers, as well as the
quality of communication between them. Moreover, the psychology of testing improves
mutual understanding among team members and helps them work towards a common goal.

I. The mindset of Developers and Testers

▪ Software development life cycle is a combination of various activities, which are
performed by different individuals using their expertise and knowledge.
▪ It is not an unknown fact that to accomplish successful development of a software,
people with different skill and mindset are required.
▪ From coding to software implementation, engineers with different skill set are
required to perform tasks, in which they are certified.
▪ As testing and analyzing the software is much different than developing or
programming it, it is quite clear that to develop a software with unique features and
superior quality, developers and testers of different mindset are required.
▪ Moreover, the introduction of new development and testing techniques and
methodologies has further made this a necessary requirement.
II. Communication in a Constructive Manner
▪ Any process, whether technical or non-technical requires constant communication
between team members to successfully achieve their goals and aims.
▪ Communication, if done in an polite and courteous manner can help build a strong
and reliable relationship between team members and help them avoid any
misunderstanding.
▪ Similarly, during the process of testing also, the requirement of communication in
constructive manner is extremely high. As testers are responsible for finding bugs and
reporting them, it becomes vital for them to communicate it in a courteous, polite, and
suitable way to avoid hurting and disappointing someone.
 ▪ Finding and reporting defects can be an achievement for the tester but is merely an
inconvenience for programmers, designers, developers, and other stakeholders of the
project.
▪ As testing can be a destructive activity, it is important for software testers to report
defects and failures as objectively and politely as possible to avoid hurting and
upsetting other members related to the project.
III. Test Independence
▪ The importance of independent software testing is comparatively higher than self
testing or group testing, as the former helps avoid author bias and often is more
effective in finding and detecting bugs and defects.
▪ This type of testing is mainly performed by individuals who are not related to the
project directly or are from different organization and are hired mainly to test the
quality as well as the effectiveness of the developed product.
▪ Test independence, therefore, helps developers and other stakeholders get more
accurate test results, which helps them build a better software product, with
innovative and unique features and functionality.
The levels of Test Independence:
o Test are designed by the person who wrote the software under test.
o By the other member of the team who is not directly related to the software under test.
o Test performed by an individual from another organizational group or a test specialist.
o Test designed by a tester from different organization or company.
❖ Independent Testing
Independent testing corresponds to an independent team, who involve in testing activities
other than developer to avoid author bias and is often more effective at finding defects and
failures.
➢ Levels of Independent Testing
▪ Testing done by developer himself
▪ Independent testers ceded to the development team
▪ Independent Testing Team within Organization
▪ Independent Testers of different Organization
▪ Outsourced test team members of other organization
➢ Benefits of Independent Testing
1. Finds out more defects as compared to other testers working inside the
programming team.
2. Unique side assumptions and ideas of independent testers result in identifying
hidden defects.
3. The independent testers are unbiased.
4. Cost-effective as it has a separate budget, which helps in tracking money spent
on training, testing tools, equipment.
5. Provides improved Software Quality.
6. Supplies more Experienced and skilled power.
7. One can easily switch between manual and automation testing using independent
testing due to being more flexible.
8. Reduces time to market by providing access to expert skills in test automation
skills ensures faster testing cycles.
➢ Drawbacks of Independent Testing
1. The isolating feature can sometimes lead to outdated documentation references.
2. Easily gets affected by delays in the early stage because it’s the execution of the
last stage.
3. Developers don’t take the responsibility of quality and let the testing team deal
with the whole issue.
4. Sometimes independent testing adds hindrance to communication.
5. Faces lack identification in project goals and a few more uncertain things.

❖ Buddy Testing

▪ Buddy Testing as the name suggests involves two team members, one from the
development team and one from the testing team. Both individuals will work
together on the same module sharing ideas and uncovering defects and bugs in the
application. It may be advantageous to team up with people with good working
relationships as buddies to overcome any apprehensions.
▪ In this technique, two team members work on the same machine where one of the
team members will work with the system and the other one is responsible for making
notes and scenarios. One person known as the primary tester performs the testing
while the other person, known as the buddy tester, observes and provides assistance as
needed.
Process of Buddy Testing
The process of buddy testing involves the following steps:
1. Identify the primary tester and the buddy tester: The primary tester is
typically an experienced tester with a strong understanding of the software or
system being tested, while the buddy tester may be a less experienced tester or a
subject matter expert with knowledge of the domain being tested.
2. Define the scope and objectives of the testing: The primary tester and the
buddy tester should agree on the scope and objectives of the testing, including
the specific features or functionality that will be tested and the expected results.
3. Plan the testing: The primary tester and the buddy tester should develop a
testing plan that outlines the specific test cases and test scenarios that will be
executed, as well as the resources and tools needed to complete the testing.
4. Execute the testing: The primary tester performs the testing while the buddy
tester observes and provides assistance as needed. The buddy tester may also be
responsible for documenting defects and issues that are identified during the
testing.
5. Review and debrief: After the testing is complete, the primary tester and the
buddy tester should review the results of the testing and debrief to discuss any
issues or challenges that were encountered.

Benefits of Buddy Testing

• Enhanced effectiveness: By working together, the primary tester and the buddy
tester can share knowledge and expertise, and catch defects more quickly.
• Increased efficiency: Buddy testing can help reduce the time and resources
needed to complete the testing process.
• Improved quality: Buddy testing can help ensure that the software or system
being tested is of high quality, as defects and issues are more likely to be
identified and addressed.
• Enhanced collaboration: Buddy testing promotes collaboration between team
members and can help build trust and teamwork within the team.
• Less workload: There will be less workload in presence of another team
member and the tester can think clearly and use more scenarios for testing.
❖V Model

Verification: It involves a static analysis method (review) done without executing code. It is
the process of evaluation of the product development process to find whether specified
requirements meet.
Validation: It involves dynamic analysis method (functional, non-functional), testing is done
by executing code. Validation is the process to classify the software after the completion of
the development process to determine whether the software meets the customer expectations
and requirements.
Developer’s Life cycle
➢ Requirement Analysis: This phase contains detailed communication with the
customer to understand their requirements and expectations. This stage is known as
Requirement Gathering.
➢ System Design: This phase contains the system design and the complete hardware
and communication setup for developing product.
➢ Architectural Design: System design is broken down further into modules taking up
different functionalities. The data transfer and communication between the internal
modules and with the outside world (other systems) is clearly understood.
➢ Module Design: In this phase the system breaks down into small modules. The
detailed design of modules is specified, also known as Low-Level Design (LLD).
➢ Coding Phase: Based on the requirements, a suitable programming language is
decided. There are some guidelines and standards for coding. Before checking in the
repository, the final build is optimized for better performance, and the code goes
through many code reviews to check the performance.
Tester life cycle
1.Unit Testing: In the V-Model, Unit Test Plans (UTPs) are developed during the module
design phase. These UTPs are executed to eliminate errors at code level or unit level. A
 unit is the smallest entity which can independently exist, e.g., a program module. Unit
testing verifies that the smallest entity can function correctly when isolated from the rest
of the codes/ units.
2.Integration Testing: After completion of unit testing Integration testing is performed. In
integration testing, the modules are integrated and the system is tested. Integration testing is
performed on the Architecture design phase. This test verifies the communication of modules
among themselves.
3.System Testing: System Tests Plans are developed during System Design Phase. Unlike
Unit and Integration Test Plans, System Tests Plans are composed by the client? business
team. System Test ensures that expectations from an application developer are met.
4.Acceptance Testing: Acceptance testing is related to the business requirement analysis
part. It includes testing the software product in user atmosphere. Acceptance tests reveal the
compatibility problems with the different systems, which is available within the user
atmosphere. It conjointly discovers the non-functional problems like load and performance
defects within the real user atmosphere.

❖ Software Testing Life Cycle (STLC)

The Software Testing Life Cycle (STLC) is a systematic approach to testing a software
application to ensure that it meets the requirements and is free of defects. It is a process that
follows a series of steps or phases, and each phase has specific objectives and deliverables.
The STLC is used to ensure that the software is of high quality, reliable, and meets the needs
of the end-users.
The main goal of the STLC is to identify and document any defects or issues in the software
application as early as possible in the development process. This allows for issues to be
addressed and resolved before the software is released to the public.
Phases of STLC
1. Requirement Analysis: Requirement Analysis is the first step of the Software Testing Life
Cycle (STLC). In this phase quality assurance team understands the requirements like what is
to be tested. If anything is missing or not understandable then the quality assurance team
meets with the stakeholders to better understand the detailed knowledge of requirements.
2. Test Planning: Test Planning is the most efficient phase of the software testing life cycle
where all testing plans are defined. In this phase manager of the testing, team calculates the
estimated effort and cost for the testing work. This phase gets started once the requirement-
gathering phase is completed.
3. Test Case Development: The test case development phase gets started once the test
planning phase is completed. In this phase testing team notes down the detailed test cases.
The testing team also prepares the required test data for the testing. When the test cases are
prepared then they are reviewed by the quality assurance team.
4. Test Environment Setup: Test environment setup is a vital part of the STLC. Basically,
the test environment decides the conditions on which software is tested. This is independent
activity and can be started along with test case development. In this process, the testing
team is not involved. either the developer or the customer creates the testing environment.
5. Test Execution: After the test case development and test environment setup test execution
phase gets started. In this phase testing team starts executing test cases based on prepared test
cases in the earlier step.
6. Test Closure: Test closure is the final stage of the Software Testing Life Cycle (STLC)
where all testing-related activities are completed and documented. The main objective of the
test closure stage is to ensure that all testing-related activities have been completed and that
the software is ready for release.

❖ Static Testing
Static testing is a sort of software testing in which an application is tested without executing
any code. In order to discover errors, manual or automated reviews of code, requirement
papers, and document design are performed. Static testing's major goal is to improve the
quality of software programmes by detecting flaws early in the development process.
Static testing entails manual or automated document evaluations. This evaluation is carried
out at the initial round of testing in order to detect defects early in the STLC process. It looks
over work documents and gives feedback. Non-execution testing is sometimes known as
verification testing.
Examples of work documents are given below −
• Requirement specifications
• Design document
• Source Code
• Test Plans
• Test Cases
• Test Scripts
• Help or User document
• Web Page content
 The following are the primary goals of static testing −
• Static testing will help to reduce manufacturing flaws.
• Static testing will detect, anticipate, and correct issues as soon as possible.
• It is utilized to save time as well as money.
• It's used to find faults early in the SDLC process, when they're easier to fix.

Advantages of Static Testing

• Product quality has improved. Static testing will improve product quality by
identifying faults or problems early in the software development process.
• Dynamic testing will become more efficient after static testing. Static testing will
boost Dynamic Testing performance since the code will get cleaner and better when
Static Testing is completed. Static testing necessitates considerable effort and time in
order to build and maintain high-quality test cases.
• SDLC costs are lower. Because it identifies defects in the early stages of the software
development life cycle, static testing lowered SDLC costs. As a result, changing and
repairing the product requires less effort and time.

❖ Dynamic Testing
A code is executed during Dynamic Testing. It examines the software system's functionality,
memory/CPU use, and overall system performance. As a result, the term "Dynamic" was
coined.
The major goal of this testing is to ensure that the software product meets the needs of the
business. This type of testing is also known as execution technique or validation testing.
Dynamic testing runs the software and compares the results to what was predicted. Dynamic
testing is conducted at all levels of testing and can be done with either a black or a white
box.

Advantages of dynamic testing −

• It verifies the software application's functionality.
• The use of dynamic testing ensures the software product's dependability and
consistency.
• It can be automated with the use of tools that uncover troublesome and sophisticated
defects in the testing process that static analysis cannot cover.
• It aids the testing team in identifying the run-time environment's weak points.
• The most significant advantage of dynamic testing versus static testing is the greater
number of bugs that can be discovered.

❖ Main Differences between Static testing and Dynamic testing

Parameter Static Testing Dynamic Testing

Definition Static testing is the testing in which Dynamic testing there is execution of
code written for application is not code written for the application and
executed during testing phase and only then defects and application
review of code is performed and basis behaviour has been examined.
on which defects and code quality has
been examined.
 Nature of As name states static testing does the Dynamic testing does the validation
testing static verification process in which the process which examines the expected
requirement and corresponding written behavior of the application based on
code has been verified. dynamic inputs provided to the
application.
Testing Static testing targets to the assessment Dynamic testing targets the runtime
target of code and documentation. bugs/bottlenecks in the software
system.
Prerequisite For static testing, a checklist of For dynamic testing, test cases for
application process and documentation execution are to be developed.
is required.
Stage of Static testing generally get performed Dynamic testing mostly performed
testing before compilation of code after compilation of code.
Cost to In Static testing, the cost of finding the In case of Dynamic testing, the cost
Company defects and fixing them is less. Also, of finding and fixing the defects is
the Return on Investment is high high. Also the Return on Investment
because static testing is carried out at (RoI) is low because this process is
an early stage of development. carried out after the development
phase.

❖ Difference between Automation testing and Manual testing

Automation testing Manual testing

When an application or software is tested with It is a type of software testing, which is

the help of some tools is known as automation done by the test Engineer to check the
testing. functionality of an application based on
the customer requirement.

It is reliable because it tests the application with It is not reliable because there is a
the help of tools and test scripts. possibility of human error, which may not
be delivered the bug-free application.

The script can be reused across multiple It could be possible when the test case
releases. only needs to run once or twice.

The execution is always faster than the manual; It is time consuming due to the usage of
that's why the automation testing process is the human resources.
time-saving.
 Without having an understanding of There is no need-to-know programming
programming language, we cannot write the test language but should have the product
script. knowledge to write the test case.

The automation test engineer can use the There is no need for a framework while
different types of frameworks like Data driven, using manual testing.
Hybrid, modular driven, and keyword-
driven to faster the automation process.

❖ Testing Software of different Technologies

➢ Test management tool
Test management tools are used to keep track of all the testing activity, fast data analysis,
manage manual and automation test cases, various environments, and plan and
maintain manual testing as well.
➢ Bug tracking tool
The defect tracking tool is used to keep track of the bug fixes and ensure the delivery of a
quality product. This tool can help us to find the bugs in the testing stage so that we can get
the defect-free data in the production server.
➢ Automation testing tool
This type of tool is used to enhance the productivity of the product and improve the accuracy.
We can reduce the time and cost of the application by writing some test scripts in any
programming language.
➢ Performance testing tool
Performance or Load testing tools are used to check the load, stability, and scalability of the
application. When n-number of the users using the application at the same time, and if the
application gets crashed because of the immense load, to get through this type of issue, we
need load testing tools.
➢ Cross-browser testing tool
This type of tool is used when we need to compare a web application in the various web
browser platforms. It is an important part when we are developing a project. With the help of
these tools, we will ensure the consistent behavior of the application in multiple devices,
browsers, and platforms.
 ➢ GUI testing tool
GUI testing tool is used to test the User interface of the application because a proper GUI is
always useful to grab the user's attention. These types of tools will help to find the loopholes
in the application's design and makes its better.

❖ Test Matrics:

Software testing metrics are quantifiable indicators of the software testing process progress,
quality, productivity, and overall health. The purpose of software testing metrics is to
increase the efficiency and effectiveness of the software testing process while also assisting
in making better decisions for future testing by providing accurate data about the testing
process. A metric expresses the degree to which a system, system component, or process
possesses a certain attribute in numerical terms. A weekly mileage of an automobile
compared to its ideal mileage specified by the manufacturer is an excellent illustration of
metrics.

Types of Software Testing Metrics

Software testing metrics are divided into three categories:

1. Process Metrics: A project’s characteristics and execution are defined by process
metrics. These features are critical to the SDLC process’s improvement and
maintenance (Software Development Life Cycle).
2. Product Metrics: A product’s size, design, performance, quality, and complexity are
defined by product metrics. Developers can improve the quality of their software
development by utilizing these features.
3. Project Metrics: Project Metrics are used to assess a project’s overall quality. It is used
to estimate a project’s resources and deliverables, as well as to determine costs,
productivity, and flaws.

Important Metrics
The following are some of the other important software metrics:
➢ Defect metrics: Defect metrics help engineers understand the many aspects of
software quality, such as functionality, performance, installation stability, usability,
compatibility, and so on.
➢ Schedule Adherence: Schedule Adherence’s major purpose is to determine the time
difference between a schedule’s expected and actual execution times.
➢ Test case efficiency: Test case efficiency is a measure of how effective test cases are
at detecting problems
➢ Defects finding rate: : It is used to determine the pattern of flaws over a period of
time.
➢ Defect Fixing Time: The amount of time it takes to remedy a problem is known as
defect fixing time.
➢ Defect cause: It’s utilized to figure out what’s causing the problem.

❖ Types of risks
1. Schedule Risk:
Schedule related risks refers to time related risks or project delivery related
planning risks. The wrong schedule affects the project development and
delivery. These risks are mainly indicates to running behind time as a result
project development doesn’t progress timely and it directly impacts to delivery
of project. Finally if schedule risks are not managed properly it gives rise to
project failure and at last it affect to organization/company economy very badly.
Some reasons for Schedule risks –
• Time is not estimated perfectly
• Improper resource allocation
• Tracking of resources like system, skill, staff etc
• Frequent project scope expansion
• Failure in function identification and its’ completion

2 Budget Risk:
Budget related risks refers to the monetary risks mainly it occurs due to budget
overruns. Always the financial aspect for the project should be managed as per
decided but if financial aspect of project mismanaged then there budget concerns
will arise by giving rise to budget risks. So proper finance distribution and
management are required for the success of project otherwise it may lead to project
failure.
Some reasons for Budget risks –
• Wrong/Improper budget estimation
• Unexpected Project Scope expansion
• Mismanagement in budget handling
• Cost overruns
• Improper tracking of Budget

3 Operational Risks:
Operational risk refers to the procedural risks means these are the risks which happen in
day-to-day operational activities during project development due to improper process
implementation or some external operational risks.
Some reasons for Operational risks –
• Insufficient resources
• Conflict between tasks and employees
• Improper management of tasks
• No proper planning about project
• Less number of skilled people
• Lack of communication and cooperation
• Lack of clarity in roles and responsibilities
• Insufficient training
 4. Technical Risks:
Technical risks refers to the functional risk or performance risk which means this
technical risk mainly associated with functionality of product or performance part of the
software product.
Some reasons for Technical risks –
• Frequent changes in requirement
• Less use of future technologies
• Less number of skilled employee
• High complexity in implementation
• Improper integration of modules
•
5. Programmatic Risks:
Programmatic risks refers to the external risk or other unavoidable risks. These are the
external risks which are unavoidable in nature. These risks come from outside and it is
out of control of programs.
Some reasons for Programmatic risks –
• Rapid development of market
• Running out of fund / Limited fund for project development
• Changes in Government rules/policy
• Loss of contracts due to any reason

❖ Myths and Reality of Testing

➢ Myth 1: Testing is Too Expensive

Reality − There is a saying, pay less for testing during software development or pay
more for maintenance or correction later. Early testing saves both time and cost in
many aspects, however reducing the cost without testing may result in improper
design of a software application rendering the product useless.

➢ Myth 2: Testing is Time-Consuming

Reality − During the SDLC phases, testing is never a time-consuming process.
However diagnosing and fixing the errors identified during proper testing is a time-
consuming but productive activity.

➢ Myth 3: Only Fully Developed Products are Tested

Reality − No doubt, testing depends on the source code but reviewing requirements
and developing test cases is independent from the developed code. However iterative
or incremental approach as a development life cycle model may reduce the
dependency of testing on the fully developed software.

➢ Myth 4: Complete Testing is Possible

Reality − It becomes an issue when a client or tester thinks that complete testing is
possible. It is possible that all paths have been tested by the team but occurrence of
complete testing is never possible. There might be some scenarios that are never
executed by the test team or the client during the software development life cycle and
may be executed once the project has been deployed.
➢ Myth 5: A Tested Software is Bug-Free
Reality − This is a very common myth that the clients, project managers, and the
management team believes in. No one can claim with absolute certainty that a
software application is 100% bug-free even if a tester with superb testing skills has
tested the application.

➢ Myth 6: Missed Defects are due to Testers

Reality − It is not a correct approach to blame testers for bugs that remain in the
application even after testing has been performed. This myth relates to Time, Cost,
and Requirements changing Constraints. However the test strategy may also result in
bugs being missed by the testing team.

➢ Myth 7: Testers are Responsible for Quality of Product

Reality − It is a very common misinterpretation that only testers or the testing team
should be responsible for product quality. Testers’ responsibilities include the
identification of bugs to the stakeholders and then it is their decision whether they will
fix the bug or release the software. Releasing the software at the time puts more
pressure on the testers, as they will be blamed for any error.

➢ Myth 8: Test Automation should be used wherever possible to Reduce Time

Reality − Yes, it is true that Test Automation reduces the testing time, but it is not
possible to start test automation at any time during software development. Test
automaton should be started when the software has been manually tested and is stable
to some extent. Moreover, test automation can never be used if requirements keep
changing.

➢ Myth 9: Anyone can Test a Software Application

Reality − People outside the IT industry think and even believe that anyone can test a
software and testing is not a creative job. However testers know very well that this is
a myth. Thinking alternative scenarios, try to crash a software with the intent to
explore potential bugs is not possible for the person who developed it.

➢ Myth 10: A Tester's only Task is to Find Bugs

Reality − Finding bugs in a software is the task of the testers, but at the same time,
they are domain experts of the particular software. Developers are only responsible
for the specific component or area that is assigned to them but testers understand the
overall workings of the software, what the dependencies are, and the impacts of one
module on another module.