Pure Test - Software Testing Tutorial

Set Up - Java and WebDriver with Eclipse

2017-11-11T03:26:00.001-08:00

https://www.mkyong.com/maven/how-to-install-maven-in-windows/

1. Download and Install Java Development Kit (JDK) on Windows

http://toolsqa.com/selenium-webdriver/download-and-install-java/

2. Download and Start Eclipse IDE

http://toolsqa.com/selenium-webdriver/download-and-start-eclipse/

3. Download Selenium WebDriver Java client (library files)

http://toolsqa.com/selenium-webdriver/download-selenium-webdriver-java-client/

4. Configure Eclipse with Selenium WebDriver

http://toolsqa.com/selenium-webdriver/configure-eclipse-with-selenium-webdriver/

5. Download Chrome driver –

http://toolsqa.com/selenium-webdriver/running-tests-in-chrome-browser/

6. How to install Maven on Windows and Set the path of the GeckoDriver in Environment Variables

GeckoDriver

***********

a. Go to My Computer and Right click to get the context menu.

b. Click on the Change Settings on the opened window.

c. Go to Advance tab in the System Properties window and click on Environment Variables.

d. Now under the System variables, select Path and click on Edit.

e. At the end of the string use semicolon and paste the path of the GeckoDriver.

Apache Maven

************

1. JDK and JAVA_HOME

Make sure JDK is installed, and “JAVA_HOME” variable is added under System variables "Environment Variable". And paste the path of JDK.

2. Download Apache Maven

Unzip to downloaded folder – C:\Program Files\Apache\maven

3. Add M2_HOME and MAVEN_HOME

Add both M2_HOME and MAVEN_HOME variables in the Windows environment and paste the path of Maven folder.

4. Add To PATH

Update PATH variable, append Maven bin folder – %M2_HOME%\bin, so that you can run the Maven’s command everywhere.

5. Verification

Done, to verify it, run mvn –version in the command prompt.

Basics of Java for Selenium

2017-11-11T01:35:00.000-08:00

JAVA

1. Class is a template or blueprint from which objects are created.

2. Object is an instance of a class.

3. Method is a collection of statements that are grouped together to perform an operation.

4. Constructor - Constructor is a special type of method that is used to initialize the object.

5. Modifiers - There are two types of modifiers access modifiers and non-access modifiers.

6. Inheritance is a mechanism in which one object acquires all the properties and behaviors of parent object.

7. Polymorphism is a concept by which we can perform a single action by different ways.

8. Encapsulation is a process of wrapping code & data together into a single unit eg. capsule.

9. Exception Handling handling is a mechanism to handle the runtime errors so that normal flow of the application can be maintained.

1. Class

It is a template or blueprint from which objects are created. A class can contain:

· Fields or Instance Variable

· methods

· constructors

Object

Object is an instance (result) of a class.

2. Instance variable

A variable which is created inside the class but outside the method.

3. Method

Method is a collection of statements that are grouped together to perform an operation.

eg. When you call the System.out.println() method, the system actually executes several statements in order to display a message on the console.

4. Constructor

Constructor is a special type of method that is used to initialize the object.

i. Difference between a constructor and a method:

a. A constructor doesn’t have a return type.

b. The name of the constructor must be the same as the name of the class.

c. A constructor is called automatically when a new instance of an object is created.

d. Constructors are called only once for a single object while regular methods could be called many times .

ii. Types of Constructor:

a. Default constructor (no-arg constructor)

b. Parameterized constructor

a. Default Constructor - Default constructor provides the default values to the object like 0, null etc.

class Bike1{

Bike1()//default constructor

{

System.out.println("Bike is created");

}

//---------------------------------------------------------------------

public static void main(String args[]){

Bike1 b=new Bike1(); //Default constructor invoked

}

b. Parameterized constructor - A constructor that have parameters is known as parameterized constructor.

class Student4{

int id; //field or data member or instance variable

String name;

Student4(inti,String n){ //Constructor having 2 parameters

id = i;

name = n;

}

void display(){System.out.println(id+" "+name);}

//---------------------------------------------------------------------

public static void main(String args[]){

Student4 s1 = new Student4(111,"Karan");

Student4 s2 = new Student4(222,"Aryan"); //Parameterized constructor invoked

s1.display();

s2.display();

}

iii. Constructor Overloading

Constructor overloading is a technique in which a class can have any number of constructors that differ in parameter lists.

class Student5{

int id;

String name;

int age;

Student5(inti,String n){

id = i;

name = n;

}

Student5(inti,Stringn,int a) //constructor overloaded

{

id = i;

name = n;

age=a;

}

void display(){System.out.println(id+" "+name+" "+age);}

//---------------------------------------------------------------------

public static void main(String args[]){

Student5 s1 = new Student5(111,"Karan");

Student5 s2 = new Student5(222,"Aryan",25);

s1.display();

s2.display();

}

5. Modifiers

There are two types of modifiers access modifiers and non-access modifiers.

i. Access modifiers - specifies the scope of "instance variable", method, constructor or class.

a. private - private access modifier is accessible only within class. If you make any class constructor private, you cannot create the instance of that class from outside the class.

b. default - If you don't use any modifier, it is treated as default bydefault. The default modifier is accessible only within package.

c. protected - The protected access modifier is accessible within package and outside the package but through inheritance only.

d. public - The public access modifier is accessible everywhere.

ii. Non-access modifiers - such as static, abstract, synchronized, native, volatile, transient etc.

a. Static - static is used for memory management. The variable or Method that belong to the Class rather than to any particular instance.

6. public static intmethodName(int a, int b) {

}

· public static − modifier

· int − return type

· methodName − name of the method

· a, b − formal parameters

· int a, int b − list of parameters

7. The this keyword

This keyword is used as a reference to the object of the current class.

8. super keyword in java

super keyword is is used as a reference to the object of immediate parent class.

9. Inheritance

Inheritance is a mechanism in which one object acquires all the properties and behaviors of parent object.

· For Method Overriding (so runtime polymorphism can be achieved).

· For Code Reusability.

Syntax of Inheritance

class Subclass-name extends Superclass-name

{

//methods and fields

}

The extends keyword indicates that you are making a new class that derives from an existing class. The meaning of "extends" is to increase the functionality.

10. Polymorphism

Polymorphism is a concept by which we can perform a single action by different ways. Polymorphism means many forms. There are two types of polymorphism:

· compile time polymorphism (Method overloading)

· runtime polymorphism (Method overriding)

We can perform polymorphism by method overloading and method overriding.

i. Method Overloading

If a class has multiple methods having same name but different in parameters, it is known as Method Overloading. Method overloading increases the readability of the program.

There are two ways to overload the method in java

· By changing number of arguments

· By changing the data type

ii. Method Overriding

If subclass (child class) has the same method as declared in the parent class, it is known as method overriding in java.

Usage of Java Method Overriding

· Method overriding is used to provide specific implementation of a method that is already provided by its super class.

· Method overriding is used for runtime polymorphism

Rules for Java Method Overriding

· method must have same name as in the parent class

· method must have same parameter as in the parent class.

· must be IS-A relationship (inheritance).

iii. Final

The final keyword in java is used to restrict the user. Final can be:

1. variable - If you make any variable as final, you cannot change the value of final variable(It will be constant).

2. method - If you make any method as final, you cannot override it.

3. class - If you make any class as final, you cannot extend it.

Can we declare a constructor final?

No, because constructor is never inherited.

11. Abstraction is a process of hiding the implementation details.

It shows only important things to the user and hides the internal details for example sending sms, you just type the text and send the message. You don't know the internal processing about the message delivery.

There are two ways to achieve abstraction in java

· Abstract class (0 to 100%)

· Interface (100%)

i. Abstract class

A class that is declared with abstract keyword is known as abstract class. It needs to be extended and its method implemented. It cannot be instantiated.

Example - abstract class A{}

Abstract method

A method that is declared with abstract keyword and does not have implementation is known as abstract method.

Example - abstract void printStatus();//no body and abstract (declaring signature)

ii. Interface

An interface is a blueprint of a class. It has static constants and abstract methods. There are mainly three reasons to use interface.

· It is used to achieve abstraction.

· By interface, we can support the functionality of multiple inheritance.

iii. Difference between abstract class and interface

1) Abstract class can have abstract and non-abstract methods.

Interface can have only abstract methods.

2) Abstract class doesn't support multiple inheritance.

Interface supports multiple inheritance.

3) Abstract class can have final, non-final, static and non-static variables.

Interface has only static and final variables.

4) Abstract class can provide the implementation of interface.

Interface can't provide the implementation of abstract class.

5) The abstract keyword is used to declare abstract class.

The interface keyword is used to declare interface.

6) Example:

public abstract class Shape{

public abstract void draw();

}

Example:

public interface Drawable{

void draw();

}

Simply, abstract class achieves partial abstraction (0 to 100%) whereas interface achieves fully abstraction (100%).

12. Encapsulation

Encapsulation is a process of wrapping code and data together into a single unit, for example capsule i.e. mixed of several medicines.

We can create a fully encapsulated class in java by making all the data members of the class private. We can use setter and getter methods to set and get the data in it.

get and set methods

They serve to set and get values from class variables that are defined as 'private' (because of security issue), but these method are defined as 'public'.

13. Exception Handling

The exception handling is a mechanism to handle the runtime errors so that normal flow of the application can be maintained.

The advantage of exception handling is to maintain the normal flow of the application.

Suppose there is 10 statements in your program and there occurs an exception at statement 5, rest of the code will not be executed i.e. statement 6 to 10 will not run. If we perform exception handling, rest of the statement will be executed. That is why we use exception handling in java.

Types of Exception

i. Checked Exception - Checked exceptions are checked at compile-time. Checked Exception uses "throws" keyword.

e.g. IOException, SQLException

ii. Unchecked Exception - Unchecked exceptions checked at runtime.

ArithmeticException

NullPointerException

NumberFormatException

There are 5 keywords used in java exception handling.

· try

· catch

· finally

· throw

· throws

Java try-catch

Java try block is used to enclose the code that might throw an exception.

2013-11-10T01:44:00.000-08:00

Software Testing

Testing is a process to find bugs, find them as early as possible, and make sure they get fixed.

Testing Types
1. White box testing (Also known as Clear Box Testing, Glass Box Testing, Open Box Testing and Structural Testing): Used to test internal based application.

2. Black box testing (Also known as Skin Box Testing, Closed Box Testing and Behavioral Testing): Used to test functional based or requirement based application.

3. Gray box testing: Used to test web applications. It is a combination of both White box & Black box testing.

Testing Techniques (Testing approach)

The most popular Black box testing techniques are:
1. Equivalence Partitioning
2. Boundary Value Analysis
3. Cause-Effect Graphing
4. Error-Guessing

The White-Box testing techniques are:
1. Statement coverage
2. Decision coverage
3. Condition coverage
4. Decision-condition coverage
5. Multiple condition coverage
6. Basis Path Testing
7. Loop testing
8. Data flow testing

Software Testing Check List

Sometimes testers get confused when they have assigned testing task. They don't know from where they should start the testing. To keep this in mind, I have compiled information from many channels. I have created a Checklist for website testing as well as Checklist for Desktop application Testing.

Checklist covers the following points:
Step 1 - User Interface Testing (GUI Testing)
Step 2 - Functional Testing
Step 3 - Interface Testing
Step 4 - Compatibility Testing
Step 5 - Security Testing
Step 6 - Performance testing

Responsibilities of a Tester

a. Understand project requirements.
b. Develops and implements Test Plans that will address the testing needs of functional, regression, integration and system testing.
c. Update Test Case document.
d. Conduct Testing including Smoke, Sanity, and Execute the Test cases.
e. Update the Test Result document.
f. Attend the Regular client calls.
g. Log / File the defects in Defect tracking tool / Bug Report.
h. Verify defects.
i. Discuss doubts/queries with Development Team / Client.
j. Implements software quality assurance standards and processes.
k. Participates in design reviews/walkthroughs for projects.
l. Other duties that are within education and experience or the incumbent may be assigned for the betterment of the company.

Related Testing Topics
a. Agile Testing
b. Black Box testing
c. Testing for Biginners
d. Smartphone Testing

Software Testing Travel domain

2011-02-12T08:44:00.000-08:00

Sr.	TERM	DEFINITION
1	CRS and GDS	Computer Reservations System (CRS) is a computerized system used to store and retrieve information and conduct transactions related to travel (e.g Booking ticket from airindia.com). CRS operations that book and sell tickets for multiple airlines are known as Global Distribution Systems (GDS - Only agents uses these systems). The following is a partial list of Global Distribution Systems: • 1A Amadeus • 1S Sabre (previously 1W) • 1G Galileo • 1P Worldspan

2	Cabin	A compartment where passenger seats are installed. More than one RBD may be assigned to a cabin for sale. Often the terms "cabin" class and "compartment" are used interchangeably.

3	Class	Section of seats on any particular flight (Economy, Business etc).

