Readings

This week my reading went through the clouds. I read about its usefulness for testing and the problems we should be prepared to face.

Writing about testing was James Whittaker, who continues to explain how Google tests, and Janet Gregory brought back to life Exploratory Testing topic.

To close the week there is an interesting blog post about teams and communities.

Cloud cracks; break down or support 

by Ewald Roodenrijs

Cloud cracks; break down or support http://bit.ly/k0h7J8 by Ewald Roodenrijs

via Lubaia

Frontiers in Virtualization for Quality Assurance

By Cameron Laird

Frontiers in Virtualization for Quality Assurance http://t.co/qUzRCNf#testing by Cameron Laird

via Lubaia

How Google Tests Software – Part Six

by James Whittaker

The Life of an SET in Google http://j.mp/k6sLL9 by James Whittaker

via Lubaia

The Power of Personas in Exploratory Testing

By Janet Gregory

#testing news: The Power of Personas in Exploratory Testing http://bit.ly/kJvBnM

via testingref

The “One Team” defined as a gift economy

By Brian Marick

The “One Team” defined as a gift economy http://j.mp/mFvm53 by Brian Marick

via Lubaia

Advertisements

Back to Readings

This week I’m back to twitter and to reading.

I selected three blog posts about Agile, a special view about TDD evolution and about Leadership.

Enjoy reading.

Building an Agile test practice: Q&A with advocates for quality

By Matt Heusser

Building an Agile test practice: Q&A with advocates for quality by @mheusser #agiletesting #agile http://bit.ly/fUzR2m

Via CMLalle

The Evolution of Test Driven Developers

By Peter  Sellars

The Evolution of Test Driven Developers – http://www.catosplace.net/blogs/personal/?p=854

Via Lubaia

Test Leadership Lessons from Harry Potter

By Pete Walen

New Blog Post: Test Leadership Lessons from Harry Potter http://bit.ly/jm71K6 #leaders #testing #learning #sharing

via PeteWalen

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.

Agile week

This week I dedicated my readings to Agile Testing.

More and more articles are being written every day about Agile Testing what gives us some good insights.

And to relax, enjoy reading the adventures of a bug.

The Agile Tester

by  JoEllen Carter

“The Agile Tester” from JoEllen Carter (VersionOne) http://bit.ly/fvTKR4 #agile #testing #agiletesting

Via  la__steph


Agile Thinking instead of Agile Testing

by Joel Montvelisky

Agile Thinking instead of Agile Testing – http://bit.ly/gL76DB #agile #testing #agiletesting

Via  la__steph


Acceptance tests are not enough!

by Anders Dinsen

Another good post from @andersdinsen “Acceptance tests are not enough!” http://t.co/aD4O1Tf #softwaretesting

via darren_mcmillan


Run, Run, as fast as you can…

by Rob Lambert

Run, Run, as fast as you can….. thesocialtester.posterous.com/run-run-as-fas… via @Rob_Lambert

Via lubaia


Have a nice week!

Plenty of Reading

Shortening the feedback loop

by Lisa Crispin

Shortening the feedback loop http://j.mp/fnhYU7 by Lisa Crispin – Great!

Via lubaia


Still No Silver Bullets

By Esther Derby

Still No Silver Bullets http://estherderby.com/?p=1903 #agile

Via lubaia


Best practices for “Best practices”

By Markus Gärtner

New blog entry: Best practices for “Best practices”http://f.ast.ly/ppBw5

Via mgaertne


Refactoring and Redesign are Different

by Johanna Rothman

Refactoring and Redesign are Different http://s2etx.th8.us by Johanna Rothman #agile

Via lubaia


There are three main strategies when recruiting testers

By The Cartoon Tester

There are three main strategies when recruiting testers http://j.mp/hH01uv by The Cartoon Tester

via lubaia


My ABC’s of Agile

By Jason Novack

ABC’s of Agile http://j.mp/e3cmdJ by Jason Novack #agile

Via Lubaia


Don’t Test It #1 – Crisis In Production

By Eric Jacobson

Don’t Test It #1 – Crisis In Production http://j.mp/fPs5Ap by Eric Jacobson

Via Lubaia


