World Clock
Share on Facebook
Share on Twitter
Share on Google Bookmarks

Copyrights @ 2012

Newaxis Selenium Online Training's

All Rights Reserved

Ph: 91-9676866710  | E-mail : info@testingtoolsonlinetrainings.com

Fixed Ph: +91-4042218298 | WhatsApp: 91-9676866710  | SKYPE  : newaxis.testing

Home AboutUs Other Testing Courses Testing Training Videos Fast Track Course Student Form Faculty Form Contact Us
Course Content
Demo Videos
What is Testing
Interview Questions
Selenium
Manual Testing
QTP
QC

Fee Details

Selenium | QA  online Training

(Manual Testing, QTP & QC)

180$/10,000 RS

Selenium
QTP
Manual Testing 
Manual Testing Online Training - INDIA
Online Manual Testing classes | Manual Testing Video Tutorials From Hyderabad
Manual Testing Online Tutorials Course Content

Introduction to Software Testing


Software Development Life Cycle(SDLC)


SDLC Models


Software Testing Methodologies


Levels of Testing


Types of Testing


Software Testing Life Cycle(STLC)


Test Case Design Techniques


Defect Management


Software Configuration Management



Manual Testing Demo Video
Student Form
Learn Manual Testing

Testing:

Testing is defined as the process to identify correctness, completeness and quality of the product.

It is the process which includes activities conducted with the intent of finding errors in software so that it could be corrected before the product is releases to the end user.

In simple words, software testing is an activity or process to check whether actual results match the expected results and to ensure that the software system is defect free.

Importance of software testing:

There are real time scenarios where software bugs created disasters. A software bug can cause many problems in terms of money, time, effort and many more.

Defect:

Defect is nothing but the deviation from the requirements.

or

An Error in programming /Fault/Undefined coding which leads to malfunction of An application

Or

Application which fails to give expected output is said to be effected with a defect

Or

It is nothing but an error in software coding

Testing methods are broadly classified into two methods. They are:

1) Manual testing

2) Automation


Manual Testing:

Manual testing is the process in which all the phases of software testing life cycle like test planning, test development, test execution, result analysis, bug tracking and reporting are accomplished successfully with human efforts.

Drawbacks of manual testing:

1) More number of human resources are required

2) Time consuming

3) No accuracy

4) Tiredness

5) Simultaneous actions are almost impossible

6) Cannot repeat the same task with same interest

Automation Testing:

Automation testing is a process in which all the drawbacks of manual testing are addressed properly and provides speed and accuracy for the existing testing process.

Drawbacks of Automation testing:

1) Tools are more expensive

2) All the areas of the application cannot be tested with the automation tools

3) Lack of automation testing experts in the market

Automation is not a replacement for manual testing it is just a continuation for the manual testing.

Unless and until the application comes to a stable state, it is suggested not to perform automation testing.

Software Development Life Cycle:

Software is a set of instructions or programs documented to perform particular task

Software can be categorized in to two types. They are:

1) System Software

2) Application Software


System Software:

This software provides interface to the System Components like Booting. System software is also called as BIOS (basic i/p o/p system)

Example: ALL Operating systems, Windows, UNIX etc

Application Software:

Software which performs operations or functions based on user inputs is called Application software. Generally application software is developed based on user business needs.

Ex: MS office, QTP, Online Banking s/w, etc.

Application Software is further divided into two types. They are:

1) Product based

2) Project based

Product Based: A Product based application is developed based on standard requirements. This product is developed for all worldwide users and who are related to specific product can buy this software from the product development company.

Example: QTP, Team viewer, etc

Project Based: A Project based application is developed based on specific client requirements .After developing the application it will be delivered to the client.

Example: Banking s/w, insurance, etc

What is SDLC?

A framework that describes the activities performed at each stage of a software development project.  It is the process of developing software Product/Project to fulfil the client Requirement within the specific cost and time. In general it is also known as a method which is adopted by the organization to develop the application with in the budget and time period.

Phases Involved In SDLC: There are 6 phases in software development life cycle. They are:

1) Requirement Collection

2) Requirement Analysis