4	RBD	Reservations Booking Designator: The code used in reservations transactions to identify a compartment on an aircraft and/or a special inventory control. The RBDs are typically represented by alphabetic characters (A, Z etc).

5	ARS	Airline Reservation System is a computerized system containing information about schedules, availability, fares and related services, and through which airline inventory is maintained, reservations can be made and/or tickets issued. Typically, only airline offices (ATO, CTO, CRC, etc) or their General Sales Agents (GSAs) utilize the ARS.

6	ADL	Additions and Deletions List. List of passengers and related data sent from a Reservations system to a Departure Control system for a flight/date, subsequent to the PNL.

7	DCS	Departure Control System: An automated method of performing check-in, capacity and load control and dispatch of flights. Generally, these type of systems are owned and/or operated by an airline or system provider.

8	PFS	Passenger Final Sales. List of passengers and related data sent at flight close out from a Departure Control system to a Reservations system, containing deviations from the PNL/ADL for this station.

9	PIL	The PIL is a teletype message geneerated by the DCS for the local cabin crew to advise special information about passengers on board.

10	PNR	Passenger Name Record: A record of each passenger’s travel requirements which contains all information necessary to enable reservations to be processed and controlled by the booking and participating airlines. The basic record may contain one or more passengers. Although different systems provide varying facilities, all PNRs contain at least passenger name(s), itinerary, and contact information. May other fields may be present such as fare, ticketing, seat selection, etc.

11	PNL	Passenger Name List. List of passengers and related data sent from a Reservations system to a Departure Control system for a flight date.

12	Record Locator	A record locator is an alphanumeric code, typically 6 characters in length, used in airline reservation systems to access a specific record. When a passenger, travel agent or airline employee refers to a record locator they typically mean a pointer to a specific reservation which is known as a Passenger Name Record or PNR.

13	Code Sharing	A code share flight is a flight that is marketed by one carrier and operated by another. The airline that actually operates the flight is called the Operating Carrier. The company or companies that sell tickets for that flight but do not actually operate it are called Marketing Carriers.

14	Interline	Interline partnerships allow two or more airlines to issue tickets on behalf of each other, while retaining the designator code of the other airline.

15	City Pair	Combination of two city and/or airport codes representing the origin and destination of a flight leg, segment or routing.

16	Round Trip	Equivalent to the term “Return Journey”, is defined as (a) travel from one point to another and return by the same air route used outbound whether or not the fares outbound and inbound be the same, or (b) travel from one point to another and return by an air route different from that used outbound for which the same normal, through, one way fare is established.

17	Circle trip	When the traveler starts from one location, goes to multiple locations and come back at same location where he started e.g. JFK->LON->DEL->JFK

18	One Way	When the traveler just goes from Origin to Destination e.g. JFK->LON

19	Round the world	The journey in which the traveler travels around the world and crosses the international timeline, visiting multiple places e.g. JFK->SYD->HKG->DEL->LON->JFK

20	Open Jaw	When the traveler goes from one place to another by air, from there, goes to a third place by other means of travel, and then takes a flight back to where he started e.g., he goes from JFK to LAX by air, from LAX to SFO by car, and then from SFO to JFK by air.

21	Stopover	Equivalent to a "break of journey", means a deliberate interruption of a journey by the passenger agreed to in advance by the airline, at a point between the place of departure and the place of destination.

22	Flight Leg	One take-off and one landing of a plane is called a flight leg with an associated flight number e.g. DEL-BOM IC123

23	Flight Segment	Passenger booking on one flight number which may include one or more flight legs e.g. if passenger goes IC123 DEL-BOM-TRV, then flight segment is IC123 DEL-TRV

24	Direct flights	A flight that has a stop but no change in plane or flight number

25	Change of Gauge	A flight with a stop and a change in plane, but the flight number is the same

26	Nonstop Flights	A flight that has no stops and there is no change in plane or flight number

27	Connect Point	An airport available as a connection location for a multi-leg itinerary

28	Married Segments	Married segments is a term used to identify two or more segments in an itinerary which are actioned as a single unit (set). Acceptance and sending of marriage information is controlled by bilateral agreements.

29	Ad Hoc Schedule	A variation, addition or cancellation from the basic schedule of one or more flights on single dates.

30	Airline Designators	IATA airline designators are two or three character codes assigned by the International Air Transport Association (IATA). Designators are used to identify an airline for all commercial purposes, including reservations, timetables, tickets, tariffs, air waybills and in airline interline telecommunications.

31	Airport Terminal	All buildings used for arrival and departure handling of aircraft.

32	ARNK	Arrival unknown. Used in reservations to fill a gap in the itinerary.

33	Cabin Baggage	Baggage of which the passenger retains custody (also known as hand or unchecked).

34	Cargo	Any goods carried on an aircraft and covered by an air waybill.

35	Check-in	The check-in process involves those activities necessary to evaluate passengers and make them ready to board flights. Check-in can be performed by humans or by machines (self-service devices such as kiosks).

36	Child	A person who has reached his/her second birthday but not his/her 12th birthday as of the date of commencement of travel.

37	Infant	A person who has not reached his/her second birthday as of the date of commencement of travel.

38	Expedite Baggage	Passenger baggage that is not traveling with the passenger due to mishandling and is being forwarded to the passenger.

39	FOID	Form of identification. Typically used to identify that the passenger is who he says he is. This information may be passed in the reservation as an SSR and subsequently passed to a PNL/ADL to Departure Control in a .R/ element.

40	FTL	Frequent Traveler List. The FTL is a teletype message generated by the DCS to advise selected applications of all locally boarded passengers who checked-in with a frequent traveller account number.

41	GMT	Greenwich Mean Time.

42	IATA	The International Air Transport Associationis an international industry trade group of airlines headquartered in Montreal, Quebec, Canada. All the Airline rules and regulations are defined by IATA. a. IATA publishes standards for use in the airline industry. b. IATA maintains the Timatic database containing cross border passenger documentation requirements. c. IATA coordinates the Scheduling process which governs the allocation and exchange of slots at congested airports worldwide.
43	International Flight Leg	A flight leg between two stations to which different ISO country codes apply.

44	ISO	International Organisation for Standardisation. This organization assigns and maintains such information as country codes.

45	Itinerary	The part of the PNR describing the flight segments booked for the passengers named in the name field of the PNR.

46	Leg	The operation between a departure station and the next arrival station.

47	Non-Stop	Flight which operates between a board point and an off point in a single leg without any intermediate landings.

48	NOREC	No record. A passenger who was boarded on a flight and was ticketed for that flight, but was not on the PNL/ADL. The No Rec (No Record) processing page is used to create a new passenger record for passengers who have a paper ticket but no actual reservation on the flight being checked-in.

49	GOSHO	Go show. A departed passenger that is not shown on a PNL/ADL and does not have an OK ticket. The Go Show processing page is designed to accommodate passengers who have booked and paid a travel agent for their journey on the flight being checked-in, but no paper ticket has been issued/electronically recorded. It is designed only to be applicable to agents/airlines using manual paper tickets.

50	NOSHO	No show. A passenger who had a reservation on a flight and is shown on the PNL/ADL but who failed to use the reservation for reasons other than misconnect.

51	OPEN	A term used to specify in a PNR and on a ticket that specific flight is not booked but that the passenger will travel by air and has paid for a flight.

52	Open Ended Schedule	A schedule submitted for processing without an end date. It is assumed that the schedule will be active indefinitely.

53	PTC	Passenger Type Code is a code typically used to identify the type of passenger, e.g., adult, infant, etc. PTC is often used to identify the type of fare.

54	SSR	Special Service Requirement (SSR). PNR record and/or message element which allows an agent to request a special service, designate a condition or provide mandatory information. Examples include special meals, identification of deaf passenger, wheelchair assistance, seat requests and government required information (APIS).

55	Waitlist	When used with PNRs, refers to the status of a passenger for a specific flight. The passenger is not confirmed but has been listed for the flight and is awaiting confirmation.

56	Vendor	Provider of a travel service to agents. Vendors may be airlines, hotel chains, car rental firms or any other provider of services which may be sold through a CRS.

57	Yield Control	Philosophy applied to many systems which attempts to maximize the income of the vendor by restricting sales of low-yield products in favor of higher yielding alternatives. For example, selling full-fare seats rather than discounted excursion seats. This may be achieved for example by manipulation of the status sent to distribution systems in an availability response by disallowing the sale of short haul flights unless in conjunction with a long-haul flight of the same vendor. The term "Revenue Management" is also applied to this process.

2009-11-10T00:02:00.001-08:00

QA, QC & Testing

Testing is often confused with the processes of quality control and quality assurance. Testing is the process of creating, implementing and evaluating tests. If you are shopping for a new television, you can call that process "testing for the best TV for you"... it's kind of pretentious, but that is what you're doing as you compare prices and features to find what will work best for you. Testing usually has a limited scope and duration – you're just looking at TVs, and only in your town, you're not going to spend a year shopping, are you?

Quality control is a refinement of testing, involving the formal and systematic use of testing and a precise definition of what quality means for the purposes of the test. You aren't just testing; you are testing and then doing something with the results. Quality control is used for testing a product or output of a process, with the test measuring the subject's ability to meet a certain benchmark or threshold of quality. The tests usually take the form of "does this product meet requirement X?", and are often pass-fail. Testing -- and by extension quality control -- is reactive; that is, you test to find deviations from a standard. If you systematically employ a formal battery of tests on a consistent schedule, you will be able to pass a product with fairly stable quality. The shortcoming here is that this kind of testing does nothing to improve the quality of output; as far as user-experience is concerned, you're just running in place. Testing and quality control does nothing to raise the level of quality beyond perhaps tweaking the standard to "raise the bar".

Quality assurance goes beyond quality control to examine the processes that create and shape the product: quality assurance looks at the quality of output, as well as at the quality of the inputs.

QA Vs Testing

QA is traditionally responsible for the measurement and auditing of the processes used to make a product. Not only is a Quality Assurance "team" not the same as a test team, they shouldn't even exist in the same organization. Quality Assurance evaluates or establishes processes, sets up measurement programs to evaluate processes, and identifies weaknesses in those processes so that the errors do not happen again. This includes analyzing the tools, metrics, and processes used by Program Management (including specification processes), Development and Testing.

The industry has created laughable titles like SQA Tester which make no sense to me. I looked at monster.com recently for QA positions (I'm happy here, but I like to know what's out there), and virtually every "QA" position is really a testing position.

Related Testing Topic
a. Black Box testing

Software Testing Techniques

2009-11-10T00:01:00.001-08:00

Black box testing techniques
a. Equivalence Partitioning.
b. Boundary Value Analysis.
c. Cause-Effect Graphing.
d. Error-Guessing.

Equivalence Partitioning

Equivalence partitioning is a software testing related technique with the goal:
1. To reduce the number of test cases to a necessary minimum.
2. To select the right test cases to cover all possible scenarios.
Following example of a function has the pass parameter "month" of a date. The valid range for the month is 1 to 12, standing for January to December. This valid range is called a partition. In this example there are two further partitions of invalid ranges. The first invalid partition would be <= 0 and the second invalid partition would be >= 13.

........ -2 -1 0 1 ....................... 12 13 14 15 ...............
------------------------------------------------------
invalid partition 1 valid partition invalid partition 2

It is sufficient to select one test case out of each partition to check the behavior of the program. The values within one partition are considered to be "equivalent". Thus the number of test cases can be reduced considerably. Equivalence partitioning is no stand alone method to determine test cases. It has to be supplemented by boundary value analysis.

Boundary Value Analysis
Boundary value analysis is a software testing related technique to determine test cases covering known areas of frequent problems at the boundaries of software component input ranges.

To set up boundary value analysis test cases you first have to determine which boundaries you have at the interface of a software component. This has to be done by applying the equivalence partitioning technique. Boundary value analysis and equivalence partitioning are inevitably linked together. For the example of the month in a date you would have the following partitions:

......... -2 -1 0 1 ...................... 12 13 14 15 .....
-------------- ---------------------------------------
invalid partition 1 valid partition invalid partition 2

Applying boundary value analysis you have to select now a test case at each side of the boundary between two partitions. The boundary value analysis can have 6 text cases: n, n-1, n+1 for the upper limit and n, n-1, n+1 for the lower limit.

White-Box testing techniques
a. Statement coverage
b. Decision coverage
c. Condition coverage
d. Decision-condition coverage
e. Multiple condition coverage
f. Basis Path Testing
g. Loop testing
h. Data flow testing

Related Testing Topic
a. Black Box testing

2009-11-10T00:00:00.007-08:00

Negative Testing

1) Testing the application for fail conditions. For example entering the special characters for phone number.

2) Testing aimed at showing software does not work. Also known as "test to fail".

3) Negative testing is testing that is directed to showing that something will not work. It's such a natural part of regular testing that I doubt that most people know that there is both a "positive" and "negative" testing.

4) Negative Testing is simply testing the application beyond and below of its limits. For example:
A) We want to enter a name for that negative test can be first we enter numbers.
B) We enter some ASCII characters and we will check
C) First numbers and characters we will check
D) Name should have some minimum length below that we will check

