Para começar, entre as pessoas, todos os engenheiros de garantia de qualidade (“à nossa maneira”, engenheiros do departamento de qualidade) são chamados de testadores. Isso não está totalmente correto, na realidade o teste é apenas parte das tarefas de controle de qualidade, mas quem se importaria. Portanto, vamos à tendência geral e usaremos a unidade usual para todos.
Então, o que determina um bom testador? Nós não vamos nos inclinar para as banalidades e dizer: atenção, perseverança, paciência, curiosidade, talento, tudo quebra e outras bobagens. Isso é tudo, é claro, importante, mas não é o principal. Antes de tudo, uma pessoa deve ter um senso de senso comum e responsabilidade.
Por exemplo, eles dizem, o principal é ter o talento para quebrar tudo. Muitas vezes você pode ouvir, eles dizem que ele não vai atender, vai quebrar tudo. É claro que isso é louvável, mas o trabalho do testador não é a principal coisa para quebrar alguma coisa. Aqui, uma definição virá em nosso auxílio, o que não é difícil de encontrar na Wikipedia.
Teste de software é o processo de pesquisar, testar um produto de software, destinado a verificar a correspondência entre o comportamento real do programa e o comportamento esperado em um conjunto finito de testes selecionados de uma determinada maneira.
Isso mostra que existem requisitos específicos para o software e é necessário que eles sejam atendidos. Se o testador interrompeu o programa em vez de verificar se ele executa as funções atribuídas a ele, como resultado, ele pode ficar estável, mas não necessário, lixo para o cliente.
Eu entendo que todo mundo adora histórias, como alguém estragou tudo, eu as tenho. No meu trabalho, trabalhei em lugares diferentes e em projetos diferentes, por isso fui testemunha ou ouvi muitas histórias de meus colegas. Alguns deles estão prontos para contar. Bem, sim, o mantra necessário: todas as coincidências são aleatórias e nomes são inventados.
Teste e mais
Vamos começar em ordem. Como eu disse no começo, o testador não está apenas testando. Como você gosta de um trocadilho? Em empresas grandes e respeitáveis, eles tentam conectar a equipe de teste ao projeto em um estágio inicial, ou seja, na fase de coleta de requisitos, mas isso não é feito em todos os lugares e nem sempre.
Uma vez durante o teste de aceitação, o usuário iniciou um bug crítico, porque um dos requisitos não foi cumprido. A essência da alegação era que o usuário na tela não encontrou o atributo que precisava (para aqueles que estavam no tanque - um campo com um valor). O testador, é claro, subiu na especificação, verificou se esse atributo estava presente no aplicativo e correu com alegria para dizer ao usuário que estava tudo bem.
Você já entende que a história não termina aí.
O testador tentou explicar ao usuário em que estava errado, tendo encontrado uma porção de negatividade e indignação. O usuário sentou-o e descobriu os requisitos com base nos quais as especificações foram escritas. Um desses requisitos quase literalmente é o seguinte: "O atributo deve ser exibido em todas as telas". Uma frase, mas que sentido! Em seguida, ele abriu o aplicativo e começou a navegar aleatoriamente para diferentes telas, dizendo: "E onde está esse atributo?" É claro que o usuário zombou abertamente, mas formalmente ele tinha o direito de fazê-lo. O problema é que a escalada continuou, e mais e mais pessoas estavam envolvidas na discussão do problema. No final do usuário, além do próprio testador, vários PMs e uma multidão de analistas o convenceram, e ele foi inflexível e exigiu o impossível.
Como resultado, foi encontrado um compromisso e, na solicitação, apareceu uma lista das telas necessárias nas quais o atributo deveria estar localizado, mas isso exigiu grandes alterações no código do programa; portanto, todo o ciclo de desenvolvimento teve que ser reexecutado, mas em um ritmo acelerado. A empresa gastou dinheiro extra, sem mencionar os custos de reputação, para o estresse e o processamento dos funcionários. Tudo isso poderia ter sido evitado se o testador estivesse conectado no início do projeto e ele pudesse ver os requisitos de ambiguidade - pelo menos, ou mais tarde, para verificar a especificação quanto à conformidade com os requisitos. E sim, os testadores geralmente trabalham diretamente com usuários reais, o que exige que eles lidem com a redução do estresse, psicanálise e percepção extra-sensorial.
Sem fanatismo
Iremos além, muito ironicamente, o próprio processo de teste é caracterizado por uma anedota barbada:
Uma vez que o testador entra na barra.
Corre para o bar.
Rasteja no bar.
Dançando, penetra no bar.
Esgueirando-se para um bar.
Invade o bar.
Salta para o bar.
Encomendas:
uma caneca de cerveja
2 copos de cerveja
0 copos de cerveja
999999999 canecas de cerveja,
lagarto em um copo
-1 xícara de cerveja
canecas de cerveja qwerty.
O primeiro cliente real entra no bar e pergunta onde fica o banheiro. O bar explode em chamas, todo mundo morre.
Nem todo mundo entende que você pode testar infinitamente. O ideal é inatingível, e os projetos têm prazos muito específicos nos quais se encaixar. Portanto, havia um testador que, ao passar no caso de teste, falha constantemente nele. O tempo passou, o projeto já havia começado ao fim e o desenvolvedor superou todos os problemas encontrados. E aqui o testador declara que a funcionalidade básica necessária não funciona. Todo mundo entende: não vai funcionar para consertar a tempo.
No decorrer do processo, verifica-se: durante o teste, o script nunca foi concluído completamente até o momento infeliz. O testador encontrou uma falha no início do processo, que testou, iniciou um ticket e jogou até a metade. Ao mesmo tempo, foi possível continuar testando, porque Todos os erros encontrados não o bloquearam. Posteriormente, toda a equipe tem estresse e processamento tradicionais.
A propósito, alguns usuários cometem isso nos testes de aceitação, declaram o erro crítico e encerram o trabalho. Isso complica muito o trabalho, porque no fluxo geral de problemas, que em geral pode não ser um problema, erros realmente críticos são perdidos.
A moral é a seguinte: um bom testador nunca para de encontrar o primeiro bug que aparece. Ele percorrerá todo o script do começo ao fim, registrando simultaneamente todos os erros encontrados e, se ocorrer um erro ao bloquear a passagem, procurará uma solução alternativa, ou seja, solução alternativa. E quando ele estiver convencido de que não há soluções alternativas, ele irá parar.
Há uma ressalva. Na maioria das vezes, os projetos são realizados com prazos apertados ou pouco, mas bastante específicos. Acontece que uma pessoa é pulverizada em testes sem fim de um campo, introduzindo nele todas as variantes possíveis e impossíveis de valores. Além disso, de acordo com os requisitos do cliente, é necessário verificar a função desempenhada pelo aplicativo, embora utilizando o valor desse campo. Como resultado, ele corre o risco de perder tempo e não verificar o principal. O testador deve poder avaliar corretamente seus pontos fortes e pontos críticos da aplicação. Não há necessidade de testar os locais que não exigem teste. O principal é que o aplicativo deve cumprir a função atribuída a ele. Primeiro, você precisa conseguir a execução de um cenário direto e depois melhorar a qualidade da execução no nível desejado.
Minha língua é minha inimiga
Além disso ... Os problemas com a documentação podem ser não apenas para analistas, mas também para testadores. Observou-se repetidamente que não apenas os desenvolvedores não são capazes de descrever claramente o conteúdo do ticket em seu campo correspondente, mas os próprios testadores não podem escrever corretamente a ordem das ações que causam o erro. Este é um grande problema. Alguém simplesmente não entende por que o erro ocorre e não se preocupa em descobrir as etapas. Alguém tem problemas de alfabetização.
O que tudo isso implica? Aqui a resposta e o ouriço são compreensíveis, mas com os exemplos, é claro, mais interessantes.
Há uma coorte de testadores que, vendo um erro à sua frente, simplesmente registram esse milhão de etapas, incluindo o lixo que levou ao bug. Eles não reproduzem o erro e não descobrem exatamente o que é feito. Ao mesmo tempo, eles podem anotar um conjunto de etapas que não está associado a esse erro. O desenvolvedor tentará se reproduzir, em algum momento sua cabeça ferverá e ele irá lidar pessoalmente com o testador. Eles entenderão juntos e passarão muito tempo com comunicações desnecessárias. Felizmente, tudo isso é tratado rapidamente pelo tempo e pela experiência, embora existam casos clínicos.
A alfabetização está ficando mais difícil. Na minha prática, houve um caso em que o lead de controle de qualidade precisava corrigir a descrição de várias dezenas de tickets, porque eles deveriam ter sido enviados ao cliente em um relatório de progresso. Isso aconteceu porque a maioria da equipe não conseguiu formular corretamente seus pensamentos em inglês.
Mas também há problemas com o russo, graças a Deus, com menos frequência. Tudo é o mesmo aqui, uma descrição mal escrita leva ao fato de que o bilhete, como uma bola de futebol, começa a galopar entre as pessoas sem entrar no gol. É bom que a equipe esteja na mesma sala e possa conversar sem se levantar do monitor. Mais difícil - se a equipe estiver distribuída. Muito ruim, se multilíngue. A pior coisa que pode acontecer no final é que o ticket será feito incorretamente devido a um mal-entendido e será reaberto mil vezes. E até o cliente voará para longe em um dos lançamentos com lógica invertida.
Espaço pessoal
Outro problema são bancos de teste e dados de teste. Em empresas diferentes, isso acontece de maneiras diferentes, mas geralmente acontece que um funcionário recebe direitos do servidor de trabalho de um cliente ou recebe seu banco de dados para teste. Parece que o que poderia dar errado?
Mas dofiga do que ... Se alguém tiver acesso ao servidor do cliente, por um lado, é conveniente, você pode analisar os problemas das primeiras fileiras e não cometer erros na foto. Mas existe o risco de estragar os dados do cliente, o que pode levar a sérias conseqüências. Já estou em silêncio sobre os casos em que esse acesso é geralmente proibido por lei.
Houve um caso em que um cliente caiu de um servidor por 3 dias. O desenvolvedor todo esse tempo não conseguiu entender por que isso aconteceu e procurou freneticamente por um erro, e os negócios sofreram perdas. Como resultado, descobriu-se: a empresa contratou índios para terceirizar, onde as pessoas, sem mais delongas, deram todos os direitos de administrador. Para todos - isso significa até mesmo a garota que trabalha há 3 dias na empresa, e não havia computador em sua aldeia, para que tenham um período de namoro mais curto. Mas a garota revelou-se terrivelmente talentosa, ela conseguiu encontrar a essência básica no painel de administração e mudou seu tipo, após o que tudo naturalmente caiu e parou de funcionar. É fácil adivinhar como ela saiu da carreira depois disso.
O mesmo absurdo e com dados do cliente. Mais uma vez, não estou falando de casos em que é proibido por lei. Se é possível trabalhar com dados reais, tudo bem, mas é preciso ter cuidado com isso. Todos provavelmente ouviram histórias sobre o envio aleatório de cartas ou mensagens de um servidor de teste para usuários reais. Então, essas não são piadas. Isso realmente acontece e com bastante frequência. Tudo bem, se essas mensagens tiverem direito como mensagens de teste e tiverem um conteúdo sensato, mas acontece que as pessoas estão fingindo escrever algo que toda a equipe de desenvolvimento de aplicativos se arrepende.
Momentos organizacionais
Eu já comecei a me aborrecer com uma abundância de texto, então o último. O testador deve fornecer constantemente ao seu chefe informações atualizadas sobre seu trabalho. De acordo com esses relatórios, se eles forem feitos corretamente, o chefe fará uma conclusão sobre o estado do projeto como um todo. Não apenas sobre o trabalho de um testador ou toda a equipe de teste, mas também sobre o trabalho da equipe de desenvolvimento e o estágio em que o projeto está. Além disso, esses relatórios permitem que a análise seja planejada para versões futuras, etc., etc.
Existem muitos exemplos em que esse trabalho não foi realizado ou de forma inadequada, a partir do qual as autoridades tiveram um sentimento de incerteza com todas as conseqüências resultantes. Eu vou te dizer o mais brilhante.
Uma vez que o testador foi colocado em um novo projeto. Como ele não o conhecia bem, ele recebeu a tarefa de classificar e registrar as observações. Como era algo informal, concordamos que escreveríamos no Googledock. O homem começou a realizar a tarefa; uma semana depois, essa tarefa foi verificada, o testador deu um tapinha no ombro e ele continuou a trabalhar. Meses se passaram, as autoridades começaram a se preocupar por que não há tickets no bugtracker e nada está sendo feito no projeto. Começamos a descobrir, mas uma pessoa continua escrevendo naquele mesmo Googledock. Ninguém disse “Potty, não cozinhe” e não parou o testador, e ele continuou a entender e registrar observações regularmente, sem se informar. Existem bugs, e ele os encontrou, mas não contou a ninguém, mas apenas os anotou em um arquivo que todos esqueceram uma semana depois.
De fato, a expectativa era que uma pessoa continuasse a trabalhar já formalmente, ou seja, no rastreador de erros, fornecendo tickets aos desenvolvedores com seus tickets, mas isso não aconteceu. Parecia que o homem não fez nada, embora ele trabalhasse. É claro que o problema não era apenas da parte do testador, mas se ele fizesse um relatório regular de suas atividades, os mal-entendidos poderiam ser evitados.
Freqüentemente, a falta de informações cria a sensação de um teste de produto ruim, que essa ou aquela parte da funcionalidade não foi testada. Para impedir que isso aconteça, você precisa fazer relatórios detalhados, isso é especialmente importante para projetos grandes.
Conclusão
Você precisa entender que o controle de qualidade é, de fato, o advogado do usuário. Em qualquer situação incompreensível relacionada ao aplicativo, o testador deve se colocar no lugar dele. Se, com essa simples manipulação da consciência, o aplicativo não estiver satisfeito com alguma coisa, será necessário iniciar um ticket. E isso pode ser um botão no lugar errado ou outra ninharia do ponto de vista do desenvolvedor, mas geralmente acontece que, para um usuário, essa ninharia pode se transformar em inferno e em um ponto de irritação. Como exemplo, você pode pegar um grande número de pop-ups no aplicativo. Sim, o programa executa sua função, mas é difícil usá-lo, porque a execução dessa função exige muito tempo e esforço de um usuário que é forçado a pressionar várias janelas extras com downloads e muito mais, em vez de fazer todo o trabalho em uma tela.
E se uma pessoa responsável e com bom senso abordar seu trabalho, será capaz de evitar a maioria dos problemas em seu caminho, não apenas na profissão de controle de qualidade.