Great way of writing Test Cases

🗄️ Archive
1

Hi,

I am searching on the internet that what should be good way to write efficient test cases. But there, few good example found. Can anyone share the great way of writing test cases.

2 Likes
2

There are some useful resources in this thread

3

Hi,

My preference, based loosely on Agile principles (but main based on good test practices), is when writing Test Cases, I ensure that one test covers 1 function/object/change/etc., ensuring we deliver working software frequently and progress is easily measureable.

For example, based on the video player example in the previous reply, Solution 1 means you will be delivery working software but it will be big bang as opposed to frequently. Progress is not ease to measure because there are 4 buttons in test but if 1 of the buttons fail, the whole test fails.

Whereas the Solution 2, in my mind fits more easily into Agile ways of working and depicts good test practices.

In the real word, Test Cases usually contain more than one step, so the other thing to consider is level of details required. Not all Test Cases need to be thread to needle based; you could an initial ‘this how you start’ case and reference this in the ‘this is the change’ case. If they are written well then you can reuse the ‘this is how your start’ case over and again. The added benefit of this flow is that Test Case maintenance is kept to a minimum.

5 Likes
4

Hi @nitin1387,
you may want to have a look at this article: https://confluence.xpand-it.com/display/XRAY/Best+practices+on+writing+great+Test+cases
Most of the tips are in fact tool agnostic, although you may find references to the tool (Xray) as it was written in that context.
Hope it helps :slight_smile:

5

I think for me writing great test cases may be less important than ensuring great coverage. Sure, test cases should have certain attributes, like each test case should test what it is supposed to test, be replicateable, very clear to follow and well maintained, but to me coverage is paramount. Rationale: you can have, and supply to others, confidence in the software without creating or running scripted test case(s) provided you perform appropriate testing.

My personal approach is to start from requirements along with performing exploratory testing to generate test scenarios. I then deepen or extend the scenarios based on further analysis of the system/requirements/conversations with stakeholders. My goal is to identify risk, clarify any ambiguities and understand system functionality.

I then draw up a list or mind map or Excel sheet with test scenarios, ideally having this peer reviewed as missing stuff and/or making mistakes is human. If the testing will be repeated in future (e.g. regression tests) I may create detailed test cases with low-level steps (e.g. type character ‘x’ in field ‘y’ and look for result ‘z’), but based on what I have tested in the past, usually the test scenario will be clear enough with a little more detail added to it if necessary.

I wish I could refer you to a tool or page that explains exactly how to create test cases. Unfortunately given the nature of software testing I think the best you may find is an algorithm/approach like I have hopefully helped with above. The good news is the more testing you perform, the better/faster you get at creating test cases when it’s appropriate to do so.

1 Like
6

Test cases are a very important part of the software testing process for any application. Writing an efficient test case lays the foundation of a quality product. A good test case should have the followings:

  1. Summary: The main highlights of the scenario to be verified.
  2. Prerequisites: It should consist of all the requirements that must be completed to run the test.
  3. Steps: It include directions which should be followed to complete the scenarios. It contains detailed step by step information that needs to be followed to verify single or a set of scenarios.
  4. Expected Result: It includes the result which should be achieved after running the test.
  5. Additional Comments or Notes: Any other information to be kept in mind while running a test (Like OS, browser and etc).

The above mentioned things revolve around following factors that should be taken care while writing a test case:

  1. Test cases often require updates as some areas of application gets changed or removed. Sometimes, during regression testing few amendments are required in test case.
  2. Test case should be clear enough that even a developer can also understand and replicate the setup using the steps.
  3. Always review the test case after writing the same, as this process could unlock some untouched areas.
  4. Test case should be reviewed by a secondary person, so that nothing is missed.
  5. Make sure that the test data specified in Test case is feasible (Not only for actual testers but is according to the real-time environment too).
  6. Always cover the negative and boundary value scenarios in your test case.
  7. Prioritize the test correctly as to which test case should be executed first.