5) Negative testing is testing the tool with improper inputs. For example entering the special characters for phone number.

6) Negative testing is kind of testing doing with the Boundary values, may be max val and min val or with some other kind of data type input etc.

7) Testing the application for fail conditions.

8) Here we test if system is doing something which it is not supposed to do. Example, In password field we try to enter only alphabets were as in requirement it is specified password should have at least 1 no, if it accepts only alphabets then test case is fail otherwise it's pass.

9) Negative testing is testing an application giving invalid data, for example entering wrong user id or wrong password to make the test unacceptable.

10) Negative testing is testing the application with negative assumptions and navigations to get a negative result which leads to positive one.

11) This is a type of testing which is done by tester's to make sure that the system works fine for the Inputs which the code dosen't designed for.

12) Negative testing is a testing which ensures that the application should not do what it is not supposed to do.

13) Negative testing is performed to check how the application works if an unexpected input is given which is out of requirements, to check the stability of the application. "For a error to be thrown it doesn’t throw error and error shouldn’t thrown it throws an error".

14) Testing the system using negative data is called negative testing, e.g. testing the password where it should be minimum of 8 characters so testing it using 6 characters is negative testing.

15) In negative testing, we check whether the application or system handles the exception properly or not. It is nothing but "Test to Break" testing.

Related Testing Topic
a. Black Box testing

2009-11-10T00:00:00.005-08:00

Software Testing Quotes

1. To find the bugs that customers see - that are important to customers - you need to write tests that cross functional areas by mimicking typical user tasks. This type of testing is called scenario testing, task-based testing, or use-case testing.

2. Testing a product is a learning process.

3. If the date is missed, the schedule was wrong. It doesn't matter why the date was missed. The purpose of the schedule was planning, not goal-setting.

4. Exploratory testing can be described as a martial art of the mind. It's how you deal with a product that jumps out from the bushes and challenges you to a duel of testing. Well, you don't become a black belt by reading books. You have to work on it. Happy practising.

5. The only person who likes change is a wet baby.

6. A fool with a tool is still a fool.

7. Quality is free, but only to those who are willing to pay heavily for it.

8. Ever Tried. Ever failed. No matter. Try again. Fail again. Fail better.

9. A day lost at the beginning of a project hurts just as much as a day lost at the end. ... There are infinitely many ways to loose a day ..but not even one way to get one back.

10. Winners never talk about glorious victories. That's because they are the ones who see what the battlefield looks like afterwards. It's only the losers who have glorious victories.

Related Testing Topics
a. Black Box testing

Software Testing Types

2009-11-10T00:00:00.001-08:00

Black Box testing refers to the technique of testing a system with no knowledge of the internals of the system. Black Box testers do not have access to the source code and are oblivious of the system architecture. A Black Box tester typically interacts with a system through a user interface by providing inputs and examining outputs without knowing where and how the inputs were operated upon. In Black Box testing, target software is exercised over a range of inputs and the outputs are observed for correctness.

Advantages

a. Efficient Testing — Well suited and efficient for large code segments or units.

b. Unbiased Testing — clearly separates user's perspective from developer's perspective through separation of QA and Development responsibilities.

c. Non intrusive — code access not required.

d. Easy to execute — can be scaled to large number of moderately skilled testers with no knowledge of implementation, programming language, operating systems or networks.

Disadvantages

a. Localized Testing — Limited code path coverage since only a limited number of test inputs are actually tested.

b. Inefficient Test Authoring — without implementation information, exhaustive input coverage would take forever and would require tremendous resources.

c. Blind Coverage — cannot control targeting code segments or paths which may be more error prone than others.

White Box Testing refers to the technique of testing a system with knowledge of the internals of the system. White Box testers have access to the source code and are aware of the system architecture. A White Box tester typically analyzes source code, derives test cases from knowledge about the source code, and finally targets specific code paths to achieve a certain level of code coverage. A White Box tester with access to details about both operations can readily craft efficient test cases that exercise boundary conditions.

Advantages

a. Increased Effectiveness — Crosschecking design decisions and assumptions against source code may outline a robust design, but the implementation may not align with the design intent.

b. Full Code Pathway Capable — all the possible code pathways can be tested including error handling, resource dependencies, and additional internal code logic/flow.

c. Early Defect Identification — Analyzing source code and developing tests based on the implementation details enables testers to find programming errors quickly.

d. Reveal Hidden Code Flaws — access to source code improves understanding and uncovering unintended hidden behavior of program modules.

Disadvantages

a. Difficult To Scale — requires intimate knowledge of target system, testing tools and coding languages, and modeling. It suffers for scalability of skilled and expert testers.

b. Difficult to Maintain — requires specialized tools such as source code analyzers, debuggers, and fault injectors.

c. Cultural Stress — the demarcation between developer and testers starts to blur which may become a cultural stress.

d. Highly Intrusive — requires code modification has been done using interactive debuggers, or by actually changing the source code. This may be adequate for small programs; however, it does not scale well to larger applications. Not useful for networked or distributed systems.

Difference between Black Box and White Box Testing

1. Synonyms for black-box include: behavioral, functional, opaque-box, and closed-box.

2. Synonyms for white-box include: structural, glass-box and clear-box.

3. Generally black box testing will begin early in the software development i.e. in requirement gathering phase itself. But for white box testing approach one has to wait for the designing has to complete.

4. We can use black testing strategy almost any size either it may be small or large. But white box testing will be effective only for small lines of codes or piece of codes.

5. In white box testing we can not test Performance of the application. But in Black box testing we can do it.

Gray Box Testing refers to the technique of testing a system with limited knowledge of the internals of the system. Gray Box testers have access to detailed design documents with information beyond requirement documents. Gray Box tests are generated based on information such as state-based models or architecture diagrams of the target system.

Advantages

a. Offers Combined Benefits — Leverage strengths of both Black Box and White Box testing wherever possible.

b. Non Intrusive — Gray Box does not rely on access to source code or binaries. Instead, based on interface definition, functional specifications, and application architecture.

c. Intelligent Test Authoring — Based on the limited information available, a Gray Box tester can author intelligent test scenarios, especially around data type handling, communication protocols and exception handling.

d. Unbiased Testing — The demarcation between testers and developer is still maintained. The handoff is only around interface definitions and documentation without access to source code or binaries.

Disadvantages

a. Partial Code Coverage — Since the source code or binaries are not available, the ability to traverse code paths is still limited by the tests deduced through available information. The coverage depends on the tester authoring skills.

b. Defect Identification — Inherent to distributed application is the difficulty associated in defect identification. Gray Box testing is still at the mercy of how well systems throw exceptions and how well are these exceptions propagated with a distributed Web Services environment.

Related Testing Topics

a. Testing Concepts

b. Error, Bug & Defect

c. Testing Models

d. Testing Techniques

e. Load testing

f. Usability Testing

g. Localization Testing

h. GUI Testing

i. QA, QC & Testing

j. Negative Testing

k. Severity vs Priority

l. Test Cases

m. Testing Tools

n. RTM, VV, Static and Dynamic Testing

Error and Bug in Software Testing

2009-11-09T23:59:00.003-08:00

1. Error/bug/defect/mistake are human intraction which produce an incorrect result.

Fault: Fault is a stage of software which is caused by an error/bug/defect/mistake.

Failure: It is a deviation of software from its expected delivery or service.

For eg.

you are driving a car and you are on road while on driving now there is two way on the road

a) left: mumbai

b) right: delhi

now you have to go to delhi it means you have to turn the stearing to the right, but by mistake you turn the stearing to the left, from that position that is called as "Error" because human intraction is there. and now Fault is there till you will not reach the mumbai, but when you reach mumbai that is a final stage which is called "Failure" becoz you had to reach delhi but now you are in Mumbai.

2. Differences in terms
a. Error: the mistakes made by developer in coding.

b. Bug: Found problem in application By Tester


c. Defect: Found problem in application By Customer after release

Difference Between Bug, Error, Defect and Issue

a. Bug: A software bug is an error, flaw, mistake, failure, or fault in a program that prevents it from behaving as intended (e.g., producing an incorrect result). Most bugs arise from mistakes and errors made by people in either a program's source code or its design, and a few are caused by compilers producing incorrect code.

b. Error: The mistake made by developer in coding.

c. Defect: Defect is something which is in the requirement document and it is not implemented or it is implemented in a wrong way.

d. Issue: Issue is something which is not all above, Some issues are there like site is slow, session related problems, security problems etc.

Related Testing Topic
a. Black Box testing

Difference between Performance and Load testing

2009-11-09T23:59:00.001-08:00

1. Performance Testing

In white box testing; testers, developers, system administrators and DBAs work together in order to instrument the application code and the database queries (via specialized profilers for example), and the hardware/operating system of the server(s) running the application and the database (via monitoring tools such as vmstat, iostat, top or Windows PerfMon). All these activities belong to performance testing.

The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.

These bottlenecks can exist at multiple levels:

a. at the application level, developers can use profilers to spot inefficiencies in their code (for example poor search algorithms)

b. at the database level, developers and DBAs can use database-specific profilers and query optimizers

c. at the operating system level, system engineers can use utilities such as top, vmstat, iostat (on Unix-type systems) and PerfMon (on Windows) to monitor hardware resources such as CPU, memory, swap, disk I/O; specialized kernel monitoring software can also be used

d. at the network level, network engineers can use packet sniffers such as tcpdump, network protocol analyzers such as ethereal, and various utilities such as netstat, MRTG, ntop, mii-tool.

From a testing point of view, the activities described above all take a white-box approach, where the system is inspected and monitored "from the inside out" and from a variety of angles.

2. Load Testing

Are you actively profiling your application code and/or monitoring the server(s) running your application? If the answer is yes, then you're engaged in performance testing. If the answer is no, then what you're doing is load testing.
In the testing literature, the term "load testing" is usually defined as the process of exercising the system under test by feeding it the largest tasks it can operate with. Load testing is sometimes called volume testing, or longevity/endurance testing.

Examples of volume testing

a. testing a word processor by editing a very large document

b. testing a printer by sending it a very large job

c. testing a mail server with thousands of users mailboxes

d. a specific case of volume testing is zero-volume testing, where the system is fed empty tasks

Examples of longevity/endurance testing

a. testing a client-server application by running the client in a loop against the server over an extended period of time

Goals of load testing

a. expose bugs that do not surface in cursory testing, such as memory management bugs, memory leaks, buffer overflows, etc.

b. ensure that the application meets the performance baseline established during performance testing. This is done by running regression tests against the application at a specified maximum load.

Although performance testing and load testing can seem similar, their goals are different. On one hand, performance testing uses load testing techniques and tools for measurement and benchmarking purposes and uses various load levels. On the other hand, load testing operates at a predefined load level, usually the highest load that the system can accept while still functioning properly. Note that load testing does not aim to break the system by overwhelming it, but instead tries to keep the system constantly humming like a well-oiled machine.

3. Stress Testing

If you want to actually discover bugs and to see if your application fails and recovers gracefully, you need to do stress testing. Blast your Web server with double the number of users for example. Unplug network cables randomly (or shut down/restart switch ports via SNMP). Take out a disk from a RAID array.

The main purpose behind this madness is to make sure that the system fails and recovers gracefully.

Here are some ways in which stress can be applied to the system:

a. double the baseline number for concurrent users/HTTP connections

b. randomly shut down and restart ports on the network switches/routers that connect the servers (via SNMP commands for example)

c. take the database offline, then restart it

d. rebuild a RAID array while the system is running

e. run processes that consume resources (CPU, memory, disk, network) on the web and database servers

If chair is designed for 100 kg weight, and my weight is 70 kg then that testing is called as normal testing. If my weight is 100 kg then that testing is called as load testing. If my wt is 120 kg then that testing called as stress testing.

Difference between Performance and Load testing
a. Performance test: To determine or validate speed, scalability, and/or stability.
b. Load test: To verify application behavior under normal and peak load conditions
c. Stress test: To determine or validate an application’s behavior when it is pushed beyond normal or peak load conditions.
d. Capacity test: To determine how many users and/or transactions a given system will support and still meet performance goals.

Related Testing Topic

a. Black Box testing

Software Testing Models

2009-11-09T23:58:00.002-08:00

Scrum Development Process

Scrum is an agile method for project management. Scrum is a method for managing work and achieving very high productivity. A popular agile method for project management, Scrum is noted for its simplicity, its high level of transparency, and a team based approach to work.

Characteristics of Scrum

a. A product backlog of prioritized work to be done;

b. Completion of a fixed set of backlog items in a series of short iterations or sprints;

c. A brief daily meeting or scrum, at which progress is explained, upcoming work is described and impediments are raised.

d. A brief sprint planning session in which the backlog items for the sprint will be defined.

e. A brief sprint retrospective, at which all team members reflect about the past sprint.

Following are some practices for the Scrum:

a. Customers become a part of the development team. (i.e., Customer must be genuinely interested in the output.)

