68
Example For Quality Enter Text here: abc ok Please enter valid data

Slides1 - testing

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Slides1 - testing

Example For Quality

Enter Text here:

abc

ok

Please enter validdata

Page 2: Slides1 - testing

Enter Text here:

abc123

OK

Please enter valid data

Summary for above two Examples

The Application should be prepared according to client’s requirements and it should be User-Friendliness.

Page 3: Slides1 - testing

Project taken by the Organization in a procedural way...

BOA

Requirements

TCS

Infosys

IBM

Tech Mahindra

DSS

RFP

Client

Page 4: Slides1 - testing

Contents of RFP

Full form of RFP : Request for Proposal Document

Contents :

1) Introduction

2) Cost

3) Experience

4) Resources

5) Approach

6) Methodologies ....etc

Page 5: Slides1 - testing

BOA DSSSelected

The Official People of both the companies will meet tofinalize the agreement. For finalizing they will sign onDocuments.

SLA Service level Agreement

SOW Statement of work

Page 6: Slides1 - testing

SDLC Phases

1) Initial or Requirement phase

2) Analysis Phase

3) Design Phase

4) Coding Phase

5) Testing Phase

6) Release & Maintenance

Page 7: Slides1 - testing

Where exactly Testing will be started

1) UnConventional Testing

2) Conventional Testing

Unconventional Testing : The person will test the application whether this application is going according to company standards are not. Herethe person is QA(Quality Analyst)

Conventional Testing : The person will test the application whether thisapplication is according to clients requirements or not. Here the personis Software Test Engineer.

Page 8: Slides1 - testing

Testing Methodologies : There are two types of testing methodologies.

1) Black Box Testing

2) White Box Testing

There is one more which is derived from above two methodologies.i.e Gray Box Testing.

Black Box Testing : The people who performs testing only on thefunctional part of the application is called as Black Box test Engineers.

Page 9: Slides1 - testing

White Box Testing : The people who test the structural part of theapplication i.e Coding part is known as White Box Testing.

> Usually developers are White Box Test Engineers.

Gray Box testing : The people who test the Functional and Structuralpart of the application is known as Gray Box Testing.

Page 10: Slides1 - testing

Levels of Testing

Different Levels of Testing are :

1) Unit Level Testing2) Module level Testing3) Integration level Testing4) System level Testing5) User acceptance Testing

Unit Level Testing :

Unit is defined as a Smallest part of the program in an application.

Page 11: Slides1 - testing

These will be performed by developers where they will test each and every unit of an application(i.e coding) and combination of units.

Different ways of unit testing are :

1) Structural Testing

2) Conditional Testing

3) Branch Testing

Page 12: Slides1 - testing

Module Level Testing :

Combining more than one functionality to perform a major task of related feature to test is known as Module Level Testing

These will be performed by Software Test Engineers.

City

GOA

HYD

Others

SelectLocation here

: OK

Page 13: Slides1 - testing

Example 2

City

GOA

HYD

Others

SelectLocation here

: OK

Enter Location name : PUNE

OK

Page 14: Slides1 - testing

SelectLocation here

:

City

GOA

HYD

PUNE

Others

OK

Page 15: Slides1 - testing

3) Integration Level Testing :

Combining all the modules of a project by using different approaches. The approaches are :

1) Top-Down Approach2) Bottom- Up Approach3) Hybrid Approach4) Big bang Integration

1) Top-Down Approach : Combining the modules from top(i.e parent) level to bottom(i.e Child) level is known as Top-down Approach.

Page 16: Slides1 - testing

A

B C

D E F G

From top to Bottom

Parent Module

Stub

Stub : In Top-Down approach if any original module is replacedWith dummy module that module we will call it as Stub.

Page 17: Slides1 - testing

Bottom-Up Approach : Combining the modules from child level to parent level is known as Bottom-up approach.

A

B C

D E F G

Parent Module

Driver

Child Module

From Bottom to Top

Page 18: Slides1 - testing

Hybrid Approach : Combination of both the approaches is known asHybrid approach.

Big Bang Integration : Combining all the modules at a time after Preparing the modules is known as Big bang Integration.

System Level Testing : Testing each and every functionality of the application where we will perform all the types of testing is knownas system level testing.

Page 19: Slides1 - testing

Software Development Models

Water Fall Model or Linear Sequential Model

Initial

Analysis

Design

