Setting up an effective test framework and environment for integration & e2e tests can be challenging and needs constant vigilance to keep tests stable. Although each company and environment may require some differences in how tests and environments are set up, there are usually a lot of best practices that apply to almost all of them. In this talk, he will discuss some common best practices he found to work well at many companies over his more than 2 decades of QA experience.

Takeaways from the talk:

• Use the same language for API (back-end) & UI (front-end) tests. That way you can reuse code from the API test framework to do some setup work in the UI tests.
• Tests should always be written to be able to run in parallel without interfering with other tests and should be idempotent (able to be run multiple times in a row without interfering with itself).
• Use random (or pseudo-random) test data to avoid data collisions when running in parallel.
• Group tests into full regression/sanity/production connectivity, with each group containing a smaller sub-set of tests to run on higher environments.
• Write unit tests to test some of the complex test utility code. That way you can refactor your common test utilities without worrying too much about breaking other tests; but exclude those unit test results from the product test results.
• Separate tests into read-only and non-read-only and make sure the non-read-only tests always create new test data instead of reusing pre-created test data. That way they can be run in parallel without interfering with other tests. Also, read-only tests can reuse test data to avoid filling up the environment with too much test data.
• Instead of injecting seed-data with SQL scripts when creating a new environment, consider having tests create the data they need using API calls if it doesn’t already exist.