3) Design

4) Coding

5) Testing

6) Delivery/ Maintenance

Requirement Collection:

In this phase Business Analyst interacts with the client and collects the requirements. The collected information will be documented as BRS (Business Requirement Specification) Or URS (User Requirement Specification) or CRS (Customer Requirement Specification).BRS is the First document prepared in SDLC. This document will be quoted with Brief description of client business needs like users, type of users, user permissions, services etc.

After preparing BRS doc Business Analyst will do/make Feasibility Study in order to check whether project is acceptable. If the project is accepted Business Analyst will provide intimation to the client and an agreement will be made. This agreement is called SLA (Service Level Agreement).Basically SLA will be made between company and the client.


Requirement Analysis:

In this phase System Analyst will Study the BRS doc and will prepare a detailed Functionality doc based on BRS and that document is called as FRS (Functional Requirement Specification).The technology selection and the environments which will be suitable for the application will be clearly analyzed here in this section.

FRS document play a very important role in software development process. It is known that a good FRS document indicates a good project.FRS document contains all the specifications and Functionalities of project.


Design:

The persons involved in this phase are Design Architect and Technical Lead will be assisting him. In this phase Design Architect will divide the whole project into modules by drawing diagrams using unified modeling language called UML. This is called High level designing and the document prepared is called HLD document. The technical lead will further divide the modules into sub modules using the same UML language which is called Low Level Designing and the document prepared is called LLD document. The technical lead and his team with the guidance of Design Architect will design the GUI part of the application and also develops the pseudo code.

Pseudo code is nothing but a set of English statements which will make developers more comfortable while developing the actual code.


Coding:

In this phase developers or programmers will prepare the actual source code (ASC) by following the coding standards like proper indentation, proper alignment, proper commenting etc with the support of the technical design document. The document prepared in this phase is called source code document.


Testing:

In this phase the application will be made available for dynamic testing. Initial Stage of testing is performed by developers like Unit testing/ Component Testing by using (WBT) White Box Testing. After unit testing application is given to separate testing team where they validate application using various BBT (Black Box Testing) techniques. After BBT the application undergoes UAT (User Acceptance test) to know the client satisfaction


Delivery and Maintenance:

In this phase the application will be delivered to the client. It is also called as go-live. And changes can be made further upon request of Client which is called maintenance.


Quality management: It is a process of preventing the defects during development process and ensures there are no defects in final project. Quality management will have two teams Quality control (QC) Quality Assurance (QA)

Quality Assurance: It’s a defect preventive Approach where they define, monitor and measure the strength of development process, QA team involves throughout life cycle

Quality Control: QC team comes in to act only when project is built, Qc identifies the defects and make sure these defects has to be resolved before delivering the application to the Client

Manual testing:

          Manual testing is broadly classified into two types. They are:

1) Static Testing

2) Dynamic Testing

Static Testing:

                Testing the documents or reviewing the documents is called static testing

Example:  Peer reviews, walk through, inspections.

Dynamic Testing:

                Testing the functional part of the application is called dynamic testing.

Example:  Unit testing, Integration testing, Functional testing, Performance testing, Security testing

Levels of Testing:

There are broadly 5 levels of testing. They are:

1) Unit testing

2) Module level testing

3) Integration testing

4) System Testing

5) UAT Testing

1) Unit Testing:  

               This is also called Component Testing. This testing is performed on standalone modules to check whether it is developed correctly or not. Dependency with other modules is not tested in this type of testing. This is usually done by developers.


2) Module Level Testing:

                              Module is defined as a group of related features to perform a major task. In this level, the module will be released to the testing department and the test engineers will be testing the functionality part of that module.


3) Integration testing:    In this testing individual modules are combined and tested as a group.  Data transfer between the modules is tested thoroughly. Tests the effect of one module on the other. This is the type of testing in which one will perform actions to check reflections in other modules. This is done by testers.

Example: Let us consider an integration test scenario of a banking application. Consider the customer is having 1000Rs in his account and transfers 500Rs to other account.

Customer navigates back to the current module and remaining balance should be 500Rs.

