🙆🏽 🚣🏽 ☹️ Padrões de justificação de tarefas e antipadrões 🍯 🏂🏾 💃🏾

Conteúdo

Quando você inicia uma tarefa, ela precisa ser justificada. Você deve convencer o desenvolvedor que:

isso é realmente um bug;
precisa ser consertado;
ele precisa ser corrigido exatamente como dissemos.

E às vezes você lê bugs (especialmente erros de iniciantes) e se pergunta:

- Por que isso é um bug?

Por exemplo, ele diz: “Faça o download do relatório, temos 57.6. E deveria ser - 57,9 ".

Escrever a lógica resolverá os problemas:

Os colegas se distraem com as perguntas "Por que isso é um bug?", Tirando-o do contexto.
Um mês depois, você se esqueceu, mas, de fato, por que era um bug ...

Veja também:
Por que a justificação em um bug é necessária - em mais detalhes sobre por que, em geral, justificação.

Centenas de testadores iniciantes (estudantes) passaram por mim. Foi precisamente nas tarefas deles que comecei a fazer a pergunta "Por que isso é um bug?" ... Você pergunta aos caras e, em troca, recebe "Sim, é óbvio!". Bem, de alguma forma, não muito =))

Através de várias tarefas e perguntas, "Por quê?" padrões de respostas começaram a surgir. Eu destaquei os padrões bons e ruins. Eu quero falar sobre eles.

Este artigo é para:

Testadores iniciantes - aprenda a explicar corretamente seu ponto de vista;
gerentes de teste - para fornecer um link para seus padawans e, em seguida, consultar antipadrões sem maiores explicações.

1. Antipadrões: raciocínio ruim

1.1 Obviamente

Por que os testadores não escrevem a lógica de um bug? Sim, porque parece óbvio para eles. E eles projetam seus pensamentos em todos. É óbvio para mim = é óbvio para todos porque escrever algo?

Mas, na realidade, não é assim, porque cada pessoa está em algum tipo de contexto. E o que é óbvio para você não é um fato óbvio para outra pessoa.

Vejamos exemplos simples. Leia a palavra que escreverei abaixo - o que você achou quando a leu? Que associações vieram à mente?

LOCK

Uma fechadura de porta ou uma enorme fortaleza de pedra?

CASAMENTO

Um casamento ou um iPhone quebrado?
...

Sim, esses são homônimos. Mas eles mostram claramente o problema "é óbvio". É óbvio para você que o castelo é um castelo, e para mim que é um castelo.

E se você escrever um bug:

Resultado
57,6

Resultado esperado
Obviamente, deve haver 57,9

Isso não responde à minha pergunta "POR QUÊ?" O que significa "óbvio"? Explique-me por favor. Não é óbvio para mim, caso contrário, não perguntaria novamente. Mas o autor é óbvio e ele pensa que todos também.

Se falamos sobre a experiência de iniciantes, um dos meus alunos formulou essa idéia da melhor maneira possível:

"Eu não entendi por que justificar bugs, até ler os bugs de outros estudantes"

Você pode dizer por muito tempo que é "óbvio" para todos que são diferentes e eu não estou no seu contexto, e muito mais ... Mas o autor da tarefa considerará que eles simplesmente encontram falhas nele, o resto deles não entende, mas ele está indo bem!

E apenas lendo os erros de outras pessoas, você começa a pensar: “Hmmm, por que ele pensa assim? Eu pensei diferente. " É então que chega a compreensão de que o seu "óbvio" não é óbvio para todos.

Uma vez que entrei no rastreador de erros e vi um bug desse tipo: “Entramos no nome Sharipat, ele é definido como masculino. E deve ser como uma mulher! Por que deveria ser como uma mulher? Eu olho para esse nome - bem, Sharipat e Sharipat, parecem um homem. Eu pergunto:

"Por que você decidiu isso?" Por que mulher?
- Sim, porque minha esposa é assim!

E isso pelo menos já me explica por que ele iniciou a tarefa. Quando testamos aplicativos, tentamos primeiro dados simples, coisas que sabemos. Tentamos o nosso nome, o nome da nossa esposa, irmão, irmã ...

Ele tentou digitar o nome de sua esposa e descobriu um bug. E se ele escrevesse o resultado esperado: “Gênero é feminino, esse é um nome feminino - meu nome é esse”, então pelo menos a pergunta “Por que você iniciou essa tarefa?” Desapareceria.

