UNIT-III

1. Regression Testing

Regression means retesting the unchanged parts of the application. Test cases are re-executed in order
to check whether previous functionality of application is working fine and new changes have not
introduced any new bugs. This test can be performed on a new build when there is significant change in
original functionality or even a single bug fix. This is the method of verification. Verifying that the bugs
are fixed and the newly added features have not created in problem in previous working version of
software.

Types of Regression Testing

 Regular Regression Testing
 Final Regression Testing
(i) Regular Regression Testing is done between test cycles to ensure that defect fixes that are done
and the functionality that were working with the earlier test cycles continue to work. It can use more
than one product build for the test cases to be executed.
(ii) Final Regression Testing is done to validate the final build before release. It is conducted for a
specific period of time which is mutually agreed upon between the developer and testing team. This is
called cooking time.

When to do Regression Testing?

It is necessary to perform regression testing when
 A reasonable amount of initial testing is already carried out.
 A good number of defects have been fixed.
 Defect fixes that can produce side effects are taken care of.

How to do Regression Testing?

There are several methodologies are used by different organizations. It should be done by the following
steps:

(i) Performing an initial “Smoke” or “Sanity” Test

Smoke testing consists of
 Identifying the basic functionality that a product must satisfy.
 Designing test cases to ensure that these basic functionality and packaging them into a smoke
test suite.
 Ensuring that every time a product is built, this suite is run successfully before anything else is
run and
 If this suite fails, escalating to the developers to identify the changes and perhaps change or roll
back the changes.

(ii) Understanding the Criteria for selecting the test cases

There are two approaches to select the test cases for a regression run.
First Approach- Choose a constant set of regression tests that are run for every build or change. The
disadvantages are

1
  The constant set of tests will encompass all features and tests which are not required may be run
every time.
 A given set of defect fixes or changes may introduce problems for which there may not be ready
made test cases in the constant set.
Second Approach- Select test cases dynamically for each build.
In this approach, the tester needs the knowledge about
 The defect fixes and changes made in the current build.
 The ways to test current changes.
 The impact that the current changes may have on other parts of the system.
 The ways of testing the other impacted part.

Some of the criteria to select test cases for regression testing. They are:
 Include the test cases that have produced the maximum defects in the past.
 Include test cases for a functionality in which a change has been made.
 Include test cases in which problems are reported.
 Include test cases that test the basic functionality of the product which are mandatory
requirement of the customer.
 Include test cases that test end to end behavior of the application or the product.
 Including the area which is highly visible to the users.

(iii) Classifying test cases

The test cases are classified into three types based on the priority. They are:
Priority-0: These test cases can be called sanity test s which checks the basic functionality and are run
for accepting the build for the further testing. It delivers a very high project value.
Priority-1: Uses the basic and normal setup and these test cases deliver high project value to both
development team and customers.
Priority-2: These test cases deliver moderate project value.

(iv) Methodology for selecting test cases

The methodology for selecting test cases that considers two factors criticality and impact. Based on
these factors test cases are classified into:
Case1: If the criticality and impact of the defect fixes are low, then it is enough that a test engineer
selects a few test cases from TCDB (Test Case Data Base) and executes them. These test cases can fall
under any priority (0,1 or 2).
Case2: If the criticality and impact of the defect fixes are medium, then we need to execute all Priority-0
and Priority-1 test cases. Some Priority-2 test cases are also executed additionally.
Case3: If the criticality and impact of the defect fixes are high, then we need to execute all Priority-0,
Priority-1 and a select subset of Priority-2 test cases.

Some of the methods are:

1. Regress all - For regression testing, all Priority 0,1 and 2 test cases are rerun.
2. Priority based regression - All Priority 0,1 and 2 test cases are run in order, based on the
availability of time. Deciding when to stop the regression testing is based on the availability of
time.
3. Regress changes - Code changes are compared to the last cycle of testing and test cases are
selected based on their impact on the code.

2
 4. Random regression - Random test cases are selected and executed for this regression
methodology.
5. Context based dynamic regression - A few Priority-0 test cases are selected and based on the
context created by the analysis of those test cases after the execution and outcome.

(v) Resetting the test cases for Regression Testing

Resetting the test cases which need ‘Test cases Result History’. In a large product release involving
several rounds of testing, it is very important to record what test cases were executed in which cycle,
their results and related information. This is called test cases result history. A method or procedure that
use test case result history to indicate some of the test cases be selected for regression testing is called
rest procedure. Resetting a procedure in nothing but setting a flag called not run or execute again in
TCDB. The rest procedure also hides the test case results of previous builds for the test cases.
It should be done:
 When there is a major change in the product.
 When there is a change in the build procedure which affects the product.
 Large release cycle where some test case were not executed for a long time.
 When the product is in the final regression test cycle with a few selected test cases.
 The expected results could be quite different from the previous cycles.
 The test cases relating to defect fixes and production problems need to be evaluated release after
release.
 Whenever existing application functionality is removed, the related test cases can be reset.
 Test cases that consistently produce a positive result can be removed.
 Test cases relating to a few negative test conditions can be removed.

(vi) Concluding the results of regression testing

Current
Previous
result from Conclusion Remarks
Results
Regression
FAIL PASS FAIL Need to improve the regression process
and code review.
PASS FAIL PASS Expected result to say defect fixes work
properly.
FAIL FAIL FAIL Need to analyze why defect fixes are not
working.
PASS (with a FAIL Analyze the Workaround also need a good review as
work workaround and it they can also create side effects.
around) satisfied, mark
result as PASS
PASS PASS PASS It give a comfort feeling that there are
no side effects due to defect fixes.

3
2. Scenario Testing

Scenario testing is done to make sure that the end to end functioning of software is working fine, or all
the business process flows of the software are working fine. In scenario testing the testers put
themselves in the end users shoes and figures out the real world scenarios or use cases which can be
performed on the software by the end user. In scenario testing, testers take assistance from clients,
stakeholders and developers to create test scenarios.

Scenario testing helps testers to explore how the software will work in the hands of an end user. Since
scenario testing tests the business flow of the software, it helps in finding lot of defects which cannot be
found with other types of testing.

Scenario testing is done by creating test scenarios which replicate the end users usage. A test scenario
can be a independent test case or a series of test cases that follow each other. Test scenario is just a
story which explains the usage of the software by any end user.

Scenario testing is a software testing technique that makes best use of scenarios. Scenarios help a
complex system to test better where in the scenarios are to be credible which are easy to evaluate.

Methods in Scenario Testing:

 System scenarios
 Use-case and role-based scenarios

(i) System scenarios

It is method where by set of activities used for scenario testing covers several components in the
system. The following approaches used to develop system scenarios are:

Story line: Develop a story line that combines various activities of the product that may be executed by
an end user.
Life cycle/State transition: Define the object, derive the different transitions/modifications that
happen to the object and derive the scenario to cover them.
Deployment/Implementation stories from Customer: Develop a scenario from a known customer
deployment/implementation details and create a set of activities by various users in that
implementation.
Business Verticals: Visualize how the product/software will be applied to different verticals and create
a set of activities as scenarios to address specific vertical businesses.
Battle ground: Create some scenario to justify that “the product works” and some scenarios to “try and
break the system” to justify “the product doesn’t work”.

(ii) Use-case and role-based scenarios

It is stepwise procedure on how a user intends to use a system with diffract user roles and associated
parameters. It includes stories, pictures and deployment details. It is useful for explaining customer
problems and how the software can solve the problems without ambiguity.

To explain the concept of use case scenarios, let us take the example of withdrawing cash from a bank.
A customer fills up a check and give sit to an official in the bank, The official verifies the balance in the
account from the computer and the required cash to the customer. In this example, the customer is an

4
actor, the clerk is an agent and the response given by the computer which gives the balance in the
account is called the system response.

Strategies to Create Good Scenarios:

 Enumerate possible users their actions and objectives
 Evaluate users with hacker's mindset and list possible scenarios of system abuse.
 List the system events and how does the system handle such requests.
 List benefits and create end-to-end tasks to check them.
 Read about similar systems and their behavior.
 Studying complaints about competitor's products and their predecessor.

Scenario Testing Risks:

 When the product is unstable, scenario testing becomes complicated.
 Scenario testing are not designed for test coverage.
 Scenario tests are often heavily documented and used time and again

Importance of Scenario Testing

As you know that exhaustive testing of any software application is not possible because of the following
reasons:
 Large number of data combinations.
 Large number of possible paths in software.

It is because of this fact you always prioritize your testing efforts and focus on the most important areas,
for that you use techniques like Boundary value analysis(BVA), Equivalence partitioning(EP), Risk
based testing etc. however these techniques still do not guarantee bug free product. By scenario testing
you figure out the most important end-to-end transactions or the real use of the software applications
which ensures that the software is working for the most common user scenarios. It helps in finding lot
of defects which cannot be found with other types of testing. Scenario testing is very important for
complex transactions and for studying end-to-end functioning of the program.

Scenario testing example

Let us take an example of Hospital Management System to explain the importance of scenario testing.
Nowadays whenever you go to some hospital the patients records are maintained using HMS(Hospital

5
Management System) software. This software system manages both outpatient and inpatient records.
Outpatients leave hospital on the same day, however inpatients are admitted in hospital and treated for
more number of days before being discharged from hospital. Now let us take a scenario where one
outpatient comes to hospital to consult bone doctor for pain in his leg. His entry is made in HMS as
outpatient and all his previous medical history is entered in HMS. After few minutes he suddenly feels
acute chest pain and needs to be admitted in hospital, after being admitted to hospital his entry is now
changed from outpatient to Inpatient. But after making this change the doctor finds that he is not able to
get any previous history of this patient, ideally the outpatient history of that patient should be available
even after changing the outpatient status to Inpatient, this happened because the HMS system fails in
this scenario (When OPD patients status is changed to Internal patient).

3. Defect bash elimination

Defect bash is an ad hoc testing where people performing different roles in an organization test the
product together at the same time. The testing is not based on written test cases. It depends on
individual’s decision and creativity. It provides some of the practices such as:
(i) Enabling people
(ii) Bringing different people performing different roles together in the organization for testing
(iii) Letting everyone in the organization use the product before delivery
(iv) Bringing fresh pairs of eyes to uncover new defects
(v) Bringing in people who have different levels of product understanding to test the product
together randomly
(vi) Let testing doesn’t wait for lack of time taken for documentation
(vii) Enabling people to say “system works” as well as enabling them to “break the system”

All the activities in the defect bash are planned activities except for what to be tested. It involves several
steps. They are:

Step1: Choosing the frequency and duration of defect bash

Defect bash is an activity involving large amount of effort and an activity involving huge planning.
Frequent defect bashes will incur low return on investment, and too few defect bashes may not meet the
objective of finding all defects. Duration is also an important factor. Optimizing small duration is a big
saving as a large number of people involved. On the other hand, the amount of testing is done may not
meet the objective.

Step2: Selecting the right product build

Defect bash involves large number of people, effort and planning, a good quality build is needed for
defect bash. When a large number of people are involved, a good quality product build gives confidence
on the product and progress.

Step3: Communicating the objective of each defect bash to everyone

Defect bash involves people performing different roles, the contribution they make has to be focused
towards meeting the purpose and objective of defect bash. The objective is to find a large number of
uncovered defects or finding out system requirements or finding the non-producible or random defects,
which could be difficult to find through other planned tests.

6
Step4: Setting up and monitoring the lab for defect bash
It makes sense to setup and monitor a laboratory. Finding out the right configuration, resources are
activities that have to be planned carefully before a bash actually starts. The majority of defect bash fail
due to inadequate hardware, wrong configuration and perceptions related to performance and
scalability of the software. During defect bash, the product parameters and system resources need to be
monitored for defects and also corrected so that users can continue to use the system for the complete
duration of defect bash.

Step5: Taking actions and fixing issues

This is to take necessary corrective actions after the defect bash. Getting a large number of defects from
users is the purpose and also the normal end result from a defect bash. Many defects could be duplicate
defects. However, different interpretations of the same defect by different users, and the impact of the
same defect showing up differently in different places, make them difficult to be called duplicates.

Step6: Optimizing the effort involved in defect bash

There are several ways to optimize the effort involved in a defect bash if a record of objectives and
outcome is kept. Having a test build, keeping the right setup, sharing the objectives and so on, to save
effort and meet the purpose. To reduce the effort, conduct micro level defect bashes before conducting
one on a large scale. A defect bash can be classified into three types such as
 Feature/Component defect bash
 Integration defect bash
 Product defect bash

4. Acceptance Testing

Acceptance Testing is a level of the software testing process where a system is tested for acceptability.
It is done by the customer which defines a set of test cases that will be executed by the customer
themselves to check the quality of the product before deciding to buy the product. Acceptance test cases
are developed jointly by the customers and product organization. In this case, the product organization
will have complete understanding of what will be tested by the customer for acceptance testing. The
purpose of this test is to evaluate the system’s compliance with the business requirements and assess
whether it is acceptable for delivery.

Acceptance Criteria
 Acceptance Criteria – Product Acceptance
 Acceptance Criteria – Procedure Acceptance
 Acceptance Criteria – Service Level Acceptance

