What is the effective test cases for any projects?

🗄️ Archive
,
1

How i write the best effective functional test cases for any project.

1 Like
2

By knowing your domain, make sure that tests are not dependent on each other - each passes or fails separately, avoid longer tests whenever possible, determine consistent naming conventions for your tests, and group them in logical sets. But most of all, maintain them and continually look to improve and refactor your tests.

1 Like
3

Your personal situation will determine your approach. Bank software has very different needs to a mobile game, for example. The other problem is that the tests you need to perform change as you test - you may be exploring the product and find something that requires more specific testing. Also projects change which means your situation will change - maybe the company now needs to concentrate on a new feature of the product and your testing will have to adapt to meet those new needs.

So to get around these problems:

  1. Don’t write anything down that you don’t have to so that you don’t have to maintain and update it later. These will add up to a bigger problem down the line.
  2. Don’t formalise your testing more than you need to - use risk catalogues, charters, etc to guide your testing to keep it adaptable, flexible and low-cost.
  3. Understand what you are there to do, for whom, and develop a test strategy that works with the resources available to you.

Once you have that then you can decide if and when you’re going to write test cases, which is its own specialisation and brings up complex issues of communication, formalisation, suitable variation and so on. A simple place to begin is to know:

1. Why this needs to be a written test case
It’s a high-cost and inexact artefact at risk of maintenance costs and needs to earn its existence to offset the problems
2. Who it’s for
Written test cases are communication tools to allow another agent to interpret them in order to replicate a process to achieve a desired outcome or behaviour. Knowing your audience helps you to predict how they might interpret your instructions and combined with knowing what outcome you want them to achieve will help you to guide the reader to the outcome you’re looking for. Including your desires often helps to communicate what you are trying to do - this goes for broader, easier systems like charters too.
3. The risks
Writing costs, maintenance costs, communication failures, hard to read useful data from, lack of variability, restriction of testing activity, reporting issues, and so on.

2 Likes
4

Drop ‘cases’ and just think about what to test. You can note that down.

I have 2 basic considerations:

  • For what need others confidence from you/testing? Testing is also a social task, informing others about the state of the prodcut.
  • What changes were introduced and what should I maybe test therefore?

Not to forget: Error handling can be also seen as “happy path”. At least its not an edge case. Its a normal function of most products.

2 Likes
5

thanks for contributing!

1 Like