You can skip the cup of coffee; this might be my shortest ever blog. Some have asked what you need to run performance testing in the CI/CD pipeline, and here’s my answer. To run performance testing in the CI/CD pipeline, all you need is to “just run the tests!” Well, except for a few minor nuances of course.
In my introduction to performance testing I mentioned two problems that stand in tension of each other. On one hand, you might make testing appear too simple. At the extreme end, this is just hitting a static web page frequently, and never actually hitting the parts of the website that require database lookups. The performance test
Sometimes when people talk about a discipline, they make it harder than it needs to be. This does not have to be on purpose. When the aspiring performance tester starts out, they have to read a bunch of documentation, thick books with big words, and, frankly, figure out what works by trial and experiment. As
Previously I explored what the word scaling means and in particular what it might mean for you and your organization. My short explanation is to allow testing to continue to “work,” without introducing delays, excessive effort, or problems, as something gets bigger. What that thing is depends on your group. It could be more features, more teams,
In computer science we have two kinds of scaling. In horizontal scaling, where we add more machines to a cluster to serve many clients at the same time. With vertical scaling we “beef up” the machines we have, adding more powerful CPU, more RAM, or faster hard drives. In Software Engineering, scaling can also mean
Exactly what to do in your test program is context-dependent. Don’t take this as the way to create a test program, but instead as one way, a way I have seen work at several companies, paying less for testing and getting better results than their peers. Some of the readers here won’t really have a test “program,” not
A few years ago I worked with a team implementing a continuous integration system. The system was pretty simple. It checked out the code and ran unit-tests, then waited an hour to run again. The manager counted not only the number of passing assertions per day, but also the growth rate. Of course, some programmer