Introdução
Boa tarde, hubrenses. Estava resolvendo uma tarefa de teste para uma vaga de QA Lead em uma empresa fintech. A primeira tarefa, elaborar um plano de teste com uma lista completa de verificação e exemplos de casos de teste para verificar um bule elétrico, é trivial.
É difícil imaginar um melhor plano de teste com uma lista completa de verificação.
Já a segunda parte foi a pergunta: “Existem problemas comuns a todos os testadores que dificultam trabalhar com mais eficiência?”.
A primeira coisa que me ocorreu: enumerar todos os problemas mais ou menos notáveis que enfrentei durante os testes, separar as pequenas coisas e generalizar o restante. Mas percebi rapidamente que o método indutivo responderia a uma pergunta que se referia não a “todos”, mas, na melhor das hipóteses, apenas à “maioria” dos testadores. Portanto, decidi abordar de outra forma, de maneira dedutiva, e aqui está o que eu consegui.
Definições
A primeira coisa que geralmente faço ao resolver uma nova tarefa é tentar entender sobre o que ela realmente se trata, e para isso, preciso entender o significado das palavras usadas. As palavras-chave que precisam ser entendidas são as seguintes:
- problema
- testador
- trabalho do testador
- eficiência do trabalho do testador
Vamos consultar a Wikipédia e o bom senso:
(do grego antigo πρόβλημα) em um sentido amplo — uma questão teórica ou prática complexa que requer estudo ou resolução; na ciência — uma situação contraditória que aparece sob a forma de posições opostas na explicação de certos fenômenos, objetos, processos e requer uma teoria adequada para sua resolução; na vida, um problema é formulado de maneira compreensível para as pessoas como "sei o que, não sei como", ou seja, sabe-se o que é preciso obter, mas não se sabe como fazê-lo. Origina-se do latim tardio problēma e do grego πρόβλημα "projetado para frente, colocado à frente"; derivado de προβάλλω "lançar adiante, apresentar diante de si; acusar".
Significado não é muito, basicamente, "problema" = "qualquer coisa com a qual é necessário lidar".
— especialista (não vamos dividir por tipos, pois estamos interessados em todos os testadores), participando do teste de um componente ou sistema, cujo resultado da atividade é:
— um conjunto de atividades relacionadas ao teste.
(lat. effectivus) — a relação entre o resultado alcançado e os recursos utilizados (:2015).
— consequência de uma cadeia (sequência) de ações (resultado) ou eventos, expressos qualitativa ou quantitativamente. Os resultados possíveis incluem vantagem, inconveniente, benefício, perda, valor e vitória.
Assim como com o “problema”, o sentido é pouco: algo que se obteve como resultado do trabalho.
— capacidade mensurável de realizar qualquer atividade por um indivíduo ou grupo; condições que permitem, por meio de determinadas transformações, obter o resultado desejado. O testador — é uma pessoa e, de acordo com a teoria dos recursos vitais, cada indivíduo possui quatro ativos econômicos:
capital financeiro (renda) — recurso renovável;
energia (força vital) — recurso parcialmente renovável;
tempo — recurso fixo e essencialmente não renovável;
conhecimentos (informação) — recurso renovável, parte do capital humano, que pode crescer ou ser destruído..
Quero ressaltar que a definição de efetividade, no nosso caso, não é totalmente precisa, pois quanto mais conhecimento utilizamos, menor é a efetividade. Portanto, eu redefiniria a efetividade como “relação entre o resultado alcançado e os recursos despendidos”. Assim, tudo fica correto: os conhecimentos utilizados no trabalho não se esgotam, mas reduzem a despesa do único recurso essencialmente não renovável do testador — seu tempo.
Solução
Assim, buscamos os problemas globais dos testadores que diminuem a efetividade de seu trabalho.
O recurso mais significativo que é utilizado no trabalho do testador é seu tempo (os outros podem ser de alguma forma convertidos a ele), e para que possamos falar de um cálculo correto da efetividade, é necessário também associar o resultado ao tempo.
Para isso, vamos considerar um sistema cuja viabilidade é garantida pelo trabalho do testador. Esse sistema é um projeto que inclui um testador na sua equipe. O ciclo de vida de um projeto pode ser grosso modo representado pelo seguinte algoritmo:
- Trabalhando com requisitos
- Formação do documento de requisitos técnicos
- Desenvolvimento
- Testes
- Lançamento em produção
- Suporte (retornar ao item 1)
Nesse caso, todo o projeto pode ser recursivamente dividido em subprojetos (features), com o mesmo ciclo de vida.
Do ponto de vista do projeto, a eficiência de sua realização é maior quanto menos tempo é gasto.
Assim, chegamos à definição da máxima eficiência do testador sob a perspectiva do projeto — esse é o estado do projeto onde o tempo para teste é igual a zero. E o problema geral para todos os testadores é a impossibilidade de atingir esse tempo.
Como lidar com isso?
As conclusões são bastante óbvias e utilizadas por muitos há muito tempo:
- Desenvolvimento e teste devem começar e terminar praticamente ao mesmo tempo (isso geralmente é feito pelo departamento ). A opção ideal é que toda a funcionalidade em desenvolvimento esteja coberta por testes automáticos no momento em que estiver pronta, organizados em testes de regressão (ou, se possível, em testes pré-commit) com a ajuda de alguma .
- Quanto mais features há em um projeto (quanto mais complexo ele é), mais tempo será necessário para verificar se a nova funcionalidade não quebrou a antiga. Portanto, quanto mais complicado o projeto, mais automação é necessária para .
- Cada vez que deixamos um bug passar para a produção, e o usuário o encontra, precisamos gastar tempo extra passando pelo ciclo de vida do projeto desde o item 1 (Trabalhando com requisitos, neste caso, os do usuário). Como as razões para deixar passar um bug geralmente são desconhecidas, a única maneira de otimização que nos resta é que cada bug encontrado pelos usuários deve ser incluído nos testes de regressão, para garantir que ele não reapareça.
Fonte: habr.com
