Agile Methodology

Now a days every MNC in IT sector is following Agile methodology because of its advantage.
In the agile methodology, the team will design and implements the code for certain part of the Software according to client requirements and delivers the build to the testing team and client for the evaluation.

If the client and Testing team feedback is positive on the basis of requirements documents, then the development team moves to Remaining part of the software development ,

If they receives negative feedback the re-work will be done on the Developed software.

This is called one of the "test driven software development model" because the client will be closely associated with the development team and testing team. So there is a high chance to deliver the high quality product.  

The software engineers follow different approaches in development and testing. Agile methodology in testing is completely different from Other models .

In agile methodlogy the software engineers follow different frameworks to develop and to deliver the project.
The popular framework among all is "Scrum".

Tomorrow we will be discussing the complete scrum process in detail.
Source: 1) Mostly Wikipedia and other related sites,
             2) My trainer notes and
             3) Special thanks to Mr. Srikanth Girijala for the support in some Concepts

Test Plan Document:

Test Plan Document:

This document is prepared by the Test lead once they get the approved test strategy document from the test manager.

The test plan document is dependent on Build release.  

Contents of Test Plan Document:  

      Title: It describes the name of the project with type of document

Example: Banking System Test Plan v1.0 à describes the type of the document with version number where v1.0 represents initial version of first module.

·         History Of Document: It describes about the details of author of test plan document, when it was prepared, who conducted reviews, change of notifications and approval of test plan document.

·         Introduction :

Ø Project Overview: Brief description about the application under test.

Ø Objective of Test Plan: Brief description about the current test plan document.

Ø Referred Documents: About the documents referred to prepare the test plan document.

Example: BRS and FRS documents.

Ø Scope :

ü    In Scope:  It describes the possible testing activities under current test plan like functionality testing, usability testing, etc…

ü    Out of Scope: It describes the activities which are not possible under current test plan like unit testing, integration testing, performance testing, etc…

·         Features to be tested: It describes about the available modules and requirements in current build to validate

·         Features not to be tested: It describes about the modules and requirements which are not required to validate.

·         Entry & Exit Criteria:

a)      Entry criteria describe when to start testing or when to perform dynamic testing or when to perform test case’s execution.

The factors which were considered in entry criteria,

      All the test cases should be prepared and reviewed.

      Build should be deployed (installed) at test environment.

      Build should pass sanity test. i.e., build must be stable.

      Test environment setup should be completed.

b)      Exit criteria describe when to stop testing activities.

The factors which were considered in exit criteria,

      All the test cases should be executed atleast once.

      Majority of the test cases should be passed.

      Identified defects should be closed or postponed.

      Defect ratio must be less than acceptance level.

      Budget and time constraints should be keep in mind.

      When UAT is completed then test engineers can stop testing.

·         Suspension & Resumption Criteria:

a)      Suspension Criteria: It describes when the test engineer can suspend the test cases    execution.

The factors which were considered in suspension criteria,

      When build is not stable, means when it is failed in Build Verification Test.

      When there is a change request from client.

      Delay in publishing input documents.

      Whenever test engineer identifies showstopper defect.

b)                  Resumption Criteria: It describes when to continue the test execution after suspension.

The factors which were considered in resumption criteria is,

      When the patch file is released for rejected build.

      When requirements are refined based on client request acception or rejection.

      When input documents are publishes.

      When showstopper defects are resolved.

·         Testing Approach: It describes the testing approaches they will be using to validate the application functionality.

Example: Usability testing, functionality testing, compatibility testing etc…

·         Roles & Responsibilities: It describes the test engineer names and allocated tasks to perform.

·         Schedule: It describes the timelines to perform each activity during testing.

·         Test Environment: It describes the required environment setup for test cases execution like hardware and software configurations in the system to run the test cases.

Example: Browser setup, OS settings, etc…

·         Test Deliverables: The document which needs to be delivered at end of every task in testing is known as test deliverables.

Here in entire testing process after every phase the documents regarding to that phase must be delivered to the appropriate officials.

Example: Test Cases Review Report, Test Cases Execution Report, etc…

·         Risks & Mitigations: It describes the possible risks and the solutions for those risks at the test environment and work environment.

Example: Lack of domain knowledge to test engineers , here the solution is conducting KT sessions .

Note: Once the test plan document is prepared, the test leas conduct review with senior test engineers to get it approved and then the approved test plan document is delivered to the test engineers of the team.

Interview Question: What is showstopper defect???

Some Useful Templates_ Defect Report Template:

Every Organization will maintain their own templates .

Defect Report: The document which is used to report about the identified defects while testing the software application to the development  team , and the process of reporting is known as defect reporting.

Sample Defect Report Template:

Components of Defect Report Template:

Summary: Brief description about the review.

Defect_ID: The name of the defect and it should be unique.

Note: If we are using any defect reporting tool then tool will generate unique ID for a defect.

Reported By: The name of the test engineer who identified the defect.

Reported On: On which date the defect identification was done.

Note: In general, whenever the Test engineer identified defect on the same day we need to report about the defect.

Reported To: The person belongs to the development to whom the test engineer reports about the defect.

Reproducible Defect: If the defect is raised whenever the test engineer rechecks the same functionality then it is the reproducible defect.

Reproducible à Yes

Not Reproducible à No

Project Name: Name of the project.

Module Name: Name of the module in the particular project.

Build Version: Version Number of the build.

Test Set: Name of the test set in which test cases are failed.

Test Case_ID/Name: Name of the test case in which the defect is identified.

Priority: It describes the importance of the functionality in which we identified the defect.  Levels of Priority were High, Medium, Low.

