ST-4360706

Assignment
Sr.
Questions
No
1 Explain SDLC and STLC Model with difference.

Aspect SDLC STLC

SDLC is mainly related to STLC is mainly related to

Domain
software development. software testing.

Besides development
It focuses only on testing
Focus other phases like testing
the software.
is also included.

SDLC involves total six STLC involves only five

Phases
phases or steps. phases or steps.

In SDLC, more number

In STLC, less number of
of members (developers)
Number of Member members (testers) are
are required for the whole
needed.
process.

In SDLC, development In STLC, testing

team makes the plans and team(Test Lead or Test
Team Involved
designs based on the Architect) makes the
requirements. plans and designs.

Goal of SDLC is to Goal of STLC is to

Objective complete successful complete successful
development of software. testing of software.

It helps in developing It helps in making the

End Result
good quality software. software defects free.

SDLC phases are STLC phases are

Execution completed before the performed after SDLC
STLC phases. phases.

Post deployment support , Regression tests are run

Maintenance
enhancement , and update by QA team to check
 are to be included if deployed maintenance
necessary. code and maintains test
cases and automated
scripts.

2 Explain V-Model and W-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.
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
This is the first phase in the development cycle where the product requirements are
understood from the customer’s perspective. This phase involves detailed
communication with the customer to understand his expectations and exact
requirement. This is a very important activity and needs to be managed well, as most
of the customers are not sure about what exactly they need. The acceptance test
design planning is done at this stage as business requirements can be used as an
input for acceptance testing.
System Design
Once you have the clear and detailed product requirements, it is time to design the
complete system. The system design will have the understanding and detailing the
complete hardware and communication setup for the product under development.
The system test plan is developed based on the system design. Doing this at an
earlier stage leaves more time for the actual test execution later.
Architectural Design
 Architectural specifications are understood and designed in this phase. 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).
The data transfer and communication between the internal modules and with the
outside world (other systems) is clearly understood and defined in this stage. With
this information, integration tests can be designed and documented during this
stage.
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.
The unit tests are an essential part of any development process and helps eliminate
the maximum faults and errors at a very early stage. These unit tests can be designed
at this stage based on the internal module designs.

Validation Phases
The different Validation Phases in a V-Model are explained in detail below.

Unit Testing
Unit tests designed in the module design phase are executed on the code during this
validation phase. Unit testing is the testing at code level and helps eliminate bugs at
an early stage, though all defects cannot be uncovered by unit testing.

Integration Testing
Integration testing is associated with the architectural design phase. Integration tests
are performed to test the coexistence and communication of the internal modules
within the system.

System Testing
System testing is directly associated with the system design phase. System tests check
the entire system functionality and the communication of the system under
development with external systems. Most of the software and hardware compatibility
issues can be uncovered during this system test execution.

Acceptance Testing
Acceptance testing is associated with the business requirement analysis phase and
involves testing the product in user environment. Acceptance tests uncover the
compatibility issues with the other systems available in the user environment. It also
discovers the non-functional issues such as load and performance defects in the actual
user environment.

W-model is the most recent software development model where we start real testing
activity simultaneously software development process. Where software development
process is a method in which a software or product is made through various stages of
planning, development, and testing before the final software or product is delivered.
testing is such a stage that is extremely crucial to ensure the delivery of an optimum
quality product.

V-model and W-model are two of the most important models that are used in
software testing.
W-Model covers those activities that are skipped by V-Model and also, it deals with
problems that couldn’t be caught by V-Model.
W-Model approach attempts to address and tackle the shortcomings W-Model
approach attempts to address and tackle the shortcomings of V-Model.
W-model can be done only once the development of the product is complete with no
modifications required to be done in between. This type of testing is most suitable for
short projects.
With the help of W-Model, we ensure that the testing of the product starts from the
very first day of the inception of the product, and each phase of the product
development is verified and validated.
w-model
W-Model

Phases of W-Model
Each phase is verified/validated. Dotted line shows that every phase in green is

Point 1 refers to – Build Test Plan & Test Strategy.

