L Comp at Ability User Interface Testing

8/3/2019 L Comp at Ability User Interface Testing

1/67

Testing Processsoftware testing


2/67

testing process

3.1 Configuration Testing

3.2 Compatibility Testing

3.3 Usability Testing

3.4 Testing the Documentation


3/67

3.1 Configuration testing

Overview

Approaching the task

Obtaining the hardware

Identifying hardware standars


4/67

Configuration testing

Ideally

all computer hardware are identical

everything would interface perfectly

Really

the are several different machines connected to thecomputer


5/67

Configuration testing

Configuration testing will make sure the software workswith as many as different hardware combination aspossible

Deal with generalities then moves into the specifichardware


6/67

Learn

Why configuration testing is necessary

Why configuration testing can be a huge job

A basis approach to configuration testing

How to Find the hardware you need to test with

What to do if you're not testing software for a desktopcomputer


7/67

overview

Consider the different configuration for standard PC

PC Several manufacturer using self designedcomponent; clone PC

Component various system board, componentcard, chipset,

Peripheral any devices that plug into the systems

Interface various types of interface were used toconnect component and peripheral

Device driver low level software used by thesystems to communicate with component andperipheral


8/67

isolating configuration bug

A software with a problem on a unique configuration

Who shold fix the bug? Your Team or hardwaremanufacturer?

bug under a broad class of configuration

bug specific only to one particular configuration

hardware have a bug that your software reveals

hardware have a bug that effect several othersoftware


9/67

Sizing up the job

Suppose a software work with very graphical, lots ofsound effect, allow multiple player and can be print thedetail

Need to concider configuration testing with different

graphic cards, sound cards,modems, printers

What happen if there are 336 possible graphic cards,210 sound cards, 1500 modems, and 1200 printers

total on bilions possibilties

You need equivalence partioning; reduce the huge setof possibilities to ones that matter most.


10/67

Approching the task

Not only about deciding what devices to test and howthey should be tested, but also what information to useto make the decision

Not about what and how but about why


11/67

Approching the task General process when planning configuration testing

decide what types of hardware are needed

decide what brands, models and drivers are available

decide which features, modes, and options arepossible

pare down into a manageable set

identify unique features that work

design the test cases to run on each configuration

Execute the test on each configuration

Rerun the test until satisf


12/67

obtaining the hardware

It would be expesive proposition to buy everything,especialy if you will only used it once for testing

Option

buy only the most often used

lend from the manufacturers

ask your friend favors beta tester

en ng ar are


13/67

en y ng ar warestandard

Knowing some details of the hardware specificationhelps you make equivalence partition decision

Get review, go to the websites, etc


14/67

3.2 Compatibility testing

Overview

Platform and Application Version

Standards and Guidelines

Data Sharing Compatibility

ibili i


15/67

compatibility testing

Costumer demand the ability to share data amongprograms of different types and from different vendor

Checking that your software operates correctly withother software

Previous Stand alone application

secific platform, isolate environment

Today Multi platform and multi user

import and export data, run on different OS, run onWeb browsers, interoperates with other software

l


16/67

learns

What means for software to be compatible How standards define compatibility

What platforms are and what the mean for compatibility

Why being able to transfer data among softwareapplications is the key to compatibility

i


17/67

overview

Software compatibility testing means checking that yoursoftware interacts with and shares information correctlywith other software

Occur between two program run simultaneously on

same machines Or on different computer through internet

tibl ft


18/67

compatible software

Copy text from web pages and paste it on wordprocessor

Saving you budget planning on accounting applicationand the loading it in spreadsheet program

Having one software running on different version ofyour OS

Upgrade to a new database program and having allyour existing databases work just as previousdatabases program

tibl ft


19/67

compatible software

What is compatible for your software?Word ProcessorfromCompany Mrunning onOperating SystemsW

NetworkImport/Export

Word ProcessorfromCompany Srunning onOperating SystemsL

SpradsheetfromCompany Grunning onWeb Browser

Cut, Copy, PasteFileImport/Export

FileLoad/Save

Q ti t


20/67

Question to answer

What other platforms and other software is your

software designed to be compatible? What compatibility standards or guidelines should be

followed that define how your software should interactwith other software?

What type of data will your software use to interact andshare information with other software

tibl ft


21/67

compatible software

What is compatible for your software?Word ProcessorfromCompany Mrunning onOperating SystemsW

NetworkImport/Export

Word ProcessorfromCompany Srunning onOperating SystemsL

SpradsheetfromCompany Grunning onWeb Browser

Cut, Copy, PasteFileImport/Export

