1. Introdução
Boa tarde, residentes de Khabrovsk. Eu estava resolvendo uma tarefa de teste para um trabalho de QA Lead de uma empresa de fintech no momento. A primeira tarefa, elaborar um plano de teste com uma lista de verificação completa e exemplos de casos de teste para verificar uma chaleira elétrica, é trivialmente resolvida:
Mas a segunda parte acabou sendo uma pergunta: "Existem problemas comuns a todos os testadores que interferem no trabalho com maior eficiência?"
A primeira coisa que me veio à mente foi listar todos os problemas mais ou menos perceptíveis que encontrei durante o teste, eliminar pequenas coisas e generalizar o resto. Mas ele rapidamente percebeu que o método indutivo responderia a uma pergunta relacionada não a "todos", mas, na melhor das hipóteses, apenas à "maioria" dos testadores. Por isso, decidi me aproximar do outro lado, dedutivo, e foi o que aconteceu.
Definições
A primeira coisa que costumo fazer ao resolver uma nova tarefa é tentar entender do que se trata, e para isso você precisa entender o significado das palavras que ela apresenta. As palavras-chave a serem entendidas são as seguintes:
- o problema
- testador
- trabalho testador
- desempenho do testador
Acesse a Wikipedia e o bom senso:
O problema (dr. Grego πρόβλημα) no sentido amplo é uma questão teórica ou prática complexa que requer estudo, resolução; na ciência - uma situação contraditória, atuando na forma de posições opostas na explicação de qualquer fenômeno, objeto, processo e exigindo uma teoria adequada para resolvê-lo; na vida, o problema é formulado de maneira que as pessoas entendam: "Eu sei o que, não sei", isto é, sabemos o que precisa ser recebido, mas não se sabe como fazê-lo. Vem tarde lat Problemēma, do grego πρόβλημα "jogado para a frente, colocado na frente"; de προβάλλω “jogue para a frente, situado na sua frente; culpa ".
Não há muito sentido, de fato, "problema" = "qualquer coisa com que lidar".
O testador é um especialista (não vamos nos dividir em tipos, pois estamos interessados em todos os testadores), que participa do teste de um componente ou sistema, cujo resultado é:
O trabalho do testador é um conjunto de atividades relacionadas ao teste.
Eficiência (lat. Effectivus ) - a razão entre o resultado alcançado e os recursos utilizados ( ISO 9000 : 2015).
Um resultado é uma conseqüência de uma cadeia (sequência) de ações (total) ou eventos expressos qualitativa ou quantitativamente. Os possíveis resultados incluem vantagem, inconveniência, ganho, perda, valor e vitória.
Como no “problema”, há pouco sentido: algo que surgiu como resultado do trabalho.
Recurso - capacidade quantitativamente medida de realizar qualquer atividade de uma pessoa ou pessoas; condições que permitem o uso de certas transformações para obter o resultado desejado. Um testador é uma pessoa e, de acordo com a teoria dos recursos vitais, cada pessoa é proprietária de quatro ativos econômicos:
dinheiro (renda) - um recurso renovável;
energia (vitalidade) - um recurso parcialmente renovável;
tempo - um recurso fixo e fundamentalmente não renovável;
conhecimento (informação) - um recurso renovável, faz parte do capital humano, que pode crescer e entrar em colapso [1] .
Quero observar que a definição de eficácia em nosso caso não é totalmente correta, pois quanto mais conhecimento usamos, menor é a eficiência. Portanto, redefiniria a eficiência como “a relação entre o resultado alcançado e os recursos gastos”. Então, tudo está correto: o conhecimento no trabalho não é desperdiçado, mas reduz o custo do único recurso fundamentalmente não renovável do testador - o seu tempo.
Solução
Portanto, estamos procurando problemas globais de testadores que piorem a eficácia de seu trabalho.
O recurso mais significativo gasto no trabalho do testador é seu tempo (o restante pode ser trazido a ele de uma maneira ou de outra) e, para falarmos sobre o cálculo correto da eficiência, precisamos levar o resultado ao tempo.
Para fazer isso, considere um sistema cuja viabilidade o testador fornece com seu trabalho. Esse sistema é um projeto cuja equipe inclui um testador. O ciclo de vida do projeto pode ser representado aproximadamente pelo seguinte algoritmo:
- Trabalhar com requisitos
- Formação de especificações técnicas
- Desenvolvimento
- Teste
- Liberar em produção
- Suporte (vá para p.1)
Além disso, todo o projeto pode ser recursivamente dividido em subprojetos (recursos), com o mesmo ciclo de vida.
Do ponto de vista do projeto, a eficácia de sua implementação é maior, menos tempo é gasto nele.
Assim, chegamos à determinação da máxima eficácia possível do testador do ponto de vista do projeto - este é o estado do projeto quando o tempo para o teste é zero. Um problema comum para todos os testadores é a incapacidade de atingir esse tempo.
Como lidar com isso?
As conclusões são bastante óbvias e há muito são usadas por muitos:
- O desenvolvimento e o teste devem começar e terminar quase simultaneamente (isso geralmente é feito pelo departamento de controle de qualidade ). A opção ideal é quando toda a funcionalidade desenvolvida no momento em que estiver pronta já estiver coberta por autotestes organizados em testes de regressão (e, se possível, pré-confirmação) usando algum IC .
- Quanto mais recursos no projeto (mais complicado), mais tempo você gastará para verificar se a nova funcionalidade não quebrou a antiga. Portanto, quanto mais complexo o projeto, mais automação é necessária no teste de regressão .
- Cada vez que pulamos um bug na produção e o usuário o encontra, precisamos dedicar mais tempo ao ciclo de vida do projeto, começando na etapa 1 (Trabalhando com requisitos, neste caso, usuários). Como as razões para a falta de um bug geralmente são desconhecidas, temos apenas uma maneira de otimizar - cada bug encontrado pelos usuários deve ser incluído no teste de regressão para garantir que ele não apareça novamente.