Point 2 refers to – Scenario Identification.
Point 3 refers to –Test case preparation from Specification document and design
documents.
Point 4 refers to – Test case preparation from Specification document and design
documents.
Point 5 refers to – review of test cases and update as per the review comments.
Point 6 refers to – Various testing methodologies such as Unit/integration testing,
path testing, equivalence partition, boundary value, specification based testing,
 security testing, usability testing, performance testing.
After this, there are regression test cycles and then User acceptance testing.
3 Explain Various Software Testing Terminologies.
1. Test Case
A test case is a set of inputs, expected results, and execution conditions that are used to
test a specific piece of software functionality.

2. Test Script
A test script is a set of instructions that are used to execute a test case. Test scripts can
be manual or automated.

3. Test Data
Test data is the input data that is used to test a software application. Test data can
include user input, database data, or other types of data.

4. Defect
A defect is a flaw or error in a software application that causes it to behave in an
unintended way.

5. Bug
A bug is a synonym for a defect.

6. Error
An error is a mistake or inaccuracy in a software application that causes it to behave in
an unintended way.

7. Failure
A failure is when a software application does not meet its requirements or
specifications.

4 Explain Manual Testing and Automation Testing.

Manual Testing
Manual testing is a type of software testing where a tester manually executes test cases
to identify defects in the software application. Manual testing involves:

1. Test Case Creation: Creating test cases based on the software requirements and
specifications.
2. Test Environment Setup: Setting up the test environment, including hardware,
software, and network configurations.
3. Test Execution: Executing the test cases manually, either by interacting with the
software application directly or by using test data.
4. Defect Reporting: Reporting defects found during testing, including steps to
reproduce, expected results, and actual results.
Advantages of Manual Testing:
1. Flexibility: Manual testing allows testers to be flexible and adapt to changing
requirements.
2. Exploratory Testing: Manual testing enables exploratory testing, where testers can
explore the software application and identify defects that may not have been caught
through automated testing.
3. Human Judgment: Manual testing involves human judgment, which can be
beneficial in identifying defects that may not be caught through automated testing.

Disadvantages of Manual Testing:

1. Time-Consuming: Manual testing can be time-consuming, especially for large and
complex software applications.
2. Error-Prone: Manual testing can be error-prone, as testers may miss defects or
incorrectly report defects.
3. Costly: Manual testing can be costly, as it requires a significant amount of time and
resources.

Automation Testing
Automation testing is a type of software testing where automated tools are used to
execute test cases and identify defects in the software application. Automation testing
involves:

1. Test Script Creation: Creating test scripts using automated testing tools, such as
Selenium or Appium.
2. Test Environment Setup: Setting up the test environment, including hardware,
software, and network configurations.
3. Test Execution: Executing the test scripts using automated testing tools.
4. Defect Reporting: Reporting defects found during testing, including steps to
reproduce, expected results, and actual results.

Advantages of Automation Testing:

1. Faster Test Execution: Automation testing enables faster test execution, as
automated tools can execute test cases quickly and efficiently.
2. Increased Accuracy: Automation testing increases accuracy, as automated tools can
execute test cases consistently and accurately.
3. Reduced Cost: Automation testing reduces cost, as automated tools can execute test
cases quickly and efficiently, reducing the need for manual testing.

Disadvantages of Automation Testing:

1. Initial Investment: Automation testing requires an initial investment in automated
testing tools and training.
2. Maintenance: Automation testing requires ongoing maintenance, as automated
testing tools and test scripts need to be updated regularly.
 3. Limited Coverage: Automation testing may not provide complete coverage, as some
test cases may require manual testing.
5 Explain QA and QC in Software Testing.
Here's an explanation of QA and QC in software testing:

QA (Quality Assurance)
QA is a systematic process that ensures software development and testing activities
conform to defined standards, processes, and procedures. QA focuses on preventing
defects and ensuring the overall quality of the software development process.

Goals of QA:
1. Ensure compliance: Ensure that software development and testing activities comply
with defined standards, processes, and procedures.
2. Prevent defects: Identify and mitigate potential defects early in the software
development process.
3. Improve processes: Continuously improve software development and testing
processes to ensure high-quality software.

QA Activities:
1. Process development: Develop and maintain software development and testing
processes.
2. Audits and reviews: Conduct regular audits and reviews to ensure compliance with
defined processes and standards.
3. Training and awareness: Provide training and awareness programs to ensure that
team members understand and follow defined processes and standards.

