What SDLC?

SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan
describing how to develop, maintain, replace and alter or enhance specific software. The life cycle defines a
methodology for improving the quality of software and the overall development process.. It aims to produce a
high quality software that meets customer expectations.

The various phases of SDLC are explained below:

First Phase: Requirement Collection or Planning Phase
The prime focus of this phase is to gather the essential requirements from the customer. This information gets
collected by the business analyst from their target customer(s) and plans the BRS (Business requirement
Specification) for the development of the product. The team of all the designers and BA will do brainstorming
to extract all the requirements and plan accordingly for the new system to be developed? Some popular
questions that this meeting picks up are - Who will use the product? What must be the output data by the
product?
Second Phase: Defining or Feasibility Study Phase
When the BRS documentation is done, there are another set of employees like Human Resource (HR), Finance
Analyst, Architect, a Business analyst as well as Project manager will sit jointly discuss as well as analyze how
to proceed and whether it is feasible and possible in the allotted budget. Such decisions are taken depending on
the cost, resources, time, etc. Documentation is made, which is the SRS (Software Requirement Specification)
document, which contains a detailed explanation of product requirements, right from design to development.
Third Phase: Designing Phase
This phase is when the design specification is organized from the prerequisite document when the project is
approved to go further. This phase contributes to the next phase for development. This phase portrays a
blueprint of the product, which helps to specify the hardware and requirements of your system as well as assist
in crafting a significant architecture of your system.
Fourth Phase: Building or Coding Phase
As you are preparing with the design document, this phase deals with the developers to start writing the code or
prepare for the engineering so that a prototype of the product can be created using some specific tools and
techniques. This is considered the longest phase of SDLC.
Fifth Phase: Testing Phase
As your product is prepared for deployment, it needs a prior testing environment by the test engineers to check
for bugs and run-time errors, and they check in this phase whether the functionality of the product is working as
per the requirement or not. The bugs or defects which are encountered in the test phase are reported to the
developers, who fix the bug and revert to the test engineers for further testing. This is an iterative process that
continues until your application is free from bugs and defects and works stably.
Sixth Phase: Deployment Phase
Once your prototype or product is developed, tested, and completely in working form as per the requirement,
and then it is installed or deployed in the customer's workplace or system for their use.
Seventh Phase: Maintenance Phase
This is an additional phase, and in many cases,when your customer(s) begin using your product and encounter
with some issues which they want us (as developers) to fix from time to time. The developer fixes the issue, and
software testers test the product and hand it over the back to the customer.
SDLC Models
There are various software development life cycle models defined and designed which are followed during the
software development process. These models are also referred as Software Development Process Models". Each
process model follows a Series of steps unique to its type to ensure success in the process of software
development.
Following are the most important and popular SDLC models followed in the industry −
 Waterfall Model
 Iterative Model
 Spiral Model
 V-Model
 Agile model
SDLC - Waterfall Model
The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential
life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed
before the next phase can begin and there is no overlapping in the phases. The waterfall Model illustrates the
software development process in a linear sequential flow. This means that any phase in the development process
begins only if the previous phase is complete.

All these phases are cascaded to each other in which progress is seen as flowing steadily downwards (like a
waterfall) through the phases. The next phase is started only after the defined set of goals are achieved for
previous phase and it is signed off, so the name "Waterfall Model". In this model, phases do not overlap.
Waterfall Model – Advantages
 Simple and easy to understand and use
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
 Phases are processed and completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Clearly defined stages.
 Well understood milestones.
 Easy to arrange tasks.
 Process and results are well documented.
Waterfall Model - Disadvantages
 No working software is produced until late during the life cycle.
 High amounts of risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and
uncertainty is high with this process model.
 It is difficult to measure progress within stages.
 Cannot accommodate changing requirements.
 Adjusting scope during the life cycle can end a project.
 SDLC - Iterative Model
In the Iterative model, iterative process starts with a simple implementation of a small set of the software
requirements and iteratively enhances the evolving versions until the complete system is implemented and ready
to be deployed.
An iterative life cycle model does not attempt to start with a full specification of requirements. Instead,
development begins by specifying and implementing just part of the software, which is then reviewed to
identify further requirements. This process is then repeated, producing a new version of the software at the end
of each iteration of the model.