b. Frequent intermediate deliveries with working functionality.

c. Frequent risk and mitigation plans developed by the development team itself. Make it live, and continuous activity.

d. Daily status discussion with the team. – Standup meetings.

e. A daily discussion asking each team member:

1. What have you done since yesterday?

2. What are you planning to do by tomorrow?

3. Do you have any problems preventing you from accomplishing your goal?

f. Transparency in planning and module development – Let everyone know, who is accountable for what and by when.

g. Workplaces and working hours must be energized. – "Working more hours" does not necessarily mean "producing more output."

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed in its entirety before the next phase can begin. At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.

Advantages

a. Simple and easy to use.

b. Easy to manage due to the rigidity of the model – each phase has specific deliverables and a review process.

c. Phases are processed and completed one at a time.

d. Works well for smaller projects where requirements are very well understood.

Disadvantages

a. Adjusting scope during the life cycle can kill a project

b. Poor model for complex and object-oriented projects.

c. Poor model for long and ongoing projects.

d. Poor model where requirements are at a moderate to high risk of changing.

V-Shaped Model

Just like the waterfall model, the V-Shaped life cycle is a sequential path of execution of processes. Each phase must be completed before the next phase begins. Testing is emphasized in this model more so than the waterfall model though. The testing procedures are developed early in the life cycle before any coding is done, during each of the phases preceding implementation.

Requirements begin the life cycle model just like the waterfall model. Before development is started, a system test plan is created. The test plan focuses on meeting the functionality specified in the requirements gathering.

The high-level design phase focuses on system architecture and design. An integration test plan is created in this phase as well in order to test the pieces of the software systems ability to work together.

The low-level design phase is where the actual software components are designed, and unit tests are created in this phase as well.

The implementation phase is, again, where all coding takes place. Once coding is complete, the path of execution continues up the right side of the V where the test plans developed earlier are now put to use.

Advantages

a. Simple and easy to use.

b. Each phase has specific deliverables.

c. Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.

d. Works well for small projects where requirements are easily understood.

Disadvantages

a. Very rigid, like the waterfall model.

b. Software is developed during the implementation phase, so no early prototypes of the software are produced.

c. Model doesn’t provide a clear path for problems found during testing phases.

Spiral Model

The spiral model gives more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral.

Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase.

Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the project to date before the project continues to the next spiral.

In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Advantages

a. High amount of risk analysis.

b. Good for large and mission-critical projects.

c. Software is produced early in the software life cycle.

Disadvantages

a. Can be a costly model to use.

b. Risk analysis requires highly specific expertise.

c. Project’s success is highly dependent on the risk analysis phase.

d. Doesn’t work well for smaller projects.

Related Testing Topic
a. Black Box testing

Severity vs Priority in Software Testing

2009-11-09T23:58:00.000-08:00

Severity: Severity determines the defect's effect on the application. Severity is given by Testers

Priority: Determines the defect urgency of repair. Priority is given by Test lead or project manager

1. High Severity and Low Priority : For example an application which generates some banking related reports weekly, monthly, quarterly & yearly by doing some calculations. If there is a fault while calculating yearly report. This is a high severity fault but low priority because this fault can be fixed in the next release as a change request.

2. High Severity and High Priority : In the above example if there is a fault while calculating weekly report. This is a high severity and high priority fault because this fault will block the functionality of the application immediately within a week. It should be fixed urgently.

3. Low Severity and High Priority : If there is a spelling mistake or content issue on the homepage of a website which has daily hits of lakhs. In this case, though this fault is not affecting the website or other functionalities but considering the status and popularity of the website in the competitive market it is a high priority fault.

4. Low Severity and Low Priority : If there is a spelling mistake on the pages which has very less hits throughout the month on any website. This fault can be considered as low severity and low priority.
Priority is used to organize the work. The field only takes meaning when owner of the bug
P1 Fix in next build
P2 Fix as soon as possible
P3 Fix before next release
P4 Fix it time allow
P5 Unlikely to be fixed
Default priority for new defects is set at P3

Related Testing Topic

a. Black Box testing

GUI (Graphical User Interface) Testing

2009-11-09T23:49:00.001-08:00

GUI testing is a process to test application's user interface and to make sure that it confirms the design requirements.

1. Text Box
a. Move the Mouse Cursor over all Enterable Text Boxes. Cursor should change from arrow to Insert Bar.
b. If it doesn't then the text in the box should be grey or non-updateable.
c. Try to overflow the text by typing to many characters.
d. Enter invalid characters - Letters in amount fields, try strange characters like + , - * etc. in All fields.
e. SHIFT and Arrow should Select Characters. Selection should also be possible with mouse. Double Click should select all text in box.

2. Radio Button:
Left and Right arrows should move ON Selection. So should Up and Down. Select with mouse by clicking.
Check Boxes: Clicking with the mouse on the box, or on the text should SET/UNSET the box. SPACE should do the same.

3. Command Buttons
a. If Command Button leads to another Screen, and if the user can enter or change details on the other screen then the Text on the button should be followed by three dots.
b. All Buttons except for OK and Cancel should have a letter Access to them. This is indicated by a letter underlined in the button text. The button should be activated by pressing ALT+Letter. Make sure there is no duplication.
c. Click each button once with the mouse - This should activate
Tab to each button - Press SPACE - This should activate
Tab to each button - Press RETURN - This should activate
d. If there is a Cancel Button on the screen , then pressing should activate it.

4. Aesthetic Conditions:
a. Is the general screen background the correct colour?
b. Are the field prompts the correct colour?
c. Are the field backgrounds the correct colour?
d. In read-only mode, are the field prompts the correct colour?
e. In read-only mode, are the field backgrounds the correct colour?
f. Are all the screen prompts specified in the correct screen font?
g. Is the text in all fields specified in the correct screen font?
h. Are all the field prompts aligned perfectly on the screen?
i. Are all the field edit boxes aligned perfectly on the screen?
j. Should the screen be resizable?
k. Should the screen be minimisable?
l. Is all user input captured in UPPER case or lower case consistently?

5. Validation Conditions:
a. Does a failure of validation on every field cause a sensible user error message?
b. Is the user required to fix entries which have failed validation tests?
c. Have any fields got multiple validation rules and if so are all rules being applied?
d. If the user enters an invalid value and clicks on the OK button (i.e. does not TAB off the field) is the invalid entry identified and highlighted correctly with an error message.?
e. Is validation consistently applied at screen level unless specifically required at field level?
f. For all numeric fields check whether negative numbers can and should be able to be entered.
g. For all numeric fields check the minimum and maximum values and also some mid-range values allowable?
h. For all character/alphanumeric fields check the field to ensure that there is a character limit specified and that this limit is exactly correct for the specified database size?
i. Do all mandatory fields require user input?
j. If any of the database columns don't allow null values then the corresponding screen fields must be mandatory. (If any field which initially was mandatory has become optional then check whether null values are allowed in this field.)

6. Usability Conditions:
a. Is all date entry required in the correct format?
b. When an error message occurs does the focus return to the field in error when the user cancels it?
c. Do all the fields edit boxes indicate the number of characters they will hold by there length? e.g. a 30 character field should be a lot longer

7. Data Integrity Conditions:
a. Check the maximum field lengths to ensure that there are no truncated characters?
b. Check maximum and minimum field values for numeric fields?
c. If numeric fields accept negative values can these be stored correctly on the database and does it make sense for the field to accept negative numbers?

8. Date Field Checks
a. Assure that leap years are validated correctly & do not cause errors/miscalculations
b. Assure that month code 00 and 13 are validated correctly & do not cause errors/miscalculations
c. Assure that 00 and 13 are reported as errors
d. Assure that day values 00 and 32 are validated correctly & do not cause errors/miscalculations
e. Assure that Feb. 28, 29, 30 are validated correctly & do not cause errors/ miscalculations
f. Assure that Feb. 30 is reported as an error
g. Assure that century change is validated correctly & does not cause errors/ miscalculations

9. Alpha Field Checks
a. Use blank and non-blank data
b. Include lowest and highest values
c. Include invalid characters & symbols
d. Include valid characters
e. Include data items with first position blank
f. Include data items with last position blank

Related Testing Topic:
a. Black Box testing

Free Automation Tools used for Software Testing

2009-11-09T23:48:00.000-08:00

1. Add-on Pinger to find broken links:
Firefox Add-on Pinger 1.0.2

Pinger Description - Looks for broken links on page, links that are not working anymore - returning 404 code. You can select to check whole page, or just links in selection.

2. Tool to find broken links online:

Summary of the features:

- Checks your websites for dead links

- Can scans 3000 web-pages

- Validates both internal and external URLs

- Shows problematic link's location is your HTML code !!!

- For bad URLs reports HTTP response code: 404 etc

- Can be used on Mac, iPad, Linux, UNIX, Windows

3. Fireshot to save screenshots:

Fireshot: Screenshots can be saved to disk (PNG, GIF, JPEG, BMP), printed (NEW), copied to clipboard, e-mailed and sent to external editor for further processing.

4. Firebug to monitor HTML:

Firebug: Integrates with Firefox to put a wealth of development tools at your fingertips while you browse. You can edit, debug, and monitor CSS, HTML, and JavaScript live in any web page.

5. Selenium used for regression testing:
Selenium: Used for functional testing

What are the components of selenium ?
Selenium IDE - Plugin to Firefox to record and play test in firefox
and also export tests in different languages. The most appealing
format is the html test case which seems to based on fit html .
Selenium RC- Allows playing of exported test in different platform/OS
Selenium Grid - Allows to control lots of selenium machines.

6. Tool used for performance testing:

Web page performance (speed) - Page Speed generates its results based on the state of the page at the time you run the tool. To ensure the most accurate results, you should wait until the page finishes loading before running Page Speed. Otherwise, Page Speed may not be able to fully analyze resources that haven't finished downloading.

7. Tool used to create video (steps to reproduce bug):
Screencast-O-Matic is the original free and easy way to create a video recording of your screen (aka screencast) and upload it for free hosting all from your browser with no install!

8. Compatibility testing of browser:
Adobe BrowserLab [Provide screen shots]:

Adobe BrowserLab is an online hosted service that lets you test the pages of your web site across a variety of web browsers and operating systems. The service works by taking screen shots of your web pages in different browsers, and then displaying them in the BrowserLab application window.

You can use BrowserLab as a standalone service, or integrated with Dreamweaver CS4. The standalone service lets you test pages that you've posted to a server within the context of a web browser. If you use BrowserLab as an integrated service with Dreamweaver, you can test your pages from within Dreamweaver without publishing your pages to a server.

BrowserLab supports the following browsers:

• Firefox 2.0 - Windows XP
• Firefox 3.0 - Windows XP
• Firefox 3.5 - Windows XP
• Chrome 3.0 - Windows XP
• Internet Explorer 6.0 - Windows XP
• Internet Explorer 7.0 - Windows XP
• Internet Explorer 8.0 - Windows XP
• Safari 3.0 - Macintosh OS X
• Safari 4.0 - Macintosh OS X
• Firefox 2.0 - Macintosh OS X
• Firefox 3.0 - Macintosh OS X
• Firefox 3.5 - Macintosh OS X

9. Compatibility testing of browser:
Browser Sandbox [Run any browser from the web]

• Microsoft Internet Explorer 8
• Internet Explorer 7
• Internet Explorer 6
• Mozilla Firefox 3.5
• Firefox 3
• Firefox 2
• Apple Safari 4
• Safari 3
• Google Chrome
• Opera 10
• Opera 9

My Comments as a Tester:
a. Adobe BrowserLab will be helpful to compare the designs of multiple Browsers.
b. Browser Sandbox will be helpful to test the functionality and design on multiple Browsers.

10. powercfg /energy:
Generate "Power Efficiency Diagnostics Report" by running the command powercfg /energy

11. Summary:
1. Bug Tracking Tool: Bugzilla
2. Recording the bug in video format: Screencast-o-matic
3. Tool for taking Screen-shots for reporting the bug: Fireshot
4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab
5. Tool to Monitor CSS and HTML: Firebug
6. Tool to ensure valid HTML: HTML Validator
7. Performance Testing tool: Page Speed by Google
8. To find Broken Links: Pinger Ad-on and brokenlinkcheck
9. For checking the spelling of content: Spell Check
10. powercfg command

Related Testing Topic:
a. Black Box testing

Creativity of Software Testers

2009-11-09T23:47:00.000-08:00

Re: CreativityThe comparison with the harvester and the hunter seems quite good!

However, the developer/designer should also fulfill the position of a “sower” as well. If they take care to “sow” the right stuff, there will be less to “de-weed” and as a result a better crop for all!!!

The harvest will of course be good too :)
After all, you reap what you sow!!

- C

Creativity of Testers:

As in many different professions, opportunities for creativity exist, but they are not all available at all levels. Comparing the tester's goals to the developer's goal, you can say that the developer looks for one solution that fits the specifications, while the tester has to (should) find all the defects that were introduced in the development process (from specificaiton to code). As such the challenge is much more interesting, just as the challenge for the "hunter" is greater than for the "harvester".

