Don’t Be Perfect

By Cameron Laird

Nice #dev | Don’t Be Perfect

via Tordf

Tales from the trenches: Essential test case design

by Darren McMillan

Blogged: “Tales from the trenches: Essential test case design” #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!) 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 #Agile #pmiagile

via wvanrheenen


Plenty of Reading

Shortening the feedback loop

by Lisa Crispin

Shortening the feedback loop by Lisa Crispin – Great!

Via lubaia

Still No Silver Bullets

By Esther Derby

Still No Silver Bullets #agile

Via lubaia

Best practices for “Best practices”

By Markus Gärtner

New blog entry: Best practices for “Best practices”

Via mgaertne

Refactoring and Redesign are Different

by Johanna Rothman

Refactoring and Redesign are Different 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 by The Cartoon Tester

via lubaia

My ABC’s of Agile

By Jason Novack

ABC’s of Agile 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 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 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


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

Via testingref

Social Networking and the Test Industry

By Sean P.Morley

The Testy Engineer: Social Networking and the Test Industry

Va lubaia

Coaching Testers Like My Uncle

By Eric Jacobson

Coaching Testers Like My Uncle Kev by Eric Jacobson

via lubaia


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.

Reading About Testing and QA

The explicit role of #testing and testers in agile projects

By Sander Hoogendoorn

#QATips: The explicit role of #testing and testers in #agile projects #qa

via jayphilips

How Google Tests Software – Part Three

By James Whittaker

Testing and Development – who owns quality ?

via Lubaia

The one that got away

By Alan Page

A software bug that escaped #testing and found its way into customer’s hands — by @alanpage #softwaretesting

via NaomiKarten

The Darker Side of Metrics

By Douglas Hoffman

There are many great papers on #metrics. Doug Hoffman’s “Darker Side of Metrics” provides insight on behavior. #testing

via lynn_mckee

Testing cloud applications; testing business technology

By Ewald Roodenrijs

RT @ewaldroodenrijs New blog post “Testing cloud applications; testing business technology”: #softwaretesting #cloud

via AndreasPrins

Read last week

Lost in the weeds

By Alan Page

New blog post: – Lost in the weeds

via alanpage

How Google Tests Software – Part Two

By James Whittaker

How Google Tests Software – Part Two #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” #softwaretesting #testing #qa

via brownie490

Mending broken windows

By Michael Johnston

New blog post: “Mending broken windows” #softwaretesting #testing #qa contributed by @lilmarshmallow

via Darren_mcmillan

The rise of continuous application

By Michael Vizard

The rise of continuous application #testing #softwaretesting #agile

via fredberinger

Last week readings

A journey in Advocacy
By Lynn McKee

RT @lynn_mckee: My Journey in Advocating for Software Testing #testing #management #advocacy

Via gilbroza

I hate pair programming (and your code and you)

By David J Bland

Interesting #dev read | I hate pair programming (and your code and you)

via Tordf

How Google Tests Software

Via James Whittaker

How Google Tests Software (from J.Whittaker)

via fredberinger

Duplication between BDD and Unit Tests

By  Gojko Adzic

RT @gojkoadzic: new blog post: duplication between unit tests and bdd tests #tdd #agiletesting #bdd #cucumber

via gregmoeck

No Agile Gospel please, just give me Enlightenment

By Martijn Linssen

RT @MartijnLinssen: @stevedenning @fredsheahan @Jabaldaia @ralph_ohr My PoV on #Agile:

Via Ralph_ohr

Testing and reading

Test Design for everyone

By Alan Page

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

Via jayphilips

It’s… thinking thursday

By Zeger Van Hese

Blogged – my response to @michaelbolton’s Thinking Thursday tweet #speedblogging #testing#softwaretesting

Via TestSideStory

Are testers’ethnographic researchers?
By  John Stevenson

New Blog Post:- Are testers’ ethnographic researchers? #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” #softwaretesting#testing #qa

Via shillu13

Man’s capacity for error

By Sean P. Morley

Enjoyed reading “Man’s capacity for error” #testing #qa

Via darren_mcmillan

New year readings

Cloud Testing: Trends & Challenges

by Shilpa Venkateshwaran

Thanks @darren_mcmillan Commented @shillu13 #Cloud #Testing: Trends & Challenges #softwaretesting #QA

via shillu13

Panic testing …

by Peter Haworth-Langford

New Blog Post: Panic Testing…

via Unlicensed2test

Scrooge The Tester

by Philk

#QATips: Scrooge the #Tester visited by ghosts of releases past, current & future via @pkirkham #softwaretesting #qa

via jayphilips

Sailing the Seas of B’s

by Adam Yuret

Commented (pending approval) RT @AdamYuret New voyage posted on Sailing the Seas of B’s. Quality Advocate:My philosophy

via darren_mcmillan

My prediction for 2011 – The tipping point for Cloud Testing

by Fred Beringer

New blog post: My prediction for 2011 – The tipping point for #Cloud #Testing #softwaretesting

via fredberinger

You are a Leader

By Michael Norton

Doc On Dev: You are a Leader

via Lubaia

Agile Programs Require Agile Teams, Up, Down, Sideways

by Johanna Rothman

Agile Programs Require Agile Teams, Up, Down, Sideways

via Lubaia