In this in-depth hands-on tutorial on How to Write Test Cases, I have covered the details of what is a Test Case, Its standard definition and Test Case Design techniques.
What is a Test case?
A test case has components that describe input, action and an expected response, in order to determine if a feature of an application is working correctly.
A test case is a set of instructions on “HOW” to validate a particular test objective/target, which when followed will tell us if the expected behavior of the system is satisfied or not.
List of Tutorials Covered in this Test Case Writing Series:
How to Write:
Tutorial #1: What is a Test Case and How to Write Test Cases (this tutorial)
Tutorial #2: Sample Test Case Template with Examples [Download] (must read)
Tutorial #3: Writing Test Cases from SRS Document
Tutorial #4: How to Write Test Cases for a Given Scenario
Tutorial #5: How to Prepare Yourself for Test Case Writing
Tutorial #6: How to Write Negative Test Cases
Tutorial #7: 180+ Sample Test Cases for Web and Desktop Applications
Tutorial #8: 100+ Ready-to-Execute Test Scenarios (Checklist)
Tutorial #9: Cause and Effect Graph – Dynamic Test Case Writing Technique
Tutorial #10: State Transition Testing Technique
Tutorial #11: Orthogonal Array Testing Technique
Tutorial #12: Error Guessing Technique
Tutorial #13: Field Validation Table (FVT) Test Design Technique
Test Case Vs Test Scenarios:
Tutorial #14: Test Cases Vs Test Scenarios
Tutorial #15: Difference Between Test Plan, Test Strategy and Test Case
Tutorial #16: How to Select Correct Test Cases for Automation Testing
Tutorial #17: How to Translate Manual Test Cases into Automation Scripts
Test Management Tools:
Tutorial #18: Best Test Management Tools
Tutorial #19: TestLink for Test case Management
Tutorial #20: Creating and Managing Test Cases Using HP Quality Center
Tutorial #21: Executing Test Cases Using ALM/QC
Domain Specific Cases:
Tutorial #22: Test Cases for ERP Application
Tutorial #23: JAVA Application test cases
Tutorial #24: Boundary value analysis and Equivalence partitioning
Let's continue with the first tutorial in this series.
Before continuing to the test case writing process, we recommend downloading this test case management tool. This will ease your test cases writing process mentioned in this tutorial.
What You Will Learn:
- What is a Test Case and How to Write Test Cases?
- Tips for Writing Tests
- How to Achieve Excellence in Test Case Documentation
- Useful Tips and Tricks
- #1) Is your Test Document in Good Shape?
- #2) Do not Forget to Cover the Negative Cases
- #3) Have Atomic Test Steps
- #4) Prioritize the Tests
- #5) Sequence Matters
- #6) Add Timestamp and the Tester Name to the Comments
- #7) Include Browser Details
- #8) Keep two separate sheets – ‘Bugs’ & ‘Summary’ in the Document
- Useful Tips and Tricks
- How NOT to Write Tests
- How to Improve Test Case Efficiency
- Importance of Standardizing the Test Cases
What is a Test Case and How to Write Test Cases?
Writing effective cases is a skill. And you can learn it from experience and knowledge of the application under test.
For basic instructions on how to write tests, please check the following video:
The above resources should give us the basics of the test writing process.
Levels of the test writing process:
- Level 1: In this level, you will write the basic cases from the available specification and user documentation.
- Level 2: This is the practical stage in which writing cases depend on the actual functional and system flow of the application.
- Level 3: This is the stage in which you will group some cases and write a test procedure. The test procedure is nothing but a group of small cases, maybe a maximum of 10.
- Level 4: Automation of the project. This will minimize human interaction with the system and thus the QA can focus on the currently updated functionalities to test rather than remaining busy with Regression testing.
Why do we Write Tests?
The basic objective of writing cases is to validate the test coverage of an application.
If you are working in any CMMi organization, then the test standards are followed more closely. Writing cases brings some sort of standardization and minimizes the ad-hoc approach in testing.
How to Write Test Cases?
- Test case id
- Unit to test: What to be verified?
- Test data: Variables and their values
- Steps to be executed
- Expected Result
- Actual result
Basic Format of Test Case Statement
Using [tool name, tag name, dialog, etc]
To [what is returned, shown, demonstrated]
Verify: Used as the first word of the test statement.
Using: To identify what is being tested. You can use ‘entering’ or ‘selecting’ here instead of using depending on the situation.
For any application, you need to cover all types of tests as:
- Functional cases
- Negative cases
- Boundary value cases
While writing these all your TC's should be simple and easy to understand.
Tips for Writing Tests
One of the most frequent and major activities of a Software Tester (SQA/SQC person) is to write Test scenarios and cases.
There are some important and critical factors that are related to this major activity. Let us have a bird’s eye view of those factors first.
Important Factors Involved Writing Process:
a) TCs are prone to regular revision and update:
We live in a continuously changing world and the same holds good for software as well. Software requirements change directly impact the cases. Whenever requirements are altered, TCs need to be updated.
Yet, it is not only the change in the requirement that may cause revision and update of TCs. During the execution of TCs, many ideas arise in the mind and many sub-conditions of a single TC may be identified. All this causes an update of TCs and sometimes it even leads to the addition of new TCs.
Moreover, during regression testing, several fixes and/or ripples demand revised or new TCs.
b) TCs are prone to distribution among the testers who will execute these:
Of course, there is hardly such a situation in which a single tester executes all the TCs. Normally, there are several testers who test different modules of a single application. So the TCs are divided among the testers according to their owned areas of the application under test.
Some TCs which are related to the integration of application may be executed by multiple testers while the other TCs may be executed only by a single tester.
c) TCs are prone to Clustering and Batching:
It is normal and common that TCs belonging to a single test scenario usually demand their execution in some specific sequence or in the form of a group. There may be certain pre-requisites of a TC which demand the execution of other TCs before running itself.
Similarly, as per the business logic of the AUT, a single TC may contribute to several test conditions and a single test condition may consist of multiple TCs.
d) TCs have a tendency of inter-dependence:
This is also an interesting and important behavior of the TCs denoting that they can be interdependent on each other. From medium to large applications with complex business logic, this tendency is more visible.
The clearest area of any application where this behavior can definitely be observed is the interoperability between different modules of the same or even different applications. Simply speaking, wherever the different modules a single application or multiple applications are interdependent, the same behavior is reflected in the TCs as well.
e) TCs are prone to distribution among the developers (especially in Test-driven development environment):
An important fact about TCs is that these are not only to be utilized by the testers. In the normal case, when a bug is under fix by the developers, they are indirectly using the TC to fix the issue. Similarly, if the test-driven development is followed, then TCs are directly used by the developers in order to build their logic and cover all the scenarios in their code which are addressed by TCs.
Tips to Write Effective Tests:
Keeping the above 5 factors in mind, Here are a few tips to write effective TCs.
#1) Keep it simple but not too simple; make it complex but not too complex:
This statement seems a paradox. But, I promise that it is not so. Keep all the steps of TCs atomic and precise. Mention the steps with the correct sequence and correct mapping to the expected results. The test case should be self-explanatory and easy to understand. This is what I mean to make it simple.
Now, making it a complex means to make it integrated with the Test Plan and other TCs. Refer to the other TCs, relevant artifacts, GUIs etc. where and when required. But, do this in a balanced way. Do not make a tester to move to and fro in the pile of documents for completing a single test scenario.
On the other hand, do not even let the tester to document these TCs in a very compact manner. While writing TCs, always remember that you or someone else will have to revise and update these.
#2) After documenting the Test cases, review once as Tester:
Never think that the job is done once you have written the last TC of the test scenario. Go to the start and review all the TCs once, but not with the mindset of a TC writer or Testing Planner. Review all TCs with the mind of a tester. Think rationally and try to dry run your TCs.
Evaluate that all the Steps and see if you have mentioned these clearly in an understandable way and the expected results are in harmony with those steps.
Ensure that the test data specified in TCs is feasible not only for actual testers but is according to the real-time environment too. Ensure that there is no dependency conflict among TCs and verify that all the references to other TCs/artifacts/GUIs are accurate. Otherwise, the Testers may be in great trouble.
#3) Bound as well as ease the Testers:
Do not leave the test data on testers. Give them a range of inputs especially where calculations are to be performed or application's behavior is dependent on inputs. You can let them decide the test data item values but never give them the liberty to choose the test data items themselves.
Because, intentionally or unintentionally, they may use the same test data again & again and some important test data may be ignored during the execution of TCs.
Keep the testers at ease by organizing the TCs per the testing categories and the related areas of an application. Clearly, instruct and mention which TCs are inter-dependent and/or batched. Likewise, explicitly indicate which TCs are independent and isolated so that the tester may manage his overall activity accordingly.
At this point, you might be interested to read about boundary value analysis which is a test case design strategy that is used in black box testing. Click here to know more about it.
#4) Be a Contributor:
Never accept the FS or Design Document as it is. Your job is not just to go through the FS and identify the Test Scenarios. Being a QA resource, never hesitate to contribute to business and give suggestions if you feel that something can be improved in the application.
Suggest to developers too, especially in TC-driven development environment. Suggest the drop-down lists, calendar controls, selection-list, group radio buttons, more meaningful messages, cautions, prompts, improvements related to usability, etc.
Being a QA, don’t just test but make a difference!
#5) Never Forget the End User:
The most important stakeholder is the ‘End User' who will finally use the application. So, never forget him at any stage of TCs writing. In fact, the End User should not be ignored at any stage throughout the SDLC. Yet, my emphasis so far is just related to my topic.
So, during the identification of test scenarios, never overlook those cases which will be mostly used by the user or the cases which are business critical even if they are less frequently used. Keep yourself in the shoes of End User and then go through all the TCs and judge the practical value of executing all your documented TCs.
How to Achieve Excellence in Test Case Documentation
Being a software tester, you will surely agree with me that coming up with a perfect Test Document is really a challenging task.
We always leave some scope for improvement in our Test Case Documentation. Sometimes, we are unable to provide 100% test coverage through the TCs and at times, the test template is not up to par, or we lack in providing good readability and clarity to our tests.
As a tester, whenever you are asked to write test documentation, do not just start away in an ad-hoc manner. It is very important to understand the purpose of writing test cases well before you work on the documentation process.
The tests should always be clear and lucid. They should be written in a way that offers the tester ease to conduct the complete testing by following the steps defined in each of the tests.
In addition, the test case document should contain as many cases as required to provide complete test coverage. For Example, you should try to cover the testing for all the possible scenarios that can occur within your software application.
Keeping the above points in mind, let me now take you through a tour about How to Achieve Excellence in Test Documentation.
Useful Tips and Tricks
Here, I am going to provide you some useful guidelines that can give you a leg up in your test documentation from the others.
#1) Is your Test Document in Good Shape?
The best and simple way to organize your test document is by splitting it into many single useful sections. Divide the entire testing into multiple test scenarios. Then divide each scenario into multiple tests. Finally, divide each case into multiple test steps.
If you are using excel, then document each test case on a separate sheet of the workbook wherein each test case describes one complete test flow.
#2) Do not Forget to Cover the Negative Cases
As a software tester, you need to think outside the box and draw up all the possibilities that your application comes across. We, as testers, have to verify that if any unauthentic attempt to enter into the software or any invalid data to flow across the application should be stopped and reported.
Thus, a negative case is as important as a positive case. Make sure that for each scenario you have two test cases- one positive and one negative. The positive one should cover the intended or normal flow and the negative one should cover the unintended or exceptional flow.
#3) Have Atomic Test Steps
Each test step should be an atomic one. There should not be any further sub-steps. The more simple and clear-headed a test step is, the easier it would be to proceed with the testing.
#4) Prioritize the Tests
We often have stringent timelines to finish up testing for an application. In this case, we may miss testing some of the important functionalities and aspects of the software. In order to avoid this, you should tag a priority with each test while documenting it.
You can use any encoding for defining the priority of a test. It is generally better to use any of the 3 levels, high, medium and low, or 1, 50 and 100. So, when you have a strict timeline, you should complete all the high priority tests first and then move to the medium and low priority tests.
For Example – for a shopping website, verifying access denial for an invalid attempt to log into the app can be a high priority case, verifying the display of relevant products on the user screen can be a medium priority case and verifying the color of the text displayed on the screen buttons can be a low priority test.
#5) Sequence Matters
Confirm whether the sequence of steps in the test is absolutely correct. A wrong sequence of steps can lead to confusion. Preferably, the steps should also define the entire sequence from entering the app until exiting the app for a particular scenario that is being tested.
#6) Add Timestamp and the Tester Name to the Comments
There may be a case where you are testing an application, someone is making modifications in parallel to the same app or someone may update the app after your testing is done. This leads to a situation where your test results can vary with time.
So, it is always better to add a timestamp with the tester's name in the testing comments so that a test result (pass or fail) can be attributed to the state of an application at that particular time. Alternatively, you can have an ‘Executed Date’ column added separately to the test case which will explicitly identify the timestamp of the test.
#7) Include Browser Details
As you know, if it’s a web application, test results can differ based on the browser on which the test is executed. For the ease of other testers, developers or whoever is reviewing the test document, you should add the browser name and version to the case so the defect can be replicated easily.
#8) Keep two separate sheets – ‘Bugs’ & ‘Summary’ in the Document
If you are documenting in an excel, then the first two sheets of the workbook should be Summary and Bugs. The Summary sheet should summarize the test scenario and the Bugs sheet should list all the issues encountered during testing. The significance of adding these two sheets is that it will give a clear understanding of the testing to the reader/user of the document.
So, when the time is restricted, these two sheets can prove to be very useful in providing an overview of the testing.
The test document should provide the best possible test coverage, excellent readability and should follow one standard format throughout.
We can achieve excellence in test documentation by just keeping few essential tips in mind as the organization of test case document, prioritizing the TCs, having everything in proper sequence, including all mandatory details to execute a TC, and providing clear & lucid test steps, etc. as discussed above.
How NOT to Write Tests
We spend most of our time writing, reviewing, executing or maintaining these. It is quite unfortunate that tests are also the most error-prone ones. The differences in understanding, organization testing practices, lack of time etc. are some of the reasons why we often see tests that leave a lot to be desired.
There are a lot of articles on our site on this topic, but here will see How NOT to write test cases – a few tips that will be instrumental in creating distinctive, quality and effective tests.
Let’s read on and please note that these tips are for both new and experienced testers.
3 Most Common Problems in Test Cases
- Composite steps
- Application behavior is taken as expected behavior
- Multiple conditions in one case
These three have to be on my top 3 list of common problems in the test writing process.
What’s interesting is that these happen with both new and experienced testers and we just keep following the same flawed processes never realizing that a few simple measures can fix things easily.
Let’s get to it and discuss each one in detail:
#1) Composite Steps
First of all, what is a composite step?
For instance, you are giving directions from Point A to point B: if you say that “Go to XYZ place and then to ABC” this is not going to make a lot of sense, because here we find ourselves thinking – “How do I get to XYZ in the first place”- instead starting with “Turn left from here and go 1 mile, then turn right on Rd. no 11 to arrive at XYZ” might achieve better results.
The exact same rules apply to tests and its steps as well.
For Example I am writing a test for Amazon.com – place an order for any product.
The following are my test steps (Note: I am only writing the steps and not all the other parts of the test like the expected result etc.)
a. Launch Amazon.com
b. Search for a product by entering the product keyword/name into the “Search” field on the top of the screen.
c. From the search results displayed, choose the first one.
d. Click on Add to Cart on the product details page.
e. Checkout and pay.
f. Check the order confirmation page.
Now, can you identify which of these is a composite step? Right- Step (e)
Remember, tests are always about “How” to test so it is important to write the exact steps of “How to check out and pay” in your test.
Therefore, the above case is more effective when written as below:
a. Launch Amazon.com
b. Search for a product by entering the product keyword/name into the “Search” field on the top of the screen.
c. From the search results displayed, choose the first one.
d. Click on Add to Cart on the product details page.
e. Click on Checkout in the shopping cart page.
f. Enter the CC information, shipping, and billing information.
g. Click Checkout.
h. Check the order confirmation page.
Therefore, a composite step is the one that can be broken down into several individual steps. Next time when we write tests, let’s all pay attention to this part and I am sure you will agree with me that we do this more often than we realize.
#2) Application behavior is taken as expected behavior
More and more projects have to deal with this situation these days.
Lack of documentation, Extreme programming, rapid development cycles are few reasons that force us into relying on the application (an older version or so) to either write the tests or to base the testing itself on. As always, this is a proven bad practice- not always really.
It is harmless as long as you keep an open mind and keep the expectation that the –“AUT could be flawed”. It is only when you do not think that it is, things work badly. As always, we will let the examples do the talking.
If the following is the page you are writing/designing the test steps for:
If my test case steps are as below:
- Launch the shopping site.
- Click on Shipping and return- Expected result: The shipping and returns page is displayed with “Put your info here” and a “Continue” button.
Then, this is incorrect.
- Launch the shopping site.
- Click on Shipping and return.
- In the ‘Enter the order no’ text box present in this screen, enter the order no.
- Click Continue- Expected result: The details of the order related to shipping and returns are displayed.
Case 2 is a better test case because even though the reference application behaves incorrectly, we only take it as a guideline, do further research and write the expected behavior as per the anticipated correct functionality.
Bottom line: Application as a reference is a quick shortcut but it comes with its own perils. As long as we are careful and critical, it produces amazing results.
#3) Multiple Conditions in one case
Once again, let’s learn from Example.
Take a look at the below test steps: The following are the test steps within one test for a login function.
a. Enter valid details and click Submit.
b. Leave Username field empty. Click Submit.
c. Leave the password field empty and click Submit.
d. Choose an already logged in username/password and click Submit.
What had to be 4 different cases is combined into one. You might be thinking- What’s wrong with that? It is saving a lot of documentation and what I can do in 4, I am doing it in 1- isn’t that great? Well, not quite. Reasons?
- What if one of the conditions fails – we have to mark the entire test as ‘failed’. If we mark the entire case ‘failed’, it means all 4 conditions are not working, which isn’t really true.
- Tests need to have a flow. From precondition to step 1 and all through the steps. If I follow this case, in step (a), if it is successful, I will be logged onto the page, where the “login” option is no longer available. So when I get to step (b) – where is the tester going to enter the username? You see, the flow is broken.
Hence, write modular tests. It sounds like a lot of work but all it takes for you is to separate things and use our best friends Ctrl+C and Ctrl+V to work for us. :)
How to Improve Test Case Efficiency
The software testers should write their tests 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 below list.
Document Collection for Test Writing
#1) User Requirements Document
It is a document that lists 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
This document 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
This document details the functional requirements of each feature for the system under requirements.
Normally, functional requirements document serves as a common repository for both the 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 the 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
This document details the quality management system, documentation standards, change control mechanism, critical modules, and functionalities, configuration management system, testing plans, defect tracking, acceptance criteria etc.
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 writing, test coverage, test deliverables, pre-requisite for test execution, bug reporting and tracking mechanism, test metrics etc.,
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 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 designing a prototype in the earlier stages of development.
But, if an SRS (Software Requirements Specification) document is available for the project, most of the screen prototypes are developed by the project team. This kind of screen simplifies the tester's job and increases the efficiency of tests.
#2) Next, the functional requirements specifications. It depends on the organization process, it will be available in a suite of multiple documents.
So, decide the best document for writing cases, either it may be a user requirement document or a functional requirements specifications (or even an SRS document if it can be understandable comfortably by the testing team) which will give a 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 the cases with the following approach and criteria.
- UI Tests: 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 Cases: On the other hand, Login button and the Hyperlinks (Forgot Password? & Registration) are dynamic fields which require user interaction by clicking on the controls, which will do some action afterward.
- Database Cases: Once the user enters the username and password, the tests may be written to check the related database for, whether the username & password is checked in the right database and table and also the user has the permission to login to the application under test.
- Process Tests: This is related to the process (not the actions associated with the visible controls available on 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, maybe 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 to positive and negative tests.
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 on 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 tests 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 this information in hand, let us start writing the TCs 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 execution history of test cases.
Test Case Document
Note: The test columns are not limited to the below sample test 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.,
Also read => 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 tests for the login screen in detail below.
Note: Add Actual Behavior column at the end of 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 the 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 document at the time of writing the tests, the tester would spend abnormally more time to collect the data at the time of test execution. The test data should be collected for both positive and negative cases from all the perspective of the functional flow of the feature. The business use case document is very much useful in this situation.
Find a sample test data document for the tests written above, which in turn will be helpful on how effectively we can collect the data which will ease our job at the time of 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.|
Importance of Standardizing the Test Cases
In this busy world, no one can do repetitive things day in and day out with the same level of interest and energy. Especially, I am not passionate about doing the same task again and again at work. I like managing things and saving time. Anyone in IT should be so.
All IT companies execute different types of projects. These projects can either be product based or service based. Out of these projects, most of them work around websites and website testing. The good news about it is, all websites have many similarities. And, if the websites are for the same domain, they have several common features too.
The question that always baffles me is that: “If most applications are similar, for example: such as retail sites, which have been tested a thousand times before, “Why do we need to write test cases for yet another retail site from scratch?” Won’t it save a ton of time by pulling out the existing test scripts that were used to test a previous retail site?
Sure, there might be some small tweaks that we might have to do, but overall it is easier, efficient, time & money-saving too and thereby always helps to keep the interest levels of the testers high. Who likes to write, review and maintain the same test cases repeatedly, right? Reusing the existing tests can solve this to a great extent and your clients will find this smart and logical too.
So logically, I started pulling the existing scripts from similar web-based projects, made changes and did a quick review of them. I also used color coding to show the changes that were made, so that the reviewer can only focus on the part that has been changed.
Reasons to Reuse Test Cases
#1) Most functional areas of a website are almost- login, registration, add to cart, wish list, checkout, shipping options, payment options, product page content, recently viewed, relevant products, promo code facilities etc.
#2) Most of the projects are just enhancements or changes to the existing functionality.
#3) Content management systems that define the slots for image uploads with static and dynamic ways is also common for all websites.
#4) Retail websites have CSR (Customer Service) system too.
#5) Backend system and warehouse application using JDA are also used by all websites.
#6) The concept of cookies, timeout and security are common too.
#7) Web-based projects are frequently prone to requirement changes.
You see, there is plenty that is common and similar.
Having said that reusability is the way to go, sometimes the modifications themselves may or may not take more or less time. Sometimes one may feel it is better to start from scratch than to modify so much.
This can be easily handled by creating a set of standard test cases for each of the common functionality.
What is a Standard Test in Web Testing?
- Create test cases that are complete – steps, data, variable, etc. This will ensure that the non-similar data/variable can simply be replaced when a similar test case is required.
- The entrance and exit criteria should be properly defined.
- The modifiable steps or the statement in the steps should be highlighted in a different color for quick find and replace.
- The language used for the standard test case creation should be generic.
- All the features of each website should be covered in the test cases.
- The name of the test cases should be the name of the functionality or the feature that the test case is covering. This will make the finding of the test case from the set much easier.
- If there is any basic or standard sample or GUI file or screenshot of the feature, then it should be attached with the relevant steps.
By using the above tips one can create a set of standard scripts and use them with little or required modifications for different websites.
These standard test cases can be automated too, but once again focusing on reusability is always a plus. Also, if automation is based on a GUI, reusing the scripts across multiple URLs or sites is something I personally never found effective.
Using a standard set of manual test cases for different websites with minor modifications is the best way to carry a website testing. All we need is to create and maintain the test cases with proper standards and use.
Improving Test Case Efficiency is not a simply 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 the improvement of such tasks as it is the best tool for greater achievements in the quality world, this is proven in many of the testing organizations worldwide on mission-critical projects and complex applications.
Hope you would have gained immense knowledge on the concept of Test Cases. Watch out our series of tutorials to know more about test cases and feel free to express your thoughts in the comments section below!