Tuesday, August 3, 2010

Getting Testing?

Very few people get testing.

The mindset of a good testing person is hard to identify...
When asked to test something do they split the problem up into small parts, or do they simply test inputs and outputs...do they cover all the inputs? all the outputs? Do they only ask hard questions, and never cover the easy stuff? Do they only think of the obvious, and never broach the harder questions? Do they think of the system as a whole? Do they think of things outside the system that can affect it?
See cause a good tester hits lots of these things in turn, they identify that they've attacked a problem from one angle, go back to the beginning and attack it from another angle. This is the single hardest thing to identify, cause some people use up minutes while thinking of different paths to test, others take significantly longer.

Explaining that to other people is one of the hardest things I've ever tried to do.
Haha, explaining to other people that few people get testing is hard...hehe...sorry, back on topic.

When I explain things to other people by simplifing them, I often feel that I am dumbing it down and that those people are not going to be making informed decisions. However, if they get accessibility (to the information) instead of accuracy (details) is that enough?

I mean we don't teach math by starting with decimals...you learn integers first.
Example: In first grade we were taught 2 divided by 3 is not doable... despite the fact that .6666 is a valid decimal value. In order to teach accessibility (integers) so that kids can grasp it we left out accuracy (decimals) till after they got the first concept...

So what information about testing can be accessible (to non-testers) while perhaps not being accurate (for testers)?
Depth vs Breadth? Maintainance of test cases? Automation? Execution?

Wednesday, July 14, 2010

People, too many expectations

Recently I've converted from a real job in testing, into a manager of testing people. It's odd going from expecting awesomeness in oneself to being responsible for the awesomeness of a team of people.

For one thing, the people underneath me, that I'm supposed to guide, none of them can move fast enough. Things take longer then normal, projects never seem to be as easy as they first appeared. At first I thought this was because I was a new manager and I needed to guide them more, but I have no wish to micro-manage people. I've been micro-managed and it was all I could do to get my manager off my back (sometimes lying) and then do what I needed to do.

Next I thought perhaps people weren't applying themselves enough. So I grabbed some people I knew had the requisite skills and gave them a project I thought was simple. Results: took three times what I thought it should.

So then I chucked it up to people not having enough time, I mean a QA Engineer whose on at least one team doesn't have that much free time, not to mention in reality most of the QA people under me are on multiple teams. But I can receive detailed feedback from these same QA people about topics that they had to have researched.

I've finally come to the conclusion that it isn't them, it's me (not surprisingly).

I couldn't keep pace with my own expectations, how would anyone else be able to do that? For one thing I never seemed able to move at a pace that was acceptable, there was always something more that I could do, some little thing that could be tweaked or made better, a new feature added, some better way to store, retrieve or move data. So it's not that I've settled for less, it's that I've realized that each individual has just this small sliver of time that they can devote to 'side' projects, and most of those people need to learn something (often times multiple things) new, before they can even start the project.

PS: This isn't a ding on them. The crew I have is some of the best people I've had the pleasure of working with. However I have to temper my need for results / speed with what people can reasonably do, without burning themselves out.