I’ve been asked to give a talk to some of our off-shore developers. They’re sitting through a workshop on just about everything related to the client environment, and I’m talking for 15 minutes about performance testing with Loadrunner against web-baed sales flows.

I thought about winging it, but the manager has asked for a powerpoint deck, so I’m assembling that now. And as I get to the first page about entry criteria and intake activities, it occurs to me that I’ve not defined this before although it’s always in my head and is a very common interview question and answer.

I had a chat with my colleague and explained to him that I use 4 questions to gather all the information I need to build and execute a performance test. He didn’t believe me and say’s he uses nine questions to get that information. So we discussed it some more and reached an understanding.

I’m talking about the 4 top-level first questions to which I need an answer before I’m building anything. Other questions will be required as we move forwards with the project. And the answers to the 4 questions will evoke other questions and answers but at the highest level, I walk into that first client meeting armed with my 4 questions.

1. How is it built? – The solution under test
2. What request(s)? – the script(s)
3. How many? – requests per hour – the scenario
4. How quickly? – do they need to go? – the requirement(s)

MM (my colleague) wants to ask about network topology, about transactional drop-out rates, about reporting structure and team contacts etc. I argue that isn’t necessary in the first instance, but is useful to know as and when, or before the first execution.

Simply, those 4 questions define the solution, the scripts, the scenario and the pass/fail criteria. From that I can build the test. Maybe it’s experience, maybe I’m overstating my abilities, or maybe I’m wrong, all I know is that for 15 years, I’ve been a performance tester and my refined approach begins with those 4 questions.