Q: How should I divide my project into suites?
A: See your app as a various set of features and try to group these features in hierarchy. Root-level features can be the key areas of your app which serve as entrypoint to rest of features.
Take a look at this example:
Assume you have a mailing web app (like GMail), follow suite structure might fit your needs:

For very large app, you might have various microservices and root-level suites might be named after each microservice.

So it depends on your preferences but for most cases we recommend following structure of the above example as it fits 90% of use cases.

Some DO's and DONT's:

  • Do not specify suite names with info related to execution. For example, "IE Tests" is not a good suite name. Suite name needs to strictly tell a user the part of app it refers to, not where or how to run it.

  • Stick to 3-4 words for suite names. Longer name = More room for interpretation or boring names.

Q: How to write a test case?
A: There are many guides on how to write a test case online. But here's the summary:

  • Focus on title / Title should easily communicate what particular case is based on.

  • If you are a small team or your software changes a lot, do not bother defining steps, title might be enough.

  • Make each test case atomic.

Q: How to use tags in testing?
A: There are many ways you can utilize tags but one of our favourite example is:

Multi-staged E2E testing

How to do this?

  • Name your QA checks in CI/CD pipeline (for example: staging tests, production tests, production monitoring test)

  • Create tags for each of this QA Stage (tags can be named like: staging, production, production-monitoring etc.)

  • Now tag various test cases with these stages so that you can easily assign QA tasks later during release cycle.

Did this answer your question?