You will enjoy creativity in coming up with different attacks (methods for finding defects) to show presence (or absence) of defects. However, it is most likely that you will first have to execute tests created by others (less creativity here). Then you will have enough understanding of the different types of possible defects, and conceive new tests that others will execute (more creativity).

In the end you may come up with completely new paradigms on testing, and that is the greatest creativity possible.

The creativity is not based on company, nor on the team where you will work. It is based only on how you look at your work: if you limit yourself to executing again and again the same activity (without learning new things) then it will not be creative. If you limit the scope of your thoughts you will not find creativity. On the other hand, if you challenge your own knowledge and try to expand it always, then you will have the opportunity to be both creative and recognized by your peers.

Venkat has asked following simple question:

"I have a question. I am new to testing field.
Developers can not test there code while developing there code and save time? Sorry if my question sounds silly."

Then I gave him following answer:

1. Every director likes his own movie no matter movie is good or bad. Only audience can tell whether the movie is good or bad.

2. Mother of ugly child can not admit that her child is ugly. For her, her child is the most beautiful child in the world.

Similarly how can developer tell you that project has bug or not. A person who create anything can not find any bad thing in it.

If any one has other examples then please add below.

Related Testing Topic:
a. Testing Experiences
b. Having Other People Test....
c. Black Box testing

Realities of QA in Software Testing

2009-11-09T23:44:00.000-08:00

1. I have seen in my experience till now that position of QA is least in most of the organizations.
2. No body is aware about QA. Nobody knows the value of QA. But they can take decisions on QA tasks/plans easily.
3. Everyone thinks that any person can perform QA tasks on any project.
4. QA always dances on the fingers of Developers.
5. Developers decides who will be the QA of their project.
6. Developers decides which bug should be address to the client because it can harm their positions.
7. When new comers come to any organization they do not want to become QA because of above points.
8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.

Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final drop before 1-2 hours of product delivery.
And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.

Please forgive QAs and try to understand their feelings afterall they are also human beings.

Here are the valuable comments on invaluable article written above:

Yes! Rajiv,
you are very true!! Now a days nobody was have QA scene!
-Krish

Yes rajiv, it's really true
-Vaneeta

Yes..
That is 100 % correct
I am also agreeing with Rajeev
-Sarath

Totally agree, for a real QA there must be an active compromise from management leaders making sure that everyone is aware of QA, and protecting the space of QA within a company or project environment.
-Antonio

HI Rajiv and Guys!
I really appreciate your effort and feelings about QA position in the present industry.
Exactly I am in a same situation where u have explained the points. In my current project, DEV team did not fixed the bugs and repeatedly client reported bugs. My manager thinks that everybody can test an application to catch bugs.
But in my view, Testing of the application is not that much easy as people thinking.
Let me give one example: One developer will write the code to fulfill one requirement and not to break by a tester with maximum number of scenarios. But a tester has to think technically & realistically (as a end user) to break the application with more number of scenarios as a developer thinks and finally breaks the system.
Let me know if I wrote anything wrong.
Thanks
-Arif

Sad, but true :/
-LadyRoot

I've seen a lot of agreement with Rajiv's observations, but I must say that it's not true in every company. In my experience it's been more true in the larger corporate environments, but I'm currently working with a small company where the QA department is greatly appreciated, the developers are eager to fix bugs, and they actually want the input from QA.
I would also like to point out that even in the large corporate environments I achieved a high level of success with the developers (managers were a completely different story). I used the principles from Cem Kaner's Defect Advocacy course and taught it to my entire team. While convincing management of our true value was never achieved, we had most of the developers wanting our testing and responding to our defects. A lot of how they react to our bug reports is dependent on how we approach them with the defects. Continuing to hold an attitude of "us vs. them" tends to make them put up defensive walls whereas an approach of helping them produce better code produces more of a teamwork atmosphere.
I'd highly recommend going through Cem's course (http://www.testingeducation.org/BBST/BBSTbugAdvocacy.htm) and applying what you learned to your environment. You can often change the environment by changing your approach.
-Thad Butterworth me too in the same situation

-Venkatesalu

1. I have seen in my experience till now that position of QA is least in most of the organizations.
Ravi: Its not in my Organization. I feel you have not seen much in your life.

2. No body is aware about QA. Nobody knows the value of QA. But they can take decisons on QA tasks/plans easily.
Ravi:
- No one will be aware of anything, unless its been proven.
- Prove yourself, test & expose the s/w in all ways.
- For all this you must be aware of the system like anyone else developing it, designing it.
- If you look at all projects like a user then you will be treated as common.

3. Everyone thinks that any person can perform QA tasks on any project.
5. Developers decides who will be the QA of their project.

Ravi:
- It may happen initially, but once your QA team gain some expertise then you can assign some person.
- If all of the team members are doing user level / black box testing then its obvious that anyone can do the job.

4. QA always dances on the fingers of Developers.
Ravi:
- Whomesoever doesn't have knowledge on system dance on other person fingers.
- Its applicable for another developer too, so learn about the system in much more details and expose s/w by all means.

6. Developers decides which bug should be address to the client. because it can harm their positions.

Ravi:
- If its might be a business decision.
- But keep a record of all the issues through mail and get their reply in specified time and save them so that at adverse time you can expose with details.

7. When new joinies come to any organization thay do not want to become QA because of above points.
Ravi:
You must be proud of yourself being a tester first, are you ??

8. Everyone thinks that there is no career in manual testing only automation is required to build career in software testing.
Ravi:
I feel you must be aware of system / OS to be a better tester.

9. Result: Bad quality of product, issues issues and more issues are reported by client. Client can report the issues because he has enough free time to explore the product.
Poor QA can not report these bugs because he did not get the product for testing in time. Developers always eat tester's time like a burger and provide final drop before 1-2 hours of product delivery. And then everybody expects from Tester that he should test the whole application in 1-2 hours. QA is not an invaluable object on which anybody kicks.
Ravi:
- This might be applicable for development team too by giving small time for development.
- You must have good managerial skill to tackle these kind of issues.
- Give your report specifying basic testing alone executed and details testing is not done due to lack of timing constrains.

10. Please forgive QAs and try to understand their feelings afterall they are also human beings.
Ravi:
- Don't plead for QA's, QA is in good position only. You need to improve your knowledge & other soft skills.

I aggree with Rajiv's points. Its true man!
Although it is not true in my current company but in my previous
company this was so very true.
-Mugen

A debate should remain healthy but I see points that can turn this into something else.
I am also working as a tester & I believe some of the points both you gentlemen (Ravi & Rajiv) are correct, Though I feel Ravi has better points.
At some point everyone remain unsatisfied whether he is developer or tester. And Rajiv, you would be agree that there are few companies where developer feel same as you wrote about testers. Tester is not any pitiful animal, he has his points & if management decides to disagree with his point of view it does not mean that he is worthless.
I refuse to accept my job on the points you wrote however some of them might be correct in your context.
People will feel pity for you only if you represent yourself as one helpless creature.
All in all, its up to me how I take & value my job & it does not need any debate to change my point of view. I value it, I know its worth & hence I am here.
Instead of writing this stuff lets concentrate on the queries on testing, problems & the solutions. We are not here to create any minority group but we re professionals.
-Vikas

First of all, let's clarify what you are talking about. I've got a
feeling that you speak of testing rather than QA role.
It can be that testers are undervalued in some organization but it
isn't true for all organizations. As they say a fish starts getting
spoiled from the head. If top management sees testers like monkey,
like under qualified working force then others in organization are
most likely to share this vision.
Also, a lot is in hands of a test manager. His or her primary goal is
to provide quality working conditions to the performers. Treating like
pigeons by management or developers will hardly make team moral
better. Test team manager should keep defining comfortable working
atmosphere by loosing strain between testers and developers. I did it
many times in my career. The best way is to explain tester that this
is natural for developers to express their bad feeling about discovery
of an issue, so we need to learn how to politely ignore the first
expression and keep the voice of discussion down. On another hand I
kept preaching to developers that we are all in same boat, that
testers are just like them but simply doing another work, that this is
much better that we have found earlier than later.
So, this is frustrating to be undervalued, but you can do something
about it.
-Vladimir Trushkin

Hi Vikas,
Thanks for the beautiful reply. I know Ravi's points are better. I am also not facing these problems in my current organization.
But I have written this article on behalf of my friends who are working in different organizations. Also I have taken survey on this and found that more than 70 % people are facing these problems. I have written just the problems of those people who are working in different organizations and facing similar problems.
My motive is not to tell just the problem. I wanted to discuss the proper solution on these points.
We can do this only if we *all* agree on the points which I have written. We have to admit that many testers are facing these problems. If we will not going to admit this then we can not help them.
I am not satisfy with your comment i.e.
"Instead of writing this stuff lets concentrate on the queries on testing, problems & the solutions. We are not here to create any minority group but we re professionals."
I think this Google group is not created for just to discuss theory part. We should also discuss these types of real time challenges which we face practically. And I do not want to create any minority group but I want to help people who belongs to my profession. Because..
I am proud of my testing profession.
So I request you all, first of all please agree with my points then provide your solutions. Otherwise this debate will be endless.
I am sorry in advance if anyone of you think that I am wrong.
-Rajiv

Hi all,
appart of my initial agreement with the initial message by Rajiv I would like to add the following as a paradigm in perharps many of these organisations where testing tasks are compromised and QA not managed as a whole. Let me know how many of you agree:
1 - Selling is the real constraint, no matters what is going to be sold.
2 - The product is not completelly specified normally so that the whole project is opened to any customer's request.
3 - Eventually any request may arrive for development without any analysis work done about feasibility or impact in the project's current state.
4 - If new requests impact is not taken into acount, milestones' deadlines may not be postponed accordingly.
5 - The project goes into a state in which there are more tasks to do than planned and there is less time for them than planned.
6 - Since development happens before than testing (obvious, I know), development takes integration and verification time.
7 - Hopefully testers just perform some sanity tests of a recently integrated product version before releasing the product.
My conclusion after all these comments: it is a must that management believes in QA and works for it, giving enough flexibility for selling but always allowing time for analysing, developping and verifying what is being done as a product.
All the best,
-Antonio

Related Testing Topics:
a. Black Box testing
b. Testing Experiences

Software Testing in Agile

2009-11-09T23:42:00.001-08:00

Agile means being able to quickly change direction. Agile software development is a group of software development methodologies.

Agile software development methods:
1. Agile Modeling
2. Agile Unified Process (AUP)
3. Dynamic Systems Development Method (DSDM)
4. Essential Unified Process (EssUP)
5. Extreme Programming (XP)
6. Feature Driven Development (FDD)
7. Open Unified Process (OpenUP)
8. Scrum
9. Velocity tracking

Agile method: Scrum (development)
Scrum is an iterative incremental process of software development commonly used with agile software development.

Software developed during one unit of time is referred to as an iteration, which typically lasts from two to four weeks. Each iteration passes through a full software development cycle, including planning, requirements analysis, design, writing unit tests, then coding until the unit tests pass and a working product is finally demonstrated to stakeholders.

The Product Backlog is the master list of all functionality desired in the product. A product or a project backlog is a prioritized list of requirements with a rough size and complexity estimate of each requirement. Hence, the backlog has 3 components: requirements, priority, rough size and complexity estimate.

Sprint Backlog: The sprint backlog is the list of tasks that the Scrum team is committing that they will complete in the current sprint. Items on the sprint backlog are drawn from the Product Backlog, by the team based on the priorities set by the Product Owner.

Daily SCRUM meeting rules:
1. Hold the daily scrum in the same place at the same time every work day.
2. All team members are required to attend.
3. The scrum master begins the meeting by starting with the person to his or her left and proceeding counter clockwise around the room until everyone has reported.
4. Each team member should respond to three questions only:
a) What have you done since the last daily scrum regarding this project?
b) What will you do between now and the next daily scrum meeting regarding this project?

QC Process followed in small companies

1) If there is small project then we opt for Ad-hoc testing. Ad-hoc testing is done without test cases. But for this, software tester should have enough knowledge about the project. And it is done by experienced QA engineer.

2) If software tester don't know anything about the project then we perform exploratory testing on that project. We explore all the features and then create and execute test cases.

3) In general, following Testing process is followed by small companies:

a) Requirement Stage: Analyze requirement document, discuss with team internally, ask doubts from client if required.

b) Test Plan: Create test plan which defines the type of testing should be done, who will test this, duration for which we have to test, availability of test resources, types of Testing performed, features to be tested, features not to be tested etc.

4) Test Cases: Test cases (sequence of steps to test the correct behavior of a functionality) are prepared by reviewing the functional requirements in use cases or by
exploring the application.

5) Execution of Test Cases: Each test case is executed by more than one QC engineer and on different configuration PCs to ensure that its working 100% fine.

6) Instant Bug reporting: If we find number of bugs then initially we report the bugs in excel sheet and send it to developers so that they can make a proper plan and start work on it.

