My personal performance #30daysoftesting challenge

What time is it? Game time! Well, almost, it’s time for the latest #30daysoftesting challenge. Again organized by ministry of testing, this time with some support of the PerfGuild. Which leads us to the topic of this challenge: performance testing. Instead of posting a blogpost afterwards, I decided to start one right from the beginning and keep on updating it while doing the challenge. And as things are getting rather long, I decided to split the one post into 3 smaller ones.

My personal performance #30daysoftesting challenge days 1-9 (this one)

My personal performance #30daysoftesting challenge days 10-19 

My personal performance #30daysoftesting challenge days 20-31

So, without much further adoo, here is

Day 1: Buy or download a performance testing related book and read it by day 30

I decided to go for


Three simple reasons for that:

  1. It claims to provide a less technical and more of a management position. I especially did not want to go for a tool-related book, however intriguing getting to know jMeter is.
  2. It’s free if you subscibe to Kindle Unlimited
  3. It has been in my kindle reading list for some time already 😉

Day 2: Listen to a performance testing podcast.

 

My notes from the podcast look like this:

Overall those 40 minutes were absolutely worthwile. I especially liked the “Use what you got” attitude, since that is something I have been trying to do. Those of you coming by regularly might remember that I stated that it was a close call for fifth on my favourite podcast post between the Scrum Master’s Toolbox and TestTalks and that I went with the former. Well, some time has passed and, while it is still a close call, I’d meanwhile go with the latter as I noticed myself getting more value out of TestTalks recently.

Day 3: Find 5 performance testing experts to follow on twitter.

I was a bit late to this one as several people had already posted their recommendations. As mine probably would have been very similiar I decided to post the last five people that took the challenge to give those some props as well.

Day 4: Share a performance issue you’ve read in the news recently

Without wanting to go VW-bashing, it was the topic that instantly came to my mind. Probably triggered by the fact that my car is most likely affected by the latter recall, although I didn’t get a letter yet. This is nevertheless an interesting performance topic: An electronic control unit doesn’t behave properly when temperature reach a certain threshold. The wikipedia definition of performance testing says:

"In software engineeringperformance testing is in general, a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other qualityattributes of the system, such as scalabilityreliability and resource usage."

I dare to argue that in the VW case we are dealing with the reliability aspect mentioned under a particular temperature workload. So in this case the workload is getting a physical dimension that needs to be taken into account.

Day 5: Arrange a meeting with your team to talk about your current approach to performance testing
I did not. Technically speaking I failed this one. But (you know there would be a but) I have had several meetings and talks with our sales department about our current approach during the last days (including today), so I’d go for that instead. And on the positive side of that, explaining it to other people often gets you to identify flaws and humps in your approach and your own understanding of a topic. So that helped me as well and so I dare to half tick it off.

 

Day 6: Think about who are the stakeholders for your performance testing

I wanted to visualize the stakeholders and came up with the idea to map them on a dart board. The intention was to put some emphasis on certain stakeholders even though they are not that closely to me as a tester. That is why I put the customer in the triple 20 area to stress that ultimately it is all about the customer even though I am more in contact with other roles (yellow) or internal groups (orange) than with external (pink) groups.

 

Day 7: Refresh your knowledge of the basics of web application architectures

&

Day 8: Find the top ten slowest API/Database transaction in your application

I skipped those two for now and will have to live with eternal shame ever after. Or I will do these later. Probably the latter.

Day 9: Read a performance testing blog and share it with someone

This is something that really interests me while taking part in a challenge: how are others doing? Do they encounter the same struggles? Do they have any ideas I might get some good ideas from? That is why I actually chose the blog of someone who is actively participating.