QC (Quality Control)
QC is a systematic process that evaluates the quality of software during and after
development. QC focuses on detecting and removing defects in the software.

Goals of QC:
1. Detect defects: Identify defects in the software during and after development.
2. Ensure quality: Ensure that the software meets defined quality standards and
requirements.
3. Improve quality: Continuously improve the quality of the software through defect
removal and process improvement.

QC Activities:
1. Testing: Perform various types of testing, such as unit testing, integration testing,
and system testing.
2. Defect tracking and reporting: Track and report defects found during testing.
3. Defect fixing and retesting: Fix defects and retest the software to ensure that defects
are removed.
 Key Differences between QA and QC:
1. Focus: QA focuses on preventing defects and ensuring the overall quality of the
software development process, while QC focuses on detecting and removing defects in
the software.
2. Scope: QA encompasses the entire software development process, while QC is
focused on the testing and quality evaluation phases.
3. Activities: QA activities include process development, audits, and reviews, while
QC activities include testing, defect tracking, and defect fixing.
4. Timing: QA is an ongoing process that occurs throughout the software development
life cycle, while QC occurs during and after the development phase.

In summary, QA ensures the quality of the software development process, while QC

ensures the quality of the software product. Both QA and QC are essential for
delivering high-quality software applications.
6 Explain Test Case with Example.

What is a Test Case?

A test case is a set of inputs, expected results, and execution conditions that are used
to test a specific piece of software functionality. A test case is designed to validate that
the software behaves as expected under specific conditions.

Components of a Test Case:

1. Test Case ID: A unique identifier for the test case.
2. Test Case Description: A brief description of the test case.
3. Preconditions: The conditions that must be met before the test case can be executed.
4. Steps: The specific actions that must be taken to execute the test case.
5. Expected Results: The expected outcome of the test case.
6. Actual Results: The actual outcome of the test case.
7. Pass/Fail Criteria: The criteria used to determine whether the test case has passed or
failed.

Example of a Test Case:

Let's say we're testing a login feature for a web application. Here's an example test
case:

Test Case ID: TC-001

Test Case Description: Test login with valid credentials
Preconditions: The user has a valid username and password
Steps:

1. Enter a valid username in the username field.

2. Enter a valid password in the password field.
3. Click the login button.
Expected Results: The user is logged in successfully and redirected to the dashboard
 page.
Actual Results: [To be filled in after executing the test case]
Pass/Fail Criteria: If the user is logged in successfully and redirected to the dashboard
page, the test case passes. Otherwise, it fails.

Types of Test Cases:

1. Functional Test Cases: Test the functionality of the software.
2. Non-Functional Test Cases: Test the performance, security, and usability of the
software.
3. Positive Test Cases: Test the software with valid inputs.
4. Negative Test Cases: Test the software with invalid inputs.
5. Edge Test Cases: Test the software with boundary values.

By creating and executing test cases like this one, we can ensure that our software
meets the required functionality and quality standards.
7 Explain Test Plan with Example.

What is a Test Plan?

A test plan is a document that outlines the approach, scope, and timeline for testing a
software application. It provides a detailed plan for testing, including the test
objectives, test scope, test schedule, test deliverables, and test resources.

Components of a Test Plan:

1. Test Plan ID: A unique identifier for the test plan.
2. Test Plan Name: A brief name for the test plan.
3. Test Objectives: A description of what the testing aims to achieve.
4. Test Scope: A description of what is included and excluded from the testing.
5. Test Schedule: A timeline for the testing activities.
6. Test Deliverables: A list of the expected outputs from the testing.
7. Test Resources: A list of the resources required for the testing.
8. Test Environment: A description of the environment in which the testing will take
place.
9. Test Data: A description of the data required for the testing.
10. Test Risks: A description of the potential risks associated with the testing.

Example of a Test Plan:

Let's say we're testing a new e-commerce website. Here's an example test plan:

Test Plan ID: TP-001

Test Plan Name: E-commerce Website Testing
Test Objectives:

- To ensure that the website is functional and meets the requirements.

- To identify and report any defects or issues.
- To ensure that the website is secure and meets the security requirements.

Test Scope:

- The testing will cover the following features:

- User registration and login
- Product search and browsing
- Shopping cart and checkout
- Payment processing
- The testing will exclude the following features:
- Admin dashboard
- Reporting and analytics

Test Schedule:

- Testing will start on March 1st and end on March 31st.

- Testing will be performed during business hours (9am-5pm) Monday-Friday.

Test Deliverables:

- A detailed test report outlining the results of the testing.

- A list of defects or issues identified during the testing.

Test Resources:

- 2 testers with experience in e-commerce website testing.

- 1 test lead with experience in managing testing projects.
- Test equipment (laptops, tablets, smartphones).

Test Environment:

- The testing will take place in a controlled environment with the following
configuration:
- Windows 10 operating system
- Google Chrome browser
- Internet connection with a speed of at least 10 Mbps

Test Data:

- Test data will be provided by the development team.

 - Test data will include sample products, user accounts, and payment information.

Test Risks:

- The testing may be delayed due to technical issues or availability of test resources.
- The testing may not cover all the possible scenarios or edge cases.

8 Difference between Smoke Testing and Sanity Testing.

9 Explain Static Testing and Dynamic Testing.

Static Testing
Static Testing is a type of a Software Testing method which is performed to check the
defects in
software without actually executing the code of the software application. Whereas in
Dynamic
Testing checks, the code is executed to detect the defects.
Static testing is performed in early stage of development to avoid errors as it is easier
to find
sources of failures and it can be fixed easily. The errors that cannot be found using
Dynamic
 Testing, can be easily found by Static Testing.
Static Testing Techniques:
There are mainly two type techniques used in Static Testing:
1. Review
2. Static Analysis
1. Review: In static testing review is a process or technique that is performed to
find the potential defects in the design of the software. It is process to detect and
remove errors and defects in the different supporting documents like software
requirements specifications. People examine the documents and sorted out errors,
redundancies and ambiguities.

2.Static Analysis: Static Analysis includes the evaluation of the code quality that is
written by developers. Different tools are used to do the analysis of the code and
comparison of the same with the standard

5. Dynamic testing:
Dynamic testing is a type of software testing that involves executing the software
and evaluating its behavior during runtime. It used to analyze the dynamic
behavior of the code. It includes the testing of the software for the input values
and output values that are analyzed. It is performed to describe the dynamic
behavior of code. It refers to the observation of the physical response from the
system to variables that are not constant and change with time.

Advantages of Dynamic Testing

Disclosure of Difficult and Complex Defects: It discloses very difficult and
complex defects.
Improvement in Software Quality: It increases the quality of the software
product or application being tested.
Security Threat Detection: Dynamic testing detects security threats and ensure
the better secure application.
Early-Stage Functionality Testing: It can be used to test the functionality of the
software at the early stages of development.
Ease of Implementation: It is easy to implement and does not require any special
tools or expertise.
Testing with Different Inputs, Data Sets, and User Profiles: It can be used to test
the software with different input values, data sets and user profiles.
Functionality and Performance Testing: It can be used to test the functionality of
the code and performance of the code.
Disadvantages of Dynamic Testing
Time-Consuming Process: It is a time consuming process as in dynamic testing
whole code is executed.
Increased Budget: It increases the budget of the software as dynamic testing is
costly.
Resource Intensive: Dynamic testing may require more resources than static
testing.
Less Effective in Some Cases: Dynamic testing may be less effective than static
testing in some cases.
Incomplete Test Scenario Coverage: It is difficult to cover all the test scenarios.
Difficulty in Root Cause Analysis: It is difficult to find out the root cause of the
defects.
10 Explain any Two White-Box Testing Methods.
Here are explanations of two black-box testing methods, Equivalence Partitioning and
Boundary Value Analysis, with examples:

1. Equivalence Partitioning
Equivalence partitioning is a black-box testing method that involves dividing the input
data into partitions based on the requirements of the software. The goal of equivalence
partitioning is to test each partition with at least one test case.

Example:
Suppose we are testing a software that accepts ages of users and categorizes them into
three groups: children (0-12), teenagers (13-19), and adults (20 and above).

Partitions:
1. Children (0-12)
2. Teenagers (13-19)
3. Adults (20 and above)