7) Bug reporting in bug tracking tool: Then we post each bug with more details in to bug tracking tool.

8) Explain the required bug to developer with exact scenario

9) Re test the issue fixed by developer

10) Mark the status in bug tracking tool.

Related Testing Topics:
a. Black Box testing
b. Testing for Beginners
c. Smartphone Testing

Usability Testing

2009-11-09T23:41:00.005-08:00

Usability testing is a technique used to evaluate a product by testing it with representative users.

Elements of Usability Testing:
a. Participation of QA and designers.
b. Participation of sample end users (Non Team Members).
c. Observation by test moderator.
d. Development of research questions.
e. Recomendation of improvements to the design of the product.

Limitation:

a. Testing is always an artificial situation.
b. Test results do not prove that product works.
c. Participants are rarely fully representatives of the target population.

Types of usability tests:

a. Exploratory or formative study: is conducted quite early in the development cycle.

b. Assessment or Summative Test: are conducted after fundamental or high-level design or organization of the product has been established.

c. Verification or Validation Test: To confirm that problems discovered earlier have been remedied and that new ones have not been introduced. This test takes place much closer to the release of the product.

Usability testing VS GUI testing:

GUI testing is a process to test application's user interface and to make sure that it confirms the design requirements. e.g are the colors, fonts and control placements done according to the specs?

Usability testing goes much more into human factoring. Examples of Usability issues:

1. Long Scrolling Pages

2. Non-Standard Link Colors

3. Complex Website Addresses (URLs)

Related Testing Topic:
a. Black Box testing

Localization Testing

2009-11-09T23:41:00.003-08:00

In order to perform Localization testing, test engineer should follow following levels:

Globalization Testing (Internationalization Testing): The goal of globalization testing is to detect potential problems in application design that could inhibit globalization. It makes sure that the code can handle all international support without breaking functionality that would cause either data loss or display problems. Globalization testing checks proper functionality of the product with any of the culture/locale settings using every type of international input possible.

Localizability Testing: Localizability testing verifies that you can easily translate the user interface of the program to any target language without re-engineering or modifying code. Localizability testing catches bugs normally found during product localization, so localization of the program is required to complete this test. Successful completion of localizability testing indicates that the product is ready for localization. You can use pseudo-localization to avoid the time and expense of true localization.

The most effective way to perform pseudo-localization is to modify the program's resources automatically. For example, here is what English-speaking localizers do when they translate a program's UI:

a. Replace English text with text containing non-English characters. For example: For a, use à or å For c, use ĉ or ç For n, use ń or ñ.

b. Add extra characters to your resource strings. In many cases translated text is longer than the English original ("some string" becomes "+++some string+++").

c. Stretch your dialog boxes. Localizers usually do this when the string length grows due to localization.

Localization Testing: Localization translates the product UI and occasionally changes some initial settings to make it suitable for another region. Localization testing checks the quality of a product's localization for a particular target culture/locale. This test is based on the results of globalization testing, which verifies the functional support for that particular culture/locale. Localization testing can be executed only on the localized version of a product.

Related Testing Topic:
a. Black Box testing

Checklist for Website Testing

2009-11-09T23:40:00.001-08:00

Here you can find the checklist for web testing. By using the checklist for web application testing, user can create test cases for any web based application:

Step 1 - User Interface Testing (GUI Testing):

a. Content wording used in the web pages should be correct.

b. Wrap-around should occur properly.

c. Instructions used in web pages should be correct (i.e. if you follow each instruction does the expected result occur?)

d. Check image size specifications: Check that at least the text of the page appears quickly.

e. View in text browser: Test each web page in text-only browser, or text-browser emulator. It will help you pick up on badly-chosen or missing ALT texts.

f. Switch images off: Check that sensible ALT texts have been provided for images.

g. Check sensible page titles.

h. Resolution change effect on web pages.

i. Image spacing – To verify that images are displaying properly with text.

j. Print – Pinting should be proper.

For more information about GUI testing, kindly refer to http://puretest.blogspot.com/2009/11/gui-testing.html

Step 2 - Functional Testing

a. Check for broken links (Broken link refers to a hyperlink which does not work): Manually its very difficult to find broken links. There are various tools available to find these, such as:

- Broken Link Check

- Firefox Add-on Pinger 1.0.2

b. Validate the HTML: Make sure that you have valid HTML (or XHTML). This can be done with a W3C validator

c. Disable the cookies from your browser settings. If you are using cookies on your site, your sites major functionality will not work by disabling the cookies. See if appropriate messages are displayed.

(A cookie is a small piece of information stored as a text file on your computer that a web server uses when you browse certain web sites that you've visited before).

d. Switch JavaScript off: It is important to check that your site still functions with Javascript disabled or provide proper Javascript error message:
e.g. “enable Javascript to see animation of Intelligaia Technologies”.

e. Warning messages: Error/warning messages should be flash to user for incorrect inputs.

Step 3 - Interface Testing

a. Data display on browser should match with data available on server: To test browser and server interface, run queries on the database to make sure the transaction data is being retrieve and store properly.

b. Error Handling: Make sure system can handle application errors.

Step 4 - Compatibility Testing

a. Test on different Operating systems: Test your web application on different operating systems like Windows (XP, Vista, Win7 etc), Unix, MAC, Linux, Solaris with different OS flavors.

b. Test on different Browsers: Test web application on different browsers like:

- Firefox, as that has the best standards compliance and is the second most-used browser.

- Internet Explorer for Windows – currently the most widely used browser (IE6, IE7, IE8).

- Opera – growing in popularity due to its speed and pretty good standards compliance.

c. Mobile browsing: This is new technology age. So in future Mobile browsing will rock. Test your web pages on mobile browsers. Compatibility issues may be there on mobile.

Step 5 - Security Testing

a. Limit should be defined for the number of tries: Is there a maximum number of failed logins allowed before the server locks out the current user?

b. Verify rules for password selection.

c. Is there a timeout limit?

d. Test by pasting internal url directly into browser address bar without login. Internal pages should not open.

e. Test the CAPTCHA for automates scripts logins.

f. Test if SSL is used for security measures. If used proper message should get displayed when user switch from non-secure http:// pages to secure https:// pages and vice versa.

g. All transactions, error messages, security breach attempts should get logged in log files somewhere on web server.

h. Clear your Cache: Be sure to clear the browser cache, including cookies, before each test.

i. SQL injection: To test for SQL injection bugs, find places where users can enter text, such as where the text is used to perform a lookup function, according to Breach. Then type a single quote character and some text. If the application shows an error message from your database, then you're likely housing an SQL injection bug.

(SQL injection is an attack in which malicious code is inserted into strings that are later passed to an instance of SQL Server for parsing and execution.)

j. Cross-site scripting (XSS): Find areas in your application that accept user input, such as a page where users can send in their feedback or reviews of a product, for example. Try submitting following:
1. >"'><script>alert(‘XSS')</script>
2. >%22%27><img%20src%3d%22javascript:alert(%27XSS%27)%22>
3. >"'><img%20src%3D%26%23x6a;%26%23x61;%26%23x76;%26%23x61;%26%23x73;%26%23x63;%26%23x72;%26%23x69;%26%23x70;%26%23x74;%26%23x3a;alert(%26quot;XSS%26quot;)>
4. AK%22%20style%3D%22background:url(javascript:alert(%27XSS%27))%22%20OS%22
5. %22%2Balert(%27XSS%27)%2B%22
6. <table background="javascript:alert(([code])"></table>
7. <object type=text/html data="javascript:alert(([code]);"></object>
8. <body onload="javascript:alert(([code])"></body>

If that text displays where you reload the page, then your site has an XSS vulnerability.

(Cross-site scripting attacks occur when a malicious person, the attacker, can force an unknowing user, the victim, to run client-side script of the attacker’s choice. The term cross-site scripting is sort of a misnomer, because it’s not just about scripting and it doesn’t even have to be cross-site. It’s a name that was branded upon its discovery and it has just stuck.)

k. Session hijacking: If your application has a session identifier number in the URL decrease that number by one and reload the page. The app has a session hijacking vulnerability if the app then "sees" you as a different user.

(Session hijacking, also known as TCP session hijacking, is a method of taking over a Web user session by surreptitiously obtaining the session ID and masquerading as the authorized user. Once the user's session ID has been accessed (through session prediction), the attacker can masquerade as that user and do anything the user is authorized to do on the network.)

Step 6 - Performance testing

a. Can your site handle a large amount of users requesting a certain page.

b. Long period of continuous use: Is site able to run for long period, without downtime.

For more information about Load testing, kindly refer to: http://puretest.blogspot.com/2009/11/performance-testing-1.html

c. Web page performance (speed) - Page Speed generates its results based on the state of the page at the time you run the tool. To ensure the most accurate results, you should wait until the page finishes loading before running Page Speed. Otherwise, Page Speed may not be able to fully analyze resources that haven't finished downloading.

Free Tools which plays very important role in web site testing:
1. Bug Tracking Tool: Bugzilla

2. Recording the bug in video format: Screencast-o-matic
3. Tool for taking Screen-shots for reporting the bug: Fireshot
4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab
5. Tool to Monitor CSS and HTML: Firebug
6. Tool to ensure valid HTML: HTML Validator
7. Performance Testing tool: Page Speed by Google
8. To find Broken Links: Pinger Ad-on and brokenlinkcheck
9. For checking the spelling of content: Spell Check

Related Testing Topics:
a. Desktop App Testing Checklist
b. Test Cases
c. Testing Tools

Checklist for Desktop Application Testing

2009-11-09T23:39:00.003-08:00

Level 1 - User Interface Testing (GUI Testing):
a. Content wording used in the web pages should be correct.

b. Wrap-around should occur properly.

c. Instructions used in the application should be correct (i.e. if you follow each instruction does the expected result occur?)

d. Image spacing – To verify that images are displaying properly with text.

Level 2 - Functional Testing
a. Check for broken links (Broken link refers to a hyperlink which does not work).

b. Warning messages: User input should get verified at system level according to business rules and error/warning messages should be flash to user for incorrect inputs.

c. Resolution change effect on the application: Ensure that application's functionality and design is compatible with the different resolutions.

d. Print: Following points must be verified

- Test the print functionality of the application when no printer connected - application should behave correctly if printer is not available.

- Test the print functionality of the application when printer is connected

- Ensure that application queues prints in printer if papers are not available in printer.

- To ensure that lengthy description of an event is not truncating on print layout in selected event printing.

e. Theme change: Ensure the successful launch of application after theme change.

f. Installation Testing (Upgrade/Downgrade): Verify application is included in Programs and Features list after installation. Also Verify application is removed from Programs and Features list after un installation. Keep in mind that older version of application should not be install on latest version.

g. Testing with multi user accounts: Open Control Panel, User Accounts, and add 2 user accounts (Standard and admin) to the system. With the application running, press Start, the Switch User to the user account just created.
Verify application launches and runs correctly on the newly created user account. Switch back and forth between user accounts and use the application in both. Watch for any performance decreases and check functionality.

h. Sleep: While the application is running, put the system to sleep (S3). Wake the system up after two minutes.
a) Verify the application is still running.
b) Verify there is no distortion or error.

i. Cache:
- Delete the application's cache, launch the application and verify that application should work properly.
- Delete the application's cache while application is running and verify that application should work properly.

Level 3 - Compatibility Testing
a. Test on different Operating systems: Some functionality in your web application may not be compatible with all operating systems. All new technologies used in web development like graphics designs, interface calls like different API’s may not be available in all Operating Systems.
Test your web application on different operating systems like Windows (XP, Vista, Win7 etc), Unix, MAC, Linux, Solaris with different OS flavors.

Level 4 - Performance testing
a. Long period of continuous use: Is site able to run for long period, without downtime.

b. Memory: Note down the average memory usage in Comments column.

c. Generate "Power Efficiency Diagnostics Report" by running the command powercfg /energy

Related Testing Topics:
a. Web Testing Checklist
b. Test Cases
c. Testing Tools
d. Power Efficiency Diagnostics Report

Regression Testing Tool - Selenium 3 Interview Questions and Answers

2009-11-09T23:39:00.001-08:00

Selenium 3 – Interview Questions

1) What is selenium?

Its an open source Web Automation Tool. It supports all types of web browsers.

2) Advantages of Selenium?

· No License fees

· Supports large number of progremming language for scripting

· Support large number of browsers.

· With Selenium Grid, we can execute in parallel, ultimately fast execution.

3) Disadvantages of Selenium?

· Support only web applications

· Its free so no support is available

· No Rich GUI / Lot of programming skills are required.

4) What are the flavors of selenium?

Selenium IDE, selenium RC, Selenium WebDriver and Selenium Grid.

It has four components:

Selenium 1 (Selenium IDE + Selenium RC + Selenium Grid)

Selenium 2 (Selenium IDE + Selenium RC + Selenium Grid + Selenium Web Driver)

a) Selenium IDE?