Modules in the project are as below and they are assigned for different developers. Coding for current balance module is ready but coding for transfer module is not yet ready.














To test the integration scenario in such situations different approaches are followed. They are:

a) Big Bang Approach:

       As per this approach one need to wait till all the coding is completed and then tests the scenario.


Disadvantages:

1) It is time consuming since testers should sit idle till all the modules are developed.

2) Difficult to trace root cause of the defects

 b) Top down approach:

               Consider the scenario where current balance module is ready and that of transfer module is not ready. A temporary module will be created to replace the incomplete transfer module. This temporary program is called stub

In this top down approach higher level modules or parent modules are tested first and the incomplete child modules are replaced by temporary modules called stubs.

c) Bottom Up approach:

             Contrary to the top down approach if the transfer module is ready and current account balance module is not ready then the temporary module used in this scenario is called bottom up approach.

In this bottom up approach lower level or child modules are tested first and the incomplete parent modules are replaced by temporary modules called drivers.

These temporary modules either stub or drivers are not implementation of the original modules.   They will be helpful only in testing the particular integration test scenario.

d) Sandwich approach:

              Combination of both top down and bottom up approach is called sandwich approach.

The choice of approach depends on the system architecture and location of high risk modules.

4) System Level Testing:

               To test the system as a whole this type of testing is used. In system testing one will test the complete end to end scenarios as the end user would use the system

Example: Login to Logout scenario

In this system testing, apart from functional requirements non-functional requirements are also checked.

Non functional requirements include stability, reliability and performance of an application.

5) User Acceptance testing:

            This type of testing is usually done at client location by the client. Focus is not to find the defects but to check whether the system meets the requirements.

There are 2 types of UAT testing.

Alpha testing: This is done by small set of employees of the client.

Beta testing:   This is done by set of customers of the client

Testing Approaches:

1) WBT (White Box Testing):

        If one performs testing on the structural part of an application then that method of testing is known as white box testing. Usually developers or white box testers will be involved in white box testing.


2) BBT (Black Box Testing):

        Testing performed on only the functional part without having knowledge of structural part then that type of testing is called black box testing.

3) GBT (Gray Box Testing):

       Testing performed on both the functional part as well as the structural part of an application is called gray box testing.

Usually the test engineers who have the additional knowledge of structural part will be involved in glass box testing. This testing is also called gray box testing or glass box testing or

clear box testing

Black Box testing Techniques:

                As exhaustive testing is not possible we need techniques to identify the test cases with most likelihood of finding a defect out of the possible many. There are many test case designing techniques available also called Black Box testing techniques. They are:

1) Equivalence class partitioning

2) Boundary value Analysis

3) State Transition

4) Decision Table

5) Error Guessing

1) Equivalence class partitioning:

                   This is a black box testing techniques which can be applied to all levels of testing. In this testing technique we divide the set of test conditions into partitions that can be considered the same.

Example1: Let us take a flight reservation application with no. of tickets field accepting values only from 1 to 10.

Then the valid input values would be 1,2,3,4,5,6,7,8,9,10

Invalid values are 11 to 99

Invalid values are also 100 and above

Invalid values also include less than 1

We can’t test all the values because if done the number of test cases would be more than 100.

So to avoid  this we divide the inputs into partitions or classes (also called groups or sets) where the system behaviour can be considered the same

Partition 1:     1,2,3,4,5,6,7,8,9,10

Partition 2:     Invalid values are 11 to 99

Partition 3:     Invalid values are also 100 and above

Partition 4:     Invalid values also include less than 1

These sets are called Equivalence partitions or equivalence classes.

Then we pick up only one value from each partition for testing

The assumption behind this testing is that if one condition/value in a partition passes all others will also pass. Likewise if one condition in a partition fails, all other conditions in that partition will fail.


Example2:  suppose an application collects some data about a traveller regarding his age. When the OK button is pressed the component calculates a fare from the current location using the input values. There is a standard fare to each destination. Our travel service offers discounts to travellers based on their age. For example, children under 5 travel free and those over 65 get a 25% discount.

Age Discount

0-4 years 100%

