Ainars Galvans's blog

Farewell testingreflections!

Thu, 18 Jun 2009 07:48:03 +0100

Yes, the decision to move my blog to a new location is made. That was not an easy decision because testing reflections has become my blogging motto. Thank you Antony for everything.
There are different reasons for the decision. One of the reasons is that I feel I don’t belong here, not any more or perhaps never had. I feel like testingreflections lives primary under the agile banner. I’ve been inspired a lot by agile ideas, but I never adopted them. I reclaim my personal method .

Let them feel in charge! Tips for test process improvement

Tue, 14 Apr 2009 10:04:29 +0100

Did you ever felt like this “Why managers and developers want to teach me how to test?! I’m the tester. I know how to test!”. Ever wanted to teach the cook how to cook to satisfy your taste?
The trick I’ve learned is to let stakeholders influence what I test but decide how to test it myself. However this is not so simple: to let them influence I must make testing process crystal-clear for them. And it means different things in different contexts (and you know - context changes in time).

Why do WE do software testing?

Mon, 06 Apr 2009 14:18:04 +0100

The background of this blog is so complex that I don’t want to waste my time explaining and yours reading it. Anyway, I wanted to organize my meta-thinking about testing that I do in my current project.
So what follow is a context-specific; subjective(my personal experience based) list of types of value we tester provide to project while testing code (I choose to limit my thinking to so called dynamic testing and do not include such tasks as review):

What brings controversy: incomprehensible computer or people incomprehension?

Tue, 24 Mar 2009 09:37:31 +0000

Do you know the history of four color theorem. It was the first major math theorem to be proven with extensive computer assistance. Which caused a lot of controversy ... (among mathematicians).

I somehow recalled this fact when reading Matthew considering history of published testing ideas . I believe he choose to ignore events (such as Year 2000 problem, trend of cutting IT department costs a few years later, etc.) to concentrate on inventions (methodologies and tools). I support Matthew in his work, but I’m afraid I can’t contribute as I made my career ignoring most of the publications. I think I made my career for historical reason: I chose to excel as a tester and worked hard while others struggled to find path to development career (at that time tester was seen as second-class citizen at least in my company and I proved this to be wrong). It would not be enough today, I'm afraid.

Supportive and Directive test documentation.

Wed, 11 Mar 2009 15:17:47 +0000

So there was (unfortunately) the exploratory testing good scripted testing bad conversation which I don’t want to continue. But I learned a few more reasons for scripted testing during the conversation: lack of tester’s commitment or competence. I’ll explore them in this blog and provide link to a space where I’ve stored some test case and other test documentation samples. I think rather than talking what is good and what is wrong we need to share examples.

Why do we keep writing (manual) Test Cases upfront?

Fri, 27 Feb 2009 12:11:10 +0000

There are at least 2 ways how developers could write unit tests: before code (TDD) or after code is ready. The same applies to writing manual test cases and test scripts (given that we decided to write them at all). There are many benefits of writing up-front: you could review, better plan (schedule) and control, test faster once code is ready, etc. The draw-back is only one - you spend more effort (budget)… (well there are actually more but let’s forget about them now). But do you know how much more? 4 times…?

Communication skills: what are they?

Wed, 28 Jan 2009 13:57:35 +0000

We were recently discussing how essential communication skills are for a tester. We all agree that they are valuable, but are they number 1? More valuable than bug reporting, problem solving, etc? Well, I’m afraid we can’t draw a line between them. Not only are they interrelated; testers with coping skills overcome a lack of one skill using others instead.

Make test objectives desirable for tester

Tue, 20 Jan 2009 13:54:53 +0000

I’m a manager who is still testing. I can afford to do what like to. This makes me very productive at what I do. When setting objectives for a testing task I take into account following:

What must be done (the value of the task)

What I think I can do well

What else could I learn to do (better)

And I try to hire testers who are like me. And I try to treat them as myself – I take the same 3 things into account when set objectives for them. Well, I try to.

Chance-based testing

Mon, 12 Jan 2009 15:59:34 +0000

…If chance and risk are synonyms, then risk-based testing should not be too far from chance-based testing, should it? No I’m serious. Or do you think following quotes are from people who knows too little about test techniques?

“How can we maximize the chance of finding such a problem in the limited time we have to test?”

“I was lucky enough in my random selection of order for retesting the fixes that the system was in a state for me to get some simple extra tests in for the previous feature.”

Casinos makes money on roulette because they knows statistics. Testing is not as random as dice roll, but we could make a few conclusions if we analyze statistics. One of the conclusions that I make is following: it makes a lot of sense to vary tests (minefield analogy) when we do it first few times. But as we do regression again and again the effect is lost.

An interview hint

Sat, 10 Jan 2009 16:42:46 +0000

A hint is short: I want fair answers, not the right ones.
During interview if I ask either "do you like doing regression testing", "how to test this screen", or even "what is a functional testing", I don't expect the answer from any book. I want to learn about your experience, about your ability to think, analyse, solve problems. I want to see if you are aware of context, ...
Maybe there are different people. Maybe other test managers during expects to hear the right not the fair answers, but I wouldn't take such a job - to have a boss who want the right answers instead of the fair ones is the worst I could imagine.

Survivor’s lessons in test management

Tue, 06 Jan 2009 10:54:56 +0000

No I don’t mean TV show about people living weeks on a beach. I somehow mean show on a discovery channel. I want to tell you what I learned from a project. It was supposed for 3-4 experienced testers, but I did it all by myself. I had to sacrifice all my beliefs of test management to do so. That’s why I admit I no more understand how to manage testing (well).

I’m skeptic for the mind ability to analyze the mind

Mon, 05 Jan 2009 12:28:58 +0000

I’m not buccaneer-scholar though I recommend you to think if you are one and join the club. I recommend you to think what type of scholar you are, anyway. What follows is my own thinking of why I think I’m a skeptic-scholar and has always been. As a skeptic-scholar I welcome new ideas because I’m as skeptic about their value as I am about the established values… actually I don’t establish values at all.

Voice-pairing or New testers brings new ideas

Mon, 15 Dec 2008 12:33:31 +0000

I’m happy for Oleg recently joined my test team. He is very fast as filling in gap between his previous company testing practices and mine. Moreover, as a new player in a team he brings new ideas. He adds his own vision, experience and context to everything I recommend And I like to be misinterpreted (unless we are running out of time and we are not yet in the project he is assigned to).
So one of his inventions is skype-pair-testing. I was first surprised to learn about it but then I recalled a very similar practice with pair-bug-hunting. You could read details here .

QA testing is black magic for developers

Tue, 09 Dec 2008 08:29:22 +0000

Just red a blog about developers having no idea of what QA team is doing. As I can’t seem to be able to add a comment to Michael Furmaniuk’s blog (which is by the way in the list of blogs I read) I decided to write a short reflection here in my blog.
Well, developers may or may not know read our test cases and learn what tools we are using. But developers know for sure what the requirements we have and what the code testers get. They know the bugs testers report. What they are most curious about (in my experience) are two things:
1) How do we manage to find all those bugs they missed.
2) Why do we sometimes find them so late.

Do you write test cases to kill time?

Mon, 08 Dec 2008 09:52:45 +0000

I wouldn’t believe myself until saw this really happening. Testers keep writing detailed test cases up-front with the primary goal to justify the time they spend early on the project. And right they are (are they?). At least they believe so. Managers see evidence that testers have red and understood all the requirements, covered them by test cases. Testers don’t have to think how to prove time spent on reviewing requirements even if they don’t find any issues there. And if developers delay a milestone we have more time to polish the test cases, do one more review or them, write more details, etc. Test lead doesn’t have to worry that on the next project testers will be added much later on the project schedule. Everything is fine but quality.