Revizáo de testo praquê?

4 04 2014

Não, eu não estou assassinando a língua portuguesa. Sim, o título deste post está escrito erroneamente de propósito. Dói a vista não é? Você pode se perguntar, mas qual a relação disso com qualidade de software? Eu respondo: tudo a ver. A qualidade do seu software começa na escrita dos requisitos. Requisitos mal escritos podem gerar ambiguidade, dúvida e confusão na hora do desenvolvimento. Eu já peguei algumas documentações tão mal escritas que fiquei com “vergonha alheia”. Outro dia tava vendo uma apresentação no Slideshare, onde estava escrito no título de váaaaarios slides: ANDRIOD e não Android. Se você vai publicar sua apresentação na web (leia-se: TODO MUNDO VAI VER), pelamordedeus, revise!! Agora, veja esta imagem e me conte a sua opinião (clique na imagem para aumentá-la):

Muita preção!!

Muita preção!!

Achou o erro? E de quem você acha que foi o erro? Do analista de requisitos, do desenvolvedor, do testador ou do estagiário? Eu respondo: de nenhum deles! O erro está na falta de um processo de revisão. Eu já tive a oportunidade de trabalhar em projetos com a equipe era bem multidisciplinar. Tínhamos doutores e mestres em engenharia do conhecimento, administradores, especialistas em BI, desenvolvedores seniores, engenheiros de software E revisoras de texto! Sim, eram elas as responsáveis por revisar todos os documentos, desde contratos até essas mensagens de feedback para o usuário. Sentavam ao lado do desenvolvedor e faziam um trabalho de formiguinha, analisando cada mensagem de acordo com o contexto da tela. Aprendi com elas que a qualidade está nesses detalhes (saudade delas!!). E é o tipo de coisa que ninguém dá valor até encontrar um erro, como este ali de cima.

Daí você pode pensar: “ah mas eu não tenho um revisor na minha equipe e nem tenho dinheiro para investir nisso”. OK, acredito que isso possa sim acontecer, mas você tem os pares, você tem outros membros no time que podem fazer uma revisão com olhar mais crítico, o próprio QA tem a obrigação de primar pelos detalhes. Eu tive que fazer uma graduação em letras inglês pra descobrir que não sou fluente na minha própria língua mãe.

Tenho visto muitos blogs onde as pessoas apenas vomitam o que pensam, não se dão o trabalho de reler o que escrevem. Os pensamentos ficam soltos, sem coesão, sem conexão. Vão escrevendo como falam, não usam pontuação (eu já falei sobre isso em outro post), muito menos o corretor ortográfico. Gente, não custa nada você pedir pra alguém ler seu texto antes de publicar! Outro motivo que você pode pensar em me dizer é: “meu desenvolvimento é ágil, não tenho tempo pra revisão”. Helloooo, ágil não é sinônimo de desleixo!! Desleixo é deixar passar um “precione” na produção. Põe lá como tarefa da sprint: revisar mensagens de feedback; revisar escrita de histórias de usuário, revisar label dos botões. Faça da revisão uma tarefa!

E olha o que eu achei no jornal de hoje!

Precione!!

Precione!!

Outro exemplo de mensagem ambígua: Sim ou não O contexto da mensagem é o seguinte: um spam típico onde eu cliquei em descadastrar o e-mail. O meu desejo inicial era o de remover meu e-mail da lista, ou seja, cancelar o recebimento deles. Em momento algum eu cliquei em alterar configurações. Na mensagem de feedback eles misturaram as duas ações que eu poderia fazer e me deram duas opções: SIM ou NÃO. Daí eu fiquei pensando onde clicar: SIM, eu quero cancelar. NÃO, eu não quero alterar as configurações. Apesar da dúvida, cliquei no SIM, e para a minha surpresa, nova página com outras informações apareceram, para que eu então confirmasse o cancelamento. Gente, não tenho que dar satisfação do motivo pelo qual eu não quero receber algum e-mail, ainda mais quando é publicitário! Mas acreditem, eu tive que informar!! Mas penso que aqui essa enrolação é estratégica, pra fazer o usuário desistir do descadastramento. Mas eu fui até o fim!!

