Archive for the ‘Testing Basics’ Category

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.
Advertisements

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.

English: System Life Cycle as taught in the AQ...

Systems Development Life Cycle (SDLC):

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project. o manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental etc.

Stages or different phases of SDLC are mentioned below:

  • Project planning, feasibility study
  • Systems analysis, requirements definition
  • Systems design
  • Implementation
  • Integration and testing
  • Acceptance, installation, deployment
  • Maintenance

Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.

Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudo code and other documentation.

Implementation: Coding is written by developers in this phase.

Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.

Maintenance: What happens during the rest of the software’s life: changes, correction, additions, and moves to a different computing platform and more? This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

Waterfall Model:

The waterfall model is a sequential software development model in which development is seen as flowing steadily downwards (like a waterfall) through several phases.

Waterfall model was meant to function in a systematic way that takes the production of the software from the basic step going downwards towards detailing just like a Waterfall which begins at the top of the cliff and goes downwards but not backwards.

Different Phases of Waterfall Model:

Definition Study / Analysis: During this phase research is being conducted which includes brainstorming about the software, what it is going to be and what purpose is it going to fulfill.

Basic Design: If the first phase gets successfully completed and a well thought out plan for the software development has been laid then the next step involves formulating the basic design of the software on paper.

Technical Design / Detail Design:  After the basic design gets approved, then a more elaborated technical design can be planned. Here the functions of each of the part are decided and the engineering units are placed for example modules, programs etc.

Construction / Implementation: In this phase the source code of the programs is written.Testing: At this phase, the whole design and its construction is put under a test to check its functionality. If there are any errors then they will surface at this point of the process.

Integration: in the phase of Integration, the company puts it in use after the system has been successfully tested.Management and Maintenance: Maintenance and management is needed to ensure that the system will continue to perform as desired.

Advantages of Waterfall Model:

  • Waterfall model is simple to implement and also the amount of resources required for it are minimal.
  • This methodology is preferred in projects where quality is more important as compared to schedule or cost.
  • Documentation is produced at every stage of the software’s development. This makes understanding the product designing procedure, simpler.
  • After every major stage of software coding, testing is done to check the correct running of the code.

 Disadvantages of Waterfall Iterative Model:

  •  Real projects rarely follow the sequential flow and iterations in this model are handled indirectly. These changes can cause confusion as the project proceeds.
  •  In this model we freeze software and hardware. But as technology changes at a rapid pace, such freezing is not advisable especially in long-term projects.
  • Even a small change in any previous stage can cause big problem for subsequent phases as all phases are dependent on each-other.
  • Going back a phase or two can be a costly affair.