Obviamente, essa justificativa não é suficiente. Google "nomes incomuns", porque não é proibido sequer nomearmos a mesa de cabeceira de nosso filho, mas vale a pena considerar essa palavra como o nome masculino correto?

Então, aqui é necessário pesquisar no Google, quais são os nomes em geral, para localizar o problema - o problema com os nomes russos? Cazaque? Ucraniano? Mas o sistema deve ser capaz de processá-los? E assim por diante Talvez não seja um bug ...
E, no entanto, "o nome da minha esposa é assim" pelo menos permite que o autor nos introduza em seu contexto e explica por que ele decidiu iniciar a tarefa.

E lembre-se, as evidências podem ser ditadas pelo contexto. Você estudou cuidadosamente o grande módulo do sistema, conhece tudo minuciosamente. Portanto, é completamente óbvio para você que "esse chip deve funcionar AQUI ASSIM". Porém, se você retornar à tarefa em um mês ou dois, já estará trabalhando em outro módulo, e lembrar por que será assim será mais difícil.

Até o lápis mais idiota é mais nítido do que a memória mais nítida da Internet

Quando você inicia um bug, e o resultado esperado lhe parece óbvio, pare e pense: "Por que eu penso assim?". E escreva a resposta a esta pergunta.

1.2 Eu juro pela mãe!

Quando um aluno entende que escrever nada, "porque é óbvio", não falha, ele passa para o próximo estágio de raiva, negação e justificativa de bugs chamado "Eu juro pela mãe!" É quando dizemos que é certo, sem explicar o porquê.

Ou seja, a lógica se parece com isso:

Resultado
57,6

Resultado esperado
57,9 porque é tão certo

Mas esse raciocínio novamente não responde à minha pergunta "Mas por quê?". Por que você decidiu que isso é tão certo? Ainda não sou um idiota ou um telepata e não sei por que você acha isso certo.

De fato, isso não é muito diferente da situação "não escreveu nada, porque é óbvio". Portanto, eu chamo isso de segundo estágio - é precisamente nesse cenário que os eventos geralmente se desenvolvem, primeiro "obviamente", depois "sim, exatamente exatamente". Vejamos um exemplo da vida dos alunos:

Pedro e os índios

Nosso sistema é capaz de flexionar nomes por casos. Um aluno verifica o nome Peter. Você sabe como está se inclinando? No caso nominativo, é escrito através da letra E, e em todos os outros - através de E. "Peter, but Peter".

Então, eu vou para o rastreador de erros e leio esse erro: "Peter se inclina sobre os casos através da letra e, mas deve através de e".

Eu pergunto:

"Por que você acha isso?"
- Bem, é óbvio que através de E é necessário (primeira etapa)
"Por que você acha isso óbvio?"
- Mas é assim de acordo com as regras da língua russa!
- Por quais regras?
- Bem, devo executar e pesquisar no Google as regras do idioma russo? (segunda etapa - então, acredite)
SIM! Sim, é exatamente isso que você deve fazer. Porque essa será a lógica do bug. Porque talvez o seu desenvolvedor seja indiano e você também seja indiano. E você não conhece as regras da língua russa! Então, dê a eles um link e todas as perguntas desaparecerão imediatamente.

Obviamente, não há necessidade de ir ao extremo e fornecer links para dicionários quando você coloca um bug em um erro de digitação ou vírgula perdida. No entanto, Peter é um exemplo não trivial, isso é uma exceção à regra. Sempre funciona assim, mas para Peter é diferente.

Portanto, aqui o link será útil. Especialmente se o desenvolvedor perguntasse: "É mesmo verdade?" Você pode acusá-lo de estupidez e analfabetismo e arruinar o relacionamento. E você pode dar um link, confirmando gentilmente seu ponto de vista.

Mas tudo bem, vamos dar outro exemplo, não sobre as regras do idioma russo, que são "tão óbvias".

Email.rf

Meus alunos gostam muito dessa tarefa (quase todas as transmissões são elaboradas):

- Estou tentando me registrar no email.ru e não posso. Isso é um bug!
Porque?
Como é por isso? Vivemos na Rússia, todo mundo tem esses e-mails!

Contei esse caso na conferência DUMP e tinha uma sala de audiência completa. Pedi para levantar as mãos de quem tem esse e-mail. Das 200 pessoas, três levantaram as mãos.

O fato de morarmos na Rússia não significa que todos tenham esses e-mails. Bem, sim, sim ... E ursos mansos e bonecas ...

