In this in-depth hands-on tutorial, I have covered the details of what is a Test Case in Software testing, Test Case Definition, Test Case Design, and the step-by-step guide on How to Write Test Cases.
What is a Test case?
A test case has components that describe an input, action/event and an expected response,in order to determine if a feature of an application is working correctly.
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:
Writing Test cases:
Tutorial #1: What is 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
Test Case Examples:
Tutorial #7: 180+ Sample Test Cases for Web and Desktop Applications
Tutorial #8: 100+ Ready-to-Execute Test Scenarios (Checklist)
Test Case Writing Techniques:
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, Test Case
Test Case Automation:
Using 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 Test 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.
What You Will Learn:
Writing effective test 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 test cases, please check the following video having tips and tricks on HOW TO write effective test cases:
The above resources should give us the basics of the test case writing process.
There are certain levels of Test case writing process as stated below:
Level 1: In this level, you will write the basic test cases from the available specification and user documentation.
Level 2: This is the practical stage in which writing test cases depend on the actual functional and system flow of the application.
Level 3: This is the stage in which you will group some test cases and write a test procedure. The test procedure is nothing but a group of small test cases, may be 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.
The basic objective of writing test cases is to validate the test coverage of an application.
If you are working in any CMMi organization, then the test case standards are followed more closely. Writing test cases brings some sort of standardization and minimizes the ad-hoc approach in testing.
Fields in test cases:
Using[tool name, tag name, dialog, etc]
To [what is returned, shown, demonstrated]
Verify: Used as the first word of the test case 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 test cases like:
While writing these all your TC’s should be simple and easy to understand.
One of the most frequent and major activities of a Software Tester (SQA/SQC person) is to write Test 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.
a) Test Cases are prone to regular revision and update:
We live in a continuously changing world and the same holds good for a software as well. Software requirements change directly impact the test 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 addition of new TCs.
Moreover, during regression testing, several fixes and/or ripples demand revised or new TCs.
b) Test Cases 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) Test Cases 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 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) Test Cases 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 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) Test Cases 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.
Keeping the above 5 factors in mind, Here are few tips to write effective test cases.
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 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 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 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.
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 wayand 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, Testers may be in a great trouble.
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.
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!
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.
Test Case Writing is an activity which has a solid impact on the whole testing phase. This fact makes the task of documenting TCs very critical and subtle.
So, test case writing should be properly planned first and must be done in a well-organized manner. The person who is documenting the TCs must keep in mind that this activity is not for him or her only, but a whole team including other testers and developers, as well as the customers who will be directly and indirectly affected by this work.
Due attention must be paid during this activity. “Test Case Document” must be understandable for all of its users, in an unambiguous way and should be easily maintainable. Moreover, TC document must address all the important features and should cover all important logical flows of the AUT with real-time and practically acceptable inputs.
Being a software tester, you will surely agree with me that coming up with a perfect Test Case 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 test cases and at times, the test case template is not up to par, or we lack in providing good readability and clarity to our test cases.
As a tester, whenever you are asked to do a test case 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 purpose of a test case is to explain how you are validating and verifying the software against its specified requirements. The test cases should always be clear and lucid. They should be written in a way that offers the tester an ease to conduct the complete testing by following the steps defined in each of the test cases.
In addition, the test case document should contain as many test cases as required to provide a 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 Case Documentation.
Here, I am going to provide you some useful guidelines that can give you a leg up in your test case documentation from the others.
The best and simple way to organize your test case document is by splitting it into many single useful sections. Divide the entire testing into multiple test case scenarios. Then divide each scenario into multiple test cases. Finally, divide each test 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.
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 test case is as important as a positive test 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.
Each test case 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.
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 case while documenting it.
You can use any encoding for defining the priority of a test case. 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 test case, verifying the display of relevant products on the user screen can be a medium priority test case and verifying the color of the text displayed on the screen buttons can be a low priority test.
Confirm whether the sequence of steps in the test case 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.
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.
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 case document, you should add the browser name and version to the test case so the defect can be replicated easily.
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 the overview of the testing.
Here, we discussed the need for test case documentation and how we should proceed while using it. The test case document should provide the best possible test coverage, excellent readability and should follow one standard format throughout.
We can achieve excellence in test case documentation by just keeping few essential tips in mind like 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.
Test case writing is one of the primary activities of the QA team.
We spend most of our time writing, reviewing, executing or maintaining these. It is quite unfortunate that test cases 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 test cases 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 test cases.
Let’s read on and please note that these tips are for both new and experienced testers.
Now, the most common problems I see in the test cases these days, both from my students and colleagues at work are:
These three have to be on my top 3 list of common problems in the test case 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:
First off 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 test cases and its steps as well.
For Example: I am writing a test case for Amazon.com – place an order for any product.
The following are my test case steps (Note: I am only writing the steps and not all the other parts of the test case 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, test cases 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 case.
Therefore, the above test 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 we write test cases, 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.
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 test cases 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:
Then, this is incorrect.
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.
Once again, let’s learn from Example.
Take a look at the below test case steps: The following are the test steps within one test case 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 test 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?
Hence, write modular test cases. 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. :)
That was a quick round up on a few commonly happening test case documentation problems. Please do let us know if you have faced any of your own that you would like for us to talk about in the upcoming articles.
In this software development and programming world, the best software developers always have written their unit test cases from the functional requirements, even before starting their coding phase, this dramatically improves 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 below list.
#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 case 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 test cases.
#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 test 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 test cases with the following approach and criteria.
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 test cases.
For Example, let us see the simple BAOE approach for the sample login screen above.
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.
Note: The test case 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.,
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 test cases 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.|
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.
Also read =>
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 the 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 a sample test data document for the test cases 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.|
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!!!