Severity: It describes the impact of the defect to execute other test cases. The levels of Severity were High, Medium, Low.

Status: It describes the state of the defect.

Snapshot: The picture of the functionality in which we identified the defect.

Some Useful Templates_RTM TEMPLATE

RTM (Requirement Traceability Matrix): RTM is a dcocument consists of tabular format which is used to cross check the requirements coverage with the written test cases. It can be prepared by the test engineer or test lead. RTM can be prepared either in excel sheet or in Quality Center (Depends on the availability of the resources in the organization).

Sample Requirement Trace ability Matrix (RTM) Template:

Components of RTM Template:

Project Name: Name of the project.

Module Name: Name of the module in the particular project.

Created By:  Name of the test engineer who created the Requirement Traceability Matrix.

Created On: The date on which the RTM was prepared.

Reviewed By: Names of the persons who were responsible to conduct the reviews on RTM.

Reviewed On:  On the date review was conducted.

Referred Documents:  Inputs to derive the RTM.

Requirement_ID: The name of the specific requirement of a particular application and it should be unique:

Syntax:  001 Project Name_Module Name_Requirement

Test Scenario: The scenarios which were derived based on the requirement. One requirement may have many test scenarios.

Syntax: TS001_Requirement_Derived condition for that requirement

Test Case_ID/Name:  The name of the test case and it should be unique for the derived test scenario

Syntax:  TC001_Project Name_Module Name_Functionality

Test Case Description: It describes the purpose or objective of the written test case.

Some Useful Templates_TEST CASE TEMPLATE

Here I followed the general standards in the preparation of templates

Test Case: The step by step procedure to validate the functionality of the application, for every user and the subsequent response from the system. Every Organization will maintains their own template. 

Sample Test case Template:

Components of test case template:

Project Name: Name of the project.

Module Name: Name of the module in the particular project.

Created By:  Name of the test engineer who created the test cases.

Created On: The date on which the test cases are prepared.

Reviewed By: Names of the persons who were responsible to conduct the reviews on Test cases.

Reviewed On:  On the date review was conducted.

Referred Documents:  Inputs to derive the test cases.

Test Case_ID/Name:  The name of the test case which should be unique.
Syntax:  TC001_Project Name_Module Name_Functionality.

Test Case Description: It describes the purpose or objective of the test case.

Step Name: It describes the no. of steps in a test case.

Example: Step1. Step2, Step3…etc

Step Description: It describes the user operation to be performed on AUT (Application Under Test) during test cases execution.

Test Data: It describes the data which we give to the application during test cases execution.

Priority: It describes the importance of the test case for execution. It was derived based on the importance or usability of the functionality with respect to client business needs. Based on the importance priority status can be mentioned as High, medium, low.

Expected Result: It describes the expected behavior of the application with respect to user operations.

Actual Result: It describes the actual behavior of the application after execution of the test case.

Status: It describes the status if the test case after execution. The statuses used to mention in status column is

Passed:  When both actual result and expected result are same.

Failed: When the actual result and expected result are not same.

QC Path: It describes the name of the folder in “Test Plan” Component of Quality Center (QC) to export these written test cases. 

About Reviews

Reviews and Its Types:

Review is a type of verification technique.

Without executing the application checking to find out the defects on the work done is known as Reviews.

We have different types of Reviews.

Peer Review: Peer Reviews (One to One Reviews) are informal reviews between two employees, where one employee delivers the details regarding the documents to other employees for the identification of mistakes/defects with no cost. It is an unplanned meeting.

Example: My friend is struggling with generation of test script for particular functionality. After I finish my work, I am helping her. This is the great example of peer reviews.

Walkthroughs: Walkthroughs are the semi informal meeting with more than 2 or more employees, where the document owner (Author) explains about the document to the other employees to identify the mistakes/defects. It is a pre- planned review, so it costs more than peer reviews

Example: Presenting my ideas regarding one task in front of the 2 or more members with full preparation.

Inspections: A fully formal meeting with more than 5 employees, where all the employees participate with the intention of finding mistakes/defects.

Interview Questions_0103: What is peer review??

Interview Questions_0104: What is a walkthrough??

Interview Questions_0105: What do you mean by Inspections??

Interview Questions_0106: Have you participated in the peer reviews while doing project at your institute??

Updation to Interview Questions List :)

Now, it’s time to update interview Questions List

Interview Questions_082: What do you mean by STLC??

Interview Questions_083: What is UAT??

Interview Questions_084: What is Test strategy document??? Who prepares it??

Interview Questions_085: What is test plan document??? Who prepares it??

Interview Questions_086: Have you ever participated in the preparation of test plan document??

Interview Questions_087: Difference between test plan and test strategy documents??

Interview Questions_088: Can you explain any one of the risks during testing??

Interview Questions_089: What do you mean by Efforts Estimation??

Interview Questions_090: What do you mean by exit criteria??

Interview Questions_091: What is the minimum requirement to start the execution process??

Interview Questions_092: What is test suite??

Interview Questions_093: Basic rules to generate Test Cases??

Interview Questions_094: Explain different types of test cases??

Interview Questions_095: Difference between positive and negative test cases??

Interview Questions_096: What do you mean by Requirements Traceability Matrix??

Interview Questions_097: Explain Test Execution Flow??

Interview Questions_098: Explain different statuses using to mention in Result column of test case template??

Interview Questions_099: Give me some defect reporting tools names??

Interview Questions_100: Give me some defect tracking tools names??

Interview Questions_101: Explain defect submission process??

Interview Questions_102: Explain bug life cycle along with diagram??

Interview Questions_103: What is the difference between hold and deferred statuses??

Interview Questions_104: What is defect Age??