7
(i) Acceptance Criteria – Product Acceptance
During the requirement phase, each requirement is associated with acceptance criteria. It is possible
that one or more requirements may be mapped to form acceptance criteria. Whenever there are
changes to requirements, the acceptance criteria are accordingly modified and maintained.

(ii) Acceptance Criteria – Procedure Acceptance

It can be defined based on the procedures followed for delivery. Some examples are:
 User, administration and troubleshooting documentation should be part of the release.
 Along with binary code, the source code of the product with builds scripts to be delivered in a CD.
 A minimum of 20 employees are trained on the product usage prior to deployment.

(iii) Acceptance Criteria – Service Level Acceptance

It can become part of acceptance criteria. These are generally part of a contract signed by the customer
and product organization. Some examples are:
 All major defects that come up during first three months of deployment need to be fixed free of
cost.
 Downtime of the implemented system should be less than 0.1%
 All major defects are to be fixed within 48 hours of reporting.

Selecting test Cases for Acceptance Testing

1. End-to-End functionality verification
2. Domain tests
3. User Scenario Tests
4. Basic Sanity Test
5. New Functionality
6. A few non-functional tests
7. Test pertaining to legal obligations and Service Level Agreements
8. Acceptance test data

5. Internationalization testing

 It is a type of non-functional testing.

 Internationalization is a process of designing a software application so that it can be adapted to
various languages and regions without any changes.
 Whereas Localization is a process of adapting internationalized software for a specific region or
language by adding local specific components and translating text.

(i) Primer on internationalization

Definition of languages
A language is a tool used for communication. Internationalization focus on human languages and not on
computer languages.

Character Set
The purpose is to define a detailed understanding of how exactly each character is represented and the
knowledge of internals is not required for understanding. Some examples are:

8
  ASCII
The American Standard Code for Information Interchange (ASCII) a character-encoding scheme
originally based on the English alphabet that encodes 128 specified characters - the numbers 0-9, the
letters a-z and A-Z, some basic punctuation symbols, some control codes that originated with Teletype
machines, and a blank space - into the 7-bit binary integers.
 Double –Byte Character Set (DBCS)
A double-byte character set (DBCS) is a character encoding in which either all characters (including
control characters) are encoded in two bytes, or merely every graphic character not representable by an
accompanying single-byte character set (SBCS) is encoded in two bytes (Han characters would generally
comprise most of these two-byte characters). A DBCS supports national languages that contain a large
number of unique characters or symbols (the maximum number of characters that can be represented
with one byte is 256 characters, while two bytes can represent up to 65,536 characters).
 Unicode
It is a mechanism used to represent all the characters of all languages in the world. The characters for
all the languages need to be stored, interpreted and transmitted in a standard way. Unicode provides a
unique number to every character no matter what platform, program or language.

Locale
A locale is a set of parameters that defines the user's language, country and any special variant
preferences that the user wants to see in their user interface. Usually a locale identifier consists of at
least a language identifier and a region identifier.