5-15 years 50%

16-64 years 0%

64 years and older 25%

There are possibly an infinite number of age values that could be input, it is impractical to test them all.We can use equivalence partitioning to test the processing of data. We need to partition the possible age values into classes where all members should be treated in the same way. Using the Discount Table, we can see four partitions of valid ages and create two partitions of invalid ages:

0, 1, 2, 3, 4.

5, 6, 7, …15.

16, 17, 18, …64.

65, 66, 67, …120.

Ages greater than 120 years.

Ages containing non-numeric characters.

Equivalence partitioning requires us to choose one value from each partition where possible, a middle value is chosen. So we would test the processing of ages 2, 10, 40, 108, 555 and ‘one’. To complete equivalence partition testing we need to perform only six tests.

Example 3:

Another feature of our application is that fares are regional; fares to the same region are all the same.The Fare Table:

Destination Fare

Hyderabad 700

Vijayawada 700

Guntur 700


Tirupati 1200

Chennai 1200

Bangalore 1500

Mysore 1500

  

  

The destination field can be partitioned into the same regions:

Hyderabad, Vijayawada, Guntur.

Tirupati, Chennai.

Bangalore, Mysore

To complete equivalence partition testing on the destination input field we choose one town from each region. For example: Hyderabad, Vijayawada and Guntur. The component handles all values in the name in the same way; it prints the same name on any tickets that are issued. As all values are treated the same, it is not possible to separate the name field values for equivalence partitioning.

2) Boundary Value Analysis:

 This is also called range checking technique. It makes use of the fact that the inputs and outputs of the component under test can be partitioned into ordered sets with identifiable boundaries. Values in the same set will be treated in the same way. Test values are chosen that are just inside, on and just outside the boundaries.

Suppose our application collects some data about a traveller. When the OK button is pressed the component calculates a fare from the current location using the input values. There is a standard fare to each destination. Our travel service offers discounts to travellers based on their age. For example, children under 5 travel free and those over 65 get a 25% discount.

Age Discount

0-4 years 100%

5-15 years 50%

16-64 years 0%

64 years and older 25%

We can use boundary value analysis testing on the age field of our fare calculation component. We can partition the age input data into ordered sets using the data the Discount table. This gives us the following sets:

0, 1, 2, 3, 4.

5, 6, 7, …15.

16, 17, 18, …64.

65, 66, 67, …120.

Ages greater than 120 years.

It is often useful to draw these partitions as shown below.









3) State Transitition Technique:

This technique is used in the areas where we need to test different system Transititions.

To understand this better let us consider an example of a internet banking application which requires a valid customer id and password to login to the application.

Example:

Consider you have entered a valid customer id in the login page.In the first attempt if you give a correct password you will be given access to the application. Incase if you give a wrong password an error screen pop ups asking you to enter the correct password. Like this you can have 3 attempts but for the fourth time if you give wrong password the application will be closed. And if you give correct password in the 1st, 2nd or 3rd attempts you will be given access to the application. Amongst these various system transitions the first scenario of accessing the application and the 4th scenario in which the application gets closed are important and must be tested whereas the 2nd and 3rd attempts are less important to be tested or else any one of them could be tested.












The above diagram is called state chart or state graph. This state graph is used for identifying valid transitions. There are 4 components of the graph.

1) States the software may occupy





2) Transitition from one state to another     

3) Events that cause transition.  

                                               Correct password

4) Actions that resulted from events.      






To identify the invalid transitions of the system state table is used. In this table all the valid states are placed on the left side of the table and the events which caused them are placed on the top. For example in the s1 state suppose you enter correct password you are taken to state s6.Or else if you enter wrong password you are taken to state s2.Likewise you can determine all other states.

Correct password Incorrect password

S1)start S6 S2

S2)1st try S6 S3

S3)2nd try S6 S4

S4)3rd try S6 S5

S5)4th  try S6 S7

S6)access ?? ??

S7)close ? ?

There are two invalid states observed in the table. If you are already login to the application and if you open another instance of the same application and enter valid or invalid password for the same customer id.  System behaviour for such scenarios can be tested.

