Analisamos em detalhes como realizar testes manuais quando é melhor do que os testes automatizados, o que os testadores precisam ser capazes de fazer e como eles podem construir suas carreiras, do iniciante ao líder. O guia foi preparado em conjunto com o chefe do departamento de testes da Agima Darina Gordeeva.
Oi Meu nome é Darina Gordeeva. Trabalho na empresa AGIMA como chefe do departamento há quase 3 anos. No campo de testes e garantia de qualidade há mais de 6 anos. Durante esse período, ela passou de júnior para chefe de departamento, testando ferro, além de aplicativos móveis e da web, automatizando e configurando processos de controle de qualidade. Hoje vou falar sobre os recursos, capacidades e problemas ocultos do teste manual.
Lembre-se de que qualquer leitor que use a promoção "Habr" pode obter um desconto de 10.000 rublos no seu curso favorito, e os mais diligentes e atenciosos podem obter um desconto de 25.000 rublos resolvendo quebra-cabeças com materiais preparados em conjunto com a agência Agima:
Eficiência, flexibilidade, possibilidade de improvisação e outras vantagens
Hoje existem muitas estruturas de teste que suportam quase todos os idiomas existentes. Parece - você pode pegar e automatizar. Mas mesmo agora, testes manuais são importantes.
Uma das explicações para a necessidade deles é que, com o teste manual do funcional, podemos obter informações sobre o estado do produto que estamos analisando muito mais rapidamente, sobre a qualidade do desenvolvimento. Além disso, durante a automação, casos pré-projetados geralmente precisam ser alterados e atualizados, e leva tempo para escrever autotestes.
Ao mesmo tempo, durante o processo de desenvolvimento, o feedback do cliente pode surgir quando ele vê alguma função no produto final que ele decide alterar antes do lançamento - e se você já preparou testes de software para isso, precisará reescrevê-los. Atualizar casos, autotestes e verificá-los levarão um tempo valioso que pode ser usado para atualizar esse recurso.
Tudo isso significa que o objetivo principal dos testes manuais é primeiro garantir que a funcionalidade declarada seja funcional, que não haja erros e forneça os resultados planejados esperados. Sem eles, você não pode ter certeza de que pode trabalhar. Isso é especialmente verdadeiro para funções cuja implementação está vinculada ao desenvolvimento subsequente. Nesse caso, o barulho com a criação de autotestes para esses recursos se torna um fator de bloqueio para todo o desenvolvimento do produto, alterando os prazos e interrompendo os prazos. O momento em que chega a hora de automatizar os casos chegará mais cedo ou mais tarde - mas não tente trazê-lo artificialmente em busca da exceção total do trabalho manual.
Além disso, nos estágios iniciais do desenvolvimento de aplicativos, a automação pode ser bastante cara. Você precisará de um especialista com qualificações específicas (e possivelmente mais de uma). Manter os testes constantemente atualizados requer recursos até o lançamento do recurso. E os meses de inatividade dedicados a lamber um autoteste atingirão a motivação da equipe.
Se você deseja adicionar regularmente novas funcionalidades e acompanhar as ações dos concorrentes, antes de criar testes automáticos, verifique sempre os recursos do produto manualmente. Só porque o teste manual acelera seus processos.
Isto é especialmente verdade para o desenvolvimento móvel. A maioria desses projetos agora está sendo desenvolvida em sprints curtos, o que significa que os recursos estão sendo implementados em um ritmo acelerado. Nessas condições, o teste manual permite que você dê feedback à equipe o mais rápido possível: relatar a presença de bugs - ou agradá-lo com o fato de que tudo está bem e você pode seguir em frente. Você pode realizar uma série de autoteste posteriormente, cobrindo grandes matrizes de código com a ajuda deles. O teste manual ajudará a preparar casos para esse teste.
Os testes automáticos não permitem verificar se é conveniente usar os novos recursos do aplicativo - o teste de usabilidade é sempre realizado manualmente.
A Skillbox recomenda: O curso on-line do Fullstack é um desenvolvedor para dispositivos móveis .
Nos testes manuais, você pode improvisar, criando combinações malucas de ações que nunca ocorrem ao usuário, mas que podem ser cometidas por ele acidentalmente. Isso permite criar novos casos.
Novos casos também aparecem porque o testador constantemente se faz a pergunta "e se?". Portanto, ele encontra maneiras originais de interagir com o aplicativo - mesmo que não estivessem nos cenários base.
Problemas de teste manual e suas soluções
A maior desvantagem do teste manual é o fator humano. Obviamente, isso afeta tudo o que acontece na equipe - tanto o trabalho dos participantes quanto os eventos que ocorrem no lado do cliente. No caso do controle de qualidade, a razão pela qual o testador está imerso no processo e perde um erro em potencial pode ser qualquer coisa - falta de experiência, problemas familiares ou dor de cabeça.
Dois testadores podem testar o mesmo cenário de maneiras diferentes. O que fazer sobre isso? É importante que todos os resultados inesperados ou diferentes sejam registrados como um caso. Para que qualquer testador possa testá-lo, executando o mesmo conjunto de ações. Mas isso pode não ser suficiente - se o caso não for detalhado o suficiente e o testador não entender a descrição. Obviamente, é impossível garantir a exclusão absoluta do fator humano - mas você pode tentar minimizar a probabilidade dos problemas que ele causa.
Isso também afeta negativamente os termos de entrega de recursos nos custos de produção e mão-de-obra: afinal, agora os casos "complicados" inventados pelos testadores no processo são adicionados aos casos base e regressões periodicamente conduzidos.
A situação é agravada pela probabilidade de que alguns dos erros encontrados ainda não tenham uma descrição estrita, porque os motivos de sua ocorrência ainda não estão claros. Como lidar com esses novos testes? Encontre a fonte do erro e elimine-o, ou - ainda automatize a passagem de casos problemáticos - nesse caso, a transição para testes de software será justificada tanto em termos de tempo quanto em termos financeiros. (Não, isso não contradiz o exposto acima - porque essas situações já surgem no curso do desenvolvimento ativo e, nesse momento, você deverá, de qualquer forma, implantar processos de teste automático).
De qualquer forma, a aparência dos primeiros casos que precisam de testes de regressão ou o lançamento da segunda versão do aplicativo e o dimensionamento da equipe correspondente a esses eventos é o momento em que a automação se torna relevante (mas não exclui o teste manual de novos recursos). Nesse estágio, a automação já começará a economizar tempo: o próprio desenvolvedor, mesmo antes da transferência para o departamento de controle de qualidade, pode iniciar os testes de regressão do novo recurso para garantir que não interrompa a funcionalidade existente e que o testador não precise mais uma vez passar pelos casos básicos que ficaram doloridos. Outra vantagem da implementação de autotestes nesse estágio é que você pode executá-los de acordo com um determinado agendamento - todas as noites, nos dias do final dos sprints ou ao publicar novas construções do aplicativo.
Nesse caso, não se deve esquecer várias coisas:
- criar casos e escrever autotestes levará tempo - coloque-o em sprints;
- verifique se o caso de autoteste está bem escrito e detalhado e descreve um possível problema ou cenário existente na sua totalidade;
- verifique se o autoteste funciona corretamente e se realmente verifica o que é necessário e o faz qualitativamente.
Resumimos: o teste manual oferece uma grande vantagem nos custos de velocidade e mão-de-obra nos estágios iniciais e, à medida que o aplicativo cresce e um grande número de testes de regressão aparece, ele entra na categoria de "teste operacional" de novos recursos em um sprint separado. Será relevante e, se necessário, verificar urgentemente como o aplicativo responderá a alterações no sistema operacional ou na atualização do ambiente.
Fases de teste: o que, quando e como
Se você observar o processo de desenvolvimento como um todo e os testes como uma de suas partes, com o planejamento adequado, sempre entenderá o que e quando estará pronto. Isso permitirá que você planeje melhor o tempo de determinadas ações - uma vez que alguns eventos seguem logicamente outros e você tem a oportunidade de organizá-los em cadeias com base em suas expectativas.
O testador aparece no processo de criação do aplicativo nos estágios iniciais. Aqui o cliente tem uma certa idéia, os analistas de negócios coletam esse requisito - e os testadores já começam a trabalhar, verificando esses requisitos.
Como está indo isso? Eles fazem perguntas sobre a funcionalidade pretendida. Eles estão tentando imaginar como o aplicativo ficará quando for implementado. Se estamos falando de um novo recurso em um produto existente - eles descobrem como ele irá interagir com a funcionalidade existente. Depois que os desenvolvedores avaliaram a complexidade das idéias do cliente e determinaram quanto tempo é necessário para sua implementação.
Depois disso, a fase de design começa. Aqui torna-se necessário entender como as transições entre telas serão realizadas, determinados campos a serem validados, como o aplicativo ou sua função separada geralmente interage com o usuário final. No caso de recursos, é importante entender como eles serão incluídos na arquitetura de um aplicativo existente.
No estágio de design , quando um mapa de transições entre telas é criado, o testador esclarece o comportamento dos elementos individuais dos quais eles consistem e quais efeitos visuais acompanharão determinadas ações do usuário. Além disso, o testador valida os layouts para garantir a integridade, confirmando que eles exibem tudo o que é necessário para implementar a funcionalidade pretendida. Também será útil verificar independentemente os layouts quanto à conformidade com as diretrizes.
A Skillbox recomenda: curso on - line Design de Aplicativos Móveis
Com o início do desenvolvimento, os especialistas em controle de qualidade começam imediatamente a escrever casos de teste. Em diferentes estágios de desenvolvimento, eles podem ter um nível diferente de detalhes, mas, no final, é desejável garantir a cobertura máxima de todos os casos de produtos, para que, após receber a montagem, você possa começar a testar imediatamente.
A primeira etapa do teste em si é o teste de fumaça: uma avaliação de que o aplicativo ou sua nova parte geralmente está pronta para verificação. Um teste de fumaça é um teste para saber se um aplicativo ou uma função específica é iniciada em princípio.
Um teste de fumaça é uma maneira rápida de ver se podemos começar o teste funcional. O termo veio dos criadores de placas de circuito e microcircuitos, que primeiro tiveram que garantir que o novo circuito não queimasse - daí o nome: defumado / não defumado.
Essa é uma maneira rápida de garantir que realmente passemos a tarefa e que ela possa ser levada ao trabalho e não enviada de volta aos programadores.
Usando o formulário de autorização como exemplo, uma fumaça é uma avaliação de se você pode efetuar login, sem especificar se os dados inseridos nos campos são válidos, se recursos adicionais, como lembretes de senha e outras coisas, funcionam. Se pudéssemos efetuar login em princípio, podemos prosseguir para uma verificação mais aprofundada deste módulo: obter casos negativos, valores de limite, avaliar a conformidade com as regras de validação estabelecidas.
A próxima etapa é a realização de testes de regressão. No modo manual ou automático, é executado o principal conjunto de testes pré-planejados.
O teste de regressão é bom porque permite encontrar erros mesmo nos locais onde tudo estava em ordem antes. Isso se deve ao fato de que a regressão é uma avaliação da funcionalidade em um conjunto padrão de casos durante a implementação de cada novo módulo e cada alteração de aplicativo. De fato, quando os desenvolvedores adicionam novas funcionalidades, a versão atual pode ser danificada ou um novo recurso pode entrar em conflito com os existentes.
Por exemplo, adicionar novas telas e, portanto, alterar a navegação, pode atrapalhar o funcionamento do menu ou, pelo menos, exibi-lo. Por outro lado, a refatoração global do código do aplicativo pode trazer surpresas desagradáveis - depois disso, também é necessário realizar testes de regressão.
Os problemas podem ser causados pela atualização da biblioteca usada pelo aplicativo e pela alteração do ambiente em que ele funciona. Quanto mais você atualiza o aplicativo, mais importantes são as verificações de regressão. Não se limite a uma verificação única, realizada quando o recurso já estiver implementado - verifique todas as alterações. A automação do teste de regressão o ajudará aqui - simplesmente porque o teste de regressão manual de um novo recurso que foi criado em apenas uma semana pode demorar dois ou mais, e o departamento de testes simplesmente ficará preso nisso.
Uma verificação completa, é claro, é realizada quando o candidato a release com um ou mais recursos está pronto para iniciar a produção, mas ainda é necessário aplicar certos casos relevantes em determinados estágios de desenvolvimento.
Tudo termina com o teste da montagem final - candidato à liberação. Isso inclui verificar a versão beta por testadores internos, testes de negócios - avaliar o produto resultante pelo cliente e receber feedback dele, além de convidar um determinado grupo de usuários a se familiarizar com a versão alfa de pré-lançamento do aplicativo ou seus novos recursos. Depois disso, o aplicativo está pronto para ser lançado na produção.
Mas o trabalho do especialista em controle de qualidade não termina aí - ele terá que testar as atualizações de aplicativos e sua compatibilidade com versões anteriores, compilar casos para verificar inovações e, se necessário, automatizar a passagem desses cenários.
Paralelamente, os testadores participam de análises adicionais das estatísticas coletadas pelos analistas, monitorando o comportamento do aplicativo e como os usuários interagem com ele. Isso permite não apenas ver o uso ao vivo dos resultados de seu trabalho, mas também, às vezes, descobrir novos cenários e erros desconhecidos que causam a falha do aplicativo.
Tempo de réplica: adivinhe e um desconto de 10% em qualquer curso do Skillbox está esperando por você no momento ou mostre perseverança e colete respostas para todos os rebuses - esses descontos se somam (mas sem outros descontos nos cursos do Skillbox).
No entanto, você não deve demorar muito. A promoção funciona até 30 de agosto de 2018. Lembre-se de que o assunto do enigma é um celular, e as palavras em inglês podem interferir no russo aqui, portanto, tenha cuidado! Envie uma inscrição para o curso e, quando o gerente entrar em contato com você, forneça uma mensagem criptografada em um novo jogo (ou alguns!).
Formalização de teste: plano de teste, formato de relatórios de erros, relatórios
Para se preparar para os testes funcionais, um engenheiro de QA elabora um plano de teste. Esta é a documentação que ele precisará ao testar o produto, uma lista de ações que ele precisará executar. O plano de teste indica o momento do teste, descreve o produto ou uma tarefa específica - para determinar exatamente o que precisa ser verificado. Todos os principais casos de teste são descritos em detalhes. Lista os tipos de teste necessários: funcional e, por exemplo, estresse. O procedimento para automatizar certos casos e os estágios em que eles serão automatizados são descritos.
O plano de teste termina com uma descrição do formato do relatório: você precisa explicar com antecedência de que forma o resultado será fornecido. O formato de relatório mais comum é uma lista de casos de teste com o status de sua passagem. Sabendo como os casos abrangem todo o volume de requisitos e depois de ler o relatório, podemos concluir sobre o estado atual do desenvolvimento de aplicativos. Para fazer isso, basta ver quantos deles foram concluídos com êxito em uma ou outra montagem.
A aprovação final, indicando que o produto está pronto, é o status "todos os requisitos são cobertos por casos, todos os casos são concluídos com êxito".
Além disso, o plano de teste formaliza o formato do relatório de erros. Pode ser uma lista de erros, uma lista de tarefas no rastreador.
A tarefa do testador é fornecer as informações mais completas sobre a qualidade do produto a todos os membros da equipe.
O que você precisa saber e poder se tornar um testador
Primeiro de tudo, o testador deve ser capaz de pensar e estar atento e assíduo. A experiência é importante - permite que você acumule certas conquistas e consolide o conhecimento dos processos de teste, transformando-os em habilidades.
Um especialista em teste manual não precisa ser capaz de escrever código e ter um profundo entendimento da arquitetura. Isso não o impede de verificar a funcionalidade e entender os princípios de interação entre o aplicativo e o servidor no nível do aplicativo.
Um especialista em testes automatizados é uma profissão separada, com um conjunto de conhecimentos completamente diferente.
O autoteste de alta qualidade não é apenas scripts, mas também um entendimento de como o aplicativo é construído a partir de dentro e habilidades específicas, como saber como paralelizar testes ou executá-los na nuvem ou em vários servidores. Somente esse conjunto de habilidades nos permite orgulhar-se de "engenheiro de automação com letra maiúscula". Portanto, sem o conhecimento de idiomas, suas estruturas, os princípios da OOP e o monitoramento cuidadoso do desenvolvimento da tecnologia, este autotester não pode fazer isso.
, , . , — -. — , , — , . -. - . , .
( , ) , , . — , -.
- — , , , .
-, , — — . , .
— -. , , — , , .
- — -. , , , , , DevOps, , .
— , “Fullstack- ”. , . !
A Skillbox recomenda: