Test day

[Rafael Reggiani Manzo]

Olá a todos,

Terça ocorreu o Test day no Mezuro. Como era de se esperar, a equipe respondeu muito positivamente sobre ele, inclusive questionando a possibilidade de repetir.

Para mim é bem claro o valor dessa prática para o time. Mas eu quero levantar a discussão com todos sobre em que medida essa prática é positiva para o cliente. Afinal, além de a equipe poder ser mais feliz, um dos objetivos de XP também é a satisfação do cliente.

Qual a opinião de vocês?

Abraços,

Manzo.

[Paulo Meirelles]

A opinião de um dos clientes é que "teste é vida" \o/

--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

[Monna Cleide]

Acho que isso é meio relativo. (como tudo na vida, mas ok)

Pra clientes técnicos, que entendem do assunto, mostrar as baterias de teste e um índice de cobertura vai deixar ele dando pulinhos de alegria (se estiver satisfatório, claro =P). Mas sempre tenho a péssima sensação de que, lá fora, um cliente "comum" diria algo do tipo "Como assim, Test Day? Passaram um dia inteiro sem fazer nada? Vocês não disseram que estava testado antes? Por que passaram um dia inteiro testando de novo então?".

Pensando que o caso de vocês seja um cliente "mais ou menos", que tem um bom conhecimento técnico mas limita isso por causa do papel, talvez fosse interessante apresentar isso mostrando rapidamente o que foi feito (a parte técnica, que testes, quanto tempo, enfim, o que vocês acharem relevante), e focando mais em como isso deixa o produto dele mais estável e robusto.

Fico feliz do Test Day ter dado certo pra vocês :) Nós aqui do Games estamos numa etapa anterior muito dolorosa, que é a de implementar as plataformas novas de testes...

Att

--

Atenciosamente,
Monna Cleide Santos
Engenheira de Computação
Mestranda em Ciência da Computação - IME-USP
Tel.: (11) 9.8852-3116

[Paulo Meirelles]

Em 9 de maio de 2013 00:33, Monna Cleide <mon...@gmail.com> escreveu:

Acho que isso é meio relativo. (como tudo na vida, mas ok)

Contextualizando a "piadinha": eu sou um dos clientes do Mezuro ;)

[Graziela Simone Tonin]

Adicionando ao que o pessoal falou...se você 'vender' isso para o cliente como qualidade, garantia de qualidade e explicar que isso poderá evitar problemas e dores de cabeça futuras, podendo diminuir o custo de manutenção e futuras necessidades de alterações, acho que o cliente pode ficar bem feliz com a ideia.

abs

 

Graziela Simone Tonin, Msc

Phd Student at USP

CSM,CSPO

 +55 11 5486 8466

Skype: gttonin

Msn: gto...@gmail.com

Twitter: gtonin

Se você não conduzir a sua vida, alguém o fará por você.

[Alfredo Goldman]

Olá Pessoal,

   Isso aí, testes são essenciais, e agora a analogia com dívida ajuda muito a explicar a importância de testes automatizados. :)

Abraço,

Alfredo

[Higor Amario de Souza]

Independente de o cliente ficar contente ou ser indiferente aos testes, eles são importantes pra validar o código e melhorar sua qualidade. Mesmo que o cliente não perceba, isso vai refletir no custo de manutenção ao longo do projeto. Além disso, os testes ajudam a compreender melhor o que está sendo desenvolvido.

[]s

--
Até a próxima,
Higor.

[Vinicius Pinheiro]

Discussão interessante.

Primeiramente, é bom ressaltar que testes em si não é algo exclusivo de XP ou programação ágil. Até o famigerado modelo em cascata original está definida a fase de testes e verificação. Então, um cliente que não é familiar com a idéia de testes é algo incomum. A idéia de XP é permear o desenvolvimento com testes, ou seja, testes não servem só para testar mas também funcionam quase como um auxílio ao desenvolvimento (lembrem de TDD). Agora, cabe à equipe saber argumentar com o cliente (se necessário) o porque de dedicar um dia inteiro à testes ou à refatoração. Isso varia muito de cliente para cliente, desde os mais técnicos aos mais burocráticos como já foi discutido aqui. Na maior parte dos casos, porém, o que conta é o resultado final. Ou seja, se a equipe souber aproveitar o test day, ao final da iteração o código estará mais funcional, com menos erros e mais fácil de manter. Tudo isso implica em qualidade de software e consequentemente, em cliente feliz. :)

Vinicius

[Alfredo Goldman]

Olá Pessoal,

   Apenas para continuar um pouco mais, acho muito fácil de defender a necessidade de testes automatizados em

um projeto. Por outro lado, nem sempre fica clara a necessidade de refatoração para o cliente. Mais do que isso,

ao querer um código extremamente organizado, os programadores podem cair em um "sucesso técnico" sem que

isto reflita diretamente em valor para o cliente.

   Concluindo, para qualidade de software é sempre bom saber o que é "good enough".

Abraço,

Alfredo

[Rafael Reggiani Manzo]

De fato, eu concordo com todos: testes são vida e devemos argumentar com o cliente em favor de práticas como o Test Day, especialmente quando nosso cliente não é técnico.

Se vocês estiverem dispostos a prolongar um pouco o tema, eu quero também discutir esses argumentos. Claro vai variar de cliente para cliente e o contexto de cada projeto.

Partindo do pressuposto que o cliente entende a importância dos testes e topou a experiência de uma vez dedicar um dia para testes como experiência, como eu exponho os pontos positivos para ele? Eu quero dizer que, para nós que estamos envolvidos com isso diariamente parecem óbvios os benefícios, porém para outras pessoas isso pode não ser tão imediato.

[Rafael Reggiani Manzo]

Eu estava escrevendo o outro email quando o professor Alfredo enviou o dele :)

Acho que o que escrevi tem totalmente a ver com o que ele escreveu. E o termo que ele usou de "good enough" me lembrou do texto que o Alessandro enviou na lista geral: http://dreamsongs.com/RiseOfWorseIsBetter.html