Detalhamento do Fluxo de Trabalho: Validar Estabilidade do Build

Tópicos

Finalidade

A finalidade deste detalhamento do fluxo de trabalho é validar build tornando-o estável o suficiente para iniciar teste detalhado e o esforço de avaliação. Esse trabalho também é chamado de teste de regressão, teste de verificação do build, teste de regressão do build, verificação de limpeza ou aceitação no teste. Esse trabalho ajuda a economizar recursos de teste em esforço inútil.

Para cada Build a ser testado, o foco do trabalho será:

Fazer uma avaliação da estabilidade e testabilidade do Build
Formar uma compreensão inicial — ou confirmar a expectativa — do trabalho de desenvolvimento feito no Build
Tomar uma decisão para aceitar o Build como adequado para uso — com base na missão de avaliação — nos testes seguintes ou realizar mais testes em um Build anterior

Como Definir a Equipe

O trabalho está basicamente centrado nos papéis de Testador e Analista de Teste. As habilidades mais importantes exigidas para esse trabalho incluem fornecer resultados a tempo, meticulosidade e julgamento justo para avaliar a utilidade do Build em outros testes.

Convém alocar um subconjunto da equipe de teste para realizar esse trabalho; os outros membros da equipe ignoram o novo build até que ele seja validado como estável e dedicam seus esforços para o Detalhamento do Fluxo de Trabalho: Aprimorar Vantagens do Teste do ciclo de teste anterior.

Como uma heurística para alocação relativa de recursos por fase, os percentuais típicos
do uso de recurso de teste para esse detalhamento do fluxo de trabalho são: Iniciação — 00%, Elaboração — 05%, Construção — 10% e Transição — 10%. Observe que é normal não haver um Build formal na fase de Iniciação.

A sofisticação e a disponibilidade das ferramentas de automatização de teste e as habilidades necessárias para utilizá-las influenciarão a alocação de recursos nesse trabalho. Quando forem utilizadas as ferramentas de automatização, muito desse trabalho poderá ser realizado com rapidez e eficiência: sem a automatização, será necessário muito mais esforço.

Orientações de Trabalho

Esse trabalho deve ser realizado uma vez por Build — observe, porém, que é normal não testar todos os Builds. Quando o Build estiver suficientemente estável, o foco passará para o Detalhamento do Fluxo de Trabalho: Testar e Avaliar. Onde o Build for considerado insatisfatório para ser submetido a outros testes, o trabalho de Testar e Avaliar em geral reiniciará com um Build anterior adequado.

Embora isso dependa do tamanho do esforço de desenvolvimento, recomendamos que você planeje a automatização de determinados aspectos desse trabalho. Para os elementos automatizados desses testes de "regressão", é normal executá-los de forma autônoma em "horários mais calmos", como durante o almoço ou de madrugada.

Observe que, além de executar testes de "regressão" automatizados, você também deve planejar a execução de um conjunto mínimo de testes manuais nos itens de software novos ou com mudanças significativas.

As referências a seguir fornecem mais detalhes para orientá-lo na realização dessa tarefa:

Para obter mais informações sobre os conceitos básicos desse trabalho:

Rational Unified Process