É aquele negócio, seja o exemplo, comece por você! Quem trabalha com qualidade deve ser exigente em todos os sentidos. Errar é humano, claro, mas seja humilde o suficiente para pedir ajuda, não há nada de errado nisso. Pra finalizar, um exemplo de mensagem de feedback para o usuário muito bem bolada. Era isso que as meninas da revisão faziam com as mensagens dos nossos produtos, tornando-as amigáveis e significativas!

Cool!!

Cool!!

Pense antes de escrever e revise o que escreveu! Isso serve pra qualquer área da sua vida: um e-mail, um recado, um post no blog ou até mesmo nas redes sociais, um caso de teste, um caso de uso, uma história de usuário. Lembre-se que o objetivo da comunicação é passar uma mensagem. Cabe a você garantir que o seu significado seja recebido pelo outro sem ruídos e interferências.

Agora, vou “precionar” vocês pra me darem uma opinião!





Verificação e validação nos modelos de melhoria de processo

28 02 2014

Em setembro do ano passado, “nasceu” um filho querido, metaforicamente falando. Meu artigo de conclusão da pós em Qualidade e engenharia de software foi publicado em uma revista nacional, a Engenharia de software, da Devmedia.

Este artigo apresenta a análise dos processos de verificação e validação, realizada numa instituição de pesquisa, desenvolvimento e inovação da região de Florianópolis, utilizando-se o mapeamento proposto pelo modelo de referência de processo de verificação e validação alinhado ao CMMI, MPS.BR e à norma ISO/IEC 15504. O resultado dessa análise é apresentado e melhorias no processo são propostas para implementação de V&V (verificação e validação) na instituição. Este artigo visa auxiliar as empresas a analisarem seus processos com vista a melhorias das práticas de verificação e validação que estejam em consonância com as normas e modelos de melhoria atualmente exigidos pelo mercado (CMMI, MPS.BR e à norma ISO/IEC 15504).

Mas por que eu o chamo de filho? Porque levei 9 meses para deixá-lo maduro o suficiente para que fosse publicado. O assunto abordado tem pouca aplicação no mercado, apenas empresas que buscam ou já possuem certificação realizam esses processos e por isso é um tema pouco discutido, se compararmos com testes de sistema (exploratórios ou automatizados). Mas nem por isso são de menor importância. Eu, particularmente, já peguei vários casos de uso mal escritos, sem regras de negócio, só com regras de tela. Na hora de testar você acaba levantando tantas perguntas que o analista se vê obrigado a refazer o caso de uso (retrabalho 1) e sobra pro desenvolvedor fazê-lo novamente (retrabalho 2). Esse é só um exemplo curto onde se vê que há 2 retrabalhos, que poderiam ter sido evitados caso houvesse uma etapa de revisão entre a especificação e o desenvolvimento. E todo mundo já sabe, quanto mais retrabalho, maior vai ficando o custo do projeto.

Quer saber mais? Acesse: http://www.devmedia.com.br/vv-nos-modelos-cmmi-mps-br-e-iso-iec/28937#ixzz2ue7MnTEA

Até mais! Vejo você no TDCFloripa 2014!

Já adiantando o próximo post: Submissão de Palestras TDC2014 Florianópolis





TDC 2012 Floripa

26 08 2012

Primeiramente quero agradecer aos coordenadores da trilha de testes, Elias Nogueira e Maira Stella da Silva, pela oportunidade (e desafio) que me deram para esta apresentação. Diferente de 2010, nesta edição a trilha de testes teve mais de 100 participantes, sala cheia!!! Muita emoção e responsabilidade! A audiência foi divina, o networking também! Tirando os atrasos nas apresentações (faz parte, faz parte), o evento no geral estava super organizado! Quem não foi, perdeu!!!

Aproveito pra disponibilizar minha apresentação. Fiquem à vontade para copiar, perguntar, criticar, elogiar!

http://prezi.com/eklptekaqv8g/melhoria-de-processo-ver-e-val-segundo-os-modelos-cmmi-mps-e-isoiec-15504/

E aqui você encontra todas as palestras da trilha:

http://www.thedevelopersconference.com.br/tdc/2012/florianopolis/trilha-testes#programacao

A fotinha da galera que fez tudo isso acontecer:

Até o próximo pessoal!