10 principais lições em Teste de Software

 

“Lessons Learned in Software Testing” é um livro. Um excelente livro!

Escrito pelos gurus do teste James Bach, Cem Kaner e Bret Pettichord, é uma coleção de 293 lições - fragmentos de sabedoria, grandes e pequenos. Escrito em 2002, ainda é muito relevante hoje (talvez com pequenas exceções, como a Lição # 266 - Aprenda Perl).

Neste artigo, apresento a vocês minhas 10 lições favoritas. Elas não são classificadas na ordem de "qual gosto mais". Em vez disso, elas seguem uma ordem cronológica aproximada de como fazemos as coisas como profissionais de QA em um novo projeto.

 

1. Conheça os programadores que lerão seus relatórios

Lição #91. O que você faz nas primeiras semanas em um novo projeto com novos stakeholders - gerentes, analistas e, o mais importante - desenvolvedores?

Você tem a oportunidade de conhecer eles ! E você faz isso sempre que pode.

O software é construído por seres humanos, e eles têm a tendência de responder às suas perguntas, "dando um retorno pra você" por e-mails rápidos e, em geral, sendo mais cooperativos se tivessem uns bate-papos informais com você sobre a vida em geral.

 

Você deixa de ser um nome ou um texto sem vida por trás de um e-mail, que sempre chega para irritar eles por exigir algo. Em vez disso, você passa a ser aquela pessoa que também gosta de montanhismo, de quem eles riram de uma piada ou com quem eles tiveram uma conversa agradável. A cooperação recebe um aumento de 1000%! (valor obtido através de uma medida cientificamente precisa). Além disso, também isso também te ajudará a escrever e-mails e relatórios corteses e bem redigidos.

Isso é uma rua de mão dupla e vocês tendem a se ver como seres humanos falíveis tentando fazer um bom trabalho, em vez de idiotas incompetentes.

2. Encontre bugs importantes rapidamente

Lição #5. OK, então você conheceu pessoas e agora é hora de começar a trabalhar. E sim, você tem que começar a correr como de costume. Eu não ouvi muitas histórias em que novos ingressantes têm bastante tempo para lentamente se tornarem mais habilitados para o trabalho.

Você leu toda a documentação e recursos internos possíveis, já se familiarizou com o sistema até certo ponto e a nova versão foi lançada e precisa ser testada. Dado relativamente pouco conhecimento (você ainda é novo) e restrições de tempo, como fazer isso?

Uma imagem vale mais que mil palavras, então aqui está a resposta em poucas palavras:

Figura 1 - Foco em recursos de alta probabilidade e alto impacto

 

Essa imagem merece uma explicação detalhada:

• Teste coisas que mudaram antes das que ficaram iguais. Faz sentido né? Correções e atualizações significam novos riscos.
• Primeiro teste as funções principais de alto impacto. Se uma única função central quebrada bloqueia 20 funções secundárias, qual delas tem prioridade? As funções bloqueadas ou a que impacta as outras?[PS5] 
• Teste cenários comuns primeiro. Se o recurso A é usado por milhares todos os dias, e o recurso B por dezenas uma vez por semana, então qual deles tem prioridade?
• Capacidade de teste antes da confiabilidade. Teste se cada função atua corretamente antes de explorar como ela pode se comportar em muitas condições diferentes.

3. Todos os testes são baseados em modelos

 

Lição #25. No início de nossas carreiras, nosso teste pode ser apenas um clique aleatório e ver que nada quebra. Eu fiz isso, todos nós tínhamos que começar de algum lugar.

 Nós rapidamente melhoramos e aprendemos sobre valores de fronteira, particionamento de equivalência e outros conceitos. Portanto, nosso teste pode ser expresso de forma eloquente nesta piada clássica sobre controle de qualidade:

Um engenheiro de controle de qualidade entra em um bar. Pede uma cerveja. Pede 0 cervejas. Encomenda 99999999 cervejas. Pede um lagarto. Pede -1 cervejas. Pede um uialkdsjfslk.

O primeiro cliente de verdade entra e pergunta onde fica o banheiro. O bar explode em chamas, matando todos.

Muitas pessoas param aqui e apenas repetem. Isso não é o bastante. O teste é muito mais complexo do que isso. Se não fosse o caso, sobre o que falam as dezenas de livros sobre teste?

Como os próprios autores sugerem:

Seus testes serão baseados principalmente nos seus modelos [...] Um modelo com falhas resulta em testes com falhas. […]. Modelagem de estudo. Você testará melhor à medida que se tornar mais hábil na arte de modelar. Livros didáticos e aulas sobre análise de requisitos e arquitetura de software podem ajudar. Uma ótima maneira de adquirir habilidade em todos os tipos de modelagem é estudar o pensamento sistêmico: Veja uma introdução ao pensamento sistêmico geral (Weinberg 2001).

Tenho certeza de que os autores não estão falando sobre “V-Model” vs. “Modelagem Ágil” de teste, mas, por exemplo, “teste baseado em estado” vs. “teste de interação”, ou a capacidade de criar diversos Diagramas UML e dividi-los em cenários. Confira este documento PDF sobre Testes da Universidade de Helsinque CS para obter uma melhor compreensão do que esta lição está falando.

4. Ao criar procedimentos de teste, evite “1287”

Lição #45. Então, você usou seus modelos e agora está criando cenários de teste com etapas (ações) e resultados esperados (resultados).

Existem muitas dicas e truques para criar um bom teste. Por exemplo, deve haver um propósito claro e bem definido, e não apenas "testar isso, e enquanto você está nisso, verifique também o outro".

Outra questão que os autores decidiram destacar é o uso de “1287”. Em outras palavras, o uso de um número aleatório ou outro valor que surgiu na cabeça do criador do teste no momento da escrita, mas não tem significado para ninguém no dia seguinte.

Este é um valor especial? Se sim - por quê? Posso usar outro número de 4 dígitos? Posso usar um número de 5 dígitos? Deixe-me passar os próximos 30 minutos descobrindo isso, caso contrário permanecerá confuso para sempre.

Figura 2 - Confused comic de http://www.poorlydrawnlines.com/comic/confused/

 

Eu frequentemente encontro esse problema também em cenários de teste e scripts de automação. Aqui estão algumas dicas práticas para evitar essa confusão:

·        Em cenários de teste, não escreva “1287”, mas sim “qualquer valor grande de até 5 dígitos, por exemplo, 1287”. Isso dá aos outros, clareza e liberdade para escolher um valor apropriado durante a próxima execução de regressão.

·        Em scripts de automação, use nomes de variáveis claros para indicar a intenção:

 

int someLargeValue = 1287; // yes!

int val = 1287; // no!

 

5. Você é o que você escreve

 

Lição # 55. Você executou seus testes e encontrou um bug! Naturalmente, você escreve um relatório de bug. Listados na seção “Defesa de bugs”, os autores argumentam que os relatórios de bugs.

 

Moldar a percepção que seus leitores têm de você. Quanto melhores forem seus relatórios, melhor será sua reputação.

 

Além disso:

 

Relatórios fracos geram trabalho extra para os programadores. Se você perder o tempo deles, eles vão querer evitar você e seu trabalho.

 

Eu não poderia concordar mais. Se o SUT não funcionar bem, alguém deve investigar o quê? Porque? Quando? e onde? Quaisquer que sejam os cantos que você cortar, os desenvolvedores terão que compensar ou rejeitar o relatório levantado, caso eles não se importarem o suficiente.

Portanto, certifique-se de colocar esforço em seus relatórios de bug! Eu descrevo o que deve ser feito na seção “Seu relatório de bug é a cara do seu diplomata” do meu outro artigo: https://medium.com/javarevisited/the-most-important-soft-skill-of-a-tester-77a9fc7347f2

 

6. Não insista para que todos os bugs sejam corrigidos. Escolha suas batalhas

 

Lição #97. Eu certamente fiz um barulho desnecessário várias vezes sobre bugs rejeitados que eu relatei. Como eu não poderia? Isso machucou o ego do meu testador júnior!

O erro de lutar por todos os problemas possíveis corrói os benefícios da primeira dica neste artigo - qualquer bom relacionamento que você construiu com os desenvolvedores nas últimas semanas ou meses pode ser desfeito em um ou dois dias.

Se você tem certeza de que é uma falha importante e foi mal interpretado - claro, avance o mais diplomaticamente possível e envolva outras partes interessadas para uma segunda (ou terceira) opinião. Como último recurso, peça um e-mail oficial ou comentário sobre o tíquete para declarar que “isso não é um problema” (e observe como a maioria das pessoas se esquivará dessa responsabilidade).

No entanto, aprenda a deixar alguns de seus bugs passarem:

·        Em primeiro lugar, não é uma questão de vida ou morte, certo? (a menos que você esteja testando software na área médica ou de aviação).

·        Em segundo lugar, você fez seu trabalho, está gravado e você tirou o seu da reta. Em algum momento, seu tempo será melhor investido se você continuar procurando por novos bugs, em vez de discutir a respeito dos antigos.

·        Por fim, vale lembrar que este definitivamente não será o seu último bug rejeitado.

 

7. Quando você perder um bug, verifique se a falha é surpreendente ou apenas o resultado natural de sua estratégia.

Lição #41. Os seus bugs relatados foram corrigidos e testados novamente, e a nova versão do software foi lançada na loucura do mundo exterior. Mas alguns usuários ainda encontrarão bugs.

Você sentirá falta dos bugs. Você pode perder um bug amanhã. Isso é inevitável. Os testadores vão parar de perder bugs quando os desenvolvedores pararem de escrevê-los.

Mas há uma pergunta importante a ser feita:

Perdemos porque estávamos seguindo uma boa estratégia de teste (com base em modelos de teste bem desenvolvidos) e simplesmente não encontramos esse problema específico?

Se a resposta for "sim" e você simplesmente não entendeu por causa do momento no mundo real e outras restrições, então continue. Mas, se houver uma grande falha na comunicação, compreensão dos requisitos ou outros fatores, aproveite isso como uma oportunidade para melhorar. Não deixe o mesmo erro acontecer novamente.

“Insanidade é fazer a mesma coisa repetidamente e esperar resultados diferentes”.

      - Albert Einstein

8. Alternar testadores entre recursos

Lição nº 191. Vamos além do contexto de apenas um único testador fazendo seu trabalho e para a dinâmica e gerenciamento de equipe.

Você normalmente trabalha em equipe. Não importa se o tamanho de sua equipe é 2 ou 20. O que importa é ocasionalmente alternar colegas de equipe entre recursos ou sistemas testados.

Digamos que sua equipe seja feita de 5 pessoas e seja responsável pelos componentes A, B e C de uma arquitetura maior. A pior coisa que você pode fazer é atribuir testadores a componentes específicos e mantê-los estáticos, digo isso, por boas razões:

 

1.     É chato, ficar cutucando a mesma coisa. Pessoas competentes desejam variedade ou vão embora.

2.     Bus fator de 1. Imagine que o componente B é testado exclusivamente por Bob. Bob é um cara legal, mas ele vai embora de repente ou adoece, e há um grande lançamento agendado para a próxima sexta-feira (péssima ideia, de qualquer maneira). Agora você tem um grande problema porque não há absolutamente nenhuma maneira de Kate, John ou Dave aumentarem seus conhecimentos rápido o suficiente para fazer um trabalho decente.

Você pode alternar ou garantir uma distribuição equilibrada de conhecimento. Por exemplo, cada componente pode ter um testador primário e um testador “backup” secundário.

 

Figura 3 - Atribuir responsabilidades primárias e secundárias equilibradas dentro da equipe

 

• O componente (ou recurso) A é gerenciado principalmente por Bob.
• Kate é a testadora principal para B, mas ela também trabalha em A semana sim, semana não, então ela está por dentro e poderia fazer um bom trabalho se Bob desaparecer de repente.
• John é o testador principal de C, mas também trabalha em B...

Você entende o que eu quero dizer.

Observe que alguns sistemas são bastante complexos e requerem tempo (às vezes, cerca de 6 meses ou mais para se familiarizar). Nesses casos, é prudente não afastar as pessoas de suas tarefas quando elas estão pegando o jeito. Isso também nos leva à próxima lição.

 

9. Não espere que as pessoas lidem com vários projetos de forma eficiente

 

Lição #215. Multitarefa é um mito. Faça uma pesquisa rápida e fique impressionado com o número de artigos, pesquisas e literatura sobre o assunto.

Eu vi pessoas trabalhando em várias coisas ao mesmo tempo (bem, mudando constantemente), mas nunca vi resultados excelentes, apenas medíocres.

Acho que nunca vi alguém trabalhando em vários projetos de forma eficiente, talvez com exceção de Elon Musk, que trabalha de 90 a 120 horas por semana. Bom para ele. O resto de nós, mortais, devemos ficar longe do excesso de trabalho e da multitarefa! Organize-se ou converse com seu gerente, mas tente trabalhar na mesma coisa até se sentir razoavelmente confortável e poder assumir mais responsabilidades.

Portanto, não confunda atribuição de trabalho rotativa e equilibrada em tempo hábil (nº 8) com puxar constantemente as pessoas para frente e para trás entre tarefas e projetos (nº 9).

 

10. Muitas outras empresas são tão complicadas quanto a sua

 

Lição #252. Você já teve o suficiente! Nada está funcionando, você não é apreciado, os desenvolvedores continuam quebrando coisas e, claro, seu chefe é um idiota!

Você pode estar certo, e talvez mudar para outro trabalho ou equipe seja a melhor mudança, mas está muito longe de ser garantido. Conheço um desenvolvedor de software que, segundo suas palavras, passou de uma empresa boa para uma empresa ruim e depois para pior ainda.

Quando a grama parecer mais verde do outro lado, tente conversar com outras pessoas e obter a perspectiva delas. Talvez você descubra que seu lugar atual não é pior do que os outros. Se for esse o caso, a mudança seria um esforço perdido, então você não precisa, mas ajuste suas expectativas e termine com uma perspectiva equilibrada.

 

Conclusão

 O próprio fato de um livro chamado “Lessons Learned in Software Testing” conter 297 lições colossais significa uma coisa - testar, quando feito corretamente, é um esforço que requer grande habilidade, conhecimento e experiência.

Aprimore suas habilidade de testes. Eu recomendo totalmente que você obtenha uma cópia do livro ou verifique sua biblioteca local para ver se eles têm.