E - Tester

7/31/2019 E - Tester

1/44

Copyright 2008, Oracle. All rights reserved.

Oracle Application Testing Suite: Introduction

7/31/2019 E - Tester

2/44

Copyright 2008, Oracle. All rights reserved.1 - 2

Topics Covered

FMStocks Testing Concepts

e-Tester

e-Manager

e-Load

e-Reporter

ServerStats

7/31/2019 E - Tester

3/44


FMStocks

Introduction to Oracle Application Testing Suite

7/31/2019 E - Tester

4/44


How to Access FMStocks

Navigate to: http://Instructor*/FMStocks in a web browser

* See Instructor for the name of the host machine

7/31/2019 E - Tester

5/44


What Is FMStocks?

Fitch and Mather Stocks is a sample brokerage application Used to test Microsoft ASP and .Net technologies

This course will refer the FMStocks site as a sample

application

You can download the application athttp://www.fmstocks.com

7/31/2019 E - Tester

6/44


FMStocks Architecture

Developed for Windows 2000 Built using the standard 3-tiered technology approach

Presentation Layer IIS and ASP

Business Logic Layer COM+

Data Services Layer SQL Server

7/31/2019 E - Tester

7/44Copyright 2008, Oracle. All rights reserved.1 - 7

Presentation Logic Data

FMStocks Architecture

IIS ASP

Business

Components

SQL Server

Web Browser

ODBC

ADO

OLE DB

7/31/2019 E - Tester


FMStocks Transactions

Key transactions of the FMStocks application: Open a new account

Login

Research a company

Purchase a stock Sell a stock

Balance and portfolio data

Logout

7/31/2019 E - Tester

9/44Copyright 2008, Oracle. All rights reserved.

Testing Concepts


7/31/2019 E - Tester


Importance of Testing

Improve the quality of the application Decrease risk of users discovering problems

First impressions are lasting impressions

Reduce cost of fixing application (earlier in development

cycle)

7/31/2019 E - Tester


Testing Overview

PlanTest

RecordTest

Cases

ImplementTests

EvaluateTests

Repeat Tests

TrackDefects

7/31/2019 E - Tester


When To Test

The testing process should begin early in the systemsdevelopment life cycle

Testing should begin with a review of the requirements

documents and proceed all the way through to User

acceptance testing

7/31/2019 E - Tester


What Is A Test Plan?

Test Plan: describes the test strategy, scope, resources andschedule of testing activities. It identifies the test requirements,

test cases, expected results, pass or fail criteria, and risks

associated with the plan.

7/31/2019 E - Tester


Importance of Test Plan

Organize, manage and schedule the testing effort Repeatability

Improve coverage and efficiency

7/31/2019 E - Tester


Components of A Test Plan

Test strategy Test objectives & scope

Test requirements

Expected results & pass/fail criteria

Risk assessment & priority Test cases

Staffing & responsibilities

Test deliverables

Miscellaneous test plan components

7/31/2019 E - Tester


Test Strategy

Describes the general approach of the test project. Specifies which stages of testing (unit, build, and system)

are addressed and which kinds of testing (functional,

performance, stress, and so on) are to be performed within

each stage.

Includes test completion criteria (that is, allow the software

to progress to acceptance testing when 95 percent of test

cases have been successfully completed).

7/31/2019 E - Tester

18/44

7/31/2019 E - Tester


Exercise 1

Using the FMStocks site, develop a list of features to betested.

Discuss the possible strategies and objectives for testing.

7/31/2019 E - Tester


Test Requirements

Test requirement: reflects the behaviors that are to be verifiedof the application-under-test.

A requirement must be verifiable!

7/31/2019 E - Tester


Classification of Test Requirements

Business Functions: express the purpose of the software interms of the business it serves, and relate most directly to the

users expectations of the software.

User Interface Behaviors: are standard behaviors and sets of

attributes to be verified.

Other Functions: are not directly related to business

transactions (administrative functions, functions to set operator

preferences, and supporting utility functions).

7/31/2019 E - Tester


Think About The Requirements

Identify the most important transactions.Identify the most frequently used transactions.

Questions to ask:

What transactions will most adversely affect my business

objectives if they dont perform correctly? What transactions are absolutely mission critical to my

users?

7/31/2019 E - Tester


Decomposition of Test Requirements

Create a hierarchy of high-level test requirements, or test items.Break down each test item into more detailed test requirements,

or features to be tested.

7/31/2019 E - Tester


Exercise 2

Choose a feature from the list developed in Exercise #1. Create a test requirement hierarchy with test items, and

features to be tested.

For each requirement, classify it as a business function,

user interface, or other function.

7/31/2019 E - Tester


Expected Results & Pass/Fail Criteria

For each requirement, state the Expected Result.Define the Pass/Fail Criteria for each requirement.

Functional Criteria: whether the function meets the

expected result.

Performance Criteria: specify the response times neededby the users.

Operation Under Stress: describes acceptable response

