Teste no ciclo de vida de software

Aspectos básicos de teste

Conhecimentos avançados requerem conhecimentos básicos. Como o estudo da CTAL envolve ter na veia os conteúdos da CTFL, segue uma sessãozinha para relembrar, reforçar ou complementar a sua visão do lugar do profissional de teste no mundo (ou no ciclo de vida do software) :)



Teste no ciclo de vida de software

O teste deve estar intrínseco no ciclo de vida do software, seja ele seqüencial (cascata, V, W,...), iterativo (RAD, espiral,...) ou incremental (evolutivo, métodos ágeis,...). É essencial o alinhamento dessa disciplina com as outras como engenharia de requisitos, gerenciamento de projetos, gerencia de configuração e mudança, manutenção e desenvolvimento, documentação técnica, ...

Modelo Seqüencial:
Nesse modelo, o time irá definir os requisitos do sistema no início e depois gerenciar as “eventuais” mudanças que possam ocorrer (“eventuais” foi um eufemismo mesmo).

O time de testes pode se envolver no início do projeto planejando e projetando os testes através da análise das especificações dos requisitos para identificar condições de teste. Esse planejamento, análise e projeto realizados antecipadamente, favorecem a identificação de defeitos nos requisitos, fazendo do teste um processo mais preventivo que reativo. A detecção de falhas começaria mais tarde, quando os testes de sistema tiverem início (fim da fase de desenvolvimento).


Modelo Incremental:
Adotando uma metodologia ágil como Scrum, o time de teste não recebe o conjunto final e completo de requisitos no início do projeto (se é que recebem algum dia :) ). O time irá receber requisitos a cada 30 dias (ou como definido o sprint).

Nesse caso, o time pode, por exemplo, seguir uma estratégia baseada em riscos, identificando e priorizando áreas de risco, ajudando assim a montar os escopos dos sprints. Projetos e implementações de teste ocorrem logo após a execução, reduzindo a capacidade preventiva do teste. A detecção de falhas começa mais cedo, ao final de cada sprint, e continua repetidamente em ciclos curtos pelo projeto.

Lembrando que aplicação de Metodologia Ágil não quer dizer abolição de documentação!!


(Um parêntesis para o Gerenciamento de Configuração)

Independente do ciclo de vida adotado, gerenciamento de configuração e mudança é crucial para o teste. Falhas nesse processo podem resultar no impedimento de realização dos testes, invalidando as impressões sobre o que realmente está acontecendo no sistema. Pode resultar na perda de uma mudança, na impossibilidade de acertadamente definir o que foi testado e em que ponto foi testado e por em dúvida a confiabilidade do teste.

Saiu na Testing Experience uma matéria sobre isso. Bem cara de pau, eu vou copiar o início da matéria para dar o gostinho:

“A lei número 1 da Engenharia de Software é: ’Não importa onde você está no ciclo de vida do sistema, o sistema irá mudar, e o desejo de mudá-lo persistirá por todo o ciclo’ – Bersoff, et al, 1980"

A matéria está na 6ª edição!


Níveis de teste introduzidos no Syllabus Advanced

No Syllabus Advanced, são introduzidos os níveis de teste:

- Hardware-Software integration testing

- System integration testing

- Feature interaction testing

- Customer Product integration testing

E cada nível (não só esses, mas também todos os outros do Syllabus Foundation) deve ter:

- Objetivos

- Escopo

- Rastreabilidade para a base de teste

- Critérios de entrada e saída

- Artefatos 'entregáveis', incluindo relatórios

- Técnicas de teste

- Métricas e medidas

- Ferramentas de teste

- Conformidade com os padrões da organização e outros padrões




E assim termina o primeiro resuminho da introdução do syllabus (também com base no Advanced Software Testing Vol.1 do Rex Black.