FileLoad/Save

Getting the answers is basic static testing - black boxand white box testing

analyzing the specification of the product andsu ortin s ecification

a orm an app ca on


22/67

a orm an app ca onversions

Selecting the target platforms is a program manager ormarketing task

Best View with Firefox 2.0

For use with Linux 2.6.10

Optimized for IE7

This information is part of specification and have itsown development criteia

ac war an orwar


23/67

ac war an orwarcompatibility

Backward compatibility will work with previous version of software

Forward compatibility

will work with the future version of the software

testing multiple version


24/67

testing multiple version

Testing that multiple version of platforms and softwareapplication work properly with each other can be a

huge task

Testing new version of OS

you cant test all the software that should work on

that OS

Equivalence partitioning can be applied

criteria to decide


25/67

criteria to decide

Popularity - sales data to select top programs

Age - program version that release in last few year

Type - Select software from different type

Manufacturer - based on company that created thatsoftware

standards and guidelines


26/67

standards and guidelines

Approach the actual testing will be done

Two level High level - guide products general operation

look and feel, supported features, etc

Low Level - detail standard

file format, protocol used, etc

data sharing compatibility


27/67

data sharing compatibility

Sharing data among applications gives software its

power allow users to easily transfer data to and from other

software

saving and loading, import and export

cut, copy paste


28/67

3.3 USABILITY TESTING

Overview

User Interface Testing

What Makes Good UI?

Setting for Usability Testing :@ RMIT Usability TestLab

overview


29/67

overview

Measuring how well people can use some human-made object (such as a web pages, a computerinterface, a document, or a device) for its intendedpurpose

How appropriate, functional, and effective thatinteraction is.

uncovers difficulties, - such as understandinginstructions, manipulating parts, or interpretingfeedback

observe people using the product in as realistic asituation as possible, to discover errors and areas ofimprovement

overview
http://en.wikipedia.org/wiki/Understandhttp://en.wikipedia.org/wiki/Feedbackhttp://en.wikipedia.org/wiki/Feedbackhttp://en.wikipedia.org/wiki/Understand


30/67

overview

What is usability?

A measurable characteristic

A practice

Characteristic of usability


31/67

Characteristic of usability

Ease of learning

Ease of use Ease of remembering

Subjective satisfaction

Efficiency of use

Effectiveness of use

the practice


32/67

the practice

Focus on users Find out who they are

Find out how they use your site

See the site from their perspective

learn


33/67

learn

What usability testing involves

What to look for when testing a user interface

What special usability features are needed by the

disabled

TESTING


34/67

TESTING

What is UI? - interface which allow people interact witha machine, device, computer program or othercomplex tool

What is GUI? - which allows people to interact withcomputer and computer-controlled devices whichemploy graphical icons, visual indicators or specialgraphical elements

What is UI/GUI testing? - testing of the user interfaceto ensure that it follows accepted standards and meetsits requirements.

what makes a good ui?


35/67


Software build by programmer - good at writing but notusability expert

Use usability lab run by ergonomic -thing there areeasy and functional to use

In the field with observers

In the lab with sophisticated (expensive) recordinggear



36/67


Common good UI

Follow standards and guidelines

Intuitive - easy to use and understand

Consistent - shortcut keys, menu, terminology, naming,placement for buttons

Flexible - state jumping, state termination, data input andoutput

Comfortable - appropriateness, error handling, performance

Correct

Useful

accessibility testing


37/67

accessibility testing

Difficulty in using computer

Visual impairment, hearing impairment, motionimpairments, cognitive and language


38/67

Usability Testing

Online @ RMIT

Usability Test Lab

What (minimum) equipment do you need


39/67

to formally test a web site?Computer with Internet access

Person to monitor the test participant: where they went,

what they clicked,

how long did it take

A task, or list of tasks for the test participant toperform

Video camera (optimum: 2 cameras) tocapture:

Participants face

How do you devise the


40/67

How do you devise thetask/s?

Use the test plan (from Requirements /Specifications)

Map out what you consider a perfect step-by-step method of completing the task (like arecipe)

The task list for participants does not specifyperfect way to complete the task

Why videotape the


41/67

Why videotape thesession?Documentation for other members of the

development team

If something goes wrong, the test participant willhave some reaction on face and on screen

Debriefing (end of session):

Tester & monitor review session (run throughvideo)

Stop video at interesting points to discuss:

Reasons participant performed the task the way they did

What participant would like to happen


42/67

Layout of the room

PC is connected to notebook. Notebook displaysh t h th ti i t PC


43/67

whatever happens on the participants PC