Don’ts for test case writing:

  1. Never write composite steps that can mislead a tester. Example, if you say “navigate to ‘ABC’ page”, it can make a user think , how to navigate to that page. You should mention the same step as : “first click on navigation menu then click on heading and further select the link for ‘ABC’ page”, which is more accurate.
  2. Never run multiple conditions in a single test case. If any of the condition fails, you will have to fail the complete test case.

Following the above steps will ensure the quality assurance services that a Tester should focus on. Hope this information is helpful for you.

7

Best simplicity / cost ration technique I’ve seen: Write in pairs (in real-time, not a posteriori review with handovers back and forth).
If two people co-write a piece of information, good chances are that others will understand it.

In second place come the say “what text can I remove from here without losing information?” a couple of times.

Simplicity is key.
Test cases are not to show off how deep you know the product, but to communicate with others so that their testing will be better.
Test Cases are not Testing., they are a communication tool.

2 Likes
8

What happens when the flow changes?
What if the tester can access ABC by setting a cookie and hitting an URL? Wouldn’t this improve focus on the target (ABC page) rather than being fragile to the specified flow?

"navigate to ‘ABC’ page”

can be complemented with a single living document where people show the many ways to performing this flow.

4 Likes
9

Hello @joaofarias!

I agree! I prefer to have detailed instructions about the application kept in a separate document. Simple steps like “Navigate to ABC” is more useful to me as a tester. If I am new to the application, I can refer to the document.

A test case should not be documentation on using the application rather it should guide - not direct - a tester towards an information objective. The purpose of the test could get lost in too many steps, or steps that too detailed.

Joe

6 Likes
10

Hi joaofarias,

Yes, you are right that a single living document would be fine. But, we can’t attach document everytime with test case.

When we write test case, it is in our mind that we will not execute this test case everytime. Someone else would definitely execute our test case in-future. That’s why, we prefer to provide exact step so it would be helpful for someone else to get maximum information. In case, flow gets change, its our responsibility to update the test case.

Hope this should fine and please let me know if you need more details.

11

Don’t you have knowledge base (Git repo, Confluence, etc) from where you can link such a document?

12

I’d totally echo the value of this approach having used it recently to great effect when translating requirements into a test matrix and then going lower level into test scenarios.

13

This page doesn’t have any info anymore :frowning:

14

thanks @ahopkins180, I’ve fixed it

1 Like
15

Hello,

There are lot’s of things you have to consider while writing a test cases. Below we are going to share some points that you have to apply while writing test cases or writing test scripts.

1.Title
2.Description.
3.Assumptions
4.Clear and concise Tests
5.Expected Result & Result
6.Consistency

These are the basic points you have to keep in mind…I would like to suggest you take a few minutes and have a look on these points briefly: https://www.testrigtechnologies.com/how-to-write-a-test-case-why-it-is-important/

16

There are many different ways to write test cases. Check out the five Tips of writing effective test cases that I found on a website named ReQtest.

#1 – There is no need to specify the expected result when it’s obvious
#2 – Consider breaking up a long test case into various smaller ones
#3 – If there are only a few test steps write a checklist instead
#4 – Use agile software to create & manage test cases rather than writing them in Word file
#5 – Group similar test cases into a test run and put the pre-conditions at beginning

2 Likes
17

Some best ways to writing test cases:

  1. Test cases need to be simple and transparent
  2. Create test cases with end user in mind
  3. Avoid test case repetition
  4. Do not assume
  5. Ensure 100% coverage
  6. Test cases must be identifiable
  7. Implement testing techniques
  8. Self cleaning
  9. Repeatable and self standing
  10. Peer review
18

Test cases should provide the value you need them to, but they may also be a regulatory requirement for some industries. In these cases, more detail would be needed to provide evidence of testing etc

For me, I always used to think that test cases needed to have enough detail that anyone could run them. Now I’m definitely of the opinion that enough detail to make it clear what differentiates that test from another is fine. At the end of the day, the act of testing is what is key, providing you have enough information to know what you’re testing and how to reproduce a failed case, then you’re good

I agree with others who said about a knowledge base or oracle for the wider information which may be standard across tests so you can then focus on the necessary detail in the test case itself

2 Likes