Happy users and happy programmers are an obvious, but also a very important goal for us all. Therefore, we have set up smoke test guidelines for all extension developers and we strongly recommend that everyone run smoke tests before each major release (May & November)and minor release (February & August).
- Get a more robust Extension and a more robust Core.
- Find issues in time.
- Get happier users.
- Get happier programmers.
- Have smoother and less stressful releases for everyone: Core, Extension, developers, and users.
- Improve Extension and Core quality and usability.
If you have any questions, please don't hesitate to contact our QA Support at email@example.com.
Running smoke tests is great for you and the users in many different ways. Please note that smoke testing is not the same as a full regression test. A full regression test is also recommended before each major release.
The smoke test helps you:
- Detect new issues in your own Extension in good time before the release. i.e. you have time to fix any problems.
- Find issues related to Core functionality early enough for the Core team to resolve them in time for the upcoming release.
- Find quality improvements and new quality issues. Which includes user-friendliness, reliability, and usability issues.
- The full regression test is done after the smoke test. Thanks to the smoke test, you will likely save time during the regression test as the easy-to-spot problems will not slow things down. In general, you save time and money in total when a smoke test has been performed.
Developer can start migration approximately 7 weeks before a major release. It is recommended that you run the migration testing and smoke testing once the developer has done the migration. The testing should be repeated with the Release Candidate. For minor release, although partners might not need to do the migration, it is recommended that you run the smoke testing using the Release Candidate which is available 4 weeks before the release. Please complete all testing at least 2 weeks before the release. This is to allow the core developers to resolve the issue before release.