In the preface to his book Extreme Programming Explained, Kent Beck said that he likes teams to run fast. Design documents, technical specifications and anything that needs to be changed as the software changes create cruft. Cruft will either become outdated (and incorrect) over time, or else need to be maintained, and maintaining cruft slows
The best part of a presentation might just be the Q&A. After all, that is the part where the material meets the actual life experiences of the audience. About a month ago, we hosted a panel discussion titled “Revisiting the Test Automation Pyramid – 20 years later.” The panel attracted a lot of great questions,
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
In computer science we strive for more and more power. The way to do that is typically through reuse and high-level logic. Write a function, call it, reuse it, never write it again. In other words, Don’t Repeat Yourself (DRY). Sometimes it can be helpful to understand what is going on at lower levels. For me that
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,