Video camera set to record notebook screen and


44/67

Video camera set to record notebook screen andparticipant at PC (ideal setup would have 2

cameras)

The TV shows the video camera recording


45/67

gtester & test participant review this at the end of the

session

ow many peop e o you?


46/67

y p p ytest?

5 people provide sufficient test results andfeedback (Jakob Nielsen)

For Online @ RMIT

Group 1 (establishing benchmarks):

5 novice users

5 more experienced users

Group 2:

5 novice users after induction

ow o you measurebili ?


47/67

yusability?

The product is usable if participants performedmost of the tasks

Benchmarking (Group 1):

Quantitative: n% testers tookx minutes toperform task 2

Qualitative: comments/discussion, e.g., ifeveryone had problem with a task, tohighlight design flaws. Or positive feedback.

What happens with the


48/67

ppresults?

Results are tabled as a report (to developmentteam)

Feeds back into the design process

.DOCUMENTATION


49/67

DOCUMENTATION

Type of software Documentation

The importance of documentation testing

Reviewing Documentation

The Realities

Documentation


50/67

One of the product of your software is documentation(non software)

One time ago - README files

Now - huge potion of the overall product

As a software tester; make sure the documentation iscorrect

LEARN


51/67

The different types of software documentation

Why documentation testing is important

What to look for when testing documentation

ypes o so waredocumentation


52/67

ypdocumentation

Component of the software documentation

Packaging text and graphics

box, carton, wrapping, and so on.

Screen shots, list of feature, system requirement,copyright information

Marketing material

ads, promotion tools



53/67

documentation

Warranty/registration

Registration card, online

form to fill in and address to return to

EULA - end user license agreement

legal document printed or display on screen

protect user and manufacturer



54/67

documentation

Label and stickers

serial number, disk label

Installation and setup instructions

printed on disk, or CD sleeve, installation manual

User manual

printed or online manual

Getting started documentation



55/67

documentation

Online help

display on web

indexed and searchable

Tutorial, wizard

often tied with online help

guided way to complete task

Samples, examples and templates

Error messages

mpor ance odocumentation testing


56/67

documentation testing

All individual non-software components part areconsider as a part of the product

Its about the quality of the entire package

Its improve usability

Its improve reliability

It lower support costs

DOCUMENTATION


57/67

DOCUMENTATION

Testing documentation can occur on two different level Non-code document- such as printed manual

Code closely tied document - such as hyper-linkedonline help

DOCUMENTATION


58/67

DOCUMENTATION

Non-code document

static process,

technical editing or technical proofreading

Code closely tied document

dynamic test effort

really testing software

CHECKLIST


59/67

General Areas

audience, terminology,

content and subject matter

Correctness

just the fact, step by step,

figure and screen capture

sample and examples

spelling and grammar

the realities...1


60/67

Documentation often get the least attention, budgetand resources

all component are at least as important as thesoftware

What happen if the the software doesnt work asstated on document but work with the other ways?

which in not documented!!

Its a document error or software error?

THE REALITIES ...2


61/67

People writing the documentation arent experts inwhat the software does

Writer need all the information and must be up-to-date with the product design

They need to know about difficult-to-use and difficult-

to-understand areas Must work closely with developer

the realities ...3


62/67

Printed documentation takes time to produce

feature update must be locked down before thesoftware is completed

software changes during critical period will not reflectthe documentation

Documentation should be hold until the last possibleminute

summary


63/67

Software product may come from software developerand also from writers, illustrators, indexers and so on

On the eyes of the user, missing or wrong informationcan be labeled as a software bug just like any othersoftware failure

Quiz


64/67

There is a bus with 7 girls inside, each girl has 7 bags,

inside each bag, there are 7 Big cats, each Big cat has7 small cats,

All cats have 4 Legs each!

Question: How many Legs are there inside the bus?

Solution


65/67

7 girls * 7 bags * 7 big cat * 7 small cats * 4 legs

= 9604 legs

Wrong - where is thelegs for the girls

Solution


66/67

7 girls * 7 bags * 7 big cat * 7 small cats * 4 legs

= 9604 legs

7 girls * 2 legs = 14 legs

All legs = 9604 + 14 = 9618 legs

Still Wrong

There are other cats on the bus

Solution


67/67

7 girls * 2 legs = 14 legs 7 girls * 7 bags * 7 big cat * 4 legs = 1372 legs

7 girls * 7 bags * 7 big cat * 7 small cats * 4 legs =

9604 legs All legs = 14 + 1372 + 9604 = 10990 legs

Documents

L Comp at Ability User Interface Testing