Building Better Software

Last week I attended ExpoQA International Conference on Software Testing & Software, in Madrid. There was a lot of very good presentations. Sorry that we can’t attend all of them.

The one that touched me more even wasn’t in the program. But due to a last hour cancelation it was replaced by a presentation by Paul Gerrard about Specification by Example and the Business Story method.

It is amazing when we understand how such a simple thing could resolve such a huge problem like requisite’s flaws.

Some time ago I wrote about these kind of flaws and how we could mitigate them. My theory was close to Business Story method.

The idea of writing Business Stories based on client’s requisites or specifications, describing and giving examples in a clear language, it is simple and powerful. When we send these stories to the client we got the client’s confirmation about the correct understanding about what the he wants.

Whenever I mention Development Team I mean a team of Analysts, Developers, Testers, Technical Writers and User Experience experts.

The truth is that a requisite’s flaw is, most of the times, a communication problem. It happens when the information flows across teams and loose a bit each time it is passed, or a team just didn’t have access to all information.

We all know that a requisite’s flaw is very expensive. This phase is the most expensive where it can happen.

Being a communication issue, why don’t we ever look for experts non IT to help us? An exper in Organizations, a Human Resources specialist, team managers and others, have skills to watch our Development team behavior, find the problems and propose changes.

Why aren’t these people evolved in the Software Development Process definition? Engineers are not the best people to do it, yet we can only fid them in these teams.

What I like most in Business Story method is the fact that it is neither an agile nor a conventional method. We can adapt it to any of them but it still is neither of them.

Another advantage is that the writing of Business Stories is a collaborative process, involving the entire development team.

With this method everyone is automatically informed. The fact that they receive a pack of requisites or specifications, discuss then e rewrite them, consolidates all data among team members. When the client confirms that is really what he wants everyone can start working. Business Analysts write more detailed documentation, programmers write code, testers write test cases while they wait for code to test. All of them have the same information and they are aligned with each other.

It is not necessary to follow a methodology to the letter, instead, we should adapt it to our company and our team, looking to improve our performance.

Construir melhor software


A semana passada estive na ExpoQA International Conference on Software Testing & Software, em Madrid. Assisti a apresentações muito boas. É pena não podermos assistir a todas.

A que mais mexeu comigo, nem sequer estava no programa. Devido a um cancelamento de última hora, foi substituída por uma apresentação do Paul Gerrard , sobre “Especificação com exemplos” (Specification by Example) e o método “Business Story”.

Surpreendente foi perceber como uma coisa tão simples podia resolver um problema tão grave como a falha nos requisitos.

Em tempos escrevi sobre essa falha e como poderia ser mitigada. A minha teoria aproximava-se um pouco do método “Business Story”.

A ideia de escrever “Business Stories” baseadas nos requisitos ou especificações feitas pelo cliente, descrevendo e exemplificando numa linguagem de fácil leitura, é simples e eficaz. Enviando essas “Business Stories” ao cliente, consegue-se uma confirmação da sua parte, do correto entendimento sobre o que pretende.

Sempre que falar em equipa de Desenvolvimento falo de uma equipa constituída por analistas, programadores, testers, especialistas de documentação e user experience.

Na verdade, o problema da falha de requisitos é, na maioria das vezes, um problema de comunicação. Acontece quando a informação é passada sequencialmente pelas equipas, perdendo-se algo pelo caminho, ou quando algumas equipas não recebem a totalidade da informação.

Todos sabemos que uma falha na fase de requisitos é muito cara. É nesta fase do processo de desenvolvimento de software que uma falha tem o custo mais elevado.

Sendo um problema de comunicação, porque é que nunca recorremos a especialistas não IT, para nos ajudar? Um psicólogo especialista em organizações, um gestor de recursos humanos, um gestor de equipas, um gestor de projetos ou outros, têm competências para observar o comportamento das equipas de Desenvolvimento, encontrar falhas e aconselhar alterações.