Coding

Testing

R & M

Phases

Cost

Cost of a bug phase by phase

Page 20: Slides1 - testing

Initial

Analysis

Design

Coding

Testing

R & M

When ever Requirements are addedIn the middle again the process Should start from first.

Page 21: Slides1 - testing

ENVIRONMENT

Present Layer

Database Layer

Applicati-on Layer

Request Request

ResponseResponse

Validations Appropriate data

Displaying data

There are 4 types of architectures :

1) 1-Tier Architecture2) 2-Tier Architecture3) 3-Tier Architecture4) n-Tier Architecture

Page 22: Slides1 - testing

Environment in the Organization for a project

D1 D2

D3

T1 T2

T3

P1

Dev Environment Test Environment Production Environment

Build 1 released

Build 1(Defects)

Page 23: Slides1 - testing

D1 D2

D3

T1 T2

T3

P1

Dev Environment Test Environment Production Environment

Build 1000 released

Build 1000 (No Bugs found)

Deploying Build 1000

Page 24: Slides1 - testing

Types of Testing

1) Build Verification Testing or Build Acceptance Testing or Sanity Testing

Conditions for accepting the Build :

1) Build Installation.2) Navigating through pages.3) Features Availability.4) Required connections are properly established or not.

If all these conditions are satisfied then we will continue withNormal testing.

Page 25: Slides1 - testing

Sanity Testing : After releasing the build the testing will be performed onsome major functionalities to accept the build is known as Sanity Testing.

Smoke Testing : Before releasing the build the developers will test the application that is known as Smoke testing.

2) Regression Testing : It is a type of testing in which one will perform testing on the already tested functionality again with there dependencies.

Usually we do it in two scenarios.

Whenever we raise the defects to the development department, once the next build is released we will test the defect functionality as well as the related functionality again and again.

Whenever some new features added (incorporated) to application, When next build is released to the testing department then all the related features of the new features will be tested once again.

Page 26: Slides1 - testing

Example for Regression Testing

Calculator

V1 1

V2 2

Res 3

ADD

SUB

MUL

Page 27: Slides1 - testing

V1 1

V2 2

Res 30

ADD

SUB

MUL

Clicking on SUB

V1 1

V2 2

Res 300

ADD

SUB

MUL

Clicking on MUL

Page 28: Slides1 - testing

Retesting :

Username : abc

Password : abc

OK Cancel

Username : abcd

Password : abcd

OK Cancel

Page 29: Slides1 - testing

Definition : Testing the application again and again with differentset of values is known as Retesting.

Alpha Testing : It is a type of user acceptance testing conducted in the software company by our test engineers in front of client to make him accept.

Example : Project or Product

Beta Testing : It is a type of testing conducted by the End users or third party experts or clients before releasing to Client is known as beta Testing.

Example : Product

Page 30: Slides1 - testing

Static Testing :

Usernane :

Passward :

Cancel

Login

Definition : Without performing any actions on the application while testing is known as Static Testing

Page 31: Slides1 - testing

Dynamic Testing : Here we will perform some actions on the application to test the functionality whether it is according to client requirement.

Example : Functionality Testing

Installation Testing :-It is a type of testing in which one will install the application into the environment by following the guidelines provided in the deployment document. In-order to come to a conclusion whether those guidelines are perfectly suitable for installing the application or not.

Compatibility Testing:-It is a type of testing in which one will install the application into the number of environments prepared with different combinations in-order to confirm whether the application is suitable with all those environments or not. Usually the type of testing is compulsory for products rather than projects.EX:- Testing the application with different browsers(Netscape Navigator, Mozilla Firefox, Internet explorer).

Page 32: Slides1 - testing

There are two types of Compatibility Testing : > Forward Compatibility. > Backward Compatibility.

MS 2000 MS 2003 MS 2007

Forward Compatibility : Verifying whether previous Version files are opening in latest version files.

Forward Compatibility

Page 33: Slides1 - testing

MS 2000 MS 2003

Backward Compatibility

MS 2007

Backward Compatibility : whether the latest version files areopening in the previous version files is known as Backward Compatibility.

Page 34: Slides1 - testing

Monkey Testing :-

It is a type of testing in which one will perform abnormal actions on the application intentionally in-order to check the stability of the application.

Ex: - (i) Clicking on "submit" button of the login page repeatedly.

(ii) Pressing F5 button continuously.

