Primeiramente é necessário encontrar respostas claras para algumas questões genéricas:
- Vamos fazer testes unitários e/ou de sistema?
- Vamos fazer testes funcionais, de performance ou de regressão?
- Trata-se de um produto novo ou é um projecto de manutenção?
- Como é que os programadores entendem o sistema?
- Que outra documentação existe além de especificação funcional?
- Existe algum analista/especialista de negócio, ou um utilizador final disponível?
- Há componentes funcionais previamente definidas?
- Quais são as áreas de risco?
- Qual o nível de experiência da equipa de testes?
- Vão ser feitos testes manuais e/ou automáticos?
As respostas às questões anteriores revelarão possíveis formas de pôr em prática o processo de testes.
Quanto ao aspecto organizacional dos testes podemos considerar os seguintes aspectos:
- Identificar os pontos fortes da equipa de testes.
- Obter informações sobre as componentes técnicas desenvolvidas.
- Combinar ou separar módulos consoante o tipo de testes.
- Distribuir os módulos a testar de acordo com as competências e conhecimentos dos testers.
- Encorajar a comunicação constante entre a equipa de testes e programadores e analistas.
- Escolher uma abordagem de testes clara e objectiva, que não seja passível de diferentes leituras, para evitar erros de interpretação.
- Documentar os passos básicos nos detalhes do processo de teste, se houver pouco tempo disponível.
Com estes princípios em mente, podemos ainda tentar algumas abordagens alternativas para os testes. Podemos realizar testes exploratórios, em que testamos a aplicação de acordo com o nosso próprio método. E podemos fazer testes de aceitação (ou com utilizadores) envolvendo um utilizador desconhecido para perceber como são entendidos os requisitos e as funcionalidades básicas, e compreender a forma como os utilizadores interagem com a nova aplicação. Também se pode pedir aos utilizadores que escrevam pequenas histórias (descrições do negócio) que podem servir de base para o desenho de mais testes.
Em resumo, podemos dizer que, quaisquer que sejam as condições para testar software, devemos sempre pensar cuidadosamente e definir objectivos claros antes de começar.
----------------------
Traduzido e adaptado de: Testing In The Dark: How To Come Out Into The Light (Blog Hunteress)
Outros links sobre este assunto:
- Software Testing without Requirements: Survival Guide
- How To Test With Little To No Requirements
- Testing Without Requirements
- Testing Without Requirements or Specifications
- Testing Without Requirements