Iterative and Incremental development is a combination of both iterative design or iterative method and
incremental build model for development. "During software development, more than one iteration of the
software development cycle may be in progress at the same time." This process may be described as an
"evolutionary acquisition" or "incremental build" approach."
In this incremental model, the whole requirement is divided into various builds. During each iteration, the
development module goes through the requirements, design, implementation and testing phases. Each
subsequent release of the module adds function to the previous release. The process continues till the complete
system is ready as per the requirement.
Iterative Model - Pros and Cons
The advantages of the Iterative and Incremental SDLC Model are as follows
 Some working functionality can be developed quickly and early in the life cycle.
 Results are obtained early and periodically.
 Parallel development can be planned.
 Progress can be measured.
 Less costly to change the scope/requirements.
 Testing and debugging during smaller iteration is easy.
 Risks are identified and resolved during iteration; and each iteration is an easily managed milestone.
 Easier to manage risk - High risk part is done first.
 With every increment, operational product is delivered.
 Issues, challenges and risks identified from each increment can be utilized/applied to the next increment.
 Risk analysis is better.
 It supports changing requirements.
The disadvantages of the Iterative and Incremental SDLC Model are as follows −
 More resources may be required.
 Although cost of change is lesser, but it is not very suitable for changing requirements.
 More management attention is required.
 System architecture or design issues may arise because not all requirements are gathered in the beginning of
the entire life cycle.
 Defining increments may require definition of the complete system.
 Not suitable for smaller projects.
 Management complexity is more.
 End of project may not be known which is a risk.
 Highly skilled resources are required for risk analysis.
SDLC - Spiral Model
The spiral model combines the idea of iterative development with the systematic, controlled aspects of the
waterfall model. This Spiral model is a combination of iterative development process model and sequential
linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows
incremental releases of the product or incremental refinement through each iteration around the spiral.

Based on the customer evaluation, the software development process enters the next iteration and subsequently
follows the linear approach to implement the feedback suggested by the customer. The process of iterations
along the spiral continues throughout the life of the software.
Spiral Model - Pros and Cons
The advantages of the Spiral SDLC Model are as follows −
 Changing requirements can be accommodated.
 Allows extensive use of prototypes.
 Requirements can be captured more accurately.
 Users see the system early.
 Development can be divided into smaller parts and the risky parts can be developed earlier which helps in
better risk management.
The disadvantages of the Spiral SDLC Model are as follows −
 Management is more complex.
 End of the project may not be known early.
 Not suitable for small or low risk projects and could be expensive for small projects.
 Process is complex
 Spiral may go on indefinitely.
 Large number of intermediate stages requires excessive documentation.

SDLC - V-Model
The V-model is an SDLC model where execution of processes happens in a sequential manner in a V-shape. It
is also known as Verification and Validation model.
The V-Model is an extension of the waterfall model and is based on the association of a testing phase for each
corresponding development stage. This means that for every single phase in the development cycle, there is a
directly associated testing phase. This is a highly-disciplined model and the next phase starts only after
completion of the previous phase.
V-Model - Verification Phases
There are several Verification phases in the V-Model, each of these are explained in detail below.
 Business Requirement Analysis
 System Design
 Architectural Design- Usually more than one technical approach is proposed and based on the technical
and financial feasibility the final decision is taken. The system design is broken down further into
modules taking up different functionality. This is also referred to as High Level Design (HLD).
 Module Design-In this phase, the detailed internal design for all the system modules is specified,
referred to as Low Level Design (LLD). It is important that the design is compatible with the other
modules in the system architecture and the other external systems.
 Coding Phase
Validation Phases
The different Validation Phases in a V-Model are explained in detail below.
 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing
V-Model - Pros and Cons
The advantages of the V-Model method are as follows −
 This is a highly-disciplined model and Phases are completed one at a time.
 Works well for smaller projects where requirements are very well understood.
 Simple and easy to understand and use.
 Easy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.
The disadvantages of the V-Model method are as follows −
 High risk and uncertainty.
 Not a good model for complex and object-oriented projects.
 Poor model for long and ongoing projects.
 Not suitable for the projects where requirements are at a moderate to high risk of changing.
 Once an application is in the testing stage, it is difficult to go back and change a functionality.
 No working software is produced until late during the life cycle.