Usability Testing:-

It is a type of testing in which one will perform testing on the user-friendliness of the application.

EX:- In "Login Page" of an application, if cursor is placed in "PasswordTextbox" instead of "Username Textbox".

Page 35: Slides1 - testing

End to End Testing:-

It is a type of testing in which one will perform testing on the end- to – endscenarios of the application.

Exploratory Testing :-

Exploratory testing is particularly suitable if requirements and specificationsare incomplete, or if there is lack of time

It is a type of testing in which the domain experts will perform testing on theapplication without having the knowledge of the requirements, just byparallel exploring the functionality.

Exploring:- Having the basic knowledge of any concept, doing something a knowing more about it, is known as exploring.

Page 36: Slides1 - testing

Security Testing :-

It is a type of testing in which one will check whether the application is properly protected or not.

To do the same the Black Box Test Engineers will perform the following typesof testing.

a. Authentication Testing:-

In this type of testing one will enter different combinations of usernames and passwords and check whether only the authorized people are accessingthe application or not.

Ex:- In login application of a project, tester will try enter differentcombination of usernames and passwords.

b. Direct URL Testing :-

In this type of testing one will enter the direct URL's of secured pages and check whether they are able to access or not.

Page 37: Slides1 - testing

Ex:- Here the tester will navigate to all the pages of the project, while navigating from one page to the other he will copy all the URL's and try to navigate through that pages after singing out of the project.

C. Firewall Leakage Testing (OR) User Privileged Testing:-

In this type of testing one will enter into the application as one level of usersand will try to access the pages beyond his limits, in-order to confirm whether they can be accessible or not.

Port Testing:-

It is a type of testing in which one will install the application, into the original customer environment and check whether it is compatible with thatenvironment or not

Soak Testing (or) Reliability Testing

It is a type of testing in which one will perform testing on the applicationcontinuously for long period of time. In-order to check the stability of the application.

Page 38: Slides1 - testing

Adhoc Testing:-

It is a type of testing in which one will perform testing on the application intheir own style after understanding the requirements clearly.

Performance Testing :-

Verifying for the speed of the application by gradually increasing withnumber of users.

We can do performance testing by 3 ways..

a. Load Testing :-

Increasing gradually the users to access the application to analyze the critical point i.e where exactly the speed of the applicationgetting degraded.

Page 39: Slides1 - testing

b. Stress Testing :-

Verifying where exactly the application is going to crash after Increasing the users more than the load.

c. Endurance Testing :

Keeping the application under test for 24X7 to check the stability of the application.

Ex : Call center Applications

Volumes Testing :-

Huge amount of data is processed through the application (which isbeing tested) in order to check the extreme limitations of the system

Page 40: Slides1 - testing

Memory Testing :-

After opening/Closing an application verifying for the Allocation/De-allocation of an application is known as memory testing.

I18N Testing :-

Testing is conducted on other than Local languages for an application.

Ex :- Working on Spanish Language application.

Localization Testing :-

Testing is conducted on the Local languages application.

Page 41: Slides1 - testing

Cookies Testing :-

Cookie is small information stored in text file on user’s hard drive.This information is later used by web browser to retrieveinformation from that machine. Generally cookie contains personalized user data or information that is used to communicatebetween different web page.

Conditions for conducting cookies testing :-

After sign in copy the URLs of web pages and After sign out paste the URLs and verify for page navigations.

Sessions Testing :- The User’s information which is stored in the serverside is called a session.

After sign out click “Back” button in the browser.

Page 42: Slides1 - testing

Conditions for sessions Testing :-

Keeping webpage Ideal for some time.

Removing the network connection of the system when processing is going on.

Click Refresh or Back button while your request is processing.

Page 43: Slides1 - testing

SOFTWARE TESTING LIFE CYCLE

1. Test Planning2. Test Development3. Test Execution4. Result Analysis5. Defect Tracking & Reporting6. Test Closure Activity

Test Planning:-

Test Plan:-It is a strategic document which contains some information that describeshow to perform testing on an application in an effective, efficient and optimized way. Test lead prepares the test plan document.

Page 44: Slides1 - testing

Contents of the Test Plan:-

1) INTRODUCTION :-

a) Objective :- The purpose of the document will be clearly described in this section.

b ) Reference documents :- The list of all the documents that are referred while preparing the test plan will be mentioned here in this section.

