Skip to main content

Testing Artifacts


TEST PLAN Fundamentals

TEST PLAN DEFINITION
A Software Test Plan is a document describing the testing scope and activities. It is the basis for formally testing any software/product in a project.
ISTQB Definition
  • test plan: A document describing the scope, approach, resources and schedule of intended test activities. It identifies amongst others test items, the features to be tested, the testing tasks, who will do each task, degree of tester independence, the test environment, the test design techniques and entry and exit criteria to be used, and the rationale for their choice,and any risks requiring contingency planning. It is a record of the test planning process.
  • 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 TYPES
One can have the following types of test plans:
  • Master Test Plan: A single high-level test plan for a project/product that unifies all other test plans.
  • Testing Level Specific Test Plans:Plans for each level of testing.
    • Unit Test Plan
    • Integration Test Plan
    • System Test Plan
    • Acceptance Test Plan
  • Testing Type Specific Test Plans: Plans for major types of testing like Performance Test Plan and Security Test Plan.
TEST PLAN TEMPLATE
The format and content of a software test plan vary depending on the processes, standards, and test management tools being implemented. Nevertheless, the following format, which is based on IEEE standard for software test documentation, provides a summary of what a test plan can/should contain.

Test Plan Identifier:
  • Provide a unique identifier for the document. (Adhere to the Configuration Management System if you have one.)
Introduction:
  • Provide an overview of the test plan.
  • Specify the goals/objectives.
  • Specify any constraints.
References:
  • List the related documents, with links to them if available, including the following:
    • Project Plan
    • Configuration Management Plan

Test Items:
  • List the test items (software/products) and their versions.
Features to be Tested:
  • 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
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.
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]
Item Pass/Fail Criteria:
  • Specify the criteria that will be used to determine whether each test item (software/product) has passed or failed testing.
Suspension Criteria and Resumption Requirements:
  • Specify criteria to be used to suspend the testing activity.
  • Specify testing activities which must be redone when testing is resumed.
Test Deliverables:
  • List test deliverables, and links to them if available, including the following:
    • Test Plan (this document itself)
    • Test Cases
    • Test Scripts
    • Defect/Enhancement Logs
    • Test Reports

Test Environment:
  • Specify the properties of test environment: hardware, software, network etc.
  • List any testing or related tools.
Estimate:
  • Provide a summary of test estimates (cost or effort) and/or provide a link to the detailed estimation.
Schedule:
  • Provide a summary of the schedule, specifying key test milestones, and/or provide a link to the detailed schedule.
Staffing and Training Needs:
  • Specify staffing needs by role and required skills.
  • Identify training that is necessary to provide those skills, if not already acquired.
Responsibilities:
  • List the responsibilities of each team/role/individual.
Risks:
  • List the risks that have been identified.
  • Specify the mitigation plan and the contingency plan for each risk.
Assumptions and Dependencies:
  • List the assumptions that have been made during the preparation of this plan.
  • List the dependencies.
Approvals:
  • Specify the names and roles of all persons who must approve the plan.
  • Provide space for signatures and dates. (If the document is to be printed.)
TEST PLAN GUIDELINES
  • Make the plan concise. Avoid redundancy and superfluousness. If you think you do not need a section that has been mentioned in the template above, go ahead and delete that section in your test plan.
  • Be specific. For example, when you specify an operating system as a property of a test environment, mention the OS Edition/Version as well, not just the OS Name.
  • Make use of lists and tables wherever possible. Avoid lengthy paragraphs.
  • Have the test plan reviewed a number of times prior to baselining it or sending it for approval. The quality of your test plan speaks volumes about the quality of the testing you or your team is going to perform.
  • Update the plan as and when necessary. An out-dated and unused document stinks and is worse than not having the document in the first place.
TEST CASE Fundamentals
DEFINITION
A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements or works correctly.
The process of developing test cases can also help find problems in the requirements or design of an application.
TEST CASE TEMPLATE
A test case can have the following elements. Note, however, that normally a test management tool is used by companies and the format is determined by the tool used.
Test Suite ID
The ID of the test suite to which this test case belongs.
Test Case ID
The ID of the test case.
Test Case Summary
The summary / objective of the test case.
Related Requirement
The ID of the requirement this test case relates/traces to.
Prerequisites
Any prerequisites or preconditions that must be fulfilled prior to executing the test.
Test Procedure
Step-by-step procedure to execute the test.
Test Data
The test data, or links to the test data, that are to be used while conducting the test.
Expected Result
The expected result of the test.
Actual Result
The actual result of the test; to be filled after executing the test.
Status
Pass or Fail. Other statuses can be ‘Not Executed’ if testing is not performed and ‘Blocked’ if testing is blocked.
Remarks
Any comments on the test case or test execution.
Created By
The name of the author of the test case.
Date of Creation
The date of creation of the test case.
Executed By
The name of the person who executed the test.
Date of Execution
The date of execution of the test.
Test Environment
The environment (Hardware/Software/Network) in which the test was executed.
TEST CASE EXAMPLE / TEST CASE SAMPLE
Test Suite ID
TS001
Test Case ID
TC001
Test Case Summary
To verify that clicking the Generate Coin button generates coins.
Related Requirement
RS001
Prerequisites
  1. User is authorized.
  2. Coin balance is available.