Não há relação causal aqui, é simplesmente difícil desistir de sua ideia. Afinal, aqui, encontrei um bug! Como isso pode não ser um bug? Tão legal. Rússia, obviamente! Não, não é óbvio? Bem, mesmo assim, Rússia, Certamente existem muitos.

Essa lógica é mais parecida com “Estou com preguiça de ir ao google, procurar fatos. Acredite na palavra ". Quando não temos fatos e evidências, há um desejo de ocultar sua justificativa e escrever "Provavelmente, provavelmente, com certeza ...".

Mas estas são palavras de PARADA! Se você deseja escrevê-los, não tem fatos reais. Então você apenas pensa sobre isso. E por que precisamos executar uma tarefa baseada na imaginação de um testador? Prove sua teoria!

E se não houver fatos? Então nem vale a pena começar a tarefa. Sim, é difícil recusar o bug "seu próprio nativo". Mas isso também deve ser capaz.

Email.ru - fatos

Quais poderiam ser os fatos?

Em primeiro lugar, podemos criar nosso site para alguns clientes governamentais que precisam se registrar no domain.rf. Padrão corporativo, eles não têm escolha.

Ou realmente temos muitos desses clientes, isso é mostrado pelas estatísticas. Por exemplo, existem muitos erros nos logs "tentativa de registrar através de um domínio". E talvez valha a pena fazer esse recurso. Para não perder clientes em potencial.

Com base nesses fatos, o PM (Gerente de Projeto) decide se faremos a tarefa ou não. E se quisermos, então quando. Ou ele pode dizer: "Bem, há erros, e bem, há menos de 1% do total de registros, não faremos"

Em vez do resumo "sim, essas pessoas definitivamente existem!" dê os fatos.

E ao definir a tarefa, use o princípio 5 por quê. Ao escrever o resultado esperado, pergunte-se: "Por que estou esperando isso?" A primeira resposta será "Isso é óbvio", mas faça novamente a pergunta "Por quê?". E se você notar que não há dados, parece que sim - procure os fatos ou discuta a situação com os colegas.

1.3 Coelhos estão ofendidos

Se não houver fatos, mas você não quiser recusar o bug, os alunos passarão para o próximo estágio de raiva, negação e justificativa de bugs ... Pressão sobre as emoções:

Eu tento me registrar com o nome Cthulhu, mas o sistema não. Deveria ceder, caso contrário ... Fiquei ofendido e fui embora, e VOCÊ! Perdeu um cliente!

E certamente todos são iguais a mim, então você perdeu TODOS os clientes, e eles também entraram com uma ação por insulto e levaram todo o dinheiro!

E outros carros ...

É claro que, quando eu pessoalmente não gosto de algo, é muito irritado ignorar o meu problema. O que significa "Pessoas normais não se registram com esse nome?" Eu sou louco ?! Como eu quero, é chamado, como você pode me proibir alguma coisa ?!

E então a projeção é ligada - se eu não gostar, outros usuários não vão gostar! Se não todos, pelo menos muitos. Portanto, esse é definitivamente um bug e precisa ser corrigido. Bem, ou pelo menos partimos no âmbito do treinamento, se estamos falando de estudantes.

No entanto, o usuário ofendido é a pior justificativa possível. Porque eles podem justificar qualquer bobagem:

Não existe um gato no principal? Bem, é isso! Fiquei ofendido e foi embora! E VOCÊ! Perdeu um cliente !!
Registrei-me e não fui pago por isso? Fiquei ofendido e fui embora ... E VOCÊ! Bem, você entendeu!

Tudo pode acontecer e me ofender. O botão é verde, mas eu queria um vermelho, o sistema não me ofereceu pizza de presente ... Como usuário, posso me ofender com qualquer coisa. Mas quem se importa? Mesmo assim, você não agradará, o ressentimento é inevitável. E ameaçar é geralmente a última coisa.

Tudo começou com um dos alunos, que acabou de dizer esta frase secreta:
- Ah, você não deseja se registrar através do domínio da Federação Russa? E como usuário que tentei me registrar, vi essa situação flagrante e GONE! E VOCÊ! Perdeu um cliente!

Então meu amigo disse que esses discursos são muito parecidos com "Coelhos foram ofendidos". Não sei de onde ela tirou essa analogia, mas todos gostaram.

O aluno percebeu que estava ficando empolgado. Foi buscar uma justificativa sem emoção. E nós temos o nome antipadrão.

Lembre-se de uma regra simples - não deve haver emoções no bug!