Selenium IDE is a complete integrated development environment (IDE) for Selenium tests. It is a Firefox plugin that you can install. It allows recording, editing, and debugging tests. Scripts are recorded in Selenese, a special test scripting language for Selenium.

PROS

· Very easy to se and install.

· No programming experience is required.

· Can export tests to formats usable in Selenium RC and WebDriver.

· Has built-in help and test results reporting module.

CONS

· Available only in firefox.

· Designed only to create prototypes of tests.

· Test execution is slow compared to Selenium RC and WebDriver.

b) Selenium Grid?

Selenium Grid is a tool used together with Selenium RC to run parallel tests across different machines and different browsers all at the same time. Parallel execution means running multiple tests at once.

c) Selenium WebDriver

WebDriver, unlike Selenium RC, does not rely on JavaScript for Automation. It controls the browser by directly communicating with it. At the moment, Selenium RC and WebDriver are merged into a single framework to form Selenium 2. The supported languages are:

· Java

· C#

· PHP

· Python

· Perl

· Ruby

Prerequisites to run selenium webdriver are JDK, Eclipse, WebDriver(selenium standalone jar file), browser, application to be tested.

PROS

· Simpler installation than RC

· Communication directly to the browser

· No Need for a seperate component such as RC server.

· Faster execution time than IDE and RC.

CONS

· Installation is more complicated than IDE

· Requires programming knowledge

· Cannot readily support new browsers

5) Set Up Selenium WebDriver:

a) Set Up Java

b) Set Up Eclipse

c) Set Up WebDriver Client

d) Configure Eclipse with WebDriver

e) First Test Case

a) Set Up Java

Why Java is platform independent?

With Java, you can compile source code on Windows and the compiled code can be executed on any platform running a JVM. So yes you need a JVM but the JVM can run any compiled code, the compiled code is platform independent.

The Java Virtual machine (JVM) is the virtual machine that runs the Java bytecodes. The JVM doesn't understand Java source code, that's why you compile your *.java files to obtain *.classfiles that contain the bytecodes understood by the JVM.

The Java Runtime Environment (JRE) provides the libraries, the Java Virtual Machine, and other components to run applets and applications written in the Java programming language.

The JDK is a superset of the JRE, and contains everything that is in the JRE, plus tools such as the compilers and debuggers necessary for developing applets and applications.

Download and then install JDK from website http://www.oracle.com. Please not that you will find two download links for Windows i.e.

· Windows x86

· Windows x64

Windows x86 means 32 bit system and Windows x64 is for 64 bit system. Download as per your Windows requirement.

b) Set Up Eclipse

· Download Eclipse from http://www.eclipse.org/downloads, extract and save it in any drive. Run ‘eclipse.exe’ directly so you do not need to install Eclipse.

· You need to know the type of version of your OS. If your computer is a 64 bit Windows, select Windows 64 else select Windows 32 bit.

· Create a workspace folder where you will contain all the program files you create.

c) Set Up WebDriver Client

Download WebDriver Java client driver from http://docs.seleniumhq.org/download/.

d) Configure Eclipse with Selenium WebDriver

To configure Eclipse with Selenium WebDriver, we need to perform the following activities:

i. Launch the Eclipse IDE & Create a Workspace

ii. Create a new Project

iii. Create a new Package

iv. Create a new Class

v. Add External libraries to the project

i) Launch the Eclipse IDE & Create a Workspace

You can change it from “Switch Workspace”

ii) Create a new Project

Project is a collection of related code.

· Create new Java Project from File > New > Project.

· Select Java Project and click Next.

· Then give your Project name in next wizard and Click on Finish button.

iii) Create a new Package

· Right click on newly created Project and select New > Package.

· Give your Package name ‘automationFramework‘ and click on Finish button.

· Now you can see a new package with name ‘automationFramework‘ under project name.

iv) Create a new Class

· Right click on Package ‘automationFramework‘ and select New > Class.

· Give your Class name ‘FirstTestCase‘, check the option ‘public static void main‘ and click on Finish button.

v) Add External libraries to the project

· Right click on Project > Select Properties > Java build path. Then navigate to Libraries tab and click Add External JARs.

· Add all jar files downloaded.

Now you are ready to write your test script in eclipse and run it in WebDriver.

e) First Test Case

Script 1

package AutomationFramework;

import org.openqa.selenium.By;

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;

public class FirstTestCase {

public static void main(String[] args) {

// TODO Auto-generated method stub

System.setProperty("webdriver.chrome.driver", "C:/chromedriver.exe");

WebDriver driver = new ChromeDriver();

driver.get("http://newtours.demoaut.com/");

driver.findElement(By.name("userName")).sendKeys("Rajiv");

driver.findElement(By.name("password")).sendKeys("Walia");

driver.findElement(By.name("login")).click();

System.out.println("Successfully opened a website");

}

Script 2

package AutomationFramework;

import org.openqa.selenium.WebDriver;

import org.openqa.selenium.chrome.ChromeDriver;

public class FirstTestCase {

public static void main(String[] args) {

// TODO Auto-generated method stub

System.setProperty("webdriver.chrome.driver", "C:/chromedriver.exe");

WebDriver driver = new ChromeDriver();

driver.get("https://iniitian.niit-tech.com/ntless/");

System.out.println("Successfully opened a website");

}

Other Selenium 3 Interview Questions

1) What are the annotations used in TestNG ?

@Test, @BeforeSuite, @AfterSuite, @BeforeTest, @AfterTest, @BeforeClass, @AfterClass, @BeforeMethod, @AfterMethod.

2) What is the use of xpath ?

It is used to find the WebElement in web page. It is very useful to identify the dynamic web elements.

3) What are different types of locators ?

There are 8 types of locators and all are the static methods of the By class.

By.id(), By.name(), By.tagName(), By.className(), By.linkText(), By.partialLinkText(), By.xpath, By.cssSelector().

4) What is the difference between Assert and Verify?

Assert- it is used to verify the result. If the test case fail then it will stop the execution of the test case there itself and move the control to other test case.

Verify- it is also used to verify the result. If the test case fail then it will not stop the execution of that test case.

5) How do you launch IE/chrome/FF browser?

//To open IE browser

System.setProperty(“webdriver.ie.driver”,”path of the iedriver.exe file ”);

WebDriver driver = new InternetExplorerDriver();

//To open Chrome browser

System.setProperty(“webdriver.chrome.driver”,”path of the chromedriver.exe file ”);

WebDriver driver = new ChromeDriver();

//To open Firefox browser

System.setProperty(“webdriver.gecko.driver”,”path of the geckodriver.exe file ”);

WebDriver driver = new ChromeDriver();

6) How do you simulate browser back and forward ?

driver.navigate().back();

driver.navigate().forward();

7) How do you get the current page URL ?

driver.getCurrentUrl();

8) What is the difference between ‘/’ and ‘//’ ?

//- it is used to search in the entire structure.

/- it is used to identify the immediate child.

9) What is the difference between findElement and findElements?

findElement() – it used to find the one web element. It return only one WebElement type.

findElements()- it used to find more than one web element. It return List of WebElements.

10) How do you achieve synchronization in WebDriver ?

We can use implicit wait.

Syntax- driver.manage().timeouts().implicitlyWait(10,TimeUnit.SECONDS);

11) How do you clear the contents of a textbox in selenium

Use clear() method.

driver.findElement(By.xpath("xpath of box")).clear();

12) What is a Framework?

A framework is set of automation guidelines which help in

Maintaining consistency of Testing, Improves test structuring, Minimum usage of code, Less Maintenance of code, Improve re-usability, Non Technical testers can be involved in code, Training period of using the tool can be reduced, Involves Data wherever appropriate.

There are five types of framework used in software automation testing:

1-Data Driven Automation Framework

2-Method Driven Automation Framework

3-Modular Automation Framework

4-Keyword Driven Automation Framework

5-Hybrid Automation Framework , its basically combination of different frameworks. (1+2+3).

13) What is Datadriven & Keyword Driven framework?

Datadriven framework- In this Framework , while Test case logic resides in Test Scripts, the Test Data is separated and kept outside the Test Scripts.Test Data is read from the external files (Excel File) and are loaded into the variables inside the Test Script. Variables are used both for Input values and for Verification values.

Keyword Driven framework- The Keyword-Driven or Table-Driven framework requires the development of data tables and keywords, independent of the test automation tool used to execute them . Tests can be designed with or without the Application. In a keyword-driven test, the functionality of the application-under-test is documented in a table as well as in step-by-step instructions for each test.

14) What are different components of your framework?

Library- Assertion, ConfigLibrary, GenericLibrary, ProjectSpecificLibrary, Modules.

Drivers folder, Jars folder, excel file.

13) How to get the title of the page ?

Use getTitle() method.

Syntax- driver.getTitle();

14) FirefoxDriver is class or an interface and from where is it inherited ?

FirefoxDriver is a class. It implements all the methods of WebDriver interface.

15) What is the difference b/w close() and quit()?

close() – it will close the browser where the control is.

quit() – it will close all the browsers opened by WebDriver.

16) There is a scenario whenever “Assert.assertEquals()” function fails automatically it has to take screenshot. How can you achieve this?

By using EventFiringWebDriver.

Syntax-EventFiringWebDriver eDriver=new EventFiringWebDriver(driver);

File srcFile = eDriver.getScreenshotAs(OutputType.FILE);

FileUtils.copyFile(srcFile, new File(imgPath));

17) What are the benefits of using TestNG?

a) TestNG allows us to execute of test cases based on group.

b) In TestNG Annotations are easy to understand.

c) Parallel execution of Selenium test cases is possible in TestNG.

d) Three kinds of report generated

e) Order of execution can be changed

f) Failed test cases can be executed

g) Without having main function we can execute the test method.

h) An xml file can be generated to execute the entire test suite. In that xml file we can rearrange our execution order and we can also skip the execution of particular test case.

18) What are the browsers supported by Selenium IDE?

Mozilla FireFox only. Its an Firefox add on.

19) How do you identify the Xpath of element on your browser?

To find the xpath, we use Firebug addons on firefox browser and to identify the xpath written we use Firepath addons.

20) Which one is better xpath or CSS?

xpath.

21) How will you handle dynamic elements?

By writing relative xpath.

22) what are the different assertions or check points used in your script?

The common types of validations are:

a) Is the page title as expected,

b) Validations against an element on the page,

c) Does text exist on the page,

d) Does a javascript call return an expected value.

method used for validation – Assert.assertEquals();

23) Can we run group of test cases using TestNG?

Yes.

24) What is object repository?

A repository allows a tester to store all the objects that will be used in the scripts in one or more centralized locations rather than letting them be scattered all over the test scripts.

Related Testing Topics:
a. Testing Tools

b. Basics of Java for Selenium

2009-11-09T23:37:00.000-08:00

Test Case

1. What is a test case?

“A set of test data and their expected results.

2. Why we write test cases?

To validate the testing coverage of the application.

3. How to write test cases (Example of test case or Sample of Test Case)?

There is no particular formula for writing the test case. Basic elements used in the test case are:

a. Test case number: 1 OR 1.1

b. Test Case Name: Login Verification

c. Test case Inputs or Steps or Action: Enter Login credentials, Click on “login” button.

d. Test Case Expected result: Verify that user is successfully login to “Home” page.

e. Test Case Status: Pass or Fail.

f. Comments: If test case is fail the you can write why it is failed. Also you can write bug number here which you are going to be reporting.

You should ask your self a question before writing the test case "What should be the steps followed by different users to use this functionality". Surely you will get the answer and just you have to write that answer in the form of points in excel sheet. Those points will automatically become test cases :)

Writing effective test cases is a skill and that can be achieved by some experience and in-depth study of the application on which test cases are being written.

4. What is the suitable time to create Test case?
There are levels in which test cases should be analized/designed to avoid duplication efforts.

Level 1: In this level tester should write the basic test cases from the available specification documentation.
Level 2: This is the practical stage in which writing test cases depend on actual functional and system flow of the application.
Level 3: This is the stage in which tester should group some test cases and write a test procedure. Test procedure is nothing but a group of small test cases.

5. Automation vs Manual Test Cases
The following types of test cases can be preferred for automation:
a. Test cases that need to run on every build.
b. Test cases that use multiple data values for same action.
c. Identical test cases that need to be executed using different browsers.

The following types of test cases should not consider for automation testing:
a. Test Cases that will only be executed once.
b. Test Cases used for Ad-hoc/random Testing.
c. Test Cases that are infrequently selected for execution.
d. Test Cases that will require manual intervention i.e. a task not possible to automate.
e. Based on the intuition and knowledge of application. Eg. if you find that you cannot escape from manual intervention.

6. Examples

1. Basic Test Cases for Fan 1. It should have a hook for hanging in the roof.
2. It should have minimum three blades.
3. It should be moving once the electricity pass into it.
4. Speed of the fan should be controlled by the regulator.
5. It should be stop once the electric switch off.
6. The fan should run with minimum noise.
7. The blades should have proper distance from the ceiling.
8. The fan while in motion, should not vibrate.
9. The color of the fan should be dark.
10. Fan should work in clock-wise direction

