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

Quality Essentials Guide - 1

This document serves as a comprehensive guide to Quality Assurance (QA) essentials, outlining the purpose and processes of software testing, including definitions, objectives, and methodologies. It distinguishes between testing and debugging, explains various software development lifecycle models, and details different types of testing such as functional, non-functional, and maintenance testing. Additionally, it emphasizes the importance of documentation in testing and provides insights into effective communication of findings and defect reporting.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
17 views7 pages

Quality Essentials Guide - 1

This document serves as a comprehensive guide to Quality Assurance (QA) essentials, outlining the purpose and processes of software testing, including definitions, objectives, and methodologies. It distinguishes between testing and debugging, explains various software development lifecycle models, and details different types of testing such as functional, non-functional, and maintenance testing. Additionally, it emphasizes the importance of documentation in testing and provides insights into effective communication of findings and defect reporting.
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

QUALITY

ESSENTIALS
GUIDE
A guide to understand QA essentials, what is done in
production, expectations for the testers and processes
to follow. This way the new testers will have a clear
idea of what to expect from the training.
What is testing?
Software Testing is a method to check whether the actual software product matches
expected requirements and to ensure that software product is Defect free. It involves
execution of software/system components using manual or automated tools to evaluate
one or more properties of interest. The purpose of software testing is to identify errors,
gaps or missing requirements in contrast to actual requirements.

• Objectives in software testing:


- To prevent defects
- To find failures and defects
- To build confidence in the level of quality of the test object
- To verify whether all specified requirements have been fulfilled
- To evaluate work products such as requirements, user stories, design, and code
- To validate whether the test object is complete and works as the users and other
stakeholders expect
- To reduce the level of risk of inadequate software quality (e.g., previously undetected
failures occurring in operation)
- To provide sufficient information to stakeholders to allow them to make informed
decisions, specially regarding the level of quality of the test object
- To comply with contractual, legal, or regulatory requirements or standards , and/or to
verify the test object’s compliance with such requirements or standards

Testing VS Debugging

Testing: initial test and the final confirmation test

Debugging: is the development activity that finds, analyzes, and fixes such defects.

Why is testing necessary?


- Can help reduce the risk of failures occurring during operation.
- When defects are detected, and subsequently fixed, this contributes to the quality of the
components or systems
- Software testing may also be required to meet contractual or legal requirements or
industry specific standards

Quality Assurance and Testing

Quality Assurance is typically focused on adherence to proper processes, in order to provide


confidence that the appropriate levels of quality will be achieved.

Quality Control (testing) involves various activities, including test activities, that support the
achievement of appropriate levels of quality.

Validation and Verification

Validation: Review Phase


It is the process of checking whether the specification captures the customer's needs (a relatively
objective process). Validating that the requirement is realistic, clear and follows a certain logic
and that all information needed is being provided. We can validate time frames, plans,
requirements, etc. It asks: Are we building the right system?
Verification: Testing Phase
It is the process of checking if the software (product) meets the specification (extremely subjective
process) It asks: Are we building the system right?

Software Development and Software Testing:

It is an important part of a tester's role to be familiar with the common software development
lifecycle models so that appropriate test activities can take place. For every development activity,
there is a corresponding test activity.

Software Development Lifecycle Models in Context

Software development lifecycle models must be selected and adapted to the context of project
and product characteristics. Depending on the context of the project, it may be necessary to
combine or reorganize test levels and test activities.

Model Types:

• Waterfall Model: In a Waterfall model, each phase must be completed


before the next phase can begin and there is no overlapping in the phases.

• V Model: The V model 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.

• Spiral Cycle: It looks like a spiral with many loops. Each loop of the spiral
is called a Phase of the software development process. The exact number
of phases needed to develop the product can be varied as the project
manager dynamically determines the number of phases.

• Iterative-incremental Model: 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. This process is then repeated, producing a new version of the
software at the end of each iteration of the model.
Software Development Methodologies: The agile software development methodology is used for
articulating a well-organized project management procedure allowing for recurrent alterations.

Methodologies types:

• Prototyping: This model is used when the customers do not know the
exact project requirements beforehand. In this model, a prototype of the
end product is first developed, tested and refined as per customer
feedback repeatedly till a final acceptable prototype is achieved which
forms the basis for developing the final product.

• Scrum Cycle: Scrum teams work in two to four-week cycles


called sprints. During each sprint, teams plan, deliver, and
review a small chunk of the product. Creating potentially
releasable product increments is a new concept for those who
are used to done meaning ready to handoff to the next phase
of development, whether that is testing, documentation, or
something else.

Test levels:
• Component testing: A component is the lowest unit of any application. So, Component
testing; as the name suggests, is a technique of testing the lowest or the smallest unit of
any application.

• Integration Testing: Integration testing focuses on interactions between components or


systems. Component integration testing is often the responsibility of developers. System
integration testing is generally the responsibility of testers.

- Component integration testing focuses on the interactions and interfaces between


integrated components. Component integration testing is performed after component
testing and is generally automated.
- System integration testing focuses on the interactions and interfaces between systems,
packages, and microservices. System integration testing can also cover interactions with,
and interfaces provided by, external organizations.

