Harry from csswizardy.com shared this post about performance testing and where it sits within software development life cycle. Often performance testing ownership is not clear and this is a common reason why performance gets overlooked.
Author tries to distill the types of testing that we do into three distinct categories: Proactive, Reactive, and Passive. Each have their own time, place, purpose, focus, and audience.
The first kind of testing a team should carry out is Proactive testing: this is very intentional and deliberate, and is an active attempt to identify performance issues. This takes the form of developers assessing the performance impact of every piece of work they do as they’re doing it.
Reactive testing should be reasonably automated, and should be carried out in as live-like an environment as possible.
Reactive testing is usually done in response to an event in the development life cycle, such as a build or a release. You could use Gulp tasks that run Lighthouse against your staging environment, automated WebPageTests that run at every deployment, performance budgets that run on every build, and so on.
Passive tests to gather data over time and asses the situation: can we spot patterns? Do certain browsers or geographic locales suffer more than others? Do changes in performance correlate to changes in business metrics?
More information on tooling and charts accompanying explanations also in the article. Good read!
[Read More]