Test Procedure
  1. Select the coin denomination in the Denomination field.
  2. Enter the number of coins in the Quantity field.
  3. Click Generate Coin.
Test Data
  1. Denominations: 0.05, 0.10, 0.25, 0.50, 1, 2, 5
  2. Quantities: 0, 1, 5, 10, 20
Expected Result
  1. Coin of the specified denomination should be produced if the specified Quantity is valid (1, 5)
  2. A message ‘Please enter a valid quantity between 1 and 10’ should be displayed if the specified quantity is invalid.
Actual Result
  1. If the specified quantity is valid, the result is as expected.
  2. If the specified quantity is invalid, nothing happens; the expected message is not displayed
Status
Fail
Remarks
This is a sample test case.
Created By
John Doe
Date of Creation
01/14/2020
Executed By
Jane Roe
Date of Execution
02/16/2020
Test Environment
  • OS: Windows Y
  • Browser: Chrome N
WRITING GOOD TEST CASES
  • As far as possible, write test cases in such a way that you test only one thing at a time. Do not overlap or complicate test cases. Attempt to make your test cases ‘atomic’.
  • Ensure that all positive scenarios and negative scenarios are covered.
  • Language:
    • Write in simple and easy to understand language.
    • Use active voice: Do this, do that.
    • Use exact and consistent names (of forms, fields, etc).
  • Characteristics of a good test case:
    • Accurate: Exacts the purpose.
    • Economical: No unnecessary steps or words.
    • Traceable: Capable of being traced to requirements.
    • Repeatable: Can be used to perform the test over and over.
    • Reusable: Can be reused if necessary.
TEST SCRIPT Fundamentals
A Test Script is a set of instructions (written using a scripting/programming language) that is performed on a system under test to verify that the system performs as expected. Test scripts are used in automated testing.
Sometimes, a set of instructions (written in a human language), used in manual testing,  is also called a Test Script but a better term for that would be a Testcase.
Some scripting languages used in automated testing are:
  • JavaScript
  • Perl
  • Python
  • Ruby
  • Tcl
  • Unix Shell Script
  • VBScript

Comments

Post a Comment

Popular posts from this blog

Test Scenarios for Excel Export Functionality

1. The file should get exported in the proper file extension. 2. The file name for the exported Excel file should be as per the standards e.g. if the file name is using the timestamp, it should get replaced properly with an actual timestamp at the time of exporting the file. 3. Check for date format if exported Excel file contains the date columns. 4. Check number formatting for numeric or currency values. Formatting should be the same as shown on the page. 5. The exported file should have columns with proper column names. 6. Default page sorting should be carried in the exported file as well. 7. Excel file data should be formatted properly with header and footer text, date, page numbers etc. values for all pages. 8. Check if the data displayed on a page and exported Excel file is the same. 9. Check export functionality when pagination is enabled. 10. Check if export button is showing proper icon according to the exported file type E.g . Excel file icon for xls files 11.
Post a Comment
Read more

Basic Introduction of RPA

  1) What is Robotic Process Automation? ·          Robotic process automation (RPA) is defined by the Institute for Robotic Process Automation (IRPA) as ‘the application of technology allowing employees in a company to configure computer software or a ‘robot’ to capture and interpret existing applications for processing a transaction, manipulating data, triggering responses and communicating with other digital systems.’ ·          RPA (Robotic Process Automation) Robotic Process Automation enables you with tools to create your own software robots to automate any business process. Your “bots” are configurable software set up to perform the tasks you assign and control. 2) What Can RPA Do? ·          RPA is software-based, it can be used to perform various tasks. These include maintenance of records, queries, calculations, and transactions. Additionally, any application commonly used by your company can be operated by RPA. ·          For example, Citrix, .NET, HTML,
Post a Comment
Read more

Introduction to Apache JMeter

Apache JMeter is a great open source application with awesome testing abilities. Web Server is a platform which carries loads of numbers of applications and users, so that it is necessary to know that how does it works or performs means; how effective it is to handle simultaneous users or applications. For example; how the “Gmail” supporting server will perform when numbers of users simultaneous access the Gmail account – basically have to do performance testing using performance testing tools like JMeter, Loadrunner etc. To check the high performance of the application or server, do high performance testing using JMeter for exceptional results. Before understanding Overview of JMeter , let us have a look on three testing approach, Performance Test : This test provides the best possible performance of the system or application under a given configuration of infrastructure. Very fast, it also highlights the change need to be made before application goes into producti
Post a Comment
Read more