to abnormal conditions such as unusually high transaction

rates (I.e. Does the site slow down? Does it cease to

function?)

7/31/2019 E - Tester

26/44


Risk Assessment

For each requirement, identify the risk factor. The most importantrequirements to test are those with the highest risk.

What could cause a requirement to fail?

What is the effect, or impact of a test requirement failing?

What is the likelihood, or probability, that a test case willfail?

7/31/2019 E - Tester

27/44


Risk Assessment

First, list all of the causes of a failed requirement.Second, for each cause, assign a number for the level of impact

(that is, 1=low, 3=medium, 5=high)

Third, for each cause, assign a number for the likelihood of

failure (that is, 1=lease likely, 3=likely, 5=highly likely)Finally, multiply the level of impact by the likelihood of failure to

get the risk factor.

Impact * Likelihood = Risk Factor

7/31/2019 E - Tester

28/44


Priority

Once you have determined the risk factor, use it to assign apriority level to each requirement.

The priority will indicate the order of importance.

Example:

Risk factors (1 - 8) = Low priority Risk factors (9 - 15) = Medium priority

Risk factors (16 - 25) = High priority

7/31/2019 E - Tester

29/44


Test Cases

For each requirement, design a test case to test it.Next, develop the test case.

For manual tests, document each step of the test case.

For automated tests, document each step of the test case,

and generate the script using the automation tool. (Be sureto reference the script file in the test plan).

Create data files (if needed) and reference their location in the

test plan.

7/31/2019 E - Tester

30/44


Think About Test Cases

Understand how users will use the site and record scriptsthat reproduce these transactions.

Transaction-based scripts provide more meaningful results

and are easier to work with.

Longer scripts can be more difficult to work with and debug.

7/31/2019 E - Tester

31/44


Exercise 3

Using the requirements from exercise #2, specify theexpected results for each.

Prioritize the requirements. Explain the reason for the

prioritization.

Create a test case to satisfy each requirement.

7/31/2019 E - Tester

32/44


Test Environment

Specify the needed and desired properties of the testenvironment, including:

Hardware (computer type, memory, hard-drive size, and so

on)

Communications and system software

Bandwidth

Mode of usage (that is, stand-alone)

Other software or supplies needed (operation system,

browser type, and so on)

Level of security

Identify the source for all needs not currently available.

7/31/2019 E - Tester

33/44


Staffing & Responsibilities

Identify team members required for completing the test plan, andlist the responsibilities for each.

Test Manager: provides over all direction for testing.

Test Engineer (Design/Development): design and

develop test cases. Test Engineer (Test Execution): executes test cases.

Test System Administrator: installs and configures

software/hardware on the test machines according to the

test environment specifications.

7/31/2019 E - Tester

34/44


Test Deliverables

List of the test materials developed by the test team, during thetest cycles, that are to be delivered before the completion of the

project.

Test plan (requirements document & test cases)

Defect tracking reports Final release report

7/31/2019 E - Tester

35/44


Miscellaneous Components

Task List: specifies the tasks to be executed. The order in whichtasks will be performed, and who will perform the tasks. The

task order should take into consideration the requirement

priorities, and which tests can be executed using the same

setup.

Schedule: specifies the date and time that each task will be

performed.

7/31/2019 E - Tester

36/44


Test Plan Example

Refer to the FmStocks Test Plan in Appendix A of yourworkbook.

7/31/2019 E - Tester

37/44


Track Defects

How do you identify defects? A defect will be any result that does not comply with the

requirements document

It is possible to find defects that comply with the requirements

document. In such cases:

Use common sense

Anything that would make a user not want to continue to

use the site is a defect

7/31/2019 E - Tester

38/44


Testing Approaches


7/31/2019 E - Tester

39/44


Functional Testing

Positive Testing Positive testing exercises the basic functionality dictated in

the requirements documents.

Positive testing exercises functionality using the data the

user IS SUPPOSED to use.

Negative Testing

Negative testing exercises the error handling functionality of

the application under test.

Negative testing uses data the user IS NOT SUPPOSED to

use.

7/31/2019 E - Tester

40/44


Functional Testing

Black Box Testing Test by exercising the UI and validating that the UI returns

the expected results

Black box testing focuses on the values returned by the UI,

not on what is happening behind the scenes.

White Box Testing

Test by exercising the UI and validating against database

entries and code break points.

White box testing focuses on what is happening behind the

scenes.

7/31/2019 E - Tester

41/44


Functional Testing

Grey Box Testing A combination of white box and black box testing.

Validates database entries as a result of exercising the UI

without stepping through code

7/31/2019 E - Tester

42/44


Regression Testing

Re-executing previously performed testsUsually occurs after a new build has been released to validate

that no new defects have been introduced

Applies to all aspects of testing

Functional Scalability

Regression testing lends itself to automation due its repetitive

nature

7/31/2019 E - Tester

43/44


Questions?

7/31/2019 E - Tester

44/44

Documents

E - Tester