Introdução
Boa tarde, residentes de Khabrovsk. Agora há pouco eu estava resolvendo uma tarefa de teste para uma vaga de líder de controle de qualidade para uma empresa fintech. A primeira tarefa, criar um plano de teste com uma lista de verificação completa e exemplos de casos de teste para testar uma chaleira elétrica, pode ser resolvida trivialmente:
É difícil pensar em um plano de teste melhor com uma lista de verificação completa.
Mas a segunda parte acabou sendo uma pergunta: “Existe algum problema comum a todos os testadores que os impeça de trabalhar com mais eficiência?”
A primeira coisa que me veio à mente foi listar todos os problemas mais ou menos perceptíveis que encontrei durante os testes, eliminar as pequenas coisas e resumir o resto. Mas rapidamente percebi que o método indutivo responderia a uma questão que não se aplicava a “todos”, mas, na melhor das hipóteses, apenas à “maioria” dos testadores. Portanto, resolvi abordar pelo outro lado, dedutivamente, e foi isso que aconteceu.
Definições
A primeira coisa que costumo fazer ao resolver um novo problema é tentar entender do que se trata, e para isso preciso entender o significado das palavras que o colocam. As palavras-chave a serem compreendidas são as seguintes:
- problema
- testador
- trabalho de testador
- eficiência do testador
Vamos recorrer à Wikipedia e ao bom senso:
(grego antigo πρόβλημα) em sentido amplo - uma questão teórica ou prática complexa que requer estudo e resolução; na ciência - uma situação contraditória que aparece na forma de posições opostas na explicação de quaisquer fenômenos, objetos, processos e requer uma teoria adequada para resolvê-la; na vida, o problema é formulado de uma forma compreensível para as pessoas: “Eu sei o que, não sei como”, ou seja, sabe-se o que precisa ser obtido, mas não se sabe como fazê-lo . Vem de tarde. lat. problema, do grego. πρόβλημα “lançado para frente, colocado na frente”; de προβάλλω “jogue para frente, coloque na sua frente; culpa".
Na verdade, não faz muito sentido “problema” = “qualquer coisa que precise ser resolvida”.
- um especialista (não vamos dividir em tipos, pois todos os testadores nos interessam) que participa do teste de um componente ou sistema, cujo resultado é:
— um conjunto de atividades relacionadas com testes.
(lat. effectivus) - a relação entre o resultado alcançado e os recursos utilizados (: 2015).
- consequência de uma cadeia (série) de ações (resultado) ou eventos, expressas qualitativa ou quantitativamente. Os resultados possíveis incluem vantagem, desvantagem, ganho, perda, valor e vitória.
Tal como acontece com o “problema”, há pouco significado: algo que surgiu como resultado do trabalho.
- a possibilidade quantitativamente mensurável de realizar qualquer atividade de uma pessoa ou pessoas; condições que permitem utilizar certas transformações para obter o resultado desejado. O testador é uma pessoa e, de acordo com a teoria dos recursos vitais, cada pessoa é proprietária de quatro ativos econômicos:
o dinheiro (renda) é um recurso renovável;
a energia (força vital) é um recurso parcialmente renovável;
o tempo é um recurso fixo e fundamentalmente não renovável;
o conhecimento (informação) é um recurso renovável, faz parte do capital humano que pode crescer e ser destruído.
Gostaria de salientar que a definição de eficiência no nosso caso não é totalmente correta, pois quanto mais conhecimento utilizamos, menor é a eficiência. Portanto, eu redefiniria eficiência como “a relação entre os resultados alcançados e os recursos despendidos”. Então está tudo correto: o conhecimento não é desperdiçado durante o trabalho, mas reduz os custos do único recurso fundamentalmente não renovável do testador - o seu tempo.
Solução
Portanto, procuramos problemas globais dos testadores que prejudiquem a eficácia do seu trabalho.
O recurso mais significativo que se gasta no trabalho de um testador é o seu tempo (o resto pode ser reduzido a ele de uma forma ou de outra), e para que possamos falar sobre o cálculo correto da eficiência, o resultado também deve ser reduzido ao tempo .
Para isso, considere um sistema cuja viabilidade o testador garanta através do seu trabalho. Tal sistema é um projeto cuja equipe inclui um testador. O ciclo de vida do projeto pode ser representado aproximadamente pelo seguinte algoritmo:
- Trabalhando com Requisitos
- Formação de especificações técnicas
- Desenvolvimento
- Teste
- Lançamento em produção
- Suporte (vá para o item 1)
Neste caso, todo o projeto pode ser dividido recursivamente em subprojetos (features), com o mesmo ciclo de vida.
Do ponto de vista do projeto, quanto menos tempo gasto nele, mais eficaz é a sua implementação.
Assim, chegamos à definição da máxima eficiência possível de um testador do ponto de vista do projeto - este é o estado do projeto quando o tempo de 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 têm sido utilizadas por muitos há muito tempo:
- O desenvolvimento e os testes devem começar e terminar quase simultaneamente (isso geralmente é feito pelo departamento ). A opção ideal é quando toda a funcionalidade em desenvolvimento já estiver coberta por autotestes no momento em que estiver pronta, organizada em testes de regressão (e, se possível, pré-commit) usando algum tipo de .
- Quanto mais recursos um projeto tiver (quanto mais complexo ele for), mais tempo terá que ser gasto para verificar se a nova funcionalidade não quebra a antiga. Portanto, quanto mais complexo o projeto, mais automação é necessária .
- Cada vez que perdemos um bug na produção e um usuário o encontra, temos que gastar mais tempo percorrendo o ciclo de vida do projeto começando do ponto 1 (Trabalhando com requisitos, neste caso, usuários). Como as razões para a falta de um bug são geralmente desconhecidas, ficamos com apenas um caminho de otimização - cada bug encontrado pelos usuários deve ser incluído no teste de regressão para ter certeza de que não aparecerá novamente.
Fonte: habr.com