Terms
 Internationalization (I18n) - Internationalization (sometimes shortened to "I18N , meaning "I -
eighteen letters -N") is the process of planning and implementing products and services so that
they can easily be adapted to specific local languages and cultures
 Localization (L11n)- Language localization is the process of adapting a product that has been
previously translated into different languages to a specific country or region. The aim of
localization is to give a product the look and feel of having been created for the target market and
to eliminate, or at least minimize, local sensitivities.
 Globalization (G13n)- Globalization (or globalization) is the process of international integration
arising from the interchange of world views, products, ideas, and other aspects of culture.

(ii) Test Phases

9
Some of the aspects are:
 Testing the code for how it handles input, strings, and sorting items
 Display of messages for various languages
 Processing of messages for various languages and conventions

1. Enabling testing
It is a white box method which is done to ensure that the source code used on the software allows
internationalization. An activity of code review or code inspection mixed with some test cases for unit
testing, with an objective to catch I18n defects is called enabling testing. The checklists are:
 Check the code for hard coded date, currency formats, ASCII code or character constant.
 Check the code to see that there are no computations done on date variables
 Check the dialog boxes and screen to see whether they leave at least 05 times more spaces for
expansion
 Ensure that no string operations are performed in the code.
 Ensure that adequate size is provided for buffers and variables to contain translated messages.
 Ensure that all the messages are documented along with usage contents.
 Ensure that all the resources are separated from the code stored in resource files.
 All messages are understood even by the least experienced user of the product.

Fig – Reading and scrolling direction

2. Locale testing
Changing the different locales using the system settings, or environment variables, and testing the
software functionality, number, date, time and currency format is called locale testing. Whenever a
locale is changed, the tester needs to understand the changes to software functionality. It requires
knowledge of code enabling. If the code is not enabled correctly, each and every feature of the product
with each locale has to be tested. The checklists are:
 All the features are tested with different locales of the software for which they are intended.
 Hot keys, function keys, and help screens are tested with different applicable locales.
 Currency, Number, Date and time format are tested with different locales.

3. Internationalization Validation
It is performed with following objectives:
 The software is tested for functionality with ASCII, DBCS and European Characters.
 The software handles string operations, sorting, sequencing operations as per the language and
character selected.
 The software display is consistent with characters.

10
  The software messages are handled properly.
The checklists are:
 The functionality in all languages and locales are the same.
 Sorting and sequencing the items to be as per the conventions of language and locale.
 The input can be non-ASCII or special characters.
 The characters are displayed as it enters.
 The cut copy paste features retain after pasting.

4. Fake language testing

It uses software translator to catch the translation and localization issues early. It also ensures that
switching between languages works properly and correct messages are picked up from proper
directories that have the translated messages. Fake language testing helps in identifying the issues
proactively before the product is localized. For this purpose, all messages are consolidated from the
software, and fake language conversions are done by tools and tested. It uses English-like target
languages, which are easy to understand and test. This type of testing helps English testers to find the
defects that may otherwise be found only by language experts during localization testing. The
checklists are:
 Ensure software functionality is tested for at least one of the European single byte fake language.
 Ensure software functionality is tested for at least one double byte fake language.
 Ensure all strings are displayed properly on the screen.
 Ensure that screen width, size of pop-ups, and dialog boxes are adequate for string display with
the fake language.

5. Language Testing
It is short form of “Language Compatibility Testing”. This ensures that software created in English can
work with platforms and environments that are English and non-English. This testing is done to ensure
that the functionality of software is not broken on other language settings and it is still compatible. The
checklists are:
 Check the functionality on English, one non-English, and one double byte language platform
combination.
 Check the performance of key functionality on different language platforms and across different
machines connected in the network.

11
6. Localization testing
Localization is a very expensive and labor-intensive process. Not all the messages that belong to the
software need to be translated. Some of the messages could be for administrators and developers and
may not be for the target users. Such messages need not be translated and should be excluded from the
file used for translation. While translating, not only the messages but also resources such as GUI
screens, dialog boxes, icons, bitmaps, need to be included for localization as resizing and customization
are needed to fit in the translated messages. The checklists are:
 All the messages, documents, pictures, screens are localized to reflect the native users and the
conventions of the country, locale and language.
 Sorting and case Conventions are right as per language convention.
 Font sizes and hot keys are working correctly in the translated messages, documents and screens
 Filtering and searching capabilities of the software work as per the language and locale
conventions.
 Addresses, phone numbers, numbers and postal code in the localized software are as per the
conventions of the target user.

Fig – Sorting in English and Spanish

12
6. Ad hoc Testing

Ad hoc testing is a commonly used term for software testing performed without planning and
documentation (but can be applied to early scientific experimental studies). The tests are intended to be
run only once, unless a defect is discovered. Ad hoc testing is the least formal test method. As such, it
has been criticized because it is not structured and hence defects found using this method may be
harder to reproduce (since there are no written test cases). However, the strength of ad hoc testing is
that important defects can be found quickly.

Testing is carried out with the knowledge of the tester about the application and the tester tests
randomly without following the specifications/requirements. Hence the success of Ad hoc testing
depends upon the capability of the tester, who carries out the test. The tester has to find defects
without any proper planning and documentation, solely based on tester's intuition.

When to Execute Ad hoc Testing?

Ad hoc testing can be performed when there is limited time to do exhaustive testing and usually
performed after the formal test execution. Ad hoc testing will be effective only if the tester has in-depth
understanding about the System under Test.

The major benefits of ad-hoc testing are:

1. No planning and documentation needed. It can be added successfully during beginning of the
project, mid or before release of the product.
2. The important bugs are found which helps you in discovering missing test cases - can find holes
in your original testing strategy that can be incorporated later.
3. Gives more understanding of how a software application or feature behaves which may not be
known by reviewing specification documents or use cases.
4. Gives better understanding of the testing priorities, for example if an ad-hoc test runs very well,
you can decide testing in that area can be deferred to the later stage.
5. Easy to start and Implement.
6. It helps to save a lot of precious time. Sometimes its after spending valuable time on preparing
and explaining tests that the programs design is changed. With Ad-hoc testing precious time is
not wasted on planning and documents.

Some of the issues faced by planned testing are as follows:

 Lack of clarity in requirements and other specifications
 Lack of skills for doing the testing
 Lack of time for test design
13
Drawbacks and their resolution

Drawbacks Possible Resolution

Difficult to ensure that the learning gleaned in Document ad hoc tests after test completion.
ad hoc testing are used in future.
Large number of defects found in ad hoc
testing.
Lack of comfort on coverage of ad hoc testing
Difficult to track the exact steps.
Lack of data for metric analysis.
 Schedule a meeting to discuss defect
impacts.
 Improve the test cases for planned
testing.
 When producing test reports combine
planned test and ad hoc test
 Plan for additional planned test and ad
hoc test cycles.
 Write detailed defect reports in a step
by step manner.
 Document ad hoc tests after test
execution.
Plan the metrics collection for both planned
tests and ad hoc tests.

Types of Ad hoc Testing

 Buddy testing
 Pair Testing
 Exploratory testing
 Iterative testing
 Agile and Extreme testing

1. Buddy Testing
Two buddies mutually work on identifying defects in the same module. Mostly one buddy will be from
development team and another person will be from testing team. Buddy testing helps the testers
develop better test cases and development team can also make design changes early. This testing
usually happens after unit testing completion.

When NOT to use Buddy testing:-

1. The product needed or should go under automation testing; another team member is not needed.
2. If the character set, behavior or attitude of the two members doesn’t match then the testing
shouldn’t be done in pair as it may create conflict.
3. If there are only structured test cases, then only one tester will suffice.
And in many cases where one man power is sufficient, the pair testing is not needed.

Advantages of Buddy testing:-

1. Here if the developer and a tester are paired together then the developer can learn a better
approach to the built and the tester also can learn the functionality from better angle.
2. There are many random bugs occurs during testing which are tough to reproduce, but if a tester
and developer are paired together then developer can catch the link of this type of random bugs at
once. This may save a lot of time. The tester doesn’t have to waste time in reproducing the issue

14
 and doesn’t need to capture screenshots. Direct and immediate communication leads to the faster
fixation.
3. Both developer and tester will work to their best due to the presence of each other.
4. Developer can mark his/her mistakes, so that they can be efficient and optimized in future.
5. Work load will be less in presence of another team member’s help, so, the tester can think clear
and use maximum scenarios in to his/her benefit.
6. Work will be fun and enjoyable.

Getting started with Buddy Testing (How to set up):-

 First choose a developer/tester who you trust or you know him better or his attitude and
character set matches with you. It is a very vital point of Pair Testing as it has high impact on the
efficiency.
 Make a plan of approach, have a short meeting before and make schedule. A good start without
any holding back is needed.
 As both of the team members have to use one machine, and then the environment should be
chosen carefully. Both the members should feel comfortable and free to talk to each other without
any disturbance nor creating disturbance for others.
 Project also does matters while applying this type of testing. The project should be of appropriate
size. Pair testing shouldn’t be done efficiently on very big or whole project. Pair testing works well
when testing new functionality and when both participants have been working on the project
since inception.

2. Pair Testing
Pair testing is a software development technique in which two team members works together at one
keyboard to test the software application. One does the testing and the other analyzes or reviews the
testing. This can be done between one tester and developer or business analyst or between two testers
with both participants taking turns at driving the keyboard. This will help both the members to learn
more about the application. This will narrow down the root cause of the problem while continuous
testing. Developer can find out which portion of the source code is affected by the bug. This track can
help to make the solid test cases and narrowing the problem for the next time.

Benefits
 The developer can learn more about the software application by exploring with the tester.
The tester can learn more about the software application by exploring with the developer.
 Less participation is required for testing and for important bugs root cause can be analyzed very
easily. The tester can very easily test the initial bug fixing status with the developer.
 This will make the developer to come up with great testing scenarios by their own

Drawbacks
 Teaming up individual high performers may lead to problems
 It may not produce desire results, who one person take the lead and other has a laidback
attitude.
 One person do not try to understand and respect each other, it may be lead to frustration and
domination.
 The speed of understanding and execution does not match, result in loss of attention.
 It may result in delays due to the time spent on interactions with testers.

15
  Pairing up juniors with experienced one may result in the former doing tasks that the senior may
not want to do.
 No accountability on who is responsible for steering the work, providing direcions, and
delivering the results.

Usage
This is more applicable where the requirements and specifications are not very clear, the team is very
new, and needs to learn the application behavior quickly.

Characteristics of Pair Testing

 Testing is an open-ended defect hunting process. Pair Testing will generate more effective test
cases quickly and cheaply.
 Forming testers in pairs will enable test managers to gather performance of the testers within
the group.
 Pair Testing is the best approach for mentoring and training the newbies in the team.
 Testing in pairs generates a positive energy within the team with increased coordination.
 Pair the domain expert with a novice tester to develop domain knowledge within the team.

3. Exploratory Testing
Exploratory testing is an approach to software assessment that integrates learning about the program
with designing the test and conducting the testing processes. The simultaneous process ensures that
developers have a more comprehensive understanding of how it should work and create more effective
tests and, as a result, be better equipped to find problems.

Advantages
 It doesn’t require preparation for testing as we don’t have documents for testing.
 In this type of testing time saves due to all task are doing simultaneously like Testing, Designing
test scenarios and executing test scenarios.
 Tester can report many issues due to incomplete requirement or missing requirement document.

Disadvantages
 Few issues cannot be catch in this type of testing.
 There is review of test planning & designing of test cases/scenario while testing may cause
issues.
 Testers have to remember the scenario what he is executing because if any bug is found then
tester should report a bug with proper steps to reproduce Difficulty to perform the exact
manner especially for new found bugs.

Techniques:

1. Guesses: It is sued to find the part of the program that is likely to have more errors. Previous
experience on working with a similar product or software or technology helps in guessing.
2. Architecture diagrams and use cases: It depicts the interactions and relationships between
different components and modules. Use cases give an insight of the product’s usage from the end
user’s perspective. It explains a set of business events, the input required, people involved in
those events and the expected output. Exploration technique may use these diagrams and use
cases to test the product.

16
 3. Guesses: It is sued to find the part of the program that is likely to have more errors. Previous
experience on working with a similar product or software or technology helps in guessing.
4. Architecture diagrams and use cases: It depicts the interactions and relationships between
different components and modules. Use cases give an insight of the product’s usage from the end
user’s perspective. It explains a set of business events, the input required, people involved in
those events and the expected output. Exploration technique may use these diagrams and use
cases to test the product.
5. Past defects: Studying the defects reported in the previous releases helps in understanding of
the error phone functionality/modules in a product development environment. Defect reports of
the previous releases act as a explore an area of the product further.
6. Error handling: It is a portion of the code which prints appropriate messages or provides
appropriate actions in case of failures.
7. Discussions: It is based on the understanding of the product from discussions. Exploration may
be planned based on the understanding of the system during project discussions or meetings.
Plenty of information can be picked up during these meetings regarding implementation of
different requirements for the product.
8. Questionnaires and Checklists: The last technique uses Questionnaires and Checklists to
perform the exploration. Questions like “what, when, how, who and why” can provide leads to
explore areas in the product. To understand the implementation of functionality in a product,
open ended questions like “what does this module do” “when is it being called or used”, “how is
the input processed”, who are the users of this module” and so on can be asked. Such questions
will provide insights to what more can be tested.

4. Iterative testing
 The iterative model is where the requirements keep coming and the product is developed
iteratively for each requirement. The testing associated for this process is called iterative testing.
One of the biggest challenges is to ensure that all the requirements that are tested continue to
work when a new requirement is given.
 Hence, iterative testing requires repetitive testing. When a new requirement or a defect fix is
done, it may have an impact on other requirements that have already been tested.
17
  As the new requirements may involve a large number of changes at the product level, the
majority of these tests are executed manually because automation in this case is very difficult. It
aims at testing the product for all requirements, irrespective of the phase they belong to in the
spiral model.

 A test plan is created at the beginning of the first iteration and updated for every subsequent
iteration. This can be define the type and scope of testing to be done for each of the iterations.
This is because the product goes through a series of iterations and the testing time for the later
iterations increases substantially.
 Also, some of the tests that are performed in later iterations may not be possible to perform
during earlier iterations. Since iterative testing involves repetitive test execution that were run
for the previous iterations.

5. Agile and extreme testing

It takes the processes to the extreme to ensure that customer requirements are met in a timely manner.
In this model, customers partner with the project teams to go step by step in bringing the project to
completion in a phased manner. The customer becomes part of the project team so as to clarify any
doubts/questions. Agile and XP methodology emphasizes the involvement of the entire team, and their
interactions with each other, to produce workable software that can satisfy a given set of features. As a
result of such iterations, all ideas are exchanged.

XP work flow

18
There are different steps involved in following the XP methodology. It presents the process flow for a XP
product release. The different activities involved in XP work flow are a s follows:
1. Develop and understand user story
2. Prepare acceptance tests
3. Test plan and estimation
4. Code
5. Test
6. Refactor
7. Automate
8. Accepted and Delivered

6. Alpha and Beta Testing

Alpha Testing Beta Testing (Field Testing)

1. It is always performed by the developers at 1. It is always performed by the customers at
the software development site. their own site.
2. Sometimes it is also performed by 2. It is not performed by Independent Testing
Independent Testing Team. Team.
3. Alpha Testing is not open to the market and 3. Beta Testing is always open to the market
public and public.
4. It is conducted for the software application 4. It is usually conducted for software
and project. product.
5. It is always performed in Virtual 5. It is performed in Real Time Environment.
Environment.
6. It is always performed within the 6. It is always performed outside the
organization. organization.
7. It is the form of Acceptance Testing. 7. It is also the form of Acceptance Testing.
8. Alpha Testing is definitely performed and 8. Beta Testing (field testing) is performed
carried out at the developing organizations and carried out by users or you can say
location with the involvement of developers. people at their own locations and site using
customer data.
9. It comes under the category of both White 9. It is only a kind of Black Box Testing.
Box Testing and Black Box Testing.
10. Alpha Testing is always performed at the 10. Beta Testing is always performed at the
time of Acceptance Testing when developers time when software product and project are
test the product and project to check whether marketed.
it meets the user requirements or not.
11. It is always performed at the developer’s 11. It is always performed at the user’s
premises in the absence of the users. premises in the absence of the development
team.
12. Alpha Testing is not known by any other 12 Beta Testing is also known by the name
different name. Field Testing means it is also known as field
testing.
13. It is considered as the User Acceptance 13. It is also considered as the User
Testing (UAT) which is done at developer’s Acceptance Testing (UAT) which is done at
area. customers or users area.
19
9. Testing of OO(Object oriented) Systems

Testing of OO software is different from testing software created using procedural languages.
Several new challenges are posed. In the past most of the methods for testing OO software was just a
simple extension of existing methods for conventional software. Testing is conducted at 3 levels:
Unit, Integration and System. At the system level there is no difference between the testing
techniques used for OO software and other software created using a procedural language, and hence,
conventional techniques can be used. This tool provides features for testing at Unit (Class) level as
well as Integration level. Further a maintenance-level component has also been incorporated.
Results of applying this tool to sample Rational Rose files have been incorporated, and have been
found to be satisfactory.

The objectives of developing the Testing Tool for software testers and maintainers are:
(1) to help them understand the structures of, and relations between, the components of an OO
program
(2) to give them a systematic method and guidance to perform OO testing and maintenance
(3) to assist them to find better test strategies to reduce their efforts
(4) to facilitate them to prepare test cases and test scenarios , and
(5) to generate test data and to aid them in setting up test harnesses to test specific components.

Problem and Challenges

The object-oriented paradigm has set of testing and maintenance problems. The inheritance,
aggregation and association relationships among the object classes make an OO program difficult to
test. The encapsulation and information hiding features result in chains of member function
invocations that often involve objects of more than one class. The problems for software testing are:
1. It is difficult to understand the code and prepare the test cases.
2. It is not cost-effective to construct test stubs for member functions since most of them consist of
one to two statements. Rather, one would just use them provided that they have been tested.
3. It is necessary to determine and limit the required regression tests when a function or a class is
changed.
4. It requires a fresh look into the traditional coverage criteria and to extend them to include not just
coverage of individual functions, but also invocation sequence, object stated and state sequences,
and data definition and use path across functions and objects.

20
Differences in OO Testing
 Unit Testing a Class
 Putting Classes to work together
 System testing
 Regression testing
 Tools for testing OO Systems

(i) Unit Testing a Class

Classes are the building blocks for an entire OO system. Just as the building blocks of a procedure
oriented system have to be unit tested individually before being put together, so also the classes
have to be unit tested.

Why Classes have to be tested individually first?

 A class is intended for heavy reuse.
 Many defects get introduced at the time ac class gets defined.
 A class may have different features; different clients of the class may pick up different pieces
of the class. No one single class may use all the pieces of the class. Thus unless the class is
tested as a unit first, there may be pieces of a class that may never get tested.
 A class is a combination of data and methods. If the data and methods do not work in sync at
a unit test level, it may cause defects that are potentially very difficult to narrow down later
on.
 It has special feature called ‘inheritance’ which put more ‘context’ into the building blocks.

Methods that apply to testing classes

 Every class has certain variables.
 Not all methods are exercised by all the clients.
 Every class will have methods that have procedural logic.

Some of the criteria that can be used for testing are:

 Is every state reached at least once?
 Is every message generated and tested?
 Is every state transition achieved at least once?
 Are illegal state transitions tested?

Special considerations for testing classes

 Test the object through its life cycle from ‘birth to death’ (that is from instantiation to
destruction)
 Test the simple methods first and then the more complex methods.
 Test the methods from private through public methods.
 Send a message to every method at least once. This ensures that every method is tested at
least once.

Steps
1. Test the constructor method first.
2. Test the get method or accessor methods.
3. Test the methods that modify the object variables.
4. Finally, the object has to be destroyed and when the object is destroyed.
21
(ii) Putting Classes to work together- Integration testing
OO systems are designed to be made up of a number of smaller components or classes that are meant to
be reused. Testing the classes work together becomes the next step, once the basic classes themselves
are found to be tested thoroughly. It is not an individual class that is tested individually as a unit, but a
collection of related classes that always go together. In an OO system, the way in which the various
classes communicate with each other is through messages.

A message of the format

<instance name> . <method name> . <variables>
calls the method of the specified name, in the named instance, or object with the appropriate variables.
The name of the method does not uniquely identify the control flow while testing an OO system.
Methods with the same name perform different functions. The points to be noted about integration
testing OO systems are that:
 OO system inherently meant to be built out of small, reusable components. Hence integration
testing is more critical for OO systems.
 There is typically more parallelism in the development of the underlying components of OO
systems; thus the need for frequent integration is higher.
 Given the parallelism in development, the sequence of availability of the classes will have to be
taken into considerations while performing integration testing.

(iii) System Testing and Interoperability of OO systems

A class may have different parts, not all of which are used at the same time. When different clients start
using a class, they may be using different parts of a class and this may introduce defects at a later phase.
Different classes may be combined together by a client and this combination may lead to new defects
that are uncovered. An instantiated object may not free all its allocated resources, thus causing memory
leaks and such related problems, which will show up only in the system testing phase.

The classes and objects interoperate and work together as a system. Since, the complexity of
interactions among the classes can be substantial, it is important to ensure that proper unit and
component testing is done before attempting system testing. Thus proper entry and exit criteria should
be set for the various test phases before system testing so as to maximize the effectiveness of system
testing.

(iv) Regression Testing of OO Systems

Regression testing is very crucial for OO systems. As a result of the heavy reliance of OO systems on
reusable components, changes to any one component could have potentially unintended side effects on
the clients that use the component. Hence, frequent integration and regression runs become very
essential for testing OO system. It makes sense to catch the defects as early as possible.

(v) Tools for testing OO systems

There are several tools that aid in testing OO systems. Some of these are:
 Use cases
 Class diagrams
 Sequence diagrams
 State charts

22
Use cases
A use case is a list of steps, typically defining interactions between a role (known in Unified Modeling
Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human, an external
system, or time. A use case diagram at its simplest is a representation of a user's interaction with the
system and depicting the specifications of a use case. A use case diagram can portray the different types
of users of a system and the various ways that they interact with the system. This type of diagram is
typically used in conjunction with the textual use case and will often be accompanied by other types of
diagrams as well.

Class diagrams
A class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that
describes the structure of a system by showing the system's classes, their attributes, operations (or
methods), and the relationships among objects.

The class diagram is the main building block of object oriented modelling. It is used both for general
conceptual modelling of the systematics of the application, and for detailed modelling translating the
models into programming code. Class diagrams can also be used for data modeling.[1] The classes in a
class diagram represent both the main objects, interactions in the application and the classes to be
programmed.

A class with three sections.

In the diagram, classes are represented with boxes which contain three parts:
 The top part contains the name of the class. It is printed in Bold, centered and the first letter
capitalized.

23
  The middle part contains the attributes of the class. They are left aligned and the first letter is
lower case.
 The bottom part gives the methods or operations the class can take or undertake. They are also
left aligned and the first letter is lower case.

In the design of a system, a number of classes are identified and grouped together in a class diagram
which helps to determine the static relations between those objects. With detailed modelling, the
classes of the conceptual design are often split into a number of subclasses.

Sequence diagrams
A 'Sequence diagram' is an interaction diagram that shows how processes operate with one another and
in what order. It is a construct of a Message Sequence Chart. A sequence diagram shows object
interactions arranged in time sequence. It depicts the objects and classes involved in the scenario and
the sequence of messages exchanged between the objects needed to carry out the functionality of the
scenario. Sequence diagrams are typically associated with use case realizations in the Logical View of
the system under development. Sequence diagrams are sometimes called event diagrams, event.

State charts
The name of the diagram itself clarifies the purpose of the diagram and other details. It describes
different states of a component in a system. The states are specific to a component/object of a system.
A State chart diagram describes a state machine. Now to clarify it state machine can be defined as a
machine which defines different states of an object and these states are controlled by external or
internal events.

24
 10. Usability Testing

Usability testing provides quantitative and qualitative data from real users performing real tasks
with a product. Usability professionals can evaluate some aspects of accessibility by using standard
usability testing protocols, with a few modifications for including participants with disabilities.
While usability testing evaluates how usable accessibility solutions are by some people with
disabilities, usability testing can't address all accessibility issues and doesn't evaluate conformance
to accessibility standards.

Detailed guidance on usability testing with participants with disabilities in the following sections:
 Planning Usability Testing covers determining participant characteristics, recruiting
participants, choosing the best location, and scheduling the right amount of time.
 Preparing for Usability Testing covers ensuring the facility is accessible, preparing test materials,
setting up and testing participants' configurations, becoming familiar with the assistive
technology, and conducting pilot testing.
 Conducting Usability Testing covers setting up the room, orienting the participant, completing
paperwork, completing the tasks, collecting data, providing compensation, and specific
considerations for people with different disabilities.
 Reporting Usability Testing covers distinguishing between accessibility and usability issues,
including relevant study parameters, being careful about categorizations and comparisons,
clarifying conclusions, and writing about people with disabilities.
 Checklist for Usability Testing summarizes the tasks and considerations involved in planning,
preparing for, conducting, and reporting usability studies with participants with disabilities.
 Recruiting Screener lists question to ask during recruiting.

Why test with people with disabilities?

Interactive Accessibility recommends taking the next step beyond technical compliance with
accessibility standards and guidelines, to focus on the overall usability of your product. Usability testing
provides a number of benefits to:
 Increase your understanding of how people with disabilities use your website or application
25
  Maximize customer satisfaction – a user who easily accomplishes tasks is more satisfied
 Increase brand recognition
 Increase the number of site visitors
 Improve the experience for all users – usability improvements geared toward users with
disabilities often provide benefits to all users.

Usability Testing Deliverables

We provide, first, a usability test plan that describes in detail all the steps in the usability testing
process. After conducting the testing, we provide a detailed report including:
 Summary of findings, plus the full data gathered in all the tests. Data includes task times, success
rates, and satisfaction ratings for each test participant.
 Video of user testing to provide you with first-hand insights into the specific needs of people
with disabilities.
 List of recommendations on how to optimize the usability for people with disabilities;
recommendations may include coding samples as appropriate.
 Prioritization of recommendations to identify the most critical aspects to repair.

How we conduct accessibility usability testing

We apply industry-standard techniques for usability evaluations, including:
1. With input from your team, designing and preparing tasks for participants
2. Recruiting users with a range of disabilities, as suitable for the product – blind, low vision, motor
impaired, deaf and those with cognitive disabilities such as dyslexia and learning disabilities
3. Conduct a pilot test to identify any issues with the testing protocol
4. Conducting the testing either in a usability tab or through remote testing
5. Analyzing and prioritizing the findings, making recommendations

When can you conduct usability testing?

To be cost effective, we recommend first conducting an accessibility evaluation and correcting
accessibility issues before testing usability. After corrections are implemented, we test them with
individuals who have disabilities to identify specific ease-of-use challenges. Usability testing is verified
through several means. Some of them are:
 Style sheets
 Screen prototypes
 Paper designs
 Layout designs

Planning for Usability Testing

 Determining Participant Characteristics
 Identify a realistic range of participants
 Recruiting Participants
 Plan for additional recruiting.
 Make key contacts to find people with disabilities.
 Consider pilot tests as a recruiting tool.
 Add relevant information to your recruiting screener.
 Arrange for interpreters as needed.
 Plan to reimburse participants for necessary expenses.
26
  Choosing the Best Location
 Consider the goals of the usability test.
 Consider assistive technology needs.
 Take into account transportation.
 Evaluate the accessibility of potential locations.
 Scheduling the Right Amount of Time
 Use pilot tests to work out timing.
 Plan time based on specific disability considerations.
 Be aware of energy level considerations.
 Schedule time to confirm assistive technology setup.
 Plan time for the participant to become familiar with the product.

Preparing for Usability Testing

 Ensuring the Facility is Accessible
 Use a checklist to ensure that you've anticipated any potential barriers.
 Schedule a walkthrough by a person with similar accessibility needs.
 Provide enough space.
 Preparing Test Materials
 Write usability test materials in clear and simple language.
 Be prepared to provide all materials in alternative formats.
 Include alternate format questions in the recruiting screener.
 Send consent forms and other documents ahead of time.
 Provide consent forms and other documents for interpreters and attendants.
 Send materials to interpreters ahead of time.
 Setting Up and Testing the Participants' Configurations
 Acquire, set up, and test the assistive technologies to the participants' configurations.
 Becoming Familiar with the Assistive Technology
 Get experience with the assistive technology as appropriate.
 Conducting Pilot Testing
 Conduct pilot tests early.
 Use pilot tests for recruiting.
 Use pilot tests to work out timing.
 Use pilot tests to work out issues with assistive technologies.
 Use pilot tests to work out logistics.
 Use pilot tests to work out facilitation.

Conducting a Usability Test for Accessibility

 Setting Up the Room
 Check that the area is clear.

27
  Specific considerations for some participants who are blind or visually impaired
 Don't move anything without asking first.
 Record screen reader audio output.
 Watch the keyboard.
 Adjust video for wide-angle capture.
 Take speakers and lights.
 Specific considerations for some participants who are deaf or hearing impaired
 Arrange seating for an interpreter.
 Position seating for a direct line of sight.
 Be sure the room is well-lit.
 Record both participant and interpreter audio.
 Specific considerations for some participants who have physical impairments
 Allow enough room for a wheelchair.
 Orienting the Participant
 Encourage the participant to become familiar with the setup.
 Specific considerations for some participants who are blind or visually impaired
 Introduce yourself and others.
 Describe the setting to the participant.
 Explain unusual noises and your activities.
 Offer your elbow to lead the participant.
 Give directions about where to be seated.
 Don't interact with a guide dog or service animal.
 Tell the participant where there is room for the guide dog.
 Specific considerations for some participants who are deaf or hearing impaired
 Get the participant's attention before starting a conversation.
 Take turns talking.
 Be very clear that an interpreter should repeat just what you say.
 Specific considerations for some participants with physical impairments
 Don't move mobility aids.
 Remember seating for a personal attendant.

Completing Paperwork
 Specific considerations for some participants who are blind or visually impaired
 Provide documents in the participant's preferred format.
 Be prepared to indicate the place for signature.
 Specific considerations for some participants with physical impairments
 Have a clipboard available to hold documents to be signed.

Completing the Tasks

Be prepared to use alternative techniques for facilitating.

28
  Specific considerations for some participants who are blind or visually impaired
 Request screen reader speech rate according to usability test protocol.
 Specific considerations for some participants who are deaf or hard of hearing
 Face the participant while speaking, and speak at eye level.
 Speak clearly.
 Try rewording what you are saying.
 Offer to write down what you are saying.
 Move closer to the participant.

Collecting Data
Consider debriefing after each task instead of after the entire test.
 Specific considerations for some participants with speech impairments
 Listen carefully, and ask the participant to repeat for clarification if needed.
 Be prepared to offer to use written communication.
 Be very clear that an attendant should repeat exactly what the participant said.
 Specific considerations for some participants who are deaf or hard of hearing
 Be very clear that an interpreter should repeat just what the participant signs.

Providing Compensation
Specific considerations for some participants who are blind or visually impaired
 State what the currency is as you hand it to the participant, if you are paying in cash.
 Verify the spelling of the participant's name, if you are paying by check.

Reporting Usability Testing

 Distinguish Between Accessibility and Usability Issues
 Understand the difference between accessibility and general usability.
 Distinguish between usability and accessibility issues, as appropriate.
 Including Relevant Study Parameters
 Include relevant study details.
 Include relevant participant characteristics in the report, and don't include irrelevant
participant information.
 Being Careful about Categorizations and Comparisons
 Confirm that any categorizations are appropriate and useful.
 Confirm that any comparisons are appropriate and useful.
 Clarifying Conclusions
 Clearly indicate what the report asserts and what it does not assert.
 Writing about People with Disabilities
 Use appropriate language to refer to people with and without disabilities.

Quality factors for usability

 Comprehensibility

29
  Consistency
 Navigation
 Responsiveness

11. Accessibility Testing

Accessibility Testing is a subset of usability testing, and it is performed to ensure that the application
being tested is usable by people with disabilities like hearing, color blindness, old age and other
disadvantaged groups.
People with disabilities use assistive technology which helps them in operating a software product.

Why accessibility Testing?

Reason 1: Cater to market for Disabled People.
Reason 2: Abide by Accessibility Legislations
Reason 3: Avoid Potential Law Suits

Testing goals
 Set up and use the application without sighted assistance
 All task workflows in the application can be easily navigated using directional controls and
provide clear and appropriate feedback

Testing Requirements
The following tests must be completed in order to ensure a minimum level of application accessibility.
1. Directional controls: Verify that the application can be operated without the use of a touch
screen. Attempt to use only directional controls to accomplish the primary tasks in the
application. Use the keyboard and directional-pad (D-Pad) controls in the Android Emulator or
use gesture navigation on devices with Android 4.1 (API Level 16) or higher.
Note: Keyboards and D-pads provide different navigation paths than accessibility gestures.
While gestures allow users to focus on nearly any on-screen content, keyboard and D-pad
navigation only allow focus on input fields and buttons.
2. TalkBack audio prompts: Verify that user interface controls that provide information (graphics
or text) or allow user action have clear and accurate audio descriptions when TalkBack is
enabled and controls are focused. Use directional controls to move focus between application
layout elements.
3. Explore by Touch prompts: Verify that user interface controls that provide information
(graphics or text) or allow user action have appropriate audio descriptions when Explore by
Touch is enabled. There should be no regions where contents or controls do not provide an audio
description.
4. Touchable control sizes: All controls where a user can select or take an action must be a
minimum of 48 dp (approximately 9mm) in length and width, as recommended by Android
Design.
5. Gestures work with TalkBack enabled: Verify that app-specific gestures, such as zooming
images, scrolling lists, swiping between pages or navigating carousel controls continue to work
when TalkBack is enabled. If these gestures do not function, then an alternative interface for
these actions must be provided.
6. No audio-only feedback: Audio feedback must always have a secondary feedback mechanism to
support users who are deaf or hard of hearing, for example: A sound alert for the arrival of a

30
 message should also be accompanied by a system Notification, haptic feedback (if available) or
another visual alert.

Accessibility can be provided by two means:

 Basic Accessibility
 Product Accessibility

(i) Basic Accessibility

It is provided by the hardware and operating system. All the input and output devices of the computer
and their accessibility options are categorized under basic accessibility. Some of the types are:

 Keyboard Accessibility
 Strictly Keys - Sticky Keys is an accessibility feature to help Windows users who have
physical disabilities, but it is also used by others as a means to reduce repetitive strain injury
essentially serializes keystrokes instead of pressing multiple keys at a time: Sticky Keys
allows the user to press and release a modifier key, such as Shift, Ctrl, Alt, or the Windows
key, and have it remain active until any other key is pressed.
 Filter key - It is an accessibility function that tells the keyboard to ignore brief or repeated
keystrokes, in order to make typing easier for users with hand tremors.
 Toggle key sound - Toggle Keys is turned on (check mark in "Turn on Toggle Keys") but
there is no tone when pressing Caps Lock, Num Lock or Scroll Lock.
 Sound keys - Sound Keys fundamentally differs from the kframe generators that comes with
AE. They have their own palette, whereas Sound Keys is applied as a regular effect and key
frames are generated into its own output parameters and then linked with an expression.
 Arrow keys to control mouse - MouseKeys enables you to use the numeric keypad to
control the movement of the mouse pointer. If you want to use the numeric keypad for data
entry as well as for navigation, you can set MouseKeys to be activated by pressing Num Lock.
 Narrator - A narrative (or play) is any account of connected events, presented to a reader or
listener in a sequence of written or spoken words, or in a sequence of (moving) pictures.
 Screen Accessibility
 Visual Sound
 Enabling captions for multimedia
 Soft keyboard
 Easy reading with high contrast

(ii) Product Accessibility

It provides accessibility in the product through standards and guidelines is called product accessibility.
A good understanding of basic accessibility features and the requirements of different types users with
special needs helps in creating, certain guidelines on how the products user interface has to be
designed. These different requirements of different categories of users, their abilities and challenges
need to be kept in mind throughout while providing accessibility of the product.

Typical test cases for accessibility might look similar to the following examples -
 Make sure that all functions are available via keyboard only (do not use mouse)
 Make sure that information is visible when display setting is changed to High Contrast modes.
 Make sure that screen reading tools can read all the text available and every picture/Image have
corresponding alternate text associated with it.
 Make sure that product defined keyboard actions do not affect accessibility keyboard shortcuts.
31