4) Decision table testing:

       It is the best technique to deal with the combination of inputs which produce different results.

Example:

Let us consider the behaviour of the flight button in the flight reservation application which is also having two other input fields Fly from: and Fly to:  If the two inputs Fly from: and Fly to:    are not set then the flight button is disabled. In the decision table we note the outcomes of the flight button as below:

Conditions Rule1 Rule2 Rule3 Rule4

Fly From F(not set) T(set) F(not set) T(set)

Fly To F(not set) F(not set) T(set) T(set)

OUTCOME

Flight Button F(disabled) F(disabled) F(disabled) T(enabled)


From the decision table it can be observed that the outcome of Rule1, Rule2, Rule3 are same. So anyone of those scenarios can be tested instead of testing all the three.

Flight button is enabled only if the Flight from: and Flight to: fields are set.

The importance of this technique can be understood better when the number of inputs increases.

Possible combinations = 2 ^ n (2 raised to n)    where n = number of input conditions

For n = 10 you will have 2 ^ 10 =1024 different combinations. From that large number of input conditions you will choose a rich subset of the possible combinations

5) Error Guessing:

Error Guessing is a test case design technique where the tester has to guess what faults might occur and to design the tests to represent them.

Ability to guess based on previous experience in Software Testing environment.

Adhoc method to identify tests likely to expose errors based on experience and intuition. Some areas to guess are Empty or null strings, Zero instances, occurrences, Blank or null characters in strings, Negative numbers

The purpose of error guessing is to focus the testing activity on areas that have not been handled by the other more formal techniques, such as equivalence partitioning and boundary value analysis. Error guessing is the process of making an educated guess as to other types of areas to be tested. For example, educated guesses can be based on items such as metrics from past testing experiences, or the tester's identification of situations in the Functional Design Specification or Detailed Design Specification, that are not addressed clearly.


Types of testing:

              Generally types of testing are broadly classified into 3 types. They are Functional testing, Non Functional and Maintenance testing.


Functional Testing:  Testing the functional part of the application is called functionality testing.

Ex: Unit testing, Integration testing, Smoke testing, sanity testing, User acceptance testing, Localisation, Globalisation testing,  Interoperability testing etc comes under this testing


Non-Functional Testing:  Apart from functional testing non functional requirements like performance, usability, load factor are also important and these types of testing comes under non-functional testing

Ex: Performance testing, Endurance testing, Load testing, Volume testing, Scalability testing, Usability and so on.


Maintenance Testing:   Once deployed test enhancements, system changes , corrections comes under this testing

Ex: Regression and Maintenance testing


Sanity Testing:  

Sanity testing is checking the functionalities of the system before it is accepted for major testing. This testing is quick and non-exhaustive. Goal of this type of testing is not to find the defects but to check the system health.


Consider a scenario where the application is made available for system testing to the testing team after the defects are fixed in unit testing. On the first day by looking at the login screen the system looks fine. The next day you plan to execute the integration test scenario below:

Login > View Balance > Transfer 500 > Logout.


The deadline to execute the above scenario is 2 hours. When you start executing the scenario and enter the valid customer id and password you see a blank screen and you cannot proceed further. This might be due to the developer negligence and it takes 5 hours to fix the defect and deadline is missed. To avoid such situations you should do sanity/smoke testing. The main concentration of this type of testing is:

1)   whether one can navigate to all the pages of the application or not

2)   whether all the objects are available and properly managed or not

3)   Whether the required connections are properly established or not.


Smoke testing:

Before making the application available for testing team the testing done by development team to check the health of the application is called smoke testing.


Regression testing:

It is a type of testing in which the testing will be done on already tested functionalities again and again. Usually this is done in two scenarios:

1) Whenever the testers finds the defects, send them to development team after rectification developers will release the next build. Once the next build is released the test engineers will check the defect functionality as well as the relative functionalities also.

2) Whenever new functionalities are incorporated, next build is released to the testing department then the test engineers will once again test all the functionalities which are related or dependent on those new functionalities.


Regression testing is carried out to check modifications in software have not caused unintended adverse side effects.