Ex: - Project Plan, SRS Document. Basically Project Plan is developed by Project Manager.

2) Coverage of Testing :-

a) Features to be tested :- The list of all the features that are within the scope and planned for testing will be mentioned here in this section.

Page 45: Slides1 - testing

Features not to be Tested :-

The list of all the features that are not planned for testing will be mentionedhere in this section Usually based on the following scenarios it happens.

• Out of Scope Features.• Low Risk Features.• Features that are planned to be incorporated in future.• Features that are skipped based on the time Constraints.

3) Test Strategy :-

Making a strategy of how to test the application.

Levels of Testing:-

The list of all the types of testing that are performed in that company willbe mentioned here in this section.

Page 46: Slides1 - testing

Types of Testing:-

The list of all the types of testing that are performed in that company will bementioned here in this section.

Test Designed Techniques:-

The list of all the techniques that are used in that company while designing the test cases will be mentioned here in this section

Test Metric :-

The list of all the metrics that are maintained in that company will be listed out here in this section.

A test metric is a way to measure the size of a project to estimate the quantity of effort needed to perform of testing.

A Test metric is just like any other tool used to measure the quality of software product to serve best to the customer

Page 47: Slides1 - testing

We have a formula to measure a software test engineer work of how effectively he has done testing on the application.

The formula is:

A----- X 100 A+B

A = The defects identified by Software test engineer.

B = The defects identified by Client

For Example :

No of defects identified by Test engineer is 90

No of defects identified by Client is 10

So, 90% Efficiently the test engineers has done the work.

Page 48: Slides1 - testing

Automation Plan:-

The list of all the areas that are planned for automation will be mentioned here in this section

List of Automated Tools:-

The list of automated tools that are used in that company will be mentionedhere in this section.

BASE CRITERIA:-

Acceptance Criteria:-

When to stop testing will be clearly described in this section.

Suspension Criteria:-

When to suspend the build will be clearly described here in this section

Page 49: Slides1 - testing

Test Environment:-

The details of the Environment that is about to be used for testing will be clearly described here in this section.

Resource Planning:-

"Who has to do what" will be clearly mentioned or described here in this section.

Scheduling:-

The starting dates and the ending dates of each and every task will be clearlyplanned here in this section.

Staffing and Training:-

The list of all the additional resources required and any training need to beprovided to accomplish that project successfully will be analyzed and mentioned here in this section.

Page 50: Slides1 - testing

Risks & contingencies:-

The list of all the possible risks that may occur and the corresponding solution plans(contingencies) will be listed out here in this section.

Risks:-

Employees may leave the organization in the middle of the project. Customer may impose the deadlines. Unable to deliver the project within deadlines. Unable to test all the features within the given time. Lack of experts.

Contingencies:-

Employees need to be maintained on bench.

What not to be tested should be planned incase of customer imposing deadlines. Proper plan assurance. Priority based execution. Proper Training needs to be provided.

Page 51: Slides1 - testing

Approval Information:-

Who has approved that document and when it is approved will be clearly mentioned here in this section.

Test Development Phase :-

Use Case:- It describes the functionality of certain feature of an application, in terms of actors, actions and responses.

How a use case Document represented?

Page 52: Slides1 - testing

For Example : Bank application

Client

Teller

With drawl

Deposit

Accounts

Actors Actions

Page 53: Slides1 - testing

Contents in UseCase Document :-

Screenshot of the application Name of the usecase Brief Description of the usecase. Actors Involved. Special Requirements. Pre Condition. Post Condition. Flow of Events.

1) Screenshot of the application :-

In this section the design of the application will be provided, Sothat a user will write test cases based upon the requirements Understood by seeing the application.

Page 54: Slides1 - testing

Username :

Password :

Clear OK Cancel

Login

Connect To :

Two people can login i.e Admin, User.

2) Name of the usecase :- Login

3) Brief Description of the usecase : What will be the functionality of the Login Module.

Page 55: Slides1 - testing

4) Actors Involved :- Admin and User

5) Preconditions :-

a) Build should get installed.b) Valid credentials should be there.

6) Post condition :-After entering valid credentials the page should be navigated to respective page or validation messagesshould be provided.

7) Flow of events :- The application flow will be mentioned here for every requirement.

8) Special Requirements :- There are two types of requirements that are :

a) Explicit Requirementsb) Implicit Requirements

