What is Difference Between Test Plan, Test Strategy, Test Case, Test Script, Test Scenario and Test Condition?

Software Testing Training: End to End Training on a Live Project – Free Online QA Training Part 1

We are very excited to present this next series of software testing training free tutorials. We are going to simulate an end to end real time software project going over each and every phase in detail with a special emphasis on QA training processes, phases, roles & responsibilities, deliverables etc. In short be ready for a short online software

Why this Free QA Training?

We get many queries from our readers to share our experience on the exact software testing process followed by the software testing teams. So we decided to document this complete STLC with the help of a sample live application which is available to test on the Internet.

We will be using this live project for our software testing training series. We strongly recommend you to closely follow this series as it is going to be a crash course to learn and implement testing practices on a live application.

Software Testing Training on Live Project – What is it?

Before we go any further, let me take a moment to explain what this software testing course series is all about and how it is going to take shape as we move forward.

We picked a live application (whose details are below) and start with:

• SRS review
• writing test scenarios
• test planning
• test case design
• test data identification
• test execution
• defect management
• status reporting
• metric collection

– basically, everything that we would typically do in a real time software testing project – with real time examples, artifacts and deliverables all created in the process.

How to follow this software testing course series?

Step#1: Introduction and SRS Walkthrough – We will start this mini software testing course with SRS walkthrough. We have created and shared a sample SRS document. Go through it as all further steps depend on your understanding of this application.

Step #2: SRS review and test scenario preparation.

Step #3: Test Plan – complete process of creating a test plan from the scratch. The final test plan version will be shared with you for reference.

Step #4: Test Cases – complete test cases writing process with some sample test cases. We may use any test management tool or spreadsheet for writing test cases.

Step #5: Application walkthrough and test execution – how to execute test cases and record the test results.

Steps #6: Defect reporting

Step #7: Defect verification, regressing testing process

Steps #8: QA Sign-off

The intention is to give you all a feel of real time project experience and expertise. We hope you find this series useful.

Introduction to the application that we are going to use further:

Client: Orange

Application: OrangeHRM demo.

Service provider: SoftwareTestingHelp.com

Project description: Orange wants to create a commercial human resources management product that can be consumed and customized by medium sized businesses located in a single country and globally. It has 2 versions: Professional and Enterprise.

The features include:

• Personal Information Management
• Advanced Leave Management
• Time & Attendance Tracking
• Employee Performance Management
• Recruitment
• Advanced Reporting
• Country / Location Based Employee Management
• Localized Leave Rules
• Configurable Workflows
• Platinum Support
• Country/Location Based Reporting
• Custom Reporting

Note: For the sake of simplicity and to limit out scope let us consider the employee module of this HRM portal where the user has an option to enter their personal information.

When a customer or a business owner has a need to venture into the online world or make updates on the already existing site or application, the need is a business problem and the software is a piece of code that is designed to solve this business problem.

A customer then approaches a software service provider to make this software a reality for them. That is when the software project inception begins.

A traditional waterfall project (SDLC) has the following phases:

• As QAs we all know that even though “Test” is step 5 of this flow, it is not the only place we testers play a prominent role.
• Also, testing is a reactive job. With no code/application ready to test we cannot really ‘test’ anything. In order to be ready and react in the most efficient way possible we try as much as we can to plan and prepare ahead. So, even though phase 5 is for testing, our activities start way ahead.

Briefly this is what happens in each phase:

Initiate:

Once the producer and the customer agree on terms – the software production begins.

• In this phase, business requirements are gathered and analyzed. The analysis is going to involve the decisions on technological considerations, hardware & software specifications, people, effort, time, relevance and improvements among others.
• Business analysts, Project Managers and client representative are involved in this step.
• At the end of this step and basic project plan is prepared.
• Project specific documents like scope document and/or business requirements are made.
• QA involvement at this stage is typically not to be expected. (This is a slight deviation from what it should be because to identify issues early in the developmental phases, it is best to involve QA right from the beginning.)

Define:

The business requirements finalized are the inputs for this step.

• This phase involves the translation of business requirements into functional requirements for the software. For example: if the business requirement is to allow a user to buy something from a site. The functional requirement will have details like site format->menu option name and placement->Search product-> shopping cart->Checkout (registration or not) ->payment options->confirmation of sale.
• Developers, Business Analysts, Project Managers are involved in this phase
• The output of this phase is a detailed document containing the functional requirements of the software. This document is referred to by many names – Software Requirement Specification (SRS), Functional requirements document (FRD) or Functional requirements specification (FRS).
• This is where the QA team gets involved – after the completion of SRS documentation.
• While the finalizing on functional requirements and the documentation of the SRS is going on, the QA manager/lead is involved to draft an initial version of the test plan and form a QA team.
• The QA team’s involvement is going to be once the SRS is documented.
• At this stage either the development team or the business analyst or sometimes even the QA team lead will give a walkthrough of the SRS to the QA team.
• In case of a new project a thorough walkthrough in the form of a conference or meeting works best
• In case of later releases for an existing project, a document is sent via email or placement in a common repository to the QA team. QA team at this point would read/review it offline and understand the system thoroughly.
• Since the primary target audience for the SRS document is not just testers, not all of it is useful for us. We testers should be diligent enough when reviewing this document to decide what parts of it are useful for us and what parts of it are not.

SRS Document for this Live Project

A sample SRS document is attached to this post to give you an idea on how this document looks like, the format in which it is written, what kind of information it contains etc. In the next article we will get into how this document is consumed by the QA team to proceed further in our testing projects.

==> Download Live Project Sample SRS Document.

Summary:

In this article we introduced you to the software development and testing process. We also shared a sample SRS document for the live project that we are going to test.

=> Next article in this software testing training series will be – SRS review and the process of creating test scenarios.

A note to the readers here: While the next article in this QA training series is being written, work with us in parallel here for the most live-like experience. Try to give the SRS document a good reading and then we will continue with the next steps when we meet again.

Happy Testing, till then!