TEST PLAN

Definition: It is a document which is prepared by the managers or test lead. It consists of all information about the testing activities.

Test plan components or attributes: –

  1. Aim           : – It indicate the aim of the application means the application behavior,                                      goal etc.
  2. Objective : – It consists an information about modules, features, test data etc.
  3. Scope        : – This contains an information which need to be tested with respective                                      of an application.
  4. Test methodology: – It contains an information about performing a different kind               of testing like FT, IT, ST etc.
  5. Schedule   : – It contains information about the timing with respective to particular task.           Ex: – Writing test cases Execution process
  6. Template   : – It is a format used to maintain Generic.                                                                     EX: – different types of templates 1.Test case Template                                                                                                                                2. RTM Template                                                                                                                                      3.Bug Report Template
  7. Test Environment: – It consist of software and hardware configuration S/W configuration means information about OS/Browsers H/W configuration like Ram, Rom, Processors.
  8. Assumption          : – It contains an information about a problem may be                                 occur during the testing process.
  9. Risk : – The effect of the problem during testing process.                                                           Ex: – Effect for an application, release date become post pond
  10. Mitigation Plan or Contingency Plan: – It is a back-up plan prepared to avoid the assume risks
  11. Assume               : – There are the problem that may encounter during testing process
  12. Test deliverable: – The test documents which is given to the customer while giving the product to him                                                                                                                                         Test Cases – Test Scripts – RTM – Test Execution Report – Release Notes like User-manual/Installation process/List of platform on which Tested/list of available bugs in current release/list of fixed bugs in previous release
  13. Role & Responsibility: – It defines the complete task which need to be performed by the     entire testing team.

avb

Test Document:

Definition: These are the necessary test document which are prepared by every Test Engineer before starting the test execution process.

  • Generally we write the test documents simultaneously when the developer is busy in coding.
  • Entire execution process depends on test document only.
  • Team lead will assign the modules and we go through this requirement for some days.

Test Document is a combination of Test Scenarios and Test Cases

Test Scenarios:

Definition: The High level document which are written by the Test Engineer that talks about all the possible ways to test the application.

How to write Test Scenarios:

  1. Always list down the known modules.
  2. While writing the scenarios pick module by module so that we don’t miss any module.
  3. Before writing scenarios we should have knowledge on each and every module.
  4. Every scenario need to be written maximum of 2 sentences so that we can easily understand.
  5. always write the delete option has last scenario.

Test Cases

Definition: It is an in detail document that describe step by step procedure to test an application and also consists of inputs and all the scenarios that need to be tested for an application.

For writing test case we need test case template

5

  1. Header: It consists of
  • Test Case NameTells about the name of the test case. Each test case has different names.
  • Test Case Type: Tells about which type of testing whether functional or integration
  • Module name: Tells about which module this test case belongs to. 
  • Project Name: Name of the project we are doing.
  • Status  : Tells about whether the test case is pass or fail it is written after the test case execution.
  • Severity : Severity is nothing but the importance of the module. There are 3 types
  1. critical-  If the module is used by all users and it effects more                                                                        Example: login,compose,inbox  
  2. Major –  If the module is used by all users and it effects some less                                                                   Example: sent items                                      
  3. Minor –  If the module is used by some users and it effects is less                                                                   Example:help,logout
  • Release                 : These are the major changes done in the application.
  • Version                 : These are the small UI issues changed for the application.
  • Precondition       :  These are the necessary condition which need to full filled by the test engineer before starting the test execution process.                                                                      Example – Email id, files because first they need to be created.
  • Test Data              : What are the inputs need to be given for the application is written in it.

2. Body: It consists of

  • Step                     : No of steps are there. It is like serial number.
  • Description        : What we need to do with the application.
  • Input                    : The value needs to be given in the components.
  • Expected Result: Test Engineer with out executing he will write the result what need to be                                come when executed.
  • Actual Result     : The result which will come after execution is done.
  • Status                  : Whether the components is pass or fail.
  • Comments         : Here we write the reasons why it is fail.

3. Footer: It consists of

  • Name of the author who write the test cases.
  • Date of creation.
  • Who reviewed the test case his name will be there.
  • The name of the person who approved the test case.

Test Case Design Techniques:

These are the rules or technique that should be followed by the test engineer while writing the test cases to achieve maximum test coverage. There are 3 different types of Test Case Design Technique they are

  1.  Error Guessing: In this type we simply start guessing the values based our understanding of the requirement                                                                                       Disadvantages:                                                                                                                                          1. Depends on the person to person.                                                                          2. Minimum test coverage may not be achieved.                                                                  3. Boundary values not covered.
  2. Equivalence Partitioning:
  • If the requirement is range of values then derive the test case for 1 valid & 2 invalid inputs.
  • If the requirement is set of values then deriving the test case for 1 valid & 2 invalid inputs.
  • If the requirement id Boolean (true/false) then derive the test case for both true / false values.                                                                                                          Disadvantages:
  • Boundary values not covered

      3. Boundary Value Analysis:  If the requirement is range of values that is A,B then derive the test case as follows i.e. A, A+1, A-1, B, B+1, B-1.                                                                                           Example:

A, A+1, A-1B, B+1, B-1
500,501,4995000, 5001, 4999

 

Test Case Review Process:

If we don’t go for this we

  • Miss out some scenarios
  • Accuracy won’t be there
  •  Test Engineer won’t be serious                                                                                                            This is done after writing all test case and before the test execution of the test case
  1. Once the Test Cases are written it should be Review to check for the proper flow and maximum test cover before the execution so that every test engineer will be serious about writing the test cases.
  2. After Author wrote the Test Cases that will be sent to the Reviewer and review the Test case allowing with the corresponding requirement and check the correctness of Test Case by proper flow & maximum Test coverage and he found any mistake that will be written separate document called as Review Document and Team Lead be in the loop this process goes until the test case stable and it finally sends to the Test Lead to Approve the Test case.texy

Reviewer Ethics:

  • Look for flow & Maximum Test Cases.
  • Find Mistake not solutions.
  • Both Author & Reviewer are responsible for Test Case.
  • Review content not Author.

Test Case Repository:

It is a centralized location where all the based lined test cases are stored and generally the folder structure created by the Test Lead.ghfg

RTM(Requirement Trace ability Matrix):

Definition: It is a Document which is prepared before the test execution process to make sure that every requirement is covered in the form of Test case so that we don’t miss out testing any requirement.

  • Test engineer will prepare RTM for their respective assign modules and then it will be sent to the Test Lead.
  • The Test Lead will go repository to check whether the Test Case is there or not.
  • Finally Test Lead consolidate and prepare one necessary RTM document.gfhgj

Test Execution Report:

It is a document prepared by leads and managers after the complete execution process is over and all the bugs are fixed.

Every module have separate spread sheet of their respective module.Test execution report talks about the number of test cases written, executed, pass, fail and their percentages. over all it talks about the stability of the product.jhgj

Click on CONTINUE

 

 

 

 

 

 

 

 

 

 

 

 

 

 

                                                                      

Comments

  1. Pingback: Manual Testing – TechHades

Leave a Reply

Your email address will not be published. Required fields are marked *

fifteen + five =