Page 56: Slides1 - testing

Explicit requirements :-The requirements which are given by the client are known as Explicit requirements.

The requirements are :-

1) After Invoking login page the fields Username, Password, Connect To,Clear, Ok, Cancel should exist.

2) After entering valid credentials and after selecting Connect To fieldthe page should be navigated to respective page.

3) After entering valid credentials and clicking OK button the page should be navigated to respective page.

4) After entering any of the fields clicking clear button, the fields should be cleared.

5) After invoking Login page click cancel button the page should be closed.

Page 57: Slides1 - testing

Implicit Requirements :-

The Requirements which are given by the Organization is knownas Implicit requirements.

The Organization should follow some conditions to give Requirements are :

They should not add any new requirements. They should not remove any requirements of clients. They should not degrade the clients requirements.

Summary :- So, the company can only enhance the requirements.

Page 58: Slides1 - testing

Implicit Requirements :- These are continuation of explicit requirements.

6) After invoking login page clear and submit button should be disabled.

7) After entering any of the fields clear button should be enabled.

8) After entering any credentials the submit button should be enabled.

9) After entering Invalid credentials the validation messages should be provided.

10) Checking for the Tabbing order.

Page 59: Slides1 - testing

For example :-

Deletion of mails in yahoo page:-

Selecting one mail and deleting.

Selecting more than one mail and deleting.

Selecting All mails and deleting.

Going to respective mail and click delete.

Without selecting any mail click delete.

Requirement

Test case :- It’s a simple English statement of how to execute a test.

Page 60: Slides1 - testing

Types of Test Cases :- There are three types of test cases

1) GUI Test Case

2) Functional Test Case.

a) Positive test caseb) Negative Test Case

3) Non Functional Test Case

Guidelines for writing GUI test cases:- Any idea we get with which we can test some thing, without performing anyactions then that idea can be considered as GUI test case.

Example:-

Check for Spellings. Grammar checking. Check whether the text is aligned properly. Check consistency of font, size and color in entire application. Check for the availability of the objects.

Page 61: Slides1 - testing

Test Designed Techniques :- Test Designed Techniques are used for making the Test Engineers feel comfortable while writing the Test Cases even in the complex areas.

Two such type of techniques famously used in most of the companies are :-

1. Boundary Value Analysis (BVA) 2. Equivalence class Participation (ECP)

Boundary Value Analysis:-

Whenever there is a range kind of inputs to be tested then this techniqueis suggested.

BVA says that concentrate on the boundaries only, if boundaries work finethen the complete range will automatically work fine.

During BVA we usually test with following values.

Page 62: Slides1 - testing

The values are :-

LB-1 LB LB+1 MV UB-1 UBUB+

1

LB Min Value MV Middle value UB Max Value

Equivalence Class Partition :- Whenever more number of requirements aregiven for one feature or we need to test some features with different types of data, then it is suggested to first divide the inputs into different partitions equally and then write the Test Cases.

Page 63: Slides1 - testing

Requirements :-

Ex:- Write the Test Cases to test an email test box, whose requirements are as follows:

Accept minimum 4 characters and maximum of 20 characters.

Accept only small alphabets.

Accept only @,_ special characters

Valid Invalid

4 ch 3 ch

5 ch 21 ch

12 ch A-Z

19 ch 0-9

20 ch Alphanumeric

a-z Decimal number(1.7)

@ & _ Except @ & _

Page 64: Slides1 - testing

Test Closure Activity :-This is the final activity done during the testing process where the Test Lead will prepare the test summary report.

Test Summary Report contains the following information.

Number of cycle of execution. Number of Test Cases executed in each cycle. Duration of each cycle. Number of defects found in each cycle and etc.

Page 65: Slides1 - testing

WELCOME TO AUTOMATION TESTING

Page 66: Slides1 - testing

Manual Testing Draw backs :-

Time consuming

More number of human resources is required.

Less accuracy

Tiredness

Cannot repeat the same task again and again with same interest.

Page 67: Slides1 - testing

Automation Testing Drawbacks :-

Automated tools are costly.

Cannot test some of features of the application.

Lack of automation testing experts.

Sample Example for Basic Programming :-

Name

Salary :

OK

Emp Details

Page 68: Slides1 - testing

Sample Example for Basic Programming for Web Application :-

Name

Salary :

OK

Title : Emp Details

Title : Gmail