0% found this document useful (0 votes)
11 views7 pages

Assignment 2 QA

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
11 views7 pages

Assignment 2 QA

Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

Assignment # 2

M. Sarfraz

Task 1: Difference between Project and Product (30)

Differentiate between a project and a product in the context of software development. Provide
examples to support your explanation.

1.1. Project Definition and Scope

Definition:
A project in software development is a temporary attempt with a defined start and end date,
aimed at creating a specific outcome, such as a new feature, tool, or system. Projects are
often unique and are defined by constraints like scope, resources, and time.
Scope:
Projects have a limited scope and are goal-oriented, focusing on delivering a specific result
within a timeline. Once the objectives are achieved, the project ends.
Example:
Developing a new feature for a mobile banking app, like adding a digital wallet, would be a
project.
1.1. Product Definition and Scope

Definition:
A software program or service that is continuously created, maintained, and enhanced to
satisfy client or market demands is referred to as a product. Products, as compare to
projects, are produced for use continuously and usually last more.
Scope:
Products are published in versions and are continually enhanced by user input, updates,
and feature upgrades.
Example:
Microsoft Word is a product since it is continuously improved, maintained, and updated,
with new features and versions being included on a regular basis.

1.2. Lifespan and Lifecycle:


1. Lifecycle of a Project vs. Lifecycle of a Product
Project Lifecycle:
A project's lifecycle is a short, goal-oriented process that has many phases, including
planning, execution, monitoring, closure, and initiation. When the project's goal has been
achieved, its lifespan comes to a conclusion.

Product Lifecycle:
The introduction, growth, maturity, and decline phases of a product's lifecycle are more
extensive and driven by the market. It is ongoing and frequently involves cycles of end-user
input, upgrades, and iterations.
2. Project Lifecycle’s Impact on Testing Timelines and QA Planning
The projects set timeline places guidelines on testing and QA planning. Testing that
deliverables match criteria is the main goal of QA activities, which are typically concentrated
close to the project's finale. Usually, testing has a short timetable with the goal of being
completed before the project is closed.
3. Product Lifecycle Considerations for Testing
To provide long-term quality, scalability, and adaptability, product testing is continuous and
changes with each stage of the lifecycle. With each release, QA must always take customer
input, maintenance, and upgrades into account.

1.3. Objectives and Outcomes:


1. Project Objectives and Outcomes
 Objective: A main goal of a project is to create a new feature, application, or system
within a fixed amount of time. Projects are goal oriented and end. The results can be
obtained.
 QA Impact: Quality Assurance is concerned with making sure that the project deliver to
fulfill requirements before final delivery. When the project is finished, the scope specifies
the requirements that are the focus of testing.
2. Product Objectives and Outcomes
 Objective: The goal of a product is to continuously add value for users with the focus
on constant evolution and improvement to satisfy client needs and market demands.
Products have an endless lifespan and are improved through numerous iteration and
upgrade.
 QA Impact: Continuous testing includes compatibility tests across multiple devices,
regression analysis, and taking user feedback into account. Since new features and
upgrades are frequently added, the quality of the product has to be kept stable.

1.3. Stakeholders and Users:

Project Stakeholders and Users


 Stakeholders: Clients, project managers, and other team members that have a direct
stake in the project's success are examples of stakeholders that are frequently specific to
the project's scope.
 QA Impact: By a focus on fulfilling project-specific criteria and deadlines, QA priorities
closely match the expectations of these particular stakeholders.
Product Stakeholders and Users
 Stakeholders: more types of individuals are considered product stakeholders, including
marketing teams, product managers, end users, and business leaders. These stakeholders
care about long-term customer pleasure and market success since products are
continuing.
 Impact of QA: Because the product will go through several revisions and updates, QA for
products needs to take a more comprehensive approach, weighing user experience, long-
term stability, and competitive advantages.
1.5. Quality Assurance Focus:
Importance on Quality Assurance in Project-Based Settings
 Meeting Requirements: QA ensures the final output aligns with the project’s specific
requirements.
 Functionality and Stability: Testing focuses on correct functionality and eliminating
critical bugs.
 Time and Budget Constraints: QA activities are planned within a fixed schedule,
budget, and set milestones.
 Final Approval for Release: QA aims for a stable, defect-free release at the project