Bugs that automated tests aren’t good at finding

By Bj Rollison

Bugs that automated tests aren’t good at finding http://j.mp/hyBhlM by Bj Rollison #softwaretesting #testing

Via lubaia

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.

Reading

Beyond Regression Tests

By Alan Page

#testing news: Beyond Regression Tests http://bit.ly/e95tqI

Via testingref


Social Networking and the Test Industry

By Sean P.Morley

The Testy Engineer: Social Networking and the Test Industry http://www.testyengineer.com/2010/11/social-networking-and-test-industry.html

Va lubaia

Coaching Testers Like My Uncle

By Eric Jacobson

Coaching Testers Like My Uncle Kev http://bit.ly/i6s6oC by Eric Jacobson

via lubaia

Another week

Living on the Edge

By Reuven Cohen

RT @ruv: New Blog Post | Living on the Edge http://ruv.net/a/mt < Excellent, as always ! #cloud

Via fredberinger


Exploratory Testing is a pleonasm

By Aaron Hodder

AWGHodder New Blog Post: Exploratory Testing is a pleonasm: http://bit.ly/foRQ4B #softwaretesting #testing

Via mpkhosla


Don’t mess with team membership, redux

By Esther Derby

Posted: Don’t mess with team membership redux http://bit.ly/gDB9Gj #management

via estherderby


One Issue – Two Sides: Safety and Trust

By Donald E. Gray

RT @donaldegray: Just posted: One Issue – Two Sides: Safety and Trust http://ping.fm/sMPZJ #teams

via estherderby

Gestão da Mudança

Como é que gere a mudança no seu projecto?

A mudança é uma das coisas mais difíceis de lidar durante um projecto. Existem várias razões para isso, não há recursos disponíveis, a calendarização do projecto não pode ser alterada, o orçamento é limitado, etc.

As pequenas mudanças são fáceis de implementar com pouco ou nenhum impacto na data de entrega do projecto. Mas quando o pedido de mudança se refere a um comportamento já desenvolvido, ou em desenvolvimento, o problema torna-se mais sério.

Os gestores de projecto têm três coisas que podem ajustar durante o ciclo de vida de um projecto. Quando recebem um pedido de mudança de abrangência do projecto, só têm duas alternativas: adicionam recursos ou adiam a data de entrega.

Como é que eles podem evitar ter que tomar estas decisões?

Como um exemplo, imagine que está a trabalhar num projecto para desenvolver uma aplicação Web para gerir um sistema de Qualidade. Terminado o planeamento, o gestor de projecto estará em condições de dar uma data de entrega ao cliente. O primeiro passo é planear! Sim, isso envolve muitos passos e não é o meu objectivo discuti-los agora. Mas a Gestão da Mudança começa aqui.

Suponha que o projecto tem seis iterações (ou Sprints), sendo os últimos dois para estabilização (entenda-se que não há linhas de código novo, apenas correcção de erros). Provavelmente, começará por definir a abrangência do projecto, definir requisitos, definir a arquitectura e desenho, antes de começar a programar e testar. Quanto mais avançado nas iterações estiver, mais complicado se torna a gestão da mudança.

Mas todos sabemos que as mudanças não se podem evitar, a não ser que queiramos entregar, ao cliente, um produto que já não é o que ele quer.

Agora suponha que a sua equipa já está a programar e que você descobre que, uma funcionalidade importante, não foi planeada. O motivo pode ter sido uma falha de visão na fase de desenho. Imagine que essa funcionalidade afectará o código já escrito. Entra em pânico? Não é necessário.

Neste cenário, uma de duas coisas podem acontecer. Se investiu bastante tempo na fase de desenho e definição de requisitos, então a probabilidade do cenário descrito ocorrer é muito baixa. Caso contrário, a probabilidade sobe. Para estar preparado para isto deve considerar algum tempo, no seu planeamento, que poderá usar, caso um cenário como esta aconteça.

Deve existir um equilíbrio entre o tempo que se investe no desenho e definição de requisitos, e o tempo reservado a falhas de desenho ou requisitos. Isso depende da complexidade da aplicação, a especialização dos analistas e programadores, da experiência em projectos similares, entre outras coisas.