Test Cases:
1. Test case 1: Input age = 10 (children partition)
- Expected output: "Children"
2. Test case 2: Input age = 15 (teenagers partition)
- Expected output: "Teenagers"
3. Test case 3: Input age = 25 (adults partition)
- Expected output: "Adults"

Advantages of Equivalence Partitioning:

1. Reduces the Number of Test Cases: Equivalence partitioning reduces the number of
test cases needed to test the software.
2. Ensures Coverage of Input Data: Equivalence partitioning ensures that each
partition of the input data is tested.

2. Boundary Value Analysis

Boundary value analysis is a black-box testing method that involves testing the
software with input data that falls on the boundaries of the partitions. The goal of
boundary value analysis is to test the software's behavior at the boundaries of the
partitions.

Example:
Using the same example as above, the boundaries of the partitions are:

1. Age = 0 (lower boundary of children partition)

2. Age = 12 (upper boundary of children partition)
 3. Age = 13 (lower boundary of teenagers partition)
4. Age = 19 (upper boundary of teenagers partition)
5. Age = 20 (lower boundary of adults partition)

Test Cases:
1. Test case 1: Input age = 0 (lower boundary of children partition)
- Expected output: "Children"
2. Test case 2: Input age = 12 (upper boundary of children partition)
- Expected output: "Children"
3. Test case 3: Input age = 13 (lower boundary of teenagers partition)
- Expected output: "Teenagers"
4. Test case 4: Input age = 19 (upper boundary of teenagers partition)
- Expected output: "Teenagers"
5. Test case 5: Input age = 20 (lower boundary of adults partition)
- Expected output: "Adults"

Advantages of Boundary Value Analysis:

1. Identifies Errors at Boundaries: Boundary value analysis identifies errors that occur
at the boundaries of the partitions.
2. Ensures Robustness of Software: Boundary value analysis ensures that the software
is robust and can handle input data that falls on the boundaries of the partitions.

11 Explain any Two Black-Box Testing Methods.

Here are explanations of two black-box testing methods, Equivalence Partitioning and
Boundary Value Analysis, with examples:

1. Equivalence Partitioning
Equivalence partitioning is a black-box testing method that involves dividing the input
data into partitions based on the requirements of the software. The goal of equivalence
partitioning is to test each partition with at least one test case.

Example:
Suppose we are testing a software that accepts ages of users and categorizes them into
three groups: children (0-12), teenagers (13-19), and adults (20 and above).

Partitions:
1. Children (0-12)
2. Teenagers (13-19)
3. Adults (20 and above)

Test Cases:
1. Test case 1: Input age = 10 (children partition)
2. Test case 2: Input age = 15 (teenagers partition)
3. Test case 3: Input age = 25 (adults partition)

Advantages of Equivalence Partitioning:

1. Reduces the Number of Test Cases: Equivalence partitioning reduces the number of
test cases needed to test the software.
2. Ensures Coverage of Input Data: Equivalence partitioning ensures that each
partition of the input data is tested.

2. Boundary Value Analysis

Boundary value analysis is a black-box testing method that involves testing the
software with input data that falls on the boundaries of the partitions. The goal of
boundary value analysis is to test the software's behavior at the boundaries of the
partitions.

Example:
Using the same example as above, the boundaries of the partitions are:

1. Age = 0 (lower boundary of children partition)

2. Age = 12 (upper boundary of children partition)
3. Age = 13 (lower boundary of teenagers partition)
4. Age = 19 (upper boundary of teenagers partition)
5. Age = 20 (lower boundary of adults partition)

Test Cases:
1. Test case 1: Input age = 0 (lower boundary of children partition)
2. Test case 2: Input age = 12 (upper boundary of children partition)
3. Test case 3: Input age = 13 (lower boundary of teenagers partition)
4. Test case 4: Input age = 19 (upper boundary of teenagers partition)
5. Test case 5: Input age = 20 (lower boundary of adults partition)

Advantages of Boundary Value Analysis:

1. Identifies Errors at Boundaries: Boundary value analysis identifies errors that occur
at the boundaries of the partitions.
2. Ensures Robustness of Software: Boundary value analysis ensures that the software
is robust and can handle input data that falls on the boundaries of the partitions.