When you install Enterprise Tester you’re asked to…

When you install Enterprise Tester you’re asked to create an administrator account. This is the first step into security.
The security system isn’t complex and gets simple to implement.
You have Groups of users and Users. Permissions are define by Group.
Users are independent from projects. instead you assign a User to projects – like in real life.
You can define permissions to all tasks in your team. To people who writes test scripts, the ones that manage iterations, the ones that execute and, very important, the ones that read your test scripts.
Although some of you think that writing test scripts is a waste of time and that you get more results if you spent that time testing, I think test scripts can be useful.
Like everything else in life, there must be a balance between what you write and what you get in return. When I write test scripts, I don’t get in too many details, I don’t describe every little steps. I try to describe what to do and spent more time describing what to check (I wrote check, not test !) to get it useful to others.
I think our test scripts are part of the product documentation. This is why, in Enterprise Tester, we have to create a Group of Users that will not write nor execute tests but will read tests.


Don’t Be Perfect

By Cameron Laird

Nice #dev | Don’t Be Perfect http://ow.ly/532PL

via Tordf

Tales from the trenches: Essential test case design

by Darren McMillan

Blogged: “Tales from the trenches: Essential test case design” http://bit.ly/jk7GlA #softwaretesting #qa #testing

Via darren_mcmillan 

Testers!! know your Business (& don’t do that of others!)

By Joel Montvelisky

Posted: Testers!! know your Business (& don’t do that of others!)http://bit.ly/kyNBdn based on feedback by @jerryweinberg to an old post

Via joelmonte

Agile Brings Changes to Key Roles and Responsibilities

By Dave Moran

Posted: Agile Brings Changes to Key Roles and Responsibilities http://tinyurl.com/3rk5fks #Agile #pmiagile

via wvanrheenen


Bug statistics are a waste of time

By Gojko Adzic

 new blog post: bug statistics are a waste of time http://bit.ly/ixnScj #agile #testing

via gojkoadzic

Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks

By Mike Kuphal

Blogged: Agile Planning: My Top Five Tips on Decomposing User Stories Into Tasks http://bit.ly/lSvXLH #Scrum #Agile #PMOT
via mkuphal

Does ATDD = Waterfall?

By Adam Yuret

Fantastic post! RT @AdamYuret New post: Does #ATDD = Waterfall? http://bit.ly/iGAQei #softwaretesting

via darren_mcmillan

Revisited – Test Strategy

By Fiona Charles

 Just published: Basics Revisited – Test Strategy http://tinyurl.com/3k3qyx5 & http://tinyurl.com/3b62j5c #testing #softwaretesting

via FionaCCharles

Testers are fixing bugs!

By Trish Khoo

 Blogged: Testers are fixing bugs! trishkhoo.com/?p=327

via hogfish

A Fair Witness

By Pete Houghton

 Nice post RT @pete_houghton: New blog post “A Fair Witness” http://bit.ly/jkYSbh #testing #softwaretesting

via adampknight

I’m part of the ‘Now Generation’

By Ewald Roodenrijs

 New blog post “I’m part of the ‘Now Generation’”: http://bit.ly/kEQGUi #testing

via ewaldroodenrijs


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.



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.

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


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.


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

Weekend readings

The ATDD Arch

By Elisabeth Hendrickson

Blogged: The ATDD Arch. http://bit.ly/atddarch

Via testobsessed

Introduction to Cloud Testing

By Fred Beringer

Introduction to Cloud Testing | Fred Beringer http://www.fredberinger.com/introduction-to-cloud-testing/ via @fredberinger

Via lubaia


By James Bach

The Basic Idea of Context Driven Testing – http://www.satisfice.com/blog/archives/565 by @jamesmarcusbach (I’m in!)

Via jlottosen


For each requirement ...

Before programmers start their work the testers begin planning tests. It is important that we do so at this stage to be able to detect flaws in requirements and analysis. The testers are experts in their field of business, and this gives them a different view of the changes being developed. Programmers are more knowledgeable of the product at the point of view of structure and architecture.

Today I can begin to review the requirements, analyze in detail what will be doing and draw a test plan. For each requirement I will create one or more test cases. The tests that I run are not limited to written test cases, go beyond that.  In fact, test cases guide us in testing, they are a starting point. Some of the test cases I write will be used by programmers to perform unit tests.

Another important aspect is automating tests. I will have to choose what to automate. The selection depends on the complexity, how critical is the functionality and ability to be automated. I know that everything can be automated but cost varies and it is an important criterion that weighs on the decision to automate.

In the next few hours I will come to me with some doubts that I will have to clarify with the Product Manager. Depending on complexity of the Change Set, some meetings are organized in order to clarify doubts about the new functionality. Testers, Developers,  Technical Documenters and the Product Manager, all attend to these meetings. Anyway, the communication between the various people involved in the process is continuous.

Any defects found are recorded on a tool developed internally. Everyone access this tool and every defect can be monitored. It is possible to know at any moment in what state a defect is, who will fix it, who will test it, the expected date of resolution, etc. The whole story is transparent to everyone. This way each one has the responsibility for monitoring the corrective tasks to which is responsible.

During testing phase requirements changes may occur. For example, a defect can lead to a change of requirements. These changes can be treated in time, when they are simple, or when they imply significant changes, lead to other Change Sets.

This is the begining of testing phase.

Read last week

Lost in the weeds

By Alan Page

New blog post: http://tinyurl.com/4hqx78a – Lost in the weeds

via alanpage

How Google Tests Software – Part Two

By James Whittaker

How Google Tests Software – Part Two http://bit.ly/eubFbQ #softwaretesting

via fredberinger

Believing you don’t know

By Pete Houghton

Enjoyed this article RT @pete_houghton: New Blog post: “Believing you don’t know” http://t.co/OsM2HkC #softwaretesting #testing #qa

via brownie490

Mending broken windows

By Michael Johnston

New blog post: “Mending broken windows” http://bit.ly/hZzBWO #softwaretesting #testing #qa contributed by @lilmarshmallow

via Darren_mcmillan

The rise of continuous application

By Michael Vizard

The rise of continuous application #testing http://ow.ly/3TMCz #softwaretesting #agile

via fredberinger

Testing and reading

Test Design for everyone

By Alan Page

#QATips: Very nice set of slides by @alanpage, simple & straightforward. Test Design 4 Everyone http://wfapm.com/fUUE4l #qa #softwaretesting

Via jayphilips

It’s… thinking thursday

By Zeger Van Hese

Blogged – my response to @michaelbolton’s Thinking Thursday tweet http://bit.ly/hcm3cz #speedblogging #testing#softwaretesting

Via TestSideStory

Are testers’ethnographic researchers?
By  John Stevenson

New Blog Post:- Are testers’ ethnographic researchers? http://bit.ly/hmY91i #testing #qa #softwaretesting

via steveo1967

Motivation and Passion, or, Don’t Harsh My Testing Buzz

By Pete Walen

RT @darren_mcmillan: @PeteWalen “Motivation and Passion, or, Don’t Harsh My Testing Buzz” http://bit.ly/ibDf0t #softwaretesting#testing #qa

Via shillu13

Man’s capacity for error

By Sean P. Morley

Enjoyed reading “Man’s capacity for error” http://bit.ly/hDHW52#softwaretesting #testing #qa

Via darren_mcmillan