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

(português)

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.

Advertisements

Readings

Have a break and think about your team.

Fill in the blanks

by Esther Derby
Fill in the blanks http://j.mp/k985Mn by Esther Derby #communication

via lubaia

What Can You Do About It?

by Catherine Powell

What Can You Do About It? http://j.mp/l1Lywi 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 http://j.mp/mLFp9H by @jabaldaia

via lubaia

A Competent Tester

By John Stevenson

The expected result was 42. Now what was the test?: A Competent Tester http://t.co/ICwkjTy

Via lubaia

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

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

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.

 

Great readings

Communicating Testing using Visuals

By Rob Lambert

Communicating Testing using Visuals http://post.ly/1Ypxd

via Rob_Lambert


The Checklist Is Not the Purpose

By Catherine Powell

The Checklist Is Not the Purpose http://bit.ly/gnZvn8 by Catherine Powell

via Lubaia


Pair programming research misses the most important point

by Johannes Brodwall

Pair programming research is flawed by @jhannes: http://bit.ly/fxcklR

via smalltalk80


One Test Per Requirement

by Michael Bolton

Possibly my shortest-ever blog post: One Test Per Requirement.http://bit.ly/h4m371 #testing #agile #softwaretesting #qa

Via michaelbolton


Pairing is Conversation

By Michael Norton

Doc On Dev: Pairing is Conversation http://www.docondev.com/2011/02/pairing-is-conversation.html?spref=tw

Via Lubaia


Usability Testing with my Mortgage Adviser?

By Adam Brown

RT @brownie490: Blog post: Usability Testing with my Mortgage Adviser? http://bit.ly/f01QL5 #softwaretesting #testing #qa

via Lubaia

New year readings

Cloud Testing: Trends & Challenges

by Shilpa Venkateshwaran

Thanks @darren_mcmillan Commented @shillu13 #Cloud #Testing: Trends & Challenges http://bit.ly/ePaT08 #softwaretesting #QA

via shillu13


Panic testing …

by Peter Haworth-Langford

New Blog Post: Panic Testing… http://bit.ly/htgO8e

via Unlicensed2test


Scrooge The Tester

by Philk

#QATips: Scrooge the #Tester visited by ghosts of releases past, current & future http://wfapm.com/gNZP0X 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 http://bit.ly/gcEtPX

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 http://ow.ly/3wcvT #softwaretesting

via fredberinger


You are a Leader

By Michael Norton

Doc On Dev: You are a Leader http://bit.ly/hXVTt4

via Lubaia


Agile Programs Require Agile Teams, Up, Down, Sideways

by Johanna Rothman

Agile Programs Require Agile Teams, Up, Down, Sideways http://cw49e.th8.us

via Lubaia


Last week …

 
Dispersed vs. Distributed Teams

An interesting point of view.

Dispersed vs. Distributed Teams, http://ping.fm/yZf1Y

via johannarothman


You’re a Tester, Relax

Don’t miss it

A splendid blog post from Eric Jacobson on what things a tester shouldn’t worry about: http://bit.ly/ceOTsN #testing #softwaretesting #qa

via michaelbolton


Test Case 001: Count passes made by white team.

Good point!

RT @testingexplorer: What were your actual results from executing Test Case 001 from the Test Specification Document http://goo.gl/GsOI

via charrett


Curing System Blindness

Curing System Blindness by Esther Derby http://bit.ly/c415WM

via Lubaia


Help! Cloud-Enabled Testing Services

Talking about the future

New blog post “Help! Help! Cloud-Enabled testing Services”: http://bit.ly/a65s4t #softwaretesting #clouds

via ewaldroodenrijs


If you’re going to write-down just one test case…

It’s never too much to say

After a couple of weeks of absence from the blogsphere – posted “If you are going to write only one test case…” – http://ht.ly/326nw

via joelmonte

 

When to STOP Automation

 Always a good place to find great readings Software Testing Club 

 Follow the discussion about Automation http://bit.ly/dCUOW4 in Software #Testing Club



via Lubaia