As emoções são um fenômeno passageiro. Agora você está com uma raiva justa e deseja expressá-la em comentários maliciosos como "apenas um idiota poderia escrever um código como esse". Mas lembre-se de qualquer situação em que uma criança próxima a você fosse caprichosa, organizando uma birra para a mãe por causa de um brinquedo ou sorvete não comprado. Você, como observador externo, gosta de assistir a essa cena? Mas sua histeria no rastreador de bugs parece exatamente a mesma!

Portanto, se você realmente quiser, diga tudo verbalmente. Discuta com o desenvolvedor a tarefa na sala de fumantes, defendendo veementemente sua posição. Mas assim que chegamos ao computador - removemos as emoções, escrevemos apenas os fatos. Sem "se sim, se" e sem "e VOCÊ! Perdeu o cliente!

Lembre-se de que eles retornam às tarefas após um ano ou dois ou três. E então, mesmo você vai olhar sua própria birra. Afinal, não há mais emoções passadas, isso parece ridículo. Então, o máximo de emoções verbalmente - na sala de fumantes! E em um bug de alguma forma sem eles.

E na justificativa, não escreva sobre coelhos mega-ofendidos. Às vezes, essa defesa da tarefa chega ao ridículo:

O aluno encontrou um erro de digitação na oferta do usuário. Coloque um bug com prioridade crítica. Quando solicitado a esclarecer a prioridade, ele ficou muito indignado:

- O sistema me enganou, não posso confiar nela !!!

Ele provavelmente estava preocupado com o fato de a pergunta se transformar em "isso não é um bug", então ele começou a defendê-lo. Mas ninguém não se importa que isso seja um bug. Mas por que isso é crítico? Quem lê a oferta?

Eu li! Portanto, vejo que o sistema está ruim; se houver um erro de digitação, o que ele pode fazer? E como acreditar agora ?!

Mas "eu li" ≠ "todo mundo lê". E então o próprio aluno admitiu que não lê atentamente TODOS os contratos de licença que estão sendo inseridos em nós ao instalar os programas. Assim, com a oferta, a mesma história. Enquanto tudo está bem, eles não lêem. Se algo não for agradável, já dirija-se às regras.

No entanto, "o sistema me enganou e não posso acreditar agora" por causa de um erro de digitação na décima página do texto que poucas pessoas lêem ... Bem ... Não escreva isso com um bug, não informe seu RM.

Então, removemos as emoções do bug. E o que podemos deixar lá? Claro, os fatos!

Em vez de escrever sobre emoções, “os coelhos certamente se ofenderão, eles vão embora e você perderá clientes”:

- coletar estatísticas;
- estimar custos trabalhistas;
- conte o ROI;
- Entreviste usuários;
- Compare o produto com os concorrentes;

E em vez de um esquilo histérico, você se tornará um testador bacana que faz insetos pensativos!

2. Bons padrões de justificação

Como justificar erros corretamente? O que precisa ser escrito no resultado esperado para que seu bug seja corrigido conforme você escreveu? E eles não perguntaram 10 vezes "por que isso é tão certo"?

Três antipadrões foram discutidos acima, vamos discutir três bons padrões para justificar bugs.

2.1 Pruflink

Pode ser:

Link para requisitos
Os próprios requisitos (arquivo do word, presente ...)
Ligação à Internet
ROI estimado
Carta do cliente
Estatísticas

Link para requisitos

O erro mais simples é quando existe um TK e o sistema não funciona como descrito lá.

Então, escrevemos no resultado esperado: "57,9, porque é assim na declaração de trabalho". Hmm, hmm ... Espere um minuto. Parece que "eu juro pela mãe" ...

Sim, nessa redação soa assim. Portanto, confirme suas palavras com um link. Caso contrário, o desenvolvedor lê o bug e precisa:

perceber que tipo de AT está envolvido;
encontre o próprio TK;
encontre o local específico em questão;
para entender ...

Não é mais fácil deixar apenas o último item? Afinal, o desenvolvedor pode trabalhar em 10 projetos diferentes, cuja documentação é distribuída em 10 locais diferentes. Levará de 5 a 10 minutos para procurar o TK, e adicionar um link para você é uma questão de segundo. Afinal, agora você está testando o TK, o que significa que ele está aberto e diante dos seus olhos. Copie o link e cole!

Respeite o tempo dos colegas e eles serão gratos a você.

Requisitos próprios

Se os requisitos NÃO forem armazenados em uma confluência ou outro sistema em nuvem, mas em um Word comum, anexe o documento que você está testando.

