In a software development and programming world, the best software developers always written their unit test cases from the functional requirements, before starting their coding phase, which dramatically improve their coding efficiency and quality.
Similarly, software testers should write their test cases from the earlier stage of the software development life cycle, best during the software requirements phase. The test manager or a QA manager should collect and prepare the maximum possible documents as per the list below.
What You Will Learn:
Document Collection for Test Case Writing
#1) User Requirements Document
A document which list the business process, user profiles, user environment, interaction with other systems, replacement of existing systems, functional requirements, non functional requirements, licensing and installation requirements, performance requirements, security requirements, usability and concurrent requirements etc.,
#2) Business Use Case Document
A document which details the use case scenario of the functional requirements from the business perspective. This document covers the business actors (or system), goals, pre-conditions, post-conditions, basic flow, alternate flow, options, exceptions of each and every business flow of the system under requirements.
#3) Functional Requirements Document
A document which details the functional requirements of each feature for the system under requirements. Normally, functional requirements document serves as a common repository for both development and testing team as well as to the project stakeholders including the customers for the committed (sometimes frozen) requirements, which should be treated as a most important document for any software development.
#4) Software Project Plan (Optional)
A document which describes the details of the project, objectives, priorities, milestones, activities, organization structure, strategy, progress monitoring, risk analysis, assumptions, dependencies, constraints, training requirements, client responsibilities, project schedule etc.,
#5) QA / Test Plan
A document which details the quality management system, documentation standards, change control mechanism, critical modules and functionalities, configuration management system, testing plans, defect tracking, acceptance criteria, The test plan document is used to identify the features to be tested, features not to be tested, testing team allocations and their interface, resource requirements, testing schedule, test case writing, test coverage, test deliverables, pre-requisite for test execution, bug reporting and tracking mechanism, test metrics etc.,
Writing Sample Test Cases
Let us see how to efficiently write test cases for a familiar and simple ‘Login’ screen as per the figure below. The approach of testing will be almost the same even for a complex screens with more information and critical features.
1) The first approach for any test case process will be to get a screen prototype (or wire-frames) as above, if available. This may not be available for some of the functionalities and depends on the criticality of design a prototype in the earlier stages of development. But, if a SRS (Software Requirements Specification) document is available for the project, most of the screen prototypes are developed by the project team. This kind of screens simplifies the tester’s job and increases the efficiency of test cases.
2) Next the functional requirements specifications. Depends on the organization process, it will be available in a suite of multiple documents. So, decide the best document for writing test cases, either it may be a user requirement document or a functional requirements specifications (or even a SRS document if it can be understandable comfortably by the testing team) which will give the complete functional flow of the selected feature to be tested.
3) Once the screen prototype and functional specifications are in place, the tester should start writing test cases with the following approach and criteria.
- UI test cases: The controls/fields which are visible to the user. There are static control and dynamic controls available for the feature to be tested. For example, in the login screen above, the ‘User Name & Password’ texts are static fields which require no user interaction, just for displaying the text only.
- Functional test cases: On the other hand, Login button and the Hyperlinks (Forgot Password? & Registration) are dynamic fields which requires user interaction by clicking on the controls, which will do some action afterwards.
- Database test cases: Once the user enter the user name and password, the test cases may be written to check the related database for, whether the user name & password is checked in right database and table and also the user has the permission to login to the application under test.
- Process test cases: This is related to the process (not the actions associated with the visible controls available in the screen) associated with the feature and the functionality. For example, clicking Forgot Password link in the above sample screen may send an Email to the user. So, may be an Email needs to be tested for the proper process and confirmation.
4) Finally, keep the “BAOE mantra”, means i) Basic Flow ii) Alternate Flow iii) Options and iv) Exceptions for the complete coverage of the functional flow and feature to be tested. Every concept should be applied with positive and negative test cases.
For example, let us see the simple BAOE approach for the sample login screen above.
- Basic Flow: Enter the URL path of the Login in any browser and enter the information required and login to the application.
- Alternate Flow: Install the application in a mobile device and enter the information required and login to the application.
- Options: What are the options available to come to the same login screen? For example, after login to the application, clicking ‘Logout’ may bring the same screen or if the session timeout or session expired, the user may come to the login screen.
- Exceptions: What are exceptions if my test cases are negative? For example, if wrong credentials are entered in the Login screen, whether the user will get an error message or no action associated.
With all these information in hand, let us start writing the test cases for the login screen, in a format with the complete coverage and traceability and with detailed information. The logical sequence and numbering of identifying the ‘Test Case ID’ will be very useful for a quick identification of the test cases and test case execution history.
Test Case Document
Note: The test cases columns are not limited to the below sample test case document, which can be maintained in an excel sheet to have as many columns as required for a complete traceability matrix viz., priority, purpose of testing, type of testing, error screenshot location etc.,
See also => Sample test case template with examples.
For the ease of simplicity and readability of this document, let us write the steps to reproduce, expected and actual behavior of the test cases for the login screen in detail below.
Note: Add Actual Behavior column at the end in this template.
|No.||Steps to Reproduce||Expected Behaviour|
|1.||Open a browser and enter the URL for the Login screen.||The Login screen should be displayed.|
|2.||Install the app in Android phone and open it.||The Login screen should be displayed.|
|3.||Open the Login screen and check the texts available are correctly spelled.||‘User Name’ & ‘Password’ text should be displayed before the related text box. Login button should have the caption ‘Login’. ‘Forgot Password?’ And ‘Registration’ should be available as Links.|
|4.||Enter the text in the User Name box.||Text can be entered by mouse click or focus using tab.|
|5.||Enter the text in the Password box.||Text can be entered by mouse click or focus using tab.|
|6.||Click the Forgot Password? Link.||Clicking the link should take the user to the related screen.|
|7.||Click the Registration Link||Clicking the link should take the user to the related screen.|
|8.||Enter the user name and password and click the Login button.||Clicking the Login button should take to the related screen or application.|
|9.||Go to the database and check the correct table name is validated against the input credentials.||The table name should be validated and a status flag should be updated for successful or failure login.|
|10.||Click the Login without entering any text in the User Name and Password boxes.||Click the Login button should alert a message box ‘User Name and Password are Mandatory’.|
|11.||Click the Login without entering text in the User Name box, but entering text in Password box.||Click the Login button should alert a message box ‘Password is Mandatory’.|
|12.||Click the Login without entering text in the Password box, but entering text in User Name box.||Click the Login button should alert a message box ‘User Name is Mandatory’.|
|13.||Enter the maximum allowed text in the User Name & Password boxes.||Should accept the maximum allowed 30 characters.|
|14.||Enter the User Name & Password starting with the special characters.||Should not accept the text starting with special characters, which is not allowed in Registration.|
|15.||Enter the User Name & Password starting with blank spaces.||Should not accept the text stating with blank spaces, which is not allowed in Registration.|
|16.||Enter the text in the password field.||Should not display the actual text instead should display asterisk * symbol.|
|17.||Refresh the Login page.||Page should be refreshed with both User Name and Password fields blank.|
|18.||Enter the User Name.||Depends on the browser auto fill settings, previously entered user names should be displayed as a dropdown.|
|19.||Enter the Password.||Depends on the browser auto fill settings, previously entered Passwords should NOT be displayed as a dropdown.|
|20.||Move the focus to Forgot Password link using Tab.||Both mouse click and enter key should be usable.|
|21.||Move the focus to Registration link using Tab.||Both mouse click and enter key should be usable.|
|22.||Refresh the Login page and press Enter key.||The Login button should be focussed and the related action should be fired.|
|23.||Refresh the Login page and press Tab key.||The first focus in the Login screen should be the User Name box.|
|24.||Enter the User and Password and leave the Login page idle for 10 minutes.||Message box alert ‘Session Expired, Enter User Name & Password Again’ should be displayed with both User Name & Password fields cleared.|
|25.||Enter the Login URL in Chrome, Firefox & Internet Explorer browsers.||Same Login screen should be displayed without much deviation on the look and feel and alignment of text and form controls.|
|26.||Enter the Login credentials and check Login activity in Chrome, Firefox & Internet Explorer browsers.||The action of Login button should be one and the same in all the browsers.|
|27.||Check the Forgot Password and Registration link is not broken in Chrome, Firefox & Internet Explorer browsers.||Both the links should take to the relative screens in all the browsers.|
|28.||Check the Login functionality is working properly in Android mobile Phones.||The Login feature should work the same way as it is available in the web version.|
|29.||Check the Login functionality is working properly in Tab and iPhones.||The Login feature should work the same way as it is available in the web version.|
|30.||Check the Login screen allows the concurrent users of the system and all the users are getting the Login screen without delays and within the defined time of 5-10 seconds.||This should be achieved using many combination of operating system and browsers either physically or virtually or can be achieved using some performance / load testing tool.|
Test Data Collection
When the test case is being written, the most important task for any tester is to collect the test data. This activity is skipped and overlooked by many testers with an assumption that the test cases can be executed with some sample data or dummy data and can be feed when the data is really required. This is a critical misconception that feeding sample data or input data from the mind memory at the time of executing test cases.
If the data is not collected and updated in the test case document at the time of writing the test cases, the tester would spend abnormally more time to collect data at the time of test execution. The test data should be collected for both positive and negative test cases from all the perspective of functional flow of the feature. The business use case document is very much useful in this situation. If the actors or system interacting with the software is well defined in the business case document, then it is easy for a tester to write the test cases and the related test data, thinking from each and every perspective of the actors available in the business use case document.
Find below a sample test data document for the test cases written above, which will be helpful on how effectively we can collect the data which will ease our job at the time test execution.
|Sl.No.||Purpose of Test Data||Actual Test Data|
|1.||Test the proper user name and password||Administrator (admin2015)|
|2.||Test the maximum length of user name and password||Administrator of the Main System (admin2015admin2015admin2015admin)|
|3.||Test the blank spaces for the user name and password||Enter blank spaces using space key for user name and password|
|4.||Test the improper user name and password||Admin (Activated) (digx##$taxk209)|
|5.||Test the user name and password with uncontrolled spaces between.||Admin istrator (admin 2015)|
|6.||Test the user name and password starting with special characters||$%#@#$Administrator (%#*#**#admin)|
|7.||Test the user name and password with all small characters||administrator (admin2015)|
|8.||Test the user name and password with all capital characters||ADMINISTRATOR (ADMIN2015)|
|9.||Test the Login with the same user name and password with multiple systems concurrently at the same time.||Administrator (admin2015) - for Chrome in the same machine and different machine with operating system Windows XP, Windows 7, Windows 8 and Windows Server.
Administrator (admin2015) - for Firefox in the same machine and different machine with operating system Windows XP, Windows 7, Windows 8 and Windows Server.
Administrator (admin2015) - for Internet Explorer in the same machine and different machine with operating system Windows XP, Windows 7, Windows 8 and Windows Server.
|10.||Test the Login with the user name and password in the mobile application.||Administrator (admin2015) – for Safari and Opera in Android Mobiles, iPhones and Tablets.|
Improving Test Case Efficiency is not a simple defined term, but it’s an exercise and can be achieved through a matured process and regular practice. The testing team should not be tired of getting involved in improvement of such tasks as it is the best tool for greater achievements in quality world, which is proven in many of the testing organizations worldwide on mission critical projects and complex applications.
Do you have any suggestions/methods for improving test case efficiency? Let us know.