Skip to main content

Test Cases

Test cases is the document that contains the information regarding the Test data, Prerequisite, Expected result etc. These test cases developer by the QA Team before develop the code. After develop the code , QA team verified these test cases with the execution of code and as per the output match that with expected result and provide the status of that test Pass or Fail.

Test Case document include all possible Test cases by understand the Requirement Document, Design Document. Only your test cases will define the quality of the software. if Test cases include all possible scenario then it is easy to test the application and find bugs and provide good quality of the Software.
Following fields are required for the Test Cases


  • Test Case id: This the Test Cases id for the specific test case for future reference. This is the Unique Id
  • Test Case Description/Objective: It include the description regarding your Test. Suppose you are writing the Test cases of Login Page then then it is include like "To Verify the Login Form".
  • Tester: It include the Tester Name
  • Environment: It include the environment that we are using for Testing . Suppose we are using Window/Linux/Mac operating system with, 1GB Ram, 80 GB Hard Disk, Firefox/Chrome/Opera/Safari browser etc.
  • Version: It include the version of release. 
  • Module: It include the module name. 
  • Prerequisite: it include the prerequisite condition that should be fulfilled before execution of the Test. For Login form it may be Login form should be developed, It include both email/username field and Password field with a Submit button.
  • Date of Creation: It include the Date of writing Test case.
  • Date of Release: It include the date of releasing the software or that module.
  • Test Steps: It include the procedure that we are following to execute the test. In case of Login form, it is like put valid username and valid password and click on Submit button.
  • Test Data: It include the data that will used to as a input for test. 
  • Expected Result: It include the result which is expected as per the requirement document. 
  • Actual Result: It include the result which will be generated after execution of the code. 
  • Status: It include the status Pass or Fail. If Actual result match the expected result then status is Pass otherwise status is Failed. 
  • Date: It include the date of execution.
  • Comments: If Tester/developer have any double or he/she want to write any message then he/she can use this comment section. 
  • Defect Id/Link: It include a link for Fail test cases with the defect report. 
  • Test Type: It include the type of test that needed. it may be Function Test, Regression Test, Performance Test.
  • Requirements: It include the requirement as per the Test cases with exact section number for better understanding.
  • Attachment: It include any attachment for reference for explain the other team member.
  • Automation: It include the information that the test case will execute manually or by automation. 
Download the format of the Test case template 


Comments

Popular posts from this blog

What is API?

In general way, API (Application Programming Interface) is the intermediate software which is useful for two applications to communicate. API is the tool which is used for interaction of two applications. If developer developing any software which have multiple blocks (Modules) than developer use APIs to put them together.

Ad-Hoc Testing

Ad-Hoc Testing is the testing type which is performed without any proper procedure and without any Requirement Specification. Ad-Hoc testing is totally informal testing which have intension to break the application as early as possible and found important defect early.  In Ad-hoc testing tester do not have any test cases so only the users who have very high knowledge regarding the application only they can perform Ad-Hoc Testing.

Smoke Testing

In Smoke Testing, Testing team check the key feature or key bugs of the software. Smoke testing ensure that critical functionality of the software is working fine.If key features are not working then it is no needed to test the overall functionality because it is just waste of time. In Smoke Testing, test team check the basic feature of the software and if basic feature is not working it means software is broken very badly and further testing is unnecessary. If Smoke Testing failed then it is declared that build is unstable and revert back to developer team until smoke test is pass.