É possível que você esteja testando requisitos desatualizados. E se você anexar um arquivo direto de palavras que estiver verificando, o analista poderá vê-lo e dizer: “Ah, espere, já mudamos tudo 10 vezes, esqueci de enviá-lo. Espere!

Caso contrário, passe três horas em um confronto com o desenvolvedor, que dirá "mas eu tenho um diferente!". Você executará, observará os requisitos dele e os seus e, em seguida, procure um analista para esclarecer quem está certo ...

E então você imediatamente colocou os requisitos, o desenvolvedor olhou dizendo "algo é algum tipo de lixo", redirecionou a análise. O analista as escreveu e, quando abrir sua palavra, ele entenderá imediatamente se está desatualizado ou não. Isso está economizando tempo!

Ligação à Internet

Como lembramos, os requisitos estão longe de sempre. E, em vez deles, talvez ... Link para a Internet! Sim porque não

Se lembrarmos do exemplo "Pedro, Pedro", mesmo que tenhamos requisitos no sistema, é improvável que diga "O sistema funciona de acordo com as regras do idioma russo" e todas as regras do idioma russo sejam listadas. Claro, ninguém escreve assim. E ainda assim, se você quiser consultar as regras do idioma russo, precisará ir e pesquisá-las no Google.

Ou se você der um exemplo de Sharipat. Mais uma vez, de onde você tirou esse nome feminino normal? Pesquisamos no Google todo tipo de cazaque e outros nomes, encontramos Sharipat, encontramos outros nomes semelhantes e fornecemos um link para esta página.

E aqui já, mesmo que o desenvolvedor não concorde com você, ele pode vir e dizer - "Olha, você deu um link para o site, mas isso é algum tipo de imprensa amarela, eles sempre escrevem lixo". Mas se você não forneceu o link, o desenvolvedor precisará pesquisar no próprio Google, pesquisar todos os tipos de sites e só então ele entenderá que você pode ter atacado algumas informações falsas.Economize tempo, dê imediatamente um link para a Internet.

Sim, aqui você precisa entender que nem todo link é útil e justificado, mas pelo menos mostra por que você acha que isso é realmente um bug. Não é minha "mãe jurando", mas com uma justificativa!

Carta do cliente A

justificativa pode estar sendo enviada para uma carta do cliente. Temos até um campo separado, Justificação comercial, onde anotamos qual cliente solicitou esse recurso. E então, quando lemos nosso bug, vemos imediatamente:

- Sim, o caso de negócios está vazio. Isso significa que nós mesmos encontramos esse problema e acreditamos que ele precisa ser corrigido.

Ou:

- Sim, esse cliente reclamou do problema em 1º de agosto de 2015

E se precisarmos esclarecer com esse cliente o que exatamente não combina com ele, podemos encontrar facilmente essa carta, porque temos todas as informações (quem, quando, como a carta é chamada). Conhecendo essas informações, irei encontrar uma carta em 5 segundos no meu Outlook. Se essas informações não estiverem disponíveis, terei que acessar o Outlook e pesquisar entre 10 pais diferentes - qual cliente solicitou e em qual carta?

Além disso, se percebermos que esse recurso foi solicitado por vários clientes diferentes, ele imediatamente aumentará a prioridade. Como entendemos:

- Sim, aqui está o cliente que eu reclamei, depois de algumas semanas / meses, o cliente reclamou outro. Hmmmm, mas certamente há muitos outros clientes que também sofrem, mas ficam calados. Chore, pique, mas continue a comer o cacto. Afinal, nem todos nos escrevem e relatam um problema ...

Portanto, quanto mais reclamações, maior a prioridade. Como entendemos que este é um usuário real, ele realmente tem esses problemas. E mesmo se voltarmos ao bug seis meses ou um ano depois, graças à carta em anexo ou pelo menos um link para ele, sempre será possível elevar o histórico da tarefa.

ROI

Podemos tentar calcular a relação ROI - retorno do investimento. Realmente precisamos criar esse recurso ou corrigir esse bug? Isso trará o efeito adequado?

Uma coisa é fazer uma edição menor por meia hora de desenvolvimento, o que ajudará centenas de usuários. É completamente diferente - devido à histeria de um usuário, duas semanas para refazer o sistema, adequado a todos os outros.

Se calcularmos o ROI e vermos que o jogo vale a pena, colocaremos os cálculos na tarefa. Às vezes, porém, após os cálculos, você não precisa executar a tarefa. E isso é normal! Assim, economizamos o tempo da equipe para discutir recursos desnecessários.

