Archive for October, 2013

Difference between Re-testing and Regression testing:

Re-Testing:

  • When tester finds the bug and report to developers and developer fix that bug now if tester tests only that test case in which he found the bug with same or different data then it is known as retesting.
  • Re testing requires re-running of the failed test cases.
  • Re testing is plan based for bug fixes in build notes and docs.

 Regression Testing:

  • After modification or fixing the bug if tester test that test case in which he found the bug and test all the or specified test cases which he executes earlier then it is known as regression testing . The aim of this testing is that bug fixing is not affect the passed test cases.
  • It is an important activity, performed on modified software to provide confidence that changes are correct and do not affect the other functionality and components.
  • Regression testing is generic and may not be always specific to defect fixes.

Difference between System Testing and System Integration Testing:

1. Integration testing is a testing in which individual software modules are combined and tested as a group while System testing is a testing conducted on a complete, integrated system to evaluate the system’s compliance with its specified requirements.

2. Integration testing is testing the interface between the modules; it can be top down, bottom up, big bang while System testing is testing the end to end business scenarios in the environment which is similar to production environment.

3. System testing will be conducting at final level while Integration testing will be done at each time of module binding or a new module need to bind with the system.

4. System testing is a high level testing while Integration testing is low level testing. In simple words on completion of integration testing, system testing started not vice versa.

5. Test cases Integration testing are created with the express purpose of exercising the interfaces between the components or modules while test cases for System testing are developed to simulated the real life scenarios.

6. For Example if an application has 8 modules. Testing the entire application with all 8 modules combined, we call it System testing and if application interacts with some other applications (External systems) to retrieve or send data, to test with other application and external system or any other module we call it Integration testing or system integration testing.

Difference between Sanity and Smoke Testing:

Smoke Testing:

  • When a build is received smoke testing is done to ensure that whether the build is ready or stable for further testing.
  • Smoke testing is a wide approach where all areas of software application are tested without getting into deeper.
  • Test Cases for smoke testing can be manual or automated.
  • A smoke test is basically designed to touch each and every part of an app in a cursory way.
  • Smoke testing is Shallow and wide.
  • Smoke testing is conducted to ensure whether the most crucial functions of a program are working, but not bothering with finer details.
  • Smoke testing is like General Health Check Up

Sanity Testing:

  • After receiving a software build, with minor changes in code, or functionality, Sanity testing is performed to ascertain that the bugs have been fixed and no further issues are introduced due to these changes. The goal is to determine that the proposed functionality works roughly as expected.
  • Sanity testing exercises only the particular component of the entire system.
  • A sanity test is usually unscripted and without test scripts or test cases.
  • Sanity Testing is narrow and deep
  • Sanity testing is to verify whether requirements are met or not, checking all features breadth-first
  • Sanity Testing is like specialized health check up

Test Plan:

It is a high level document in which how to perform testing is described. The Test Plan document is usually prepared by the Test Lead or Test Manager and the focus of the document is to describe what to test, how to test, when to test and who will do what test.

The plan typically contains a detailed understanding of what the eventual workflow will be.

Master test plan: A test plan that typically addresses multiple test levels.

Phase test plan: A test plan that typically addresses one test phase.

Test Plan Template contains following components:

1. Introduction

A brief summary of the product being tested. Outline all the functions at a high level.

  • Overview of This New System
  • Purpose of this Document
  • Objectives of System Test

2. Resource Requirements

  • Hardware– List of hardware requirements
  • Software–List of software requirements: primary and secondary OS
  • Test Tools—List of tools that will be used for testing.
  • Staffing

 3. Responsibilities

List of QA team members and their responsibilities

4.      Scope—

  • In Scope
  • Out Scope

 5. Training

List of training’s required

6. References

List the related documents, with links to them if available, including the following:

  • Project Plan
  • Configuration Management Plan

7.      Features To Be Tested / Test Approach

  • List the features of the software/product to be tested
  • Provide references to the Requirements and/or Design specifications of the features to be tested

8.      Features Not to Be Tested

  • List the features of the software/product which will not be tested.
  • Specify the reasons these features won’t be tested.

9.      Test Deliverables—

  • List of the test cases/matrices or their location
  • List of the features to be automated

10.  Approach

  • Mention the overall approach to testing.
  • Specify the testing levels [if it’s a Master Test Plan], the testing types, and the testing methods [Manual/Automated; White Box/Black Box/Gray Box

11.Dependencies

  • Personnel Dependencies
  • Software Dependencies
  • Hardware Dependencies
  • Test Data & Database

12.Test Environment—

  • Specify the properties of test environment: hardware, software, network etc.
  • List any testing or related tools.

13.APPROVALS

  • Specify the names and titles of all persons who must approve this plan.
  • Provide space for signatures and dates.

14.Risks and Risk management plans—

  • List the risks that have been identified.
  • Specify the mitigation plan and the contingency plan for each risk.

15.Test Criteria—

  • Entry Criteria
  • Exit Criteria
  • Suspension Criteria

16.Estimate

  • Size
  • Effort
  • Schedule
English: Blue ink on the inspection sheet indi...

English: Blue ink on the inspection sheet indicates to the students that they are a “go” during the sling load hands-on testing in the Camp Robertson Training Area Oct. 8. (Photo credit: Wikipedia)

Difference between Load Testing and Stress Testing:

  • Testing the app with maximum number of user and input is defined as load testing. While testing the app with more than maximum number of user and input is defined as stress testing.
  • In Load testing we measure the system performance based on a volume of users. While in Stress testing we measure the breakpoint of a system.
  • Load Testing is testing the application for a given load requirements which may include any of the following criteria:
    •  Total number of users.
    •  Response Time
    • Through Put
    • Some parameters to check State of servers/application.
  • While stress testing is testing the application for unexpected load. It includes
    • Vusers
    • Think-Time

Example:

If an app is build for 500 users, then for load testing we check up to 500 users and for stress testing we check greater than 500.