Por que testes de requisitos?
Em uma frase: porque é onde os projetos nascem.Qualquer software, desde uma simples calculadora até uma aplicação de grande porte passa de alguma forma por esta fase, mesmo que informalmente.
Definir requisitos é descrever um pedido, uma idéia, aquilo que nós (ou geralmente o nosso cliente) quer que o programa faça.
Fica aqui a primeira nota importante para qualquer projeto, de qualquer tamanho, e que tem valor não apenas do ponto de vista técnico, quanto do ponto de vista administrativo e financeiro: escreva os requisitos.
Essa parte, assim como quase sempre a documentação é inexistente em projetos pequenos. E não é por menos que é a maior fonte de dor de cabeça para pequenos empresários, programadores, testers e pro próprio cliente.
Creio que todo leitor aqui já deve ter passado pela situação onde o cliente pede algo, você cria, e depois de terminado, o cliente diz que queria que algumas funcionalidades fossem diferentes, e quase sempre são funcionalidades que mexem com a base do programa, do modelo adotado para a solução. Coisa boba que se explicada de início, pouparia muito tempo, retrabalho e desgaste por todas as partes mais tarde.
OK, requisitos são importantes. Mas como testá-los?
Em pequenos e médios projetos, geralmente a documentação sobre especificações técnicas é inexistente, ou feita apenas através de emails. O primeiro passo é escrever os requisitos. Não é necessário muito, mas tem que ser algo que dê bases aos outros times (design, implementação e teste).
Exemplo. Um cliente pede uma loja virtual, onde ele vai vender vários produtos e, na interface, os consumidores poderão procurar/navegar pelas diversas categorias. Ele quer poder incluir e excluir produtos na lista, tem um sistema de venda, com acompanhamento de pedidos, e um sistema de relatórios sobre as vendas e sobre o estoque.
Bastante trabalho pela frente, mas poucas linhas para descrever. Faltou alguma coisa? Muitas. Mas para este exemplo, vou pegar um ponto que certamente poderia ser um foco de divergência: as categorias.
Perguntas básicas a se fazer sobre o "simples" sistema de categorias.
- O cliente irá usar apenas categorias pré-definidas, ou quer poder gerenciar as categorias (criar novas, remover existentes...)?
- Essas categorias poderão ter subcategorias?
- Um produto pode pertencer a mais de uma categoria ou subcategoria?
Aí estão perguntas cujas respostas podem significar desde uma nova tabela e formulários no banco de dados, até uma reestruturação de boa parte do banco de dados e da aplicação.
Outro exemplo. O cliente pede um sistema onde um usuário poderá se cadastrar.
Simples, não? Não. Você não pode supor que se trata de uma newsletter, nem supor que se trata de um formulário altamente complexo. O certo é esclarecer.
- Cadastrar o que? email apenas? ou endereço, telefone...?
- Quais são os campos obrigatórios e quais são opcionais?
- Clientes de onde? de um estado específico? de uma cidade específica? um continente? do mundo?
Faça uma lista de perguntas. Se possível, ajude seu cliente sugerindo prováveis campos e indicando quais você acha que seriam os obrigatórios, mas deixe que o cliente decida e diga o que é que ele realmente quer, afinal o negócio é dele.
Resumindo
Sempre que você chegar numa situação onde para testar ou criar você tenha que supor ou adivinhar o que o cliente quer, pergunte, esclareça. Vale a pena o investimento, porque é necessário pouco tempo para obter respostas que podem significar uma diferença enorme em termos de prazo e preço a todos os lados envolvidos.Abraços e até a próxima.
----------- keepReading
Nenhum comentário:
Postar um comentário