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!





Fundamentos do Teste de Software

28 09 2009

Há algum tempo venho pensando em escrever algo mais fundamentado aqui no blog. Hoje parei pra pensar, arrumei um tempo e resolvi falar sobre o capítulo 1 do Foundation Level Syllabus, material base pra certificação do ISTQB e BSTQB. É quase um resumão, às vezes com algumas considerações minhas imbutidas conforme minha experiência na área.

Este capítulo fala sobre os Fundamentos do Teste de Software.

Erro ao tentar finalizar uma transação importante!

Erro ao tentar finalizar uma transação importante!

Muitas pessoas devem se perguntar por que se faz necessário testes em software. Ora, devemos levar em consideração o contexto de cada software em desenvolvimento. Atualmente todos temos acesso a diferentes softwares diariamente. Em menor ou maior grau de dificuldade de uso, como por exemplo, aplicações bancárias, sejam elas acessadas pela web, celular ou caixa eletrônico. Você poderia imaginar o desastre se essas aplicações não fossem muito bem testadas? Você se sentiria seguro em realizar uma transação pela web? Bom, eu com certeza não. Outra aplicação que nos serve como exemplo, é o nosso querido Gmail. Bom, eu não vivo mais sem ele, e diferentemente do sistema bancário, eu não me preocupo muito em perder informações ali contidas (minha opinião tá, tem gente que tem muita coisa armazenada ali!!). Uma outra aplicação que considero importante de ser testada, são os sistemas de lojas e supermercados. Até hoje eu tenho o hábito de verificar os valores dos itens que estou comprando, porque não me sinto segura no sistema de barramento x valor do produto. Enfim, ema ema ema, cada um com seus problemas!! Esses exemplos servem pra mostrar que softwares que não funcionam corretamente podem trazer diversos prejuízos e grandes impactos para as pessoas e empresas que os utilizam.

Algumas causas dos problemas de software podem ser causadas por erros (enganos) humanos. O erro gera um defeito (bug) no software. E esse bug, gera uma falha no sistema. É atrás dessa falha que os testadores correm atrás (imaginei uma corrida de cachorros, onde eles correm em busca de um coelho, ou A recompensa).

Testadores atrás de um bug

Testadores atrás de um bug

Falhas podem ocorrer também, por eventos externos ao software, como quedas de luz, radiação, calor, poluição, campos magnéticos ou eletrônicos. Conheço um caso onde os servidores ficavam na mesma sala com 8 desenvolvedores, onde o ar condicionado no verão mal dava pra refrescar as pessoas. A temperatura da sala girava em torno dos 24 graus diariamente. Resultado disso: queda frequente do sistema, devido ao aquecimento das máquinas no ambiente.

Os testes têm funções específicas em cada fase do desenvolvimento e manutenção do software, e servem para reduzir os riscos de ocorrências de problemas no ambiente operacional, quando os defeitos encontrados são corrigidos em fase anterior a implantação na produção.

Qualidade em software implica em testes em todas as fases do desenvolvimento, desde o planejamento, através de testes na documentação, até a fase final do aceite do cliente. O teste ajuda a medir a qualidade em termos de defeitos encontrados por características e requisitos funcionais ou não funcionais do sistema. Os resultados da execução dos testes bem projetados pode representar a confiabilidade do software, quando poucos são os erros encontrados ou quando os mesmos são encontrados e corrigidos de forma efetiva.

Testes finalizados!

Testes finalizados!

E a pergunta que não quer calar é: quando devemos parar com os testes?

Bom, não se tem uma resposta padrão pra essa pergunta, porque tudo depende de cada projeto. Diversos são os fatores que podem definir quando parar-se de testar, como por exemplo: prazo, orçamento e riscos. É nesse sentido que os testes devem trazer informações suficientes para a tomada de decisão pelos stakeholders. Seus interesses são fundamentados nas limitações do projeto e, acredito eu, no grau de maturidade e qualidade do software desenvolvido. Para isso é que temos as versões beta, não é mesmo?