In the software programming and development world, the best software developers always write their unit test cases first keeping in mind the functional requirements before starting their coding phase which improves their coding quality and efficiency.
Relatively, software testers should write test cases during the earlier stage of the software development life cycle and it is best to write test cases during the software requirements phase. The QA manager or test manager should gather and prepare the maximum possible documents as per the list given below:
What all do we need to get started for Test Case Writing?
Detailed requirements specified by the Customer: A document which lists the user profiles, user environment, business process and interaction with other systems, functional requirements, non-functional requirements, replacement of existing systems, installation and licensing requirements, security requirements, usability, concurrent and performance requirements etc.
Keep a track of all used cases: A document that gives the details of the used case scenarios of the functional requirements from the business viewpoint. This document covers the business goals, system, post-conditions, pre-conditions, alternate flow, options, basic flow and exceptions of each and every business flow of the system under requirements.
Requirements based on functionality in detail: A document that gives the details about the functional requirements of every feature for the system under requirements. Usually, functional requirements document works as a common repository for both the testing and development team as well as the project stakeholders including the customers for the dedicated necessities which should be treated as the most vital document for any software development.
Project Plan of Application to be created: A document that defines the details of the objectives, milestones, activities, organization structure, strategy, progress monitoring, risk analysis, assumptions, project, constraints, training requirements, client responsibilities, project schedule etc.
Brief documentation of the project milestones: A document that details the quality documentation standards, change control mechanism, critical modules, functionalities, configuration management system, testing plans, management system, defect tracking, acceptance criteria, management system. The test plan document is used to recognize the features not to be tested, features to be tested, testing team interface and their distributions, testing schedule, resource requirements, test coverage, test deliverables, test case writing, bug reporting and tracking mechanism, pre-requisite for test execution, test metrics etc.
Let us delve deeper into test case creation:
Let’s see how to create test cases proficiently for a simple “Login” screen. The testing methodology will be nearly the same even for multifaceted screens with critical features and more information.
1) The very first method for any test case process will be to get a screen sample. This may not be available for some of the functionalities and depends on the complexity of a design sample in the earlier stages of development. But, if an SRS (Software Requirements Specifications) document is accessible for the project, most of the screen samples are developed by the project team. These kinds of screens make the tester’s job simpler and increase the efficiency of test cases.
2) Next are the functional requirements specifications (FRS). Depends on the organization process, it will be accessible in a set of multiple documents. So, choose the best document for writing test cases, either it may be functional requirements specifications, user requirement document or even an SRS document if it can be understood easily by the testing team which will give the complete functional flow of the particular feature to be tested.
3) The tester should start writing test cases with the following criteria and approaches, once the functional specifications and screen prototypes are in place.
a) Hyperlinks, Login button, Forgot Password, and Registration is dynamic fields that need user interaction by clicking on the controls which will do some action afterwards.
b) There are dynamic controls and static controls available for the feature to be tested. For example, in the login screen, the ‘Password’ & ‘User Name’ texts are static fields that need no user interaction and are just for displaying the text.
c) This is related to the process linked with the functionality and the feature.
d) Once the user enters the password and user name, the test cases may be written to check the connected database for whether the password & user name is checked into the right table and database and also if the user has the authorization to log in to the application under test.
