How to Write Test Cases: The Ultimate Guide with Examples

This in-depth hands-on tutorial on How to Write Test Cases covers the details of what a Test Case is along with 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 works 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

Examples:

Tutorial #7: 180+ Sample Test Cases for Web and Desktop Applications
Tutorial #8: 100+ Ready-to-Execute Test Scenarios (Checklist)

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 and Test Case

Automation:

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.

What is a Test Case and How to Write Test Cases?

Writing effective cases is a skill. You can learn it from the 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 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?

Fields:

• Test case id
• Unit to test: What to be verified?
• Assumptions
• Test data: Variables and their values
• Steps to be executed
• Expected Result
• Actual result
• Pass/Fail
• Comments

Basic Format of Test Case Statement

Verify
Using [tool name, tag name, dialog, etc]
With [conditions]
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 factors that are related to this major activity. Let us have a bird’s-eye view of those factors first.

Important Factors Involved in 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 affects 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.

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 as a group. There may be certain pre-requisites of a TC that 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 comprise 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, wherever the different modules of a single application or multiple applications are interdependent, then 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 that 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.

Let’s start!!!

#1) Keep it simple but not too simple; make it complex, but not too complex

This statement seems a paradox. But, we promise 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 we 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 move back and forth in the pile of documents for completing a single test scenario.

Do not even let the tester to document these TCs compactly. 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 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 the application’s behavior depends 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 as per the testing categories and the related areas of an application. Clearly, instruct and mention which TCs are interdependent and/or batched. Likewise, explicitly indicate which TCs are independent and isolated so that the tester may manage his overall activity accordingly.

Now, 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 TC’s writing. In fact, the End User should not be ignored at any stage throughout the SDLC. Yet, our emphasis so far is just related to the 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 the 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 cannot 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, try to cover the testing for all the possible scenarios that can occur within your software application.

Keeping the above points in mind, let’s now take a tour about How to Achieve Excellence in Test Documentation.

Useful Tips and Tricks

Here, we will explore 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 be innovative and draw up all the possibilities that your application comes across. We, as testers, have to verify that if any unauthentic attempt to enter 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 testing.

#4) Prioritize the Tests

We often have stringent timelines to finish up testing for an application. Here, we may miss testing some of the important functionalities and aspects of the software. In order to avoid this, tag a priority with each test while documenting it.

You can use any encoding for defining the priority of a test. It is better to use any of the 3 levels, high, medium, and low, or 1, 50, and 100. So, when you have a strict timeline, 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 Tester’s Name to the Comments

There may be a case where you are testing an application, and 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, and this 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, should add the browser name and version to the case so that the defect can be replicated easily.

#8) Keep two separate sheets – ‘Bugs’ & ‘Summary’ in the Document

If you are documenting in 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 time is restricted, these two sheets can prove very useful in providing an overview of 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 documents, 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 tutorials on our site on this topic, but here will see How NOT to write test cases – a few tips that will help to create 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

1. Composite steps
2. Application behavior is taken as expected behavior
3. 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 without realizing that a few simple measures can fix things easily.

Let’s get to it and discuss each one:

#1) Composite Steps

Firstly, 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 will not make sense, because here we ourselves think – “How do I get to XYZ in the first place”- instead of 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 same rules apply to tests and their 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: We are 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 on 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 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 is few reasons that force us into relying on the application (an older version) 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:

Case 1:

If my test case steps are as below:

1. Launch the shopping site.
2. 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.

Case 2:

1. Launch the shopping site.
2. Click on Shipping and return.
3. In the ‘Enter the order no’ text box present on this screen, enter the order no.
4. 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 expected 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 an Example.

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 the 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 think- 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?

Read on:

• What if one condition 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 throughout 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? 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.

Real Example

Let us see how to efficiently write test cases for a familiar ‘Login’ screen as per the below figure. 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 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 that require no user interaction, just for displaying the text only.

• Functional Cases: The login button and the Hyperlinks (Forgot Password? & Registration) are dynamic fields that 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 & table, and also the user has the permission to log in 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 email the user. So, maybe an Email needs to be tested for the proper process and confirmation.

4) Finally, keep the “BAOE mantra”, which 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 apply 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 log in to the application.
• Options: What are the options that are available to come to the same login screen? For Example, after logging in to the application, clicking the ‘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 the 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 write the TCs for the login screen, in a format with complete coverage, traceability, and detailed information. The logical sequence and numbering of identifying the ‘Test Case ID’ will be very useful for quick identification of the execution history of test cases.

Also read => 180+ sample ready to use test cases for web and desktop applications.

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 below.

Note: Add the Actual Behavior column at the end of this template.

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 fed 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, then the tester would spend abnormally more time collecting the data at the time of test execution. The test data should be collected for both positive and negative cases from all the perspectives 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 will be helpful in how effectively we can collect the data, which will ease our job at the time of test execution.

---

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 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. If the websites are for the same domain, then 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 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 are 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.

#8) The types of testing needed are common, like browser compatibility testing, performance testing, security testing

There is plenty that is common and similar. 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, variables, 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 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.

Conclusion

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. Check out our series of tutorials to know more about test cases and express your thoughts in the comments section below!

Next Tutorial