É por isso que pensamos na lógica - porque às vezes parece "Ah, que bug, que bug!", E então você começa a pensar na lógica ... E você entende que esse lixo, não um bug, não vale a pena começar ...

Por exemplo, chegamos ao trabalho com um aplicativo móvel e existe um painel de depuração para testadores que se parece com isso:

Uau, uau! Há um pouco de azul, há um pouco de vermelho, o texto não está completamente visível, as fontes estão espalhadas ... Um erro óbvio! Como isso não foi percebido diante de mim? Liberação urgente, precisa de refatoração!

Como justificar? "Como assim, se um usuário VÊ ISSO, ele imediatamente se ofende e vai embora." Parar . -. , [2]. . , , !

… , ? . , , . ? !

, . . . ? ? , , .

— , !

Estatísticas

Colete estatísticas e invista na tarefa:

- o número de erros nos logs;
- o número de reclamações no suporte técnico;
- o número de cliques no botão;
- o número de usuários que saíram na fase de realização do pedido (fechou a guia);
- ...

Ou seja, se você acha que o formulário padrão para fazer um pedido na loja on-line é "ruim" e precisa ser aprimorado, justifique-o. Por que isso é ruim? Para inserir o endereço, você precisa conhecer seu índice e preencher 10 campos obrigatórios? É muito ruim ou apenas te irrita?

Lembre-se de que os desenvolvedores podem não ver o "óbvio" em seus softwares. Afinal, eles desenvolveram, testaram ... Eles veem constantemente 100 vezes por dia, já estão acostumados com a interface. Portanto, mesmo que esteja realmente desatualizado, você precisa de fatos.

E é fácil coletar os fatos - pedimos que você faça estatísticas para ver quando o usuário sai da página. E se ele adicionou pizza à cesta, e depois começou a preencher os campos e depois de 5-7 cuspir e sair, isso não é muito legal. E se cada terceiro agir assim - definitivamente vale a pena melhorar alguma coisa!

Se você se lembrar do email.rf, pode ver os logs - existem erros como "A tentativa de registrar um email desse tipo é rejeitada"? Talvez eles não existam, mas já criamos vários usuários ofendidos, por causa dos quais o site literalmente perdeu milhões.

Por que as estatísticas são melhores que as emoções? Porque nós, profissionais de TI e usuários comuns, somos dois mundos diferentes. O que é conveniente para nós é inconveniente para eles. E vice-versa.

Suponha que façamos software de contabilidade. Parece-nos: "Fu, ninguém trabalha com o mouse, devemos garantir que tudo funcione da linha de comando, para que o mouse não precise ser tocado!" Dedicamos muito tempo a essa funcionalidade, mas usuários reais não a usam. Porque eles precisam de um mouse para escolher, apertar o botão grande ... Mas o que é conveniente para os programadores, eles geralmente não se importam, porque se sentem confortáveis com algo completamente diferente.

E se você quiser contar a todos o que os usuários precisam, primeiro estude os testes de usabilidade e depois diga se os coelhos estão ofendidos ou não.

Em nosso sistema, coletamos estatísticas anônimas, qual funcionalidade é usada e qual não é. Existem muitos filtros em um formulário da web que são difíceis de manter. Eles são necessários? Você não pode simplesmente pegar e remover, vale a pena conferir.

Portanto, as estatísticas geralmente são muito surpreendentes. Achamos que esse filtro não era usado, mas na verdade funcionava a cada hora. E, por outro, eles tinham grandes esperanças, mas ninguém precisa dele ...

Somente as estatísticas falam honestamente sobre a existência do problema. Se não houver estatísticas, será apenas sabor. E todo mundo tem gostos diferentes. O testador deseja o botão vermelho, o desenvolvedor o verde e o designer o azul. Portanto, procure fatos e dê a eles um pré-link!

2.2 Uniformidade

Se não houver pré-link, podemos nos referir à uniformidade no sistema. Porque se o sistema sempre funciona dessa maneira e, de repente, ele funciona de maneira diferente - essa pode ser a razão do bug.

Por exemplo, se o nosso sistema funcionar como um comutador (isto é, quando imprimo em russo, esquecendo de mudar o layout, e o sistema o altera sozinho). Posso digitar “Olga” ou digitar “Jkmuf”, o sistema transformará a segunda opção na primeira.

Isso acontece em todos os tipos de aplicativos governamentais. Às vezes eles mesmos trabalham com o mesmo princípio. Você deve se registrar claramente como no seu passaporte. Como moramos na Rússia, o registro é em russo, portanto, corrigiremos as letras em inglês. Você obviamente esqueceu de mudar o layout, cara!