Porque é que na definição do processo de desenvolvimento de software da nossa empresa, não estão estas pessoas? Os engenheiros não são as melhores pessoas para o fazer, no entanto, só os encontramos a eles nestas equipas.

O que mais gosto no método Business Story é o facto de não ser um método ágil nem convencional. Pode ser adaptado a qualquer um deles, não sendo nenhum dos dois.

Outra vantagem é que a escrita das Business Stories ser um processo colaborativo, envolvendo toda a equipa de Desenvolvimento.

Com este método todas as pessoas ficam naturalmente informadas. O facto de receberem um conjunto de requisitos ou especificações, as discutirem em conjunto e as reescreverem, consolida a informação em todos os elementos da equipa. A confirmação por parte do cliente de que é efetivamente aquilo que pretende, dá o toque de partida para todos iniciarem as suas tarefas no processo de desenvolvimento. Os analistas escrevem os requisitos mais detalhados, os programadores avançam com a programação e os testers escrevem os seus testes, enquanto aguardam pelo código para testar. Todos têm a mesma informação e estão alinhados.

Não é necessário seguir uma metodologia à risca, em vez disso, devemos adapta-la à nossa empresa e à nossa equipa, procurando melhorar o nosso desempenho.



Have a break and think about your team.

Fill in the blanks

by Esther Derby
Fill in the blanks by Esther Derby #communication

via lubaia

What Can You Do About It?

by Catherine Powell

What Can You Do About It? by Catherine Powell #management

via lubaia

I imagined the future that I wanted and I started the construction

By José Baldaia

I imagined the future that I wanted and I started the construction by @jabaldaia

via lubaia

A Competent Tester

By John Stevenson

The expected result was 42. Now what was the test?: A Competent Tester

Via lubaia


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


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 by Ewald Roodenrijs

via Lubaia

Frontiers in Virtualization for Quality Assurance

By Cameron Laird

Frontiers in Virtualization for Quality Assurance by Cameron Laird

via Lubaia

How Google Tests Software – Part Six

by James Whittaker

The Life of an SET in Google by James Whittaker

via Lubaia

The Power of Personas in Exploratory Testing

By Janet Gregory

#testing news: The Power of Personas in Exploratory Testing

via testingref

The “One Team” defined as a gift economy

By Brian Marick

The “One Team” defined as a gift economy by Brian Marick

via Lubaia

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) #agile #testing #agiletesting

Via  la__steph

Agile Thinking instead of Agile Testing

by Joel Montvelisky

Agile Thinking instead of Agile Testing – #agile #testing #agiletesting

Via  la__steph

Acceptance tests are not enough!

by Anders Dinsen

Another good post from @andersdinsen “Acceptance tests are not enough!” #softwaretesting

via darren_mcmillan

Run, Run, as fast as you can…

by Rob Lambert

Run, Run, as fast as you can…..… via @Rob_Lambert

Via lubaia

Have a nice week!

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

Another week

Living on the Edge

By Reuven Cohen

RT @ruv: New Blog Post | Living on the Edge < Excellent, as always ! #cloud

Via fredberinger

Exploratory Testing is a pleonasm

By Aaron Hodder

AWGHodder New Blog Post: Exploratory Testing is a pleonasm: #softwaretesting #testing

Via mpkhosla

Don’t mess with team membership, redux

By Esther Derby

Posted: Don’t mess with team membership redux #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 #teams

via estherderby

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.


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

The Testing Planet

Last week I was unable to navigate on Twitter therefore I have no readings to share with you.
But nothing is lost because the third edition of The Testing Planet magazine is arrived.

You will find a variety of articles by Trish Khoo & James Martin, Robert Healy, Andréas Prins, Simon Morley, Peter Gregory, Steven Hedley, Gojko Adzic, Arik Aharoni, Sean P. Morley, John Stevenson and Luisa Baldaia. You can also find a book review by Phil Kirkham and, of course, the Cartoon Corner by Andy Glover.

The Testing Planet December 2010 – Issue 3 don’t miss it!

via Lubaia