“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?
- 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.