• System Testing: System testing focuses on the behavior and capabilities of a whole
system or product, verifying whether the functional and non-functional behaviors of the
system are as designed and specified. Preventing defects from escaping to higher test
levels or production.
• Acceptance Testing: Acceptance testing, like system testing, typically focuses on the
behavior and capabilities of a whole system or product. Defects may be found during
acceptance testing, but finding defects is often not an objective, and finding a significant
number of defects during acceptance testing may in some cases be considered a major
project risk.

• Functional Testing: Functional testing of a system involves tests that evaluate functions
that the system should perform. Functional requirements may be described in work
products. The functions are “what” the system should do.

• White box Testing: White box testing derives tests based on the system’s internal
structure or implementation. The thoroughness of white box testing can be measured
through structural coverage. Structural coverage is the extent to which some type of
structural element has been exercised by tests and is expressed as a percentage of the
type of element being covered.

• Black box Testing: Also known as behavioral testing, is a software testing method in
which the internal structure/design/implementation of the item being tested is not
known to the tester. A tester, without knowledge of the internal structures of a website,
tests the web pages by using a browser, providing inputs (clicks, keystrokes) and verifying
the outputs against the expected outcome.

• Non- functional Testing: Nonfunctional testing of a system evaluates characteristics of


systems and software such as usability, performance efficiency or security. Nonfunctional
testing is the testing of how well” the system behaves.

- Reliability: the probability that the product will not fail through a defined period of
operation. Ex: Warranty
- Performance testing: tasks that need many computational operations and are very heavy
but normal to work. Ex: Google maps looking for a place and should look for images etc.
- Load testing test the load many requests at once to the computer to see how it behaves.
Ex: special ticket has no load tests.
- Stress testing: put a lot of processing load very intense on the computer in a long period
of time, to see how it behaves. Ex: put a movie to render on the computer.
- Usability testing: tests that tell if a system is usable or not. Ex: Hacienda.
- Security testing: it is tested if confidential data can be extracted in a database. Ex: the
forms.

• Maintenance Testing: Type of software testing that refers to testing the changes to an
operational system or the impact of a changed environment to an operational system. It’s
objective is to maintain the achieved levels of quality across the entire life cycle of the
software application.
• Static Testing: The tester checks the code, design documents, requirement document and
gives review comments on the work document. It finds defects in work products directly.
• Dynamic Testing: Form of software testing which analyzes the dynamic behavior of code.
Refers to the examination of the physical response from the system to variables that are
not constant and change with time. The software must actually be compiled and run in
order to identify failures caused by defects.
• Experienced based testing: A tester verifies and validates the software product quality
using his/her past experience of testing the similar type of product in the respective
domain.
Some of the expected situations are:
- Non availability of requirements and specifications.
- Limited Knowledge of the Software product.
- Inadequate specification
- Restricted amount of time, to perform testing.

Types of Experience Testing:


• Error Guessing: It is a simple technique of guessing and detecting the potential defects
that may creep into the software product. This is to spot the areas or functionalities of
the software product.

• Exploratory Testing: During exploratory testing, a tester constantly studies and analyzes
the software product and accordingly applies his skills, traits, and experience to develop
strategy and test cases to perform and carry out the necessary testing. It’s best use may
be seen in the event of inadequate specifications & requirement and severely limited time.

• Checklist Based Testing: In this technique, experienced tester based on his experience
prepares the checklist, which work as a manual to direct the testing process. Further, it
is pertinent to mention that the checklist is the only tool to ensure the complete test
coverage in this testing.

• End to End Testing: The entire application is tested for critical functionalities such as
communicating with the other systems, interfaces, database, network, and other
applications. The purpose of end-to-end Test is to exercise a complete production-like
scenario.

Documentation in Testing

Assets: Are those that contribute directly to and impact software testing initiatives. These are
usually written in Microsoft Word, PowerPoint, Microsoft Excel and/or PDF’s.
When testing it is required to have a clear understanding of the customer’s needs. Therefore,
we must be sure that each request has a clear description. The documents typically required
are: Copydecks (in the languages it is being tested) and Mock-ups.

Copy deck: A single document (usually written in Microsoft Word) that contains all the
necessary bits and bobs for a given copywriting project. It contains the Copy format guidelines:
How should bold, italic and underline be used in the copy. Tone guidelines: How should the copy
sound chatty, authoritative, formal, or confident. Page detail: Each page is written into the copy
deck with its own page number that matches back to the site map.

Creative: Style guides, mockups, UI specs:


The information these documents include are creative type, which generally contain an image.
Their objective is to maintain consistency of the product to make sure it is visually acceptable.

Evidence in Testing (QA document): QA documentation must include evidence (screenshots) that
show the expected result: Any code, copy and/or image change, the expected behavior: Correct
landing page, New/Same Window, Cross browsing: Testing in other browsers , Responsive:
Testing in all the breaking points, Assuring the web accessibility tool interprets correctly the
content and it is visible in the speech viewer’s log.

Findings document: Build a defect report for those findings that require changes.
The document must be done in a clear, neutral, fact focused way without criticizing the person
who created the defective item.
It should include:
- A highlight: To point our where the issue is
- A defect numbering: Keep an order of the issues
- The actual result vs the expected result: Informing the difference according to the assets.

You might also like