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.