Jkmuf → Olga

Ok, mas e se eu tentar digitar o nome "Julia"? Começa com a letra U e esta letra não corresponde à letra do alfabeto russo, mas a um caractere especial:

> → Yu

E esta é uma classe de equivalência completamente diferente!

Ou seja, se entendermos que o sistema funciona como um comutador de pontos, teremos pelo menos 2 classes de equivalência: existem letras russas que correspondem a letras latinas e existem aquelas que correspondem a um caractere especial.

Estas são classes completamente diferentes, elas devem ser verificadas! E talvez quando imprimimos um caractere especial, o sistema não o reconheça. E então começamos um bug - digito o símbolo>, espero que o sistema o traduza na letra U, mas nada acontece. Por que estou esperando isso? Porque o sistema JÁ funciona assim, porque se eu entrar no Jkmuf, o sistema entenderá que é o Olga.

Mostramos que o sistema já funciona dessa maneira, e essa é uma boa justificativa. Não dizemos "juro por minha mãe, ela trabalha assim", provamos isso em Olga.

2.3 Problema ou # dor na vida

Conte-nos sobre algum problema real do usuário.

Porque nós somos testadores. Nossa tarefa é esmagar e quebrar, inserir "Guerra e paz" em um campo curto, editar uma entrada em duas guias do navegador e outra, outra. E mesmo que algo não funcione para nós, isso não significa que o usuário fará o mesmo.

E às vezes os bugs não são corrigidos simplesmente porque "sim, ninguém faz isso!" E isso é normal. Por que desperdiçar energia e recursos em um problema que nunca surge?

Isto é especialmente verdade para problemas de usabilidade. Como lembramos, o que é conveniente para um especialista em TI é inconveniente para um usuário simples. E vice-versa! E acontece que se simplesmente escrevermos “Bem, isso é desconfortável ...” - essa é uma justificativa ruim, você nunca sabe o que é desconfortável, tudo serve para o resto. Porém, se coletarmos comentários dos usuários, anexarmos suas cartas nas quais eles reclamam, isso imediatamente sugere que esse problema realmente existe. E isso já aumenta sua prioridade.

O problema de um cliente real é sempre melhor do que apenas algum tipo de teste negativo de um testador.

Isso não significa que os testadores nunca são corrigidos para problemas. Se você tiver um problema, reclame também! Talvez o desenvolvedor possa ajudá-lo em apenas 5 minutos, ele simplesmente não conhece a situação.

Ao testar um novo recurso, eu o cubro com autotestes. A estrutura de teste já existe há muito tempo, estamos acostumados. Os testes são semelhantes entre si, então copie e cole - afinal, geralmente alteramos um parâmetro, deixando o restante inalterado. Este é o princípio de "1 teste = 1 teste", para que uma queda no teste indique imediatamente a causa.

E agora eu preciso copiar parâmetros de autoteste para autoteste. E eu tenho que desenterrá-los do primeiro teste para o segundo, terceiro, quarto, quinto, décimo ... E nesta cópia-pasta eu só preciso alterar 1 valor em uma linha e, se não o fizer, tudo desmoronará um erro.

É claro que, quando copio e colo, cometerei um erro em algum lugar ... Como resultado, escrevi 30 testes, os executei de uma só vez e tudo caiu com o NPE. Sento, coço a cabeça e penso "caramba, onde estou errado?"

Venho resolvendo o dia todo, procurando um erro, executando testes automáticos ... Estou tentando encontrar um bug ou um local onde estraguei tudo. Como resultado, encontro e, no próximo comício, reclamo:

"Escrevi esses testes automáticos o dia todo ontem, porque cometi um erro no quinto teste e tentei entender por um longo tempo qual era o motivo da queda." Oh, esta cópia-pasta!

E então o desenvolvedor diz:
"Sim, ela viria até mim; eu refatoraria tudo para você em meia hora e resolveria esse problema."

E assim foi possível? !!!

Por favor, não tenha medo! Talvez você esteja sofrendo e o desenvolvedor nem saiba disso. E talvez ele possa resolver rapidamente o seu problema, aqui e agora. E talvez não conserte, mas sugira uma solução alternativa.

Obviamente, se o problema é único ou está demorando muito para corrigi-lo, a tarefa de otimização passará para a próxima versão ou mais. Mas vale pelo menos discutir "como isso pode ser melhorado" e definir uma tarefa. Afinal, se não houver tarefa, ninguém fará nada.

