A friend of mine sent me the following question the other day:

Can you give me 5 or 6 bullet points for a performance tester and what we need to tbe looking for when hiring a new person?

Attempting to honor his request for a short list (because I could very easily send a long list, here is what I came up with off the top of my head. Note the things that I would be willing to pay more for in terms of salary. If I didn't say based on salary, then the level I've indicated would required.

1. Can they test (analysis skills, techniques, planning, etc...)
   
   
   
   • intermediate
   
   
   
   


2. Can they model (UCML, UML, various diagrams, concept modeling, etc...)
   
   
   
   • intermediate to advanced based on salary
   
   
   
   


3. Do they know math (probability and statistics)
   
   
   
   • intermediate to advanced based on salary
   
   
   
   


4. Do they know hardware, networks, and application servers (servers, routers, switches, JVMs, configurations, etc...)
   
   
   
   • basic (they know where to find info and what questions to ask)
   
   
   
   


5. Do they know tools (HTTP Spy, Etherial, LoadRunner, Robot, RPT, OpenSTA, etc...)
   
   
   
   • basic to advanced depending on salary
   
   
   
   


6. Can they code (not tool-code, but code-code)
   
   
   
   • basic to advanced depending on salary
   
   
   
   

I know that many of you in the TestingReflections community are performance testers, and I was wondering how you might answer this same question. We had an interesting discussion about this topic at the last WOPR (during the SWOPRs).

Feel free to post below...

I recently visited a friend who presented me with the following problem from Mensa Logic Puzzles:

There is logic behind the distribution of numbers in the grid. Work out what it is and then fill in the missing numbers.

When he first presented me with the problem, I spent about half and hour staring at the grid. I attempted to perform all sorts of arithmetic operations on the data to try to find the pattern - but with no luck. After half and hour I gave up and told him I would sleep on it and solve it the next day.

The next day, when he gave me the problem again, I thought of something James Bach told me the last time we got together, "If you have data then graph it." With that in mind, I flipped open the laptop, fired up Excel, and came up with the following:

Solution One

The first thing I attempted to do was sum up the rows and columns. I found a repeating pattern for the rows: 35, 27, x, 35, x, 35. I quickly found that I could make that 35, 27, 35, 35, 27, 35. But that solution had two problems. First, the columns didn't add up to and sort of pattern. Second, the numbers in row five could be several variations to get six (2 and 4, 3 and 3, 4 and 2, 1 and 5, etc...).

Solution Two

Next I tried looking at evens and odds. I was looking for some sort of pattern to the way they were distributed. I quickly gave up on that...

Solution Three

Finally, I color coordinated the data. I gave each number its own color. It was then that I noticed that each color seemed to appear the number of times as the number I chose it to represent. When I looked at the difference between the number and the number of times the color appeared, I had a total difference of four. So I figured I had my numbers, now how do I put them in?

I then noticed that no color was touching itself. When I started plugging in the numbers I thought solved the problem, there was only one way they would fit that would keep them from touching their own color.

I had solved the problem. I gave him my answer, and he was shocked to learn that I had solved it correctly.

When trying to notice patterns in your testing, if you have data - graph it.