SDLC - Agile Model
Agile SDLC model is a combination of iterative and incremental process models with focus on process
adaptability and customer satisfaction by rapid delivery of working software product. Agile Methods break the
product into small incremental builds. These builds are provided in iterations. Each iteration typically lasts
from about one to three weeks. Every iteration involves cross functional teams working simultaneously on
various areas like −
 Planning
 Requirements Analysis
 Design
 Coding
 Unit Testing and
 Acceptance Testing.
At the end of the iteration, a working product is displayed to the customer and important stakeholders.
What is Agile?
In Agile, the tasks are divided to time boxes (small time frames) to deliver specific features for a release.
Iterative approach is taken and working software build is delivered after each iteration. Each build is
incremental in terms of features; the final build holds all the features required by the customer.

Following are the Agile Manifesto principles −

 Individuals and interactions − In Agile development, self-organization and motivation are important, as
are interactions like co-location and pair programming.
 Working software − Demo working software is considered the best means of communication with the
customers to understand their requirements, instead of just depending on documentation.
 Customer collaboration − As the requirements cannot be gathered completely in the beginning of the
project due to various factors, continuous customer interaction is very important to get proper product
requirements.
 Responding to change − Agile Development is focused on quick responses to change and continuous
development.
Agile Model - Pros and Cons
The advantages of the Agile Model are as follows −
 Is a very realistic approach to software development.
 Promotes teamwork and cross training.
 Functionality can be developed rapidly and demonstrated.
 Resource requirements are minimum.
 Suitable for fixed or changing requirements
 Delivers early partial working solutions.
 Good model for environments that change steadily.
 Minimal rules, documentation easily employed.
 Enables concurrent development and delivery within an overall planned context.
 Little or no planning required.
 Easy to manage.
 Gives flexibility to developers.
The disadvantages of the Agile Model are as follows −
 Not suitable for handling complex dependencies.
 More risk of sustainability, maintainability and extensibility.
 An overall plan, an agile leader and agile PM practice is a must without which it will not work.
 Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the
deadlines.
 Depends heavily on customer interaction, so if customer is not clear, team can be driven in the wrong
direction.
 There is a very high individual dependency, since there is minimum documentation generated.
 Transfer of technology to new team members may be quite challenging due to lack of documentation.
 STLC (Software Testing Life Cycle) Phases, Entry, Exit Criteria
Software Testing Life Cycle (STLC) is a sequence of specific activities conducted during the testing process
to ensure software quality goals are met. STLC involves both verification and validation activities.
STLC Phases
There are following six major phases in every Software Testing Life Cycle Model (STLC Model):
1. Requirement Analysis
2. Test Planning
3. Test case development
4. Test Environment setup
5. Test Execution
6. Test Cycle closure
What is Entry and Exit Criteria in STLC?
 Entry Criteria: Entry Criteria gives the prerequisite items that must be completed before testing can
begin.
 Exit Criteria: Exit Criteria defines the items that must be completed before testing can be concluded
Requirement Phase Testing
Requirement Phase Testing also known as Requirement Analysis in which test team studies the requirements
from a testing point of view to identify testable requirements and the QA team may interact with various
stakeholders to understand requirements in detail. Requirements could be either functional or non-functional.
Activities in Requirement Phase Testing
 Identify types of tests to be performed.
 Gather details about testing priorities and focus.
 Identify test environment details where testing is supposed to be carried out.
 Automation feasibility analysis (if required).
Test Planning in STLC
Test Planning in STLC is a phase in which a Senior QA manager determines the test plan strategy along with
efforts and cost estimates for the project. Moreover, the resources, test environment, test limitations and the
testing schedule are also determined. The Test Plan gets prepared and finalized in the same phase.
Test Planning Activities
 Preparation of test plan/strategy document for various types of testing
 Test tool selection
 Test effort estimation
 Resource planning and determining roles and responsibilities.
 Training requirement
Deliverables of Test Planning
 Test plan /strategy document.
 Effort estimation document.