Pela minha experiência, diria que muitos destes pedidos de mudança acontecerão durante os testes. Quando os testadores começam o seu trabalho, eles têm um produto, ou parte dele, para testar, e torna-se mais fácil ver algumas situações quando se tem um produto na mão. Os programadores não olharam da mesma forma. Outra razão para isto é a capacidade dos testadores de verem as coisas como programadores e utilizadores, simultaneamente. Por isso é tão importante envolver os testadores em todas as fases do processo de desenvolvimento. Eles são bons aliados dos analistas e programadores.

Considere, agora, outro cenário. Durante uma apresentação ao cliente, este decidiu incluir mais uma funcionalidade, ou alterar uma já existente, mas sem que isso altere a data de entrega. Vai trabalhar durante a noite? Como é que vai incluir mais esta funcionalidade se não tem mais recursos disponíveis?

É importante dar isto ao cliente, de outra forma ele irá receber um produto que já não é o que pretende.

Pode usar a mesma estratégia usada no primeiro cenário, ou melhora-la.

Antes de começar a planear, tente negociar com o cliente uma Caixa, que ele possa usar para adicionar ou alterar funcionalidade, durante o desenvolvimento do projecto. A Caixa pode ser uma quantidade de tempo, número de recursos, iterações extra, número de linhas de código, qualquer coisa que ambos possam medir. O cliente deverá estar disposto a pagar por isso, e você terá que incluir isso no seu planeamento.

O meu conselho é que deve contar com mudanças porque elas, de certeza, irão acontecer.

 

Change Management

How do you manage changes in your project?

The change is one of the most difficult things to deal with during a project. There are many reasons for this, you don’t have extra resources, the project timeline can not change, the budget is short, etc.

Small changes are easy to do with a few or no impact in project delivery. But when the requested change applies to a behaviour already developed or being developed, the problem becomes serious.

Project managers have three things they can change during a project life cycle. When they got a request to change the scope there are only two ways to go: add Resources or delay delivery date.

How can they avoid having to take such decisions?

As an example, imagine you are working in a project to develop a web application to manage a Quality System. After planning the project manager should be able to give a Ready To Market date to the stakeholders. The first step is to Plan! Yes, this involves a lot of steps and it is not my point to discuss it now. But Change Management starts right here.

Suppose your project has six iterations (or sprints), the last two spent in stabilization (meaning no more code only bug fixing).  You probably start by defining the scope of the project,  the requirements, architecture and design before you start coding and testing. The more advanced in iterations you are the more difficult is to manage the change.

But we all know that changes can’t be avoided, unless you prefer to delivery a product that is no longer what the client wants.

Now suppose your team is already coding and you find out that an important feature was not planned. The reason could be a missed point in design. Suppose this feature will affect the code already written. Panic? No need.

In this scenario two things might happen. If you spent a good time in design iteration, considering all conditions, then the probability to occur the scenario described is very low. Otherwise, the probability rises. To be prepared to this you should consider some time in your planning to use in case of a scenario like this occurs.

There should be a balance between the time consumed in design and requirements definition and the time reserved for design failures. This depends on the complexity of the application, the expertise of designers and developers, the experience in similar projects, the available resources, and the project budget, among others.

By my experience some of these change requests will happen during testing phase. When testers start working they have a product to test, or part of it, and it’s easier to see things when you have a product in your hands. Developers didn’t look at it the same way. Another reason is the ability a tester has to see things as a developer and as a user, at the same time. This is why it is so important to involve testers in all phases of developing process. They are good allies to analysts and developers.

Now consider another scenario. During a presentation of the application the client decided to include a new feature, or change an existent one, but he needs to keep the RTM date. Will you work during night? How can you add this new feature if you don’t have more available resources?

It is important to give this to the client, otherwise he will get a product that isn’t exactly what he would like to have.

You may use the same strategy of the first scenario or you may improve it.

Before you start planning try to negotiate with your client a Box that he might use to add or change features, during the project development. The Box can be an amount of time, number of resources, number of features, extra iterations, number of code lines, anything that you both can measure. The client must be able to pay for this and you have to include this in your planning.

My advice is that you should expect changes because they will happen for sure.