Great way of writing Test Cases

(Nitin Sharma) #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.

(Heather) #2

There are some useful resources in this thread

(sharon) #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.

2 Likes
(Sergio Freire) #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:

(Gerard) #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.

(Vishal Dutt) #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.

(João Farias) #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.

1 Like
(João Farias) #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.

3 Likes
(Joe) #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

4 Likes
(Vishal Dutt) #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.

(João Farias) #11

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