2. Basic Test Cases for Credit Card Case 1: Check for invalid Characters in Credit Card.
Description: Enter invalid characters @@@@34534"asd".
Expected Result: Error message should appear informing that invalid value is entered.

Case 2: Check for wrong Credit Card type.
Description: Enter invalid Credit Card type e.g. Enter Am Ex in place of VISA.
Expected Result: Error message should appear informing that invalid Credit Card is entered.

Case 3: Check for wrong Expiry Date.
Description: Select wrong month & year of expiry date.
Expected Result: Error message should appear informing that invalid Expiry date has been entered.

Case 4: Check for CVV number with the invalid characters as well as with the alphabetic & alpha numeric values.
Description: Enter invalid CVV number. Like: ABC or a3c. or @@" or "1".
Expected Result: Error message should appear information. Invalid characters are entered.

Case 5: Check for validation messages while enter wrong billing information.
Description: Check for Maximum & Minimum value acceptance. Check for invalid Characters. Check for Numeric value acceptance where numeric values are required & vice-versa.
Expected Result: Error message should appear while enter invalid values.

3. Basic Test Cases for Printer 1) Open page setup by selecting File>Page Setup
Expected Result: Page Setup dialog appears

What to Print
2) In Page Setup, select Orientation = Portrait, Margins = 10 for Top, Bottom, Right, Left. Click OK.Expected Result: Error: “The margins overlap or they are off the paper. Enter a different margin size.” Click OK

3) Now select Orientation =Landscape
Expected Result: Notice that all margins are automatically reset to default values.

4) In Page Setup, click on Printer. In Printer, select a printer from the Name list., then click on Properties. Expected Result: Verify that the selected printer's name is displayed as part of the title of Document Properties popup.

5) In Document Properties, leave defaults as is (Portrait, None, Front to Back). On the Layout tab, click OK to close all popups belonging to Page Setup. File>Print. In Print, click on Properties. In Document Properties, select Landscape, Flip on Long Edge, and Pages Per Sheet = 2.. Click OK
Expected Result: Notice that printout is based on the settings in File>Print, i.e. This setup override the one in Page Setup.

Miscellaneous Cases:
6) Make changes to the setting and click the Default button
Expected Result: Settings should revert to defaults

7) Switch to a different printer
Expected Result: When printed, the diagram should be sent to alternate printer

8) Switch to the plotterExpected Result: When printed, the diagram should be sent to the plotter

9) Switch to a color printer
Expected Result: When printed, the diagram should be sent to the color printer

10) Change the paper size
Expected Result: When printed, the diagram should appear on the correct paper size

11) Switch to portrait orientationExpected Result: When printed, the diagram should appear in portrait orientation

12) Switch to landscape orientation
Expected Result: When printed, the diagram should appear in landscape orientation

Other Printer Test Cases:
Case 1: Ensure correct behavior of application with Print functionality.

Steps:

1. Verify that printer is connected with machine.

2. Open the application and click on Print. Verify printouts in all the views.

Case 2: Ensure that application behaves correctly if printer is not available. Steps:1. Verify that no printer is connected with machine. 2. Open the application and click on Print. 3. Verify that proper message appears for printer unavailability.

Case 3: Ensure that application queues prints in printer if papers are not available in printer.

Steps:

1. Verify that printer is connected with machine.

2. Verify that no papers are available.

3. Open the application and click on Print. Verify that all the prints which were in queue.

Case 4: Ensure correct behavior of application if printer is uninstalled.

Steps:

1. Verify that printer is uninstalled from machine.

2. Open the application and click on Print.

3. Verify that proper message appears for printer unavailability.

Case 5: Ensure correct behavior of Print functionality with new installed printer. Steps:

1. Verify that printer is uninstalled from machine.

2. Now, install printer on machine.

3. Open the application and click on Print.

4. Verify printouts in all the views.

4. Basic Test Cases for Paging Functionality Condition: Qty available is given and we have to fill Qty we want (Reffer iReuse.com paging)

Test Case 1:
1. Try to enter Qty we want more than Qty available (this should not happend).
2. Try to enter alphabets (this should not happend).
3. Submit without entering anything.

Test Case 2:
1. Select page 1 enter items.
2. select page 2 enter items.
3. Click again on page 1 and see if this remembers same entered items.
4. Click again on page 2 and see if this remembers same entered items.
5. Submit, check the email and match result.

Test Case 3:
1. Select page 1 do not enter items.
2. select page 2 enter items.
3. Click again on page 1 and now enter items.
4. Click again on page 2 and see if this remembers same entered items. Then change some items.
5. Submit, check the email and match result.

Expected critical errors: Sometime items exchanged the values from different pages.

5. Test Cases for Upload Images 1. Upload files with extensions like .jpg, .jpeg, .gif, .png, .bmp).
2. Upload files with extensions like .jPg, .JpeG, .GIf, .pNg, .bmP).
3. Upload files with extensions like .JPG, .JPEG, .GIF, .PNG, .BMP).
4. One thing we have to keep in mind while testing files uploading that we also should have to test files with long names.

Note: I had received the server error when uploading with long file name while functionality was working file with small filename. Also I received the server error when used .JPG, but application was working fine with extension .jpg.

Related Testing Topic:
a. Black Box testing

Testing Concepts

2009-09-18T21:49:00.000-07:00

1. SDLC

a. Feasibility study

b. Requirements analysis

c. Systems design: Describes desired features and business rules

d. Implementation: The real code is written here.

e. Integration and testing: Brings all the pieces together

f. Acceptance, installation, deployment

g. Maintenance

2. STLC

a. Requirements Analysis

b. Test Planning

c. Test Development

d. Test Execution

e. Bug Reporting and Result Analysis

f. Defect Retesting and Regression testing

3. Test Plan

a. Table of Contents
b. Objective of testing
c. Personnel responsible for each task
d. Personnel contact-info
e. Relevant naming conventions
f. Features to be Tested, Features not to be Tested
g. Assumptions and dependencies
h. Test environment - hardware, operating systems, Browsers etc
i. Project risk analysis
j. Initial smoke testing period and criteria
k. Process used to manage the bugs
l. Test suspension and restart criteria
m. Duration of test

4. Test Case

a. Component Name

b. Prerequsitie

c. Test Cases Steps

d. Expected Result

e. Status

f. Comments

5. Bug Life Cycle

a. New

b. Assigned

c. Resolved

d. Verified

e. Closed

f. Reopen

6. Testing Techniques (Testing approach)

The most popular Black box testing techniques are:

1. Equivalence Partitioning

2. Boundary Value Analysis

3. Error-Guessing

7. Testing Tools

1. Bug Tracking Tool: Bugzilla

2. Recording the bug in video format: Screencast-o-matic

3. Tool for taking Screen-shots for reporting the bug: Fireshot

4. Compatibility testing tools: Browser Sandbox and Adobe BrowserLab

5. Tool to Monitor CSS and HTML: Firebug

6. Tool to ensure valid HTML: HTML Validator

7. Performance Testing tool: Page Speed by Google

8. To find Broken Links: Pinger Ad-on and brokenlinkcheck

9. For checking the spelling of content: Spell Check

8. Severity: Determines the defect's effect

Priority: Determines the defect urgency

9. Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to provide encrypted communication and secure identification of a network web server.

10. Testing Process

a. GUI Testing

a. Content should be correct.

b. Wrap-around properly.

c. Switch images off for ALT texts

d. Switch JavaScript off and See if appropriate messages are displayed to user.

e. Check sensible page titles.

b. Usability Testing

a. Participation of QA and Designers

b. Participation of sample end user

c. Observation by test morderator

d. Development of research questions

e. Recomendation of improvements to the design of the product

c. Functional Testing

a. Check for broken links.

b. Validate the HTML (Validator W3).

Functional testing types:

a. Smoke testing / Sanity testing

b. Usability Testing

c. Regression Testing

d. Pre User Acceptance Testing which includes Alpha and Beta

e. User Acceptance Testing

f. Localization Testing

Non-functional testing types:

a. Load, Stress, Performance, Volume Testing

b. Compatibility

c. Security Testing

d. Installation Testing

d. Interface

a. Data display on browser should match with data available on server.

e. Compatibility

a. Windows

b. Browsers

f. Security Testing

a. Limit the number of tries.

b. Verify rules for password selection.

c. Is there a timeout limit?

d. Paste internal url directly without log-in

e. Test if SSL is used for security measures.

f. Type a single quote

g. SQL Injection: Try submitting following: (') single quote

h. Session hijacking: If your app has a session identifier number in the URL decrease that number

g. Performance

a. Can your site handle a large amount of users requesting a certain page.

b. Long period of continuous use: Is site able to run for long period, without downtime.

c. Apply Web page performance (speed) Tool

Performance Testing: The goal of performance testing is not to find bugs, but to eliminate bottlenecks and establish a baseline for future regression testing.
Load test: To verify application behavior under normal and peak load conditions
Stress Testing: To determine application’s behavior when it is pushed beyond normal or peak load conditions.
Here are some ways in which stress can be applied to the system:
a. double the baseline number for concurrent users/HTTP connections
Volume testing:
a. testing a word processor by editing a very large document
b. testing a printer by sending it a very large job
Capacity test: To determine how many users and/or transactions a given system will support and still meet performance goals.

If chair is designed for 100 kg weight, and my weight is 70 kg then that testing is called as normal testing. If my weight is 100 kg then that testing is called as load testing. If my wt is 120 kg then that testing called as stress testing.

11. Smoke testing A smoke test is a cursory examination of all of the basic components of a software system to ensure that they work. Typically, smoke testing is conducted immediately after a software build is made. It ensures that the future testing is not blocked.

12. System testing
Testing conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements. System testing is actually done to the entire system against the Functional Requirement Specification(s) (FRS) and/or the System Requirement Specification (SRS).

Types Of System Tests:

a. Functional testing
b. User interface testing
c. Usability testing
d. Compatibility testing
e. Security testing
f. Performance testing
g. Sanity testing
h. Regression testing
i. Installation testing

13. Defect or Bug density: Defect density is equal to the ratio of number of defects to the number of lines of code.

DD=Total Defect/KLOC( Kilo lines of Code)
Ex: Suppose 10 bugs are found in 1 KLOC
Therefore DD is 10/KLOC (Kilo lines of code)

14. Traceability Matrix - Requirement Traceability matrix (RTM)
Traceability matrix is a matrix which is used to keep track of the requirements. It is a mapping between the requrements and test cases, we will do this for identify missing test cases.

Exact requirements from the requirement doc given by the client are copied in this matrix. These requirements are assigned a unique number and the remark as testable or not. Against each testable requirement test objective and test case is identified. It is highly possible that for one req there could be multiple test objectives and test cases. For each of the test objective and test case unique number is assigned.

Advantages:
a. We can trace the missing test cases.
b. Whenever requirements changes then we can easily refer to matrix document, change the usecase and go to corresponding testcases and change them.
c. Easy to test any functionality. Only we need to refer matrix document and we can reach to related test cases.
d. We can trace the impact of functionalities on one another. Because different functionalities can have same test cases.

15. Bug: A software bug is the common term used to describe an error, mistake, failure, or fault in a computer program.

16. Monkey Testing

Monkey Testing is random testing.

a. Dumb Monkeys: A dumb monkey doesn't know anything about the software being tested; it just clicks or types randomly.

b. Semi-Smart Monkeys: Add logging to your monkey so that everything it does is recorded to a file. When the monkey finds a bug, you need only to look at the log file to see what it was doing before the failure.

Another solution to track what your monkey does is to set up a video camera to record what happens on the screen. When you notice that the software has failed, just rewind and replay the tape.

c. Smart Monkeys: A true smart monkey knows Where he is, What he can do there, Where he can go, Where he's been, If what he's seeing is correct.

A smart monkey isn't limited to just looking for crashing bugs, either. It can examine data as it goes, checking the results of its actions and looking for differences from what it expects.

17. Web Testing: Web testing nothing but Browser applications testing. They are usually a most visible, widely-used - and potentially most vulnerable - applications.

18. Server Side Interface: In web testing the server side interface should be tested. This is done by verify that communication is done properly. Compatibility of server with software, hardware, network and database should be tested.

19. Client Side Compatibility: The client side compatibility is also tested in various platforms, using various browsers etc.

20. Desktop – Client server – Web Applications

Desktop application runs on personal computers and work stations.
Client server application you have two different components to test. Application is loaded on server machine while the application (exe) on every client machine.
Web application: Application is loaded on the server whose location may or may not be known and no exe is installed on the client machine, you have to test it on different web browsers and different Operating Systems.

21. Why are there so many software bugs?

a. Unclear software requirements because there is miscommunication as to what the software should or shouldn’t do.
b. Software complexity.
c. Programming errors occur because programmers and software engineers, like everyone else, can make mistakes.
d. Changing requirements



Related Testing Topics:
a. Black Box testing
b. Web Testing Checklist
c. Desktop App Testing Checklist