When the requirements fail

Did it ever happen to you to get a work and after reading the requirements realize that they do not serve?

It happened to me.

When we got a new task to test an application, or a new feature,  we start by getting to know the purpose of it. Then we read all documentation and detailed requisites. It is at this point we find possible flaws.

How does this happen? This is an interesting point – how and when we realize that something is wrong?

The first thing a tester does is to try to understand what is the purpose of it and the motivations behind it, only then starts to know about how it was done, or will be done. Immediately he starts imagine scenarios, putting questions and firing a lot of ‘What if’s.

Normally,  a Tester only goes forward on Planning and Test Execution, if he doesn’t find any problem during this first step. Sometimes it is not possible to get an answer and it is necessary to move on with some tests to get it.

I believe this skill is stronger in a Tester than in a Programmer. The Programmer is focuses in analysis and programming.

In the same way the Tester’s brain triggers thousand of test cases, trying to figure how the application will react to it, the brain of a Programmer triggers functions, procedures and how to link them, trying to find an opportunity to create a new class.

Both brains react immediately to the requisites reading. But it works in a different way to each of them, Testers and Programmers. Each one focuses on its own area. The availability of each one is different.

I think this is a major difference between a Tester and a Programmer, the willingness to find the error.

For this reason I have argued that Testers should be involved in requisites definition, although on a consultant role.

The sooner Testers are involved in the process the sooner we will find the weaknesses in the design.

Quando os requisitos falham

(português)

Já alguma vez vos aconteceu receberem um trabalho e, ao lerem os requisitos, perceberem que estes não servem?

A mim, já.

Quando recebemos um trabalho, começamos por conhecer os objectivos da nova funcionalidade ou produto. A seguir, passamos para a leitura da descrição e dos requisitos detalhados. É nessa altura que nos apercebemos de possíveis falhas graves.

Como é que essa descoberta aparece? Esse é o aspecto interessante, quando e como é que percebemos que algo não está bem?

A primeira coisa que um tester faz, quando inicia um trabalho, é perceber qual o propósito da funcionalidade e quais as suas motivações, e só depois começa a informar-se sobre o solução que foi desenvolvida, ou proposta. Imediatamente começa a desenhar cenários, a colocar questões, e a lançar uma imensidão de ‘E se ..:’ .

Um tester só passa às fases seguintes, de planeamento, preparação e execução de testes, se nesta fase não perceber nenhum problema sério escondido. Por vezes, as questões levantadas não são de resposta imediata e será necessário avançar com alguns testes para encontrar as respostas.

Penso que esta capacidade está mais desenvolvida num tester do que num programador. O programador tem o focus na análise e programação. Da mesma forma que o cérebro do tester dispara multiplos cenários de utilização, tentando perceber a reacção da solução implementada, ou a implementar, o cérebro do programador dispara procedimentos, funções e a forma de os integrar, tentando perceber onde existe lugar para a criação de classes.

Enfim, o nosso cérebro reage imediatamente no momento da leitura de requisitos. Mas em cada um de nós, testers e programadores, de uma forma diferente. Cada um focado na sua área de intervenção. A disponibilidade de cada um é diferente.

Penso que esta é uma grande diferença entre o programador e o tester, a disponibilidade para encontrar o erro.

Por esta razão, tenho defendido que os testers devem ser envolvidos na fase de definição de requisitos, embora como consultores.

Quanto mais cedo se envolver um tester no processo,  mais cedo se encontrarão as fraquezas.

Advertisements

One thought on “When the requirements fail

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s