Nota do editor: Bem-vindo à série Liderança em Testes, da autoria do guru e consultor de testes de software Paul Gerrard. A série foi concebida para ajudar os profissionais de testes com alguns anos de experiência — especialmente os que integram equipas ágeis — a destacarem-se nas suas funções de liderança e gestão de testes.
No artigo anterior, apresentámos um manifesto de risco para ajudar os gestores. Neste artigo, faremos a velha pergunta “Quanto teste é suficiente?”. Antecipação: cabe às partes interessadas decidir.
Subscreva o boletim informativo The QA Lead para ser notificado quando forem publicados novos capítulos da série. Estas publicações são excertos do curso Liderança em Testes de Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter um desconto de 60 $ no preço total do curso!
Quanto teste é suficiente? Esta é a clássica questão filosófica sem resposta que todos os profissionais de testes colocam, porque também lhes é colocada pelas partes interessadas.
As partes interessadas querem saber porque pretendem ter a certeza de que os sistemas foram testados adequadamente, mas, como são elas que pagam e têm prazos a cumprir, também querem conhecer o custo potencial dos testes e o tempo que estes irão demorar.
Por isso, cabe às partes interessadas avaliar quanto teste é suficiente. O seu trabalho enquanto gestor de testes é proporcionar-lhes o máximo valor possível, ajudando-as a tomar uma decisão. Neste artigo, abordaremos:
- O valor dos testes para as partes interessadas
- A teoria quântica e a teoria da relatividade (não a física)
- Utilizar a linguagem correta
- Estimativas, orçamentos e negociação
Comecemos.
O valor dos testes para as partes interessadas
Cada teste que executamos deve ter valor para as partes interessadas, na medida em que fornece evidências para apoiar a sua tomada de decisões de quatro formas:
- Evidências de que o sistema irá cumprir os objetivos empresariais do projeto.
- Evidências de que o sistema não irá falhar ou, caso falhe, de que o impacto da falha será suportável.
- Evidências para reproduzir e diagnosticar falhas, bem como reparar e voltar a testar o sistema que falhou.
- Evidências para apoiar a tomada de decisões no contexto de um projeto (aceitar, lançar, rejeitar, etc.)
O nosso objetivo nos testes é criar testes que aumentem progressivamente a cobertura de testes do sistema relativamente a um modelo de testes reconhecível. Os nossos testes devem demonstrar que o sistema irá cumprir os objetivos empresariais e que o risco de falha é conhecido e, esperamos, aceitável.
Dos quatro tipos de evidências acima, os três primeiros sustentam o quarto. Em última análise, as partes interessadas precisam de tomar uma decisão baseada em evidências. A decisão é delas, não dos profissionais de testes, pelo que cabe-lhes avaliar se dispõem de informação suficiente para se sentirem confiantes. De qualquer modo, o valor dos testes está nos olhos de quem os avalia.
Ora, todos os profissionais de testes fazem escolhas sobre o que testar recorrendo a um modelo formal ou até à intuição. Estas escolhas são feitas com base em algum valor percecionado.
A menos que o profissional de testes seja também uma parte interessada, normalmente avalia o valor com base em alguma medida de completude ou cobertura. Ou, se conhecer a perspetiva das partes interessadas, com base na possibilidade de o teste apoiar alguma decisão de aceitação.
Os princípios acima têm algumas consequências importantes.
Em primeiro lugar, se não conhecer a perspetiva da parte interessada, é pouco provável que a sua perceção do valor dos testes seja igual à dela. Se selecionar testes sem ter em conta os seus valores, quando chegar o momento de apresentar os resultados, as partes interessadas poderão considerar que dispõem de dados insuficientes em algumas áreas e excessivos noutras. Certamente não se sentirão tão confiantes quanto deveriam.
Em segundo lugar, quando concebe ou executa um teste, qual é o seu contributo para a tomada de decisões das partes interessadas? Se um teste não fornecer informação incremental que apoie uma decisão, ou se as partes interessadas não se importarem com o facto de o seu teste passar ou falhar, então não tem lugar num plano de testes.
Dissemos no artigo 3 sobre modelos que os modelos de testes que utiliza devem ser relevantes para as partes interessadas. Se os resultados dos seus testes corresponderem a modelos que as partes interessadas compreendem e valorizam, então irão valorizar o seu contributo.
Have an account? Log In
A teoria quântica e a teoria da relatividade
Existem ainda dois princípios relacionados com o valor e a importância dos testes. Chamo a um Teoria Quântica e ao outro Teoria da Relatividade. Estes rótulos parecem pretensiosos (são certamente irónicos), mas descrevem dois fenómenos que estão na base de todas as discussões sobre o valor, a priorização e o âmbito dos testes.
Quando executamos um teste, normalmente interpretamos o resultado como aprovado ou reprovado. A avaliação de aprovado/reprovado é um resultado binário – verdadeiro ou falso, sim ou não, um ou zero. Esse resultado de teste gera um quantum discreto de evidência. A evidência acumula-se à medida que executamos cada vez mais testes. Qualquer que seja o resultado, esse teste aumenta incrementalmente a cobertura do nosso modelo de testes e o conhecimento que temos sobre o comportamento do sistema. Os testes que não acrescentam conhecimento não acrescentam valor.
Se um teste não aumentar incrementalmente a cobertura de alguma forma, terá pouco valor.
O segundo aspeto é o valor de um teste. Qual é o valor de um teste? Será que podemos realmente atribuir um valor em dólares, libras ou euros a um único teste? Provavelmente não. Mas o que podemos fazer – e muitas vezes com bastante facilidade – é dizer: «este teste é mais valioso do que aquele».
Suponhamos que utilizamos um modelo de cobertura de código, como a cobertura de instruções. Poderíamos executar um teste que exercitasse cinco linhas de código ou cinco mil linhas de código. Qual é o valor de cada um? É difícil dizer. Mas, se o nosso objetivo for a cobertura de instruções, o segundo teste tem mais valor.
Não podemos atribuir um valor absoluto a nenhum teste, mas normalmente podemos comparar testes e inferir o valor relativo de cada um. Ou seja, se estivermos sob pressão de tempo, normalmente podemos dizer que um teste tem menos valor do que outro e, por isso, retirar o primeiro do âmbito, se for necessário.
Podemos comparar o valor dos testes, mas apenas se estes derivarem do mesmo modelo.
É importante salientar, contudo, que estas comparações só são realmente significativas se partilharem o mesmo modelo. Um teste que abranja uma vasta gama de condições extremas num processo terá provavelmente mais valor do que um teste do percurso «direto». Por exemplo, os testes de ponta a ponta de um processo complexo não podem ser comparados diretamente com os testes unitários de componentes críticos.
Embora as teorias quântica e da relatividade possam não se aplicar diretamente aos testes, os princípios da adaptabilidade e da perspetiva aplicam-se. Encontre uma ferramenta de gestão de testes que esteja alinhada com estes princípios para otimizar a sua estratégia de testes.
Utilizar a Linguagem Certa
Agora que estabelecemos quem é responsável por decidir «quanto teste é suficiente», como podemos nós, enquanto testadores conscienciosos, apoiar esta tomada de decisão?
Note-se que o nosso tratamento do valor dos testes é muito semelhante à nossa avaliação dos riscos. Como foi referido no artigo anterior, é muito difícil atribuir valores numéricos à escala ou à exposição ao risco. No entanto, normalmente é possível comparar um risco com outro e classificá-los, de modo a tomar decisões sobre os riscos abrangidos pelos testes.
Ao utilizar a linguagem do risco, os testadores serão ouvidos pela gestão.
Os líderes das equipas de desenvolvimento parecem ser frequentemente ouvidos pelos gestores, mesmo quando falam em termos técnicos. A diferença é que apresentam a tecnologia como algo estimulante e benéfico. Quando os testadores falam nos seus próprios termos técnicos – sobre os detalhes «administrativos» dos testes, como as estatísticas de incidentes –, a mensagem tende a ser negativa e os gestores podem ficar aborrecidos ou irritados.
A gestão pode já considerar os testadores ligeiramente aborrecidos enquanto grupo, mas isso deve-se, discutivelmente, ao facto de muitos gestores não compreenderem realmente o que fazem os testadores e que valor acrescentam. Por isso, os testadores devem elevar a sua linguagem ao nível da gestão.
Os testes baseados no risco comunicam com a gestão dos utilizadores e a gestão de projetos na sua própria linguagem.
Estas são pessoas que pensam muito em termos de riscos e benefícios. Se os testadores se dirigirem a elas em termos semelhantes, é mais provável que a gestão os ouça e, consequentemente, tome melhores decisões. Ao relacionarmos os testes com os objetivos do projeto, podemos concentrar a atenção nos resultados de maior valor para as partes interessadas, dedicando assim o nosso tempo a testar os elementos mais importantes.
Além disso, à medida que se progride através dos testes, podemos demonstrar que os benefícios mais valiosos estão agora disponíveis. A decisão de lançamento é, em última análise, um juízo sobre se os benefícios obtidos superam os riscos, pelo que os testes fornecerão à gestão dados melhores para fundamentar as suas decisões.
Utilize a linguagem do risco (e dos benefícios) para definir o âmbito, planear e comunicar o progresso dos testes.
Obviamente, os testadores precisam de falar tecnicamente com os programadores e com outros profissionais técnicos. Por exemplo, a qualidade dos relatórios de incidentes é um fator fundamental para que as falhas sejam corrigidas de forma rápida e fiável. Estou simplesmente a dizer que, ao falar com a gestão, o testador aborda os riscos tratados e pendentes, em vez de falar de testes, incidentes e falhas.
More Articles
Estimativas, Orçamentos e Negociação
No início de um novo projeto, o gestor do projeto pergunta-lhe: «Preciso de agendar e alocar recursos aos testes atempadamente; pode dar-me uma estimativa de quantas pessoas precisa e durante quanto tempo para realizar os testes do sistema?»
Pensa um pouco e vai falar com o chefe.
“Preciso de seis testadores durante oito semanas.”
O gestor de projeto pensa por um momento e consulta o seu rascunho do cronograma e o plano de recursos.
“Pode ter quatro testadores durante seis semanas e é tudo.”
Você objeta e diz: “Mas vai demorar mais de seis semanas! Vai custar mais do que o que alocou para testar este sistema. O sistema é maior do que o anterior. É mais complicado. É certamente demasiado arriscado poupar nos testes desta vez. Simplesmente não é suficiente.”
Mas o gestor mantém-se inflexível, murmurando qualquer coisa sobre outras dependências, autoridades superiores e por aí fora…
O que acha que terá justificado fazer uma estimativa se o gestor sempre soube qual teria de ser o orçamento? Que relevância tem um orçamento arbitrário para o trabalho em questão? Porque é que nunca levam os testes a sério? Os programadores têm sempre o tempo que pedem, não têm? Não parece justo.
Pode sentir-se lesado e sentir que o seu julgamento profissional é posto em causa. Mas o problema é, e sempre foi, que o orçamento para os testes nesta situação estava fixado. Tudo o que pode fazer é perceber quais são os testes mais adequados ou mais valiosos que consegue realizar dentro do seu orçamento.
Mas, muitas vezes, o gestor de projeto quer realmente saber quanto tempo as coisas vão demorar para que o plano possa ser ajustado. Se acha que está numa negociação, precisa de alguns argumentos para negociar. Também precisa de discutir os resultados do plano, não os recursos necessários. O âmbito é um resultado do planeamento; o esforço que aplica é um recurso.
Precisa de negociar o âmbito.
A negociação dos orçamentos para os testes deve ser sempre sobre o âmbito, não sobre o esforço.
O âmbito pode assumir um ou vários formatos, e a forma como o apresenta e discute irá variar, mas eis alguns padrões comuns. Qualquer que seja o seu âmbito, irá utilizá-lo como base da sua estimativa e da sua defesa:
Âmbito como inventário de requisitos ou funcionalidades
Quando a estimativa é reduzida em 30%, pergunte: “Que 30% do sistema não devo testar?”
Âmbito como inventário de riscos
Quando a estimativa é reduzida em 30%, pergunte: “Que riscos das partes interessadas devo retirar do plano?”
Âmbito como modelo tabular ou gráfico
Quando a estimativa é reduzida em 30%, pergunte: “Que percursos/jornadas/itens devo dizer às partes interessadas que não serão testados?”
Espero que perceba o que está a acontecer aqui.
- O âmbito dos testes baseia-se num modelo que foi previamente discutido e acordado com as partes interessadas. Este âmbito é provisório, estando dependente da disponibilidade de recursos e tempo, e deve informar as partes interessadas disso.
- Faça a estimativa com base nesse âmbito provisório. Utilize o modelo (riscos, requisitos, processo de negócio ou qualquer outro modelo) para definir um objetivo de cobertura, contabilize os itens de cobertura e faça a estimativa com base nisso.
- Discuta o assunto com o gestor de projeto. Se a estimativa for demasiado elevada, utilize as respostas acima para iniciar as discussões com as partes interessadas.
Enquanto testador ou gestor de testes, não está numa boa posição para negociar os testes com o gestor de projeto. As partes interessadas têm as suas preocupações e, se partilhar os modelos que definem o âmbito dos testes, terão opiniões, aceitarão o âmbito e poderão defendê-lo. As partes interessadas também são responsáveis por justificar o orçamento do seu sistema, pelo que estão melhor posicionadas para equilibrar o custo dos testes com a necessidade de abordar as suas preocupações.
Algumas reflexões
Reflita sobre quem, nos seus projetos, assume a responsabilidade pela quantidade de testes a realizar:
- É você, enquanto testador, que define o âmbito e a quantidade de testes?
- O gestor de projeto define um orçamento e você faz o melhor que pode com o tempo que lhe é atribuído?
- O âmbito é negociado com o gestor de projeto e as partes interessadas para chegar a um equilíbrio entre o esforço e o âmbito dos testes a realizar?
Uma das principais responsabilidades de um testador é garantir que o projeto tem conhecimento dos riscos do produto que estão a ser assumidos e documentá-los. Só quando estes riscos são visíveis é que a gestão pode reconhecer os riscos que assume ao reduzir os testes.
Não existe uma fórmula para determinar a quantidade certa de testes. Na maioria dos ambientes, o nível de testes só pode ser determinado por consenso entre a gestão do projeto, os patrocinadores do cliente, os programadores, os especialistas técnicos e os testadores – os testes são considerados abrangidos pelo âmbito se abordarem os riscos relevantes.
A quantidade suficiente de testes deve ser determinada por consenso, com o testador a facilitar e a contribuir com informação para o processo de consenso.
Subscreva o boletim informativo do The QA Lead para receber uma notificação quando forem publicados novos artigos da série. Estes artigos são excertos do curso de Liderança em Testes do Paul, que recomendamos vivamente para aprofundar este e outros temas. Se o fizer, utilize o nosso código de cupão exclusivo QALEADOFFER para obter $60 de desconto no preço total do curso!
Artigos relacionados:
