Estimating

How do we elaborate our estimations? Using intuition? Based on experience? Counting the number of code lines written?

A little of everything, I guess.

Having experience isn’t essential but it is a great help. And it doesn’t have to be testing experience.

For example, a person who knows the business where an application will be used can become a good tester. Typically, a professional accustomed to implement solutions in client has a user-side experience, which can make him a good tester.

Of course an experienced tester will make a deeper work in less time. Sometimes we believe that something works in a particular way but we can’t explain why we think it – we call it intuition. Intuition is based on personal experience.

The number of code lines written affects the time that will be needed to test? Not directly. We may assume that a large number of code lines represent more complex features, but the relationship is not proportional. This is not a good strategy to estimate.

Another possible strategy could be to create a test plan, detailed at test cases level or as a script. From this plan we estimate the time needed to run it.

Personally, I use a little of everything.

I start by reading the specifications and requirements of the new functionality. Whenever possible I take some time to think about the subject and let ideas get mature. I will not lose the chance to make questions and clarify doubts.

When I finally have a good idea of what is about, I start to think how I can test it. If the feature is intended to be integrated into an existing application, it is necessary to evaluate the impact on that application.

Only then I begin to add other things such as the team’s experience and technology involved. The search for historical data about testing similar features can help us to estimate, because we have an idea of the time used by then, as well as the quantity and type of flaws found.

Then we must think in non-functional tests, and evaluate their need. Performance tests, loading, installing, and others, can be time-consuming to run, so it is important to identify where we need them.

But after all, why we estimate? Because we want to know how much it will cost.

Well, normally we only need to do it if we are integrated in a project which purpose is to produce a quality product for a client. In these type of projects is fundamental to know two things: how much will cost and when will be finished.

However, there are other projects where the cost or time is not important. For example, when I have to purchase a tool and have to try it to check if it is what I need. In this case, the cost of doing this trial is not important, and the time it takes to do it, also doesn’t have much importance.

Another example, that is more obvious, it’s when I explore a tool, a Web site or any other application, out of curiosity. In this case, the tests will only stop when my curiosity is satisfied.

Estimates can be very fun. We should follow up doing an analysis of positive and negative deviations, after the task is finished. This way we are able to understand our insecurities and our certainties during estimation. Knowing our insecurities we can work to improve estimation.

Estimating is part of everyday life, only that we do not give account of this. Over the years we’re going to become more effective at this task.

When we are testing software we are more aware of what we’re doing, but the method that each of us holds, is similar to the one used in real life.

Estimativas

(português)

Como é que, nos Testes, elaboramos as nossas estimativas? Por intuição? Baseados na experiência? Pelo número de linhas de código escritas?

Um pouco de tudo, acho eu.

A experiência não é imprescindível, mas é uma grande ajuda. Mas não tem que ser experiência em testes.

Por exemplo, uma pessoa que conheça bem a área de negócio da aplicação, pode dar um bom tester dessa aplicação. Normalmente, um profissional habituado a implementar soluções no cliente, tem uma experiência do lado do utilizador, que pode fazer dele um bom tester.

Naturalmente que um tester experiente fará um trabalho mais profundo em menos tempo. A intuição baseia-se na experiência pessoal. Achamos que uma coisa é de determinada forma, mas não sabemos explicar porque achamos isso – chamamos-lhe intuição.

E o número de linhas de código afecta, de alguma forma, o tempo que será necessário para testar? Directamente, não. Em princípio, um elevado número de linhas de código representam funcionalidades mais complexas, mas a relação não é proporcional. Este não é um bom critério para estimar.

Uma estratégia possível, pode ser criar um plano de testes, detalhado ao nível de casos de teste, ou na forma de um guião. A partir desse plano estimamos o tempo necessário para o executar.

Pessoalmente, uso um pouco de tudo.

Começo por ler as especificações e requisitos da nova funcionalidade. Se possível, aguardo algum tempo, enquanto vou pensando sobre o assunto e deixando amadurecer os conceitos. Existindo a possibilidade, não deixo de fazer perguntas e esclarecer dúvidas.

Quando já tenho uma boa ideia do que se trata, começo a pensar como se pode testar. Se a funcionalidade se destina a ser integrada numa aplicação já existente, é necessário avaliar o impacto na aplicação.

Só depois começo a juntar outras coisas, tais como, experiência da equipa e tecnologia envolvida. A procura de dados históricos, sobre testes a funcionalidades semelhantes, pode ajudar a estimar, porque conseguimos ter uma ideia do tempo utilizado, assim como da quantidade e tipo de falhas encontrado, na altura.

Depois é necessário pensar nos testes não funcionais e avaliar a sua necessidade. Testes de performance, de carga, de instalação e outros, podem ser demorados a executar, por isso é importante identificar bem a necessidade deles.

Mas afinal, porque é que temos que estimar? Porque queremos saber quanto vai custar.

Bem, normalmente só o precisamos de fazer se estamos integrados num projecto que tem, como objectivo, produzir um produto com qualidade para um cliente. Neste tipo de projecto é fundamental saber duas coisas: quanto custa e quando vai estar finalizado.

Porem, existem outros projectos em que o custo ou o tempo não são importantes. Por exemplo, quando tenho que adquirir uma ferramenta e tenho que experimenta-la para saber se dá resposta ao que necessito. Neste caso, os custos de fazer essa experimentação não são importantes, e o tempo que demora a fazê-lo, também não tem muita importância, desde que não ultrapasse um limite considerado razoável. Outro exemplo, ainda mais claro, é quando eu exploro uma ferramenta, um site ou qualquer outra aplicação, por curiosidade. Neste caso, os testes só param quando a minha curiosidade está satisfeita.

As estimativas podem ser um exercício muito divertido. Devemos dar seguimento a esse exercício, fazendo uma análise dos desvios positivos e negativos, após a execução do trabalho. Desta forma, conseguimos perceber exactamente quais as nossas inseguranças e quais as nossas certezas, no momento de estimar. Conhecendo as nossas inseguranças, podemos trabalhar para melhorar as estimativas.

Estimar faz parte do nosso dia-a-dia, só que não damos conta disso. Com o passar dos anos vamo-nos tornando mais eficazes nessa tarefa.

Nos testes de software tomamos mais consciência do que estamos a fazer, mas o método que cada um de nós aplica, é semelhante ao utilizado na vida real.

Advertisements

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