I was going through this tutorial https://www.softwaretestinghelp.com/how-to-write-effective-test-cases-test-cases-procedures-and-definitions/

enter image description here

and I found it very time consuming from both writing and reading/execution perspective. Instead, I would recommend writing test case scenarios.

Question: Is it really old fashioned, what are the demerits of writing it in tabular formats? I know a few but need to know so that I can convince clients.

  • Why do you need to "convince clients" about how you and your team document your own work? Are they more interested in organizational aspects of your testing or in the testing itself (including the test story)? Commented Oct 29, 2020 at 16:41
  • I need to change their old mind set, if I give them a logical answer, then they will be happy, I will be happy. But if I just say oneliner that its a wrong, time consuming, old fashioned way of writing, they will accept it but won't buy it. For them to buy my point, I need to good logic across.
    – paul
    Commented Oct 29, 2020 at 17:45
  • 1
    What you have provided as screen shot is not a test case but a bug report
    – PDHide
    Commented Oct 29, 2020 at 18:02
  • @paul You said what you want to do, not why you to need. Who are your "clients" and what's their influence on yours and your team's work? Depending on who are these people, different approaches fit better than others. Commented Oct 29, 2020 at 18:14
  • COuld you add proper testcase as the expect ?
    – PDHide
    Commented Oct 30, 2020 at 0:10

5 Answers 5


Manual tabulation through spreadsheets is one way of testing.
There are advantages and disadvantages to it.


  • Automation experience not needed
  • Summarization pages and charts are easy to build
  • Non-technical folks can easily read and use the reports.


  • Doesn't scale well
  • Time consuming to run
  • Time consuming to maintain
  • Has to be manually maintained to stay in sync with app
  • Doesn't provide immediate and constant insight into state of testing
  • Leads to team issues with "devs write real programs and testers just use spreadsheets"

The term old-fashioned is irrelevant.
Quality is not about popularity and age and what is in fashion.


The screenshot you provided is not a Testcase but a bug report.

You cannot consider a personal blog as final point of truth , it can be the authors mistake or a unnoticed mistake while uploading file to that web page.

Now coming to your actual question, there is no much difference between writing testcase in a Test Case management Tool and a Excel file. Excel is just another tool.

A tabular test case looks like :

enter image description here

This template was got from the same website ( https://www.softwaretestinghelp.com/test-case-template-examples/ )

There are both merits and demerits for every approach . Its hard to suggest merits and demerits unless you states the following things like :

  1. What methodology you work in (Agile or waterfall ?)
  2. What is your sprint length
  3. How much time you gets for testing
  4. What is your responsibility ( Is it only manual , is it automation or is it both)
  5. What is the Team size
  6. What is the release plan

But i would recommend following things as best practice

  1. Adapt a TDD where you create test cases parallel to the development. So when the development sprint starts , start your test sprint in parallel and use the time to create the tabular testcases
  2. Don't wait till you get the actual product to write the testcase and start testing it
  3. Demand more time for documenting test case in tabular format if current sprint size is insufficient
  4. First start with just writing down all the use cases that comes to your mind ( means just the title ) . Else you will feel the work tedious . First write down all use cases and once you are satisfied with the use cases you have decided, start writing the test steps and other details in tabular format
  5. Split features between team members , give each team member the responsibility of testing a particular feature. This will give you more time to focus and document test scenarios for that specific feature than getting nervous about entire product.
  6. Keep initial few days for test documentation , and start execution only after it is completely done. Don't do it in parallel else you lose focus while testing


  1. If you are a single QA in a small sprint size team , this will be really hectic tasks and you might lose focus on actual testing and affect test quality
  2. If you are single QA responsible for both automation and manual , then this will be a really waste of time and effort . It should be a complete no for this approach . Just copy paste the test script title if anyone really want to know what use cases are being tested . If they still insist demand more members into team

Please read : https://sqa.stackexchange.com/a/46008/40022 which explains a general recommendation of any type of documentation


As @PDHide suggested, the example appears to contain the fields associated with a BUG rather than a test case.

Here is why: A test case prescribes the expected condition following some steps. The actual condition may be documented in the test case at the time it is executed -- if the actual meets the expected. If the actual does NOT meet the expected, a bug report would be filed.

As far as whether something is old-fashioned, I couldn't say as it would be a matter of opinion.

I would venture to say that the screenshot provided appears to me to be a csv for data-driven test automation or, more likely since results are displayed, a report of the success of the automation build (though I would expect to see the actual mentioned for the failed test).


If one is working for a software testing solutions provider, then a strong focus should be given on exactly how the functionality of a software should be.

And writing exactly how the expected outcomes should be is one of the best ways to go. Also, when writing a defect, it should be clearly mentioned what the actual outcome in comparison to what the expected result should be.

By writing these, it becomes pretty clear to any developer where the root cause of the defect is. Once defect is fixed, test cases for the scenarios could be run to check for the expected result.

Therefore, though old fashioned, but this is one of the most robust way to have the product shipped out as per the requirement and market standards.


Notwithstanding the observation made by others (this cites a bug report), in very simplistic terms, a test result is one item of information: Pass or Fail

But what do we mean by Pass? Well, the test performs as expected... ie Actual Result = Expected Result.

The only way a test tool knows the Expected Result is for the tester to specify it - or for the test automation to otherwise determine it from the specification.

So, no, it is NOT really old fashioned to specify expected results!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.