Quality Essentials Guide - 1
Quality Essentials Guide - 1
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.
Testing VS Debugging
Debugging: is the development activity that finds, analyzes, and fixes such defects.
Quality Control (testing) involves various activities, including test activities, that support the
achievement of appropriate levels of quality.
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 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:
• 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.
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.
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.
• 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.
- 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.
• 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.
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.