Existem vários casos de problemas:

- problema do cliente;
- o problema do usuário real;
- problema do testador;
- um problema dentro da equipe;

Alguns são mais prioritários, outros menos. E, no entanto, se descrevermos o caso real e o problema real, essa tarefa terá mais chances de correção do que "obviamente, para que todos fiquem melhores".

Sim, você precisa entender que, mesmo que descrevamos o quão ruim é para usuários reais, ele ainda não garante que corrigiremos o erro, mas isso é vida. De qualquer forma, se pelo menos descrevemos o problema, será pelo menos claro por que definimos essa tarefa. Mesmo se voltarmos para ele em um mês, dois ou três. Sempre veremos por que achamos que os usuários eram ruins e desconfortáveis ao trabalhar com ele.

3. Quando a justificativa não é necessária

De repente, certo? =)

No entanto, o antipadrão "obviamente" tem exceções. Realmente NÃO precisamos escrever uma justificativa se o sistema:

desligou;
caiu com um erro não tratado;

Especialmente se isso aconteceu na produção. Se o nosso site for, não há razão para justificá-lo, você precisa vencer o gong e correr para o desenvolvedor "corrija-o com urgência!" Você pode geralmente sem um bug. E você pode com um breve "Erro 500 no principal", isso é suficiente.

Não sugue a lógica do dedo, porque "é sempre necessário". Escrever "o sistema não deve cair" é um texto em prol do texto.

Mas! Você definitivamente precisa escrever o resultado esperado. Mesmo que pareça óbvio para você, anote-o, não vai acabar com você.

Passos
Abra o site example.com

Resultado
Erro 500

Resultado esperado
A página principal foi aberta

Tudo parece ser simples aqui - o principal não abre, mas deveria. Mas existem exemplos mais complicados.

Por exemplo, o desenvolvedor fez uma fórmula a partir de TK e ocorre em algum lugar a divisão por zero. Se você escrever "Não deve haver erros, o relatório está carregado", o desenvolvedor continuará acessando a pergunta "Como deve abrir?" Há divisão por zero!

Você precisa pensar sobre isso e escrever “Espero que um relatório seja aberto com esses e esses valores de acordo com a fórmula ” - enquanto você pensa no que deve estar lá, você mesmo pode encontrar uma articulação no TOR. E depois verifique com o analista como fazer isso corretamente.

Portanto, mesmo se não houver justificativa, há pelo menos o resultado esperado. E lembre-se de que isso é uma exceção à regra. O sistema não deve cair e congelar. No entanto, esses erros são raros e, em outros casos, deve haver justificativa.

4. Resumo

Discutimos três antipadrões. Três estágios de raiva, negação e justificativa de bugs:

Obviamente - é óbvio para nós que não justificamos isso. E então nós temos “oh, eu esqueci por que eu queria” ... Isso é óbvio apenas para você, somente aqui e agora. Depois de seis meses, você mesmo esquecerá o porquê. Explique quão estúpido, que tipo de evidência existe.
Juro pela minha mãe, está certo! - Por que jurar? Por alguma razão, você acha que é tão certo, então me diga o porquê. Dê um link para os requisitos, por exemplo.
Os coelhos ficaram ofendidos - "Ah, você não adicionou um gato à página principal? Bem, é isso! Fiquei ofendido ... E FOI! E você Perdeu o cliente !! Mas o que é inconveniente para você pode ser conveniente para os outros. Portanto, remova emoções e dê fatos.

Em vez disso, eles devem usar a lógica correta:

Pruflink - TK, Internet, carta do cliente em que ele solicitou essa funcionalidade ...
Uniformidade - Se o sistema sempre funciona dessa maneira e em um lugar diferente, vale a pena corrigi-lo!
Problema - descreva o problema que surgir para você ou o usuário (se estiver se comunicando com os clientes). O problema real é sempre melhor do que apenas um teste negativo.

Escreva por que decidimos que isso é realmente um bug e por que queremos que ele seja corrigido exatamente como escrevemos aqui. Nós nos perguntamos perguntas da série "5 why"

- por que eu acho isso óbvio?
- por que eu acho isso tão certo?
- por que acho que os usuários estão chateados?

Fornecemos links para requisitos na Internet, indicamos uniformidade ou falamos sobre o real problema do usuário.

E quando, depois de um ano, você reler as tarefas executadas com competência, ainda me dirá "Obrigado!" ツ

Padrões de justificação de tarefas e antipadrões