conclusion.
1.6. Examples and Scenarios
1. May you give an example of a project-specific QA methodology (such as a set
deliverable with a deadline)?
When working on a project with a set deadline (such creating a client's mobile app), QA
would normally take the following structured approach:
 Requirements analysis
 Planning tests (using functional specs as a guidance)
 Manual testing, such as security, performance, and functional testing
 Testing for regression prior to final delivery
2. How would the QA approach differ for a product, such as ongoing app updates or
a SaaS platform?
QA for a product entails continuous testing as it develops. The strategy could consist of:
Regression testing is automated following every feature upgrade.
 Testing for smoke in new releases
 A/B testing to determine the way new features affect user behavior
 Performance and issue reports are constantly reviewed in order to put up fixes.
1.7. Changes and Flexibility:
1. How does the change management process differ between a project and a
product?
 In a project, Usually, any modifications to the scope, deliverables, or timeframes
need to be checked and approved.
 In a project, Change management is more adaptable and flexible. Features might
change as part of ongoing development cycles in response to user input or market
demands.
2. What QA strategies are suitable for a fixed-scope project versus an evolving
product?
 For a project, the goal of QA techniques is to ensure that, by the end of the
development cycle, all criteria have been satisfied. Testing is usually more linear
and systematic.
 For an evolving project QA techniques, such as exploratory testing, continuous
integration, and continuous feedback loops, must provide quick changes and
continuous testing.
1.8. Documentation and Processes:
1. What kind of documentation is typically needed for a project versus a product?
 Project documentation includes functional specifications, design documents, test
plans, acceptance criteria, and comprehensive project plans. Usually definitive,
the documentation is produced at the beginning and end of the project.
 Product documentation comprises release notes, change logs, feature backlogs,
and user stories. It is more dynamic and is updated quickly when new features are
created.
2. How does the difference in documentation impact test planning, tracking, and
execution?
 For a Project, Testing is usually structured according to requirements
documentation, and test planning and execution depends on an initial set of
deliverables. Typically, tracking is based on project phases.
 For a Product, There is more continuous and iterative testing and execution. Test
planning must take into account new features and upgrades, and tracking can
sometimes be carried out via an issue tracking system or product backlog.

1.9. Metrics and Success Criteria:


1. What are the success criteria for a project versus a product?
 For a Project, Usually, meeting the set timeline and quality requirements,
delivering the product on plan, and staying under budget are the success elements.
 For a Product, The main focus of success criteria is on overall performance,
adoption, retention, and user happiness. Success is frequently gauged by metrics
such as active users, churn rate, and Net Promoter Score (NPS).
2. What specific QA metrics are used to assess the quality and success of each?
 For a project, QA metrics may include defect density, test coverage, and on-time
delivery.
 For a product, QA metrics might include bug fix turnaround time, user feedback
(bug reports or feature requests), and regression test results.

1.10. End of Life and Support:


1.How is the end of life (EOL) handled differently for a project compared to a
product?
 EOL Project: When the last deliverables are approved and the project is formally
closed, it is deemed finished. Long-term support is not available unless the client
demands post-launch maintenance.
 Product EOL: End-of-life planning for a product's dying, replacement, or
upgrade is part of its lifetime. The business might switch users to more recent
versions or keep providing maintenance for some time.
2. What QA processes are involved when a product reaches its end of life, in
contrast to a project’s completion?
 Project completion typically involves handing out the documentation after final
testing and acceptance.
 Product end-of-life involves verifying final bug fixes, ending continuous
support, and maybe making sure users have a smooth transition. Before shutting
down, QA procedures may include regression testing of the most recent version to
ensure stability.
Task 2: Difference between QA and QC (10)

Explain the differences between Quality Assurance (QA) and Quality Control (QC) in
software testing. Provide examples to illustrate each.
Answer:
Quality Assurance (QA) and Quality Control (QC) are two distinct aspects of software testing,
though they are often used interchangeably. Both are essential for delivering high-quality
software, but they focus on different areas of the software development lifecycle.
Definition
Quality Assurance (QA):The proactive purpose of quality assurance is to stop errors. To ensure
that quality is ingrained in the software development process from the start, a set of protocols,
guidelines, and standards must be implemented.
Quality Control (QC): QC is a responsive procedure that aims to find and address flaws in the
finished product. It includes running out tests to see whether the program satisfies the necessary
requirements and standards.

Goal:
QA: works to improve and set up software development procedures to avoid mistakes and flaws.
QC: works to identify errors in the finished product and confirm that it satisfies the necessary
quality requirements.

Scope:
QA: is more comprehensive and covers each step of the software development lifecycle, from
conception to execution.
QC: focused on the product itself, usually toward the conclusion of the development cycle
before release.

Approach:
QA: Process-oriented, ensuring proper development procedures are followed.
QC: Product-oriented, ensuring the final product is defect-free.

Techniques:
QA: Involves process audits, training, reviews, and setting standards.
QC: Involves actual testing, like functional, performance, unit, and system testing.

Examples:
QA: Ensures adherence to methodologies (Agile), enforces coding standards, and sets up testing
tools.
QC: Conducts tests to detect UI, functional, or performance issues in the product.
Task 3: Criteria of Tool Selection in QA (10)
List and describe at least five criteria that should be considered when selecting tools for QA
activities.
When selecting a QA tool, it's critical to make sure it improves product quality and fits the
project's requirements. Here are six essential requirements:

Ease of Use:
For team members, the tool should be simple, easy to use, and easy to set up. Complicated tools
might slow production and deter use.
Example, JIRA makes it simple to monitor tasks and issues in Agile workflows.

Integration and Compatibility:


It should interact with other technologies like Git, or defect trackers and function effectively
with existing systems.
Example, Selenium supports automation in CI/CD workflows by integrating with Jenkins.

Assistance with Test Automation:


To increase efficiency and save time, the tool should enable the creation, execution, and
reporting of automated tests if necessary.
Example, Test Complete provides strong support for automating both functional and regression
tests.

Scalability:
As the project progresses, the tool ought to be able to accommodate more tests, intricate
procedures, and more users as required.
Example, when projects expand, Jenkins may grow to accommodate growing test loads and
users.

Expense and Permits:


The instrument should be affordable, taking into account any upfront expenses, recurring fees, or
subscriptions. Think about any additional expenses, such as certain hardware or setups.
Example, QA Test has license fees but provides enterprise support, whereas Selenium is open-
source.

Analytics and Reporting:


For teams and stakeholders to comprehend test results and make data-driven decisions, the
platform should provide clear reports and analytics.
Example, offers comprehensive test monitoring and reporting that displays trends and progress.

You might also like