Test Case Development Phase
The Test Case Development Phase involves the creation, verification and rework of test cases & test scripts
after the test plan is ready. Initially, the Test data is identified then created and reviewed and then reworked
based on the preconditions. Then the QA team starts the development process of test cases for individual units.
Test Case Development Activities
 Create test cases, automation scripts (if applicable)
 Review and baseline test cases and scripts
 Create test data (If Test Environment is available)
Deliverables of Test Case Development
 Test cases/scripts
 Test data
Test Environment Setup
Test Environment Setup decides the software and hardware conditions under which a work product is tested.
It is one of the critical aspects of the testing process and can be done in parallel with the Test Case Development
Phase. Test team may not be involved in this activity if the development team provides the test environment.
The test team is required to do a readiness check (smoke testing) of the given environment.
Test Environment Setup Activities
 Understand the required architecture, environment set-up and prepare hardware and software
requirement list for the Test Environment.
  Setup test Environment and test data
 Perform smoke test on the build
Deliverables of Test Environment Setup
 Environment ready with test data set up
 Smoke Test Results.
Test Execution Phase
Test Execution Phase is carried out by the testers in which testing of the software build is done based on test
plans and test cases prepared. The process consists of test script execution, test script maintenance and bug
reporting. If bugs are reported then it is reverted back to development team for correction and retesting will be
performed.
Test Execution Activities
 Execute tests as per plan
 Document test results, and log defects for failed cases
 Map defects to test cases in RTM
 Retest the Defect fixes
 Track the defects to closure
Deliverables of Test Execution
 Completed RTM with the execution status
 Test cases updated with results
 Defect reports
Test Cycle Closure
Test Cycle Closure phase is completion of test execution which involves several activities like test completion
reporting, collection of test completion matrices and test results. Testing team members meet, discuss and
analyze testing artifacts to identify strategies that have to be implemented in future, taking lessons from current
test cycle. The idea is to remove process bottlenecks for future test cycles.
Test Cycle Closure Activities
 Evaluate cycle completion criteria based on Time, Test coverage, Cost,Software, Critical Business
Objectives, Quality
 Prepare test metrics based on the above parameters.
 Document the learning out of the project
 Prepare Test closure report
 Qualitative and quantitative reporting of quality of the work product to the customer.
 Test result analysis to find out the defect distribution by type and severity.
Deliverables of Test Cycle Closure
 Test Closure report
 Test metrics

Requirement Traceability Matrix

• RTM is a document that maps and traces user requirement with test cases.
• It captures all requirements proposed by the client and requirement traceability in a single document.
• The main purpose of Requirement Traceability Matrix is to validate that all requirements are checked
via test cases such that no functionality is unchecked during Software testing
 Types of Software Testing
White Box Testing
 White Box Testing conducts on the internal logic of the program.
 Programming skills are required. Generally Developer does this testing.
 Ex: Unit Testing & Integration Testing

Black Box Testing

 Testing conducts on the functionality of the application whether it is working according to the
requirements or not.
 Ex: System Testing & UAT Testing

Grey Box Testing

 This is combination of both White and Black box testing.
 Ex: Database Testing

Black Box Testing Types

 GUI Testing
 Usability Testing
 Functional Testing
 Non-Functional Testing

Usability Testing
 Usability Testing also known as User Experience(UX) Testing, is a testing method for measuring how
easy and user-friendly a software application is.
  Checks how easily end users are able to understand and operate the application

Functional Testing
 FUNCTIONAL TESTING is a type of software testing that validates the software system against the
functional requirements/specifications.
 The purpose of Functional tests is to test each function of the software application, by providing
appropriate input, verifying the output against the Functional requirements.
 Following is a step by step process on How to do Functional Testing :
 Understand the Functional Requirements
 Identify test input or test data based on requirements
 Compute the expected outcomes with selected test input values
 Execute test cases
 Compare actual and computed expected results

Non Functional testing

 NON-FUNCTIONAL TESTING is defined as a type of Software testing to check non-functional aspects
(performance, usability, reliability, etc.) of a software application. An excellent example of non-
functional test would be to check how many people can simultaneously login into a software.
 Non Functional Testing techniques:
 Performance Testing
 Security Testing
 Compatibility Testing
 Configuration testing
 Installation Testing

Performance Testing
• Load Testing – Testing speed of the system while increasing the load gradually till the expected
customer number (Positive Condition)
• Stress Testing – Testing how the system restarts after we increase the load beyond expected number to
break it (Negative Condition)
  Whether the system recovers to normalcy from abnormality caused due to system breakdown.
• Volume Testing – Checks how much volume of data can be handled by the system
Testing Terminology
Ad-hoc Testing
• Software Testing without proper planning and documentation
• Testing carried out with the knowledge of tester about application and tester tests application randomly
without following specification/requirements
Re-Testing
• Testing the functionality repetitively is called re-testing
• Re-testing is introduced in following cases:
 Testing functionality with multiple inputs
 Testing functionality on different environments (meaning different Browsers & OS)
 Testing functionality in the modified build to confirm bug fixes are made correctly

Regression testing
• It is a process of identifying various scenarios in modified build where there is a chance of getting side
effects and retesting these scenarios.
• It is a software testing practice that ensures an application still functions as expected after any
code changes, updates, or improvements. Regression testing is responsible for the overall stability and
functionality of the existing features.
Sanity Testing
• Sanity testing is a kind of Software Testing performed after receiving a software build, with minor
changes in code, or functionality, to ascertain that the bugs have been fixed and no further issues are
introduced due to these changes.
• The goal is to determine that the proposed functionality works roughly as expected.
• It’s narrow and deep.
Smoke Testing
• Testing done to verify that the critical functionalities of software are working fine. It is executed before
any detailed functional testing.
• The main purpose of smoke testing is to reject a software application with defects so that QA team does
not waste time testing broken software application.
• It’s shallow and wide.
UNIT TESTING
• It is a type of software testing where individual units or components of a software are tested. The
purpose is to validate that each unit of the software code performs as expected. Unit Testing is done
during the development (coding phase) of an application by the developers. Unit Tests isolate a section
of code and verify its correctness. A unit may be an individual function, method, procedure, module, or
object.
Objective of Unit Testing:
The objective of Unit Testing is:
1. To isolate a section of code.
2. To verify the correctness of the code.
3. To test every function and procedure.
4. To fix bugs early in the development cycle and to save costs.
5. To help the developers to understand the code base and enable them to make changes quickly.
6. To help with code reuse.

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 test approaches
1.Bottom-Up Integration Testing – In bottom-up testing, each module at lower levels is 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 principle advantage of this integration testing is that several disjoint subsystems can be tested
simultaneously.
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.
2. 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.
Disadvantages:
 Needs many Stubs.
 Modules at lower level are tested inadequately.

System Testing:
System Testing is done to check whether the software or product meets the specified requirements or not. It is
done by both testers and developers. It contains the Testings: System testing, Integration Testing. It is done
through more positive and negative test cases.
Acceptance Testing:
Acceptance Testing is done after the system testing. It is used to check whether the software meets the
customer requirements or not. Acceptance testing is used by testers, stakeholders as well as clients. It includes
only Functional Testing and it contain two testing Alpha Testing and Beta Testing.

Error, Bug & Failure

Error – Any incorrect human action that triggers a problem in the system is called error.
Defect/Bug – Deviation from the expected behaviour to the actual behaviour is called bug.
Failure – The deviation identified by end-user while using the system is called a failure.

What is Bug?
A bug is the consequence/outcome of a coding fault.
Defect in Software Testing
A Defect in Software Testing is a variation or deviation of the software application from end user’s
requirements or original business requirements. A software defect is an error in coding which causes incorrect
or unexpected results from a software program which does not meet actual requirements. Testers might come
across such defects while executing the test cases.
Defect Life Cycle or Bug Life Cycle in software testing is the specific set of states that defect or bug goes
through in its entire life. The purpose of Defect life cycle is to easily coordinate and communicate current status
of defect which changes to various assignees and make the defect fixing process systematic and efficient.
Defect Status
Defect Status or Bug Status in defect life cycle is the present state from which the defect or a bug is currently
undergoing. The goal of defect status is to precisely convey the current state or progress of a defect or bug in
order to better track and understand the actual progress of the defect life cycle.
The number of states that a defect goes through varies from project to project. Below lifecycle diagram, covers
all possible states
 New: When a new defect is logged and posted for the first time. It is assigned a status as NEW.
 Assigned: Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the
bug to the developer team
 Open: The developer starts analyzing and works on the defect fix
 Fixed: When a developer makes a necessary code change and verifies the change, he or she can make
bug status as “Fixed.”
 Pending retest: Once the defect is fixed the developer gives a particular code for retesting the code to
the tester. Since the software testing remains pending from the testers end, the status assigned is
“pending retest.”
 Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the
developer or not and changes the status to “Re-test.”

 Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the
software, then the bug is fixed and the status assigned is “verified.”
 Reopen: If the bug persists even after the developer has fixed the bug, the tester changes the status to
“reopened”. Once again the bug goes through the life cycle.
 Closed: If the bug is no longer exists then tester assigns the status “Closed.”
 Duplicate: If the defect is repeated twice or the defect corresponds to the same concept of the bug, the
status is changed to “duplicate.”
 Rejected: If the developer feels the defect is not a genuine defect then it changes the defect to
“rejected.”
 Deferred: If the present bug is not of a prime priority and if it is expected to get fixed in the next
release, then status “Deferred” is assigned to such bugs
 Not a bug:If it does not affect the functionality of the application then the status assigned to a bug is
“Not a bug”.
Defect Life Cycle Explained
Bug Severity or Defect Severity in testing is a degree of impact a bug or a Defect has on the software
application under test. A higher effect of bug/defect on system functionality will lead to a higher severity level.
A Quality Assurance engineer usually determines the severity level of a bug/defect.
What is Priority?
Priority is defined as the order in which a defect should be fixed. Higher the priority the sooner the defect
should be resolved.
Defects that leave the software system unusable are given higher priority over defects that cause a small
functionality of the software to fail.
Types of Severity
In Software Testing, Types of Severity of bug/defect can be categorized into four parts :
 Critical: This defect indicates complete shut-down of the process, nothing can proceed further
 Major: It is a highly severe defect and collapses the system. However, certain parts of the system
remain functional
 Medium: It causes some undesirable behavior, but the system is still functional
 Low: It won’t cause any major break-down of the system
Priority Types
Types of Priority of bug/defect can be categorized into three parts :
 Low: The Defect is an irritant but repair can be done once the more serious Defect has been fixed
 Medium: During the normal course of the development activities defect should be resolved. It can wait
until a new version is created
 High: The defect must be resolved as soon as possible as it affects the system severely and cannot be
used until it is fixed
Priority vs Severity: Key Difference
Priority Severity
 Defect Severity is defined as
 Defect Priority has defined the
the degree of impact that a
order in which the developer
defect has on the operation of
should resolve a defect
the product
 Severity is categorized into
 Priority is categorized into three five types
types  Critical
 Low  Major
 Medium  Moderate
 High  Minor
 Cosmetic

 Priority is associated with  Severity is associated with

scheduling
 Priority indicates how soon the
bug should be fixed
 Priority of defects is decided in
consultation with the
manager/client
 Priority is driven by business
value
 Its value is subjective and can
change over a period of time
depending on the change in the
project situation
 High priority and low severity
status indicates, defect have to be
fixed on immediate bases but does
not affect the application
 Priority status is based on
customer requirements
functionality or standards
 Severity indicates the
seriousness of the defect on
the product functionality
 QA engineer determines the
severity level of the defect
 Severity is driven by
functionality
 Its value is objective and less
likely to change
 High severity and low priority
status indicates defect have to
be fixed but not on immediate
bases
 Severity status is based on the
technical aspect of the product

 During SIT, the development

 During UAT the development
team will fix defects based on
team fix defects based on priority
the severity and then priority

Difference between Black Box testing and White Box testing

Below is the main difference between White Box and Black Box Testing:

Parameter Black Box testing White Box testing

It is a testing approach which is used to test
Definition the software without the knowledge of the
internal structure of program or application.
It also knowns as data-driven, box testing,
Alias
data-, and functional testing.
It is a testing approach in which
internal structure is known to the
tester.
It is also called structural testing,
clear box testing, code-based
Parameter Black Box testing White Box testing
testing, or glass box testing.
Testing is based on external expectations;
Internal working is known, and
Base of Testing internal behavior of the application is
the tester can test accordingly.
unknown.
This type of testing is ideal for higher levels of Testing is best suited for a lower
Usage testing like System Testing, Acceptance level of testing like Unit Testing,
testing. Integration testing.
Programming knowledge is
Programming Programming knowledge is not needed to
required to perform White Box
knowledge perform Black Box testing.
testing.
Implementation Implementation knowledge is not requiring Complete understanding needs to
knowledge doing Black Box testing. implement WhiteBox testing.
Test and programmer are dependent on each White Box testing is easy to
Automation
other, so it is tough to automate. automate.
The main objective of White Box
The main objective of this testing is to check
Objective testing is done to check the
what functionality of the system under test.
quality of the code.
Testing can start after preparing requirement Testing can start after preparing
Basis for test cases
specification document. for Detail design document.
Performed by the end user, developer, and Usually done by tester and
Tested by
tester. developers.
Granularity Granularity is low. Granularity is high.
Data domain and internal
Testing method It is based on trial and error method.
boundaries can be tested.
Exhaustive and time-consuming
Time It is less exhaustive and time-consuming.
method.
Algorithm test Not the best method for algorithm testing. Best suited for algorithm testing.
White box testing requires code
Code access is not required for Black Box
Code Access access. Thereby, the code could
Testing.
be stolen if testing is outsourced.
It allows removing the extra lines
Well suited and efficient for large code
Benefit of code, which can bring in
segments.
hidden defects.
Low skilled testers can test the application Need an expert tester with vast
Skill level with no knowledge of the implementation of experience to perform white box
programming language or operating system. testing.

Statement Coverage, Branch

coverage, and Path coverage are
Equivalence partitioning is Black box testing
White Box testing technique.
technique is used for Blackbox testing.
Statement Coverage validates
Equivalence partitioning divides input values
whether every line of the code is
into valid and invalid partitions and selecting
Techniques executed at least once.
corresponding values from each partition of
Branch coverage validates
the test data.
whether each branch is executed
Boundary value analysis
at least once
checks boundaries for input values.
Path coverage method tests all
the paths of the program.
Parameter Black Box testing White Box testing
Automated test cases can become
Update to automation test script is essential if
Drawbacks useless if the code base is rapidly
you to modify application frequently.
changing.

Functional Vs. Non-Functional Testing

What is Quality Assurance?

Quality Assurance is popularly known as QA Testing, is defined as an activity to ensure that an organization is
providing the best possible product or service to customers.
Quality Control in Software Testing is a systematic set of processes used to ensure the quality of software
products or services. The main purpose of the quality control process is ensuring that the software product
meets the actual requirements by testing and reviewing its functional and non-functional requirements.

What is Agile Methodology?

Agile Methodology meaning a practice that promotes continuous iteration of development and testing
throughout the software development lifecycle of the project. In the Agile model in software testing, both
development and testing activities are concurrent, unlike the Waterfall model.
The agile software development emphasizes on four core values.
1. Individual and team interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
DevOps
DevOps (a portmanteau of “development” and “operations”) is the combination of practices and tools designed
to increase an organization’s ability to deliver applications and services faster than traditional software
development processes. This speed enables organizations to better serve their customers and compete more
effectively in the market.
In simple terms, DevOps is about removing the barriers between traditionally siloed teams, development and
operations. Under a DevOps model, development and operations teams work together across the entire software
application life cycle, from development and test through deployment to operations.
Benefits of DevOps
 Speed. DevOps practices let you move at the velocity you need to innovate faster, adapt to changing
markets better, and become more efficient at driving business results.
 Rapid delivery. When you increase the pace of releases, you can improve your product faster and build
competitive advantage.
 Reliability. DevOps practices like continuous integration and continuous delivery can ensure the quality
of application updates and infrastructure changes so you can reliably deliver at a more rapid pace while
maintaining an optimum experience for end users.
 Improved collaboration. Under a DevOps model, developers and operations teams collaborate closely,
share responsibilities, and combine their workflows. This reduces inefficiencies and saves time.
 Security. You can adopt a DevOps model without sacrificing security by using automated,
integrated security testing tools.