how test software requirements specification
Você está ciente disso 'A maioria dos Insetos no software são devido a requisitos funcionais incompletos ou imprecisos? ” Por melhor que esteja escrito, o código do software não importa e nada pode ser feito se houver ambigüidades nos requisitos.
Este artigo sobre Especificação de Requisitos de Software (SRS) afirma que os Requisitos devem ser claros, específicos, mensuráveis e completos, sem contradições.
É melhor capturar as ambiguidades dos requisitos e corrigi-los no próprio ciclo de vida de desenvolvimento inicial.
O custo de corrigir o bug após a conclusão do desenvolvimento ou lançamento do produto é muito alto. Portanto, é importante ter uma análise de requisitos e capturar esses requisitos incorretos antes das especificações de design e das fases de implementação do projeto de SDLC.
O que você aprenderá:
Como medir documentos SRS funcionais?
Bem, precisamos definir alguns testes padrão para medir os requisitos. Depois que cada requisito é passado por esses testes, você pode avaliar e congelar os requisitos funcionais.
Vamos dar uma exemplo, você está trabalhando em um aplicativo baseado na web. O requisito é o seguinte: “O aplicativo da Web deve ser capaz de atender às consultas do usuário o mais cedo possível”
Como você congelará o Requisito neste caso?
Quais serão os seus critérios de satisfação de requisitos? Para obter a resposta, faça esta pergunta às partes interessadas: Quanto tempo de resposta é adequado para você? Se disserem, aceitaremos a resposta se for dentro de 2 segundos, então esta é a sua medida de requisito. Congele este requisito e execute o mesmo procedimento para o próximo requisito também.
Acabamos de aprender como medir os requisitos e congelá-los nas fases de Design, Implementação e Teste.
Agora vamos dar outro exemplo: Eu estava trabalhando em um projeto baseado na web. O cliente (partes interessadas) especificou os requisitos do projeto na fase inicial de desenvolvimento do projeto. Meu gerente distribuiu todos os requisitos da equipe para revisão. Quando começamos a discussão sobre esses requisitos, ficamos chocados!
Cada um tinha sua própria concepção sobre os requisitos. Encontramos muitas ambiguidades nos 'termos' especificados nos documentos de requisitos, que mais tarde foram enviados ao cliente para revisão / esclarecimento.
O cliente utilizou muitos termos ambíguos, que tinham muitos significados diferentes, tornando difícil para nós analisarmos o significado exato. A próxima versão do documento de requisitos do cliente foi clara o suficiente para congelar para a fase de design.
Com este exemplo, aprendemos que “os requisitos devem ser claros e consistentes”
O próximo critério para testar a especificação de requisitos é “Descubra os requisitos que faltam”, vamos dar uma olhada nisso.
Descubra requisitos ausentes
Muitas vezes os designers do projeto não têm uma ideia clara sobre cada módulo específico e simplesmente assumem alguns requisitos na fase de design. Qualquer requisito não deve ser baseado em suposições. Os requisitos devem ser completos, cobrindo todos os aspectos do sistema em desenvolvimento.
como adicionar valores a uma matriz
As especificações devem indicar os dois tipos de requisito, ou seja, o que o sistema deve fazer e o que não deve.
Geralmente, eu uso meu próprio método para descobrir os requisitos não especificados. Quando eu li o Documento de especificação de requisitos de software (SRS) , Anoto meu próprio entendimento dos requisitos que são especificados, além de outros requisitos que o documento SRS deve abranger.
Isso me ajuda a fazer as perguntas sobre os requisitos não especificados, tornando-o mais claro.
Para verificar a integridade dos requisitos, divida os requisitos em três seções, requisitos ‘Deve implementar’, requisitos que não são especificados, mas são ‘presumidos’ e o terceiro tipo é o tipo ‘imaginação’ de requisitos. Verifique se todos os tipos de requisitos são atendidos antes da fase de design do software.
Verifique se os requisitos estão relacionados ao objetivo do projeto
Às vezes, as partes interessadas têm seus próprios conhecimentos, que esperam vir no sistema em desenvolvimento. Eles nem mesmo pensam se esse requisito seria relevante para o projeto em mãos. Certifique-se de identificar esses requisitos. Tente evitar todos os requisitos irrelevantes durante a primeira fase do ciclo de desenvolvimento do projeto.
Se não for possível, faça perguntas às partes interessadas, como por que você deseja implementar este requisito específico? Isso irá descrever o requisito específico em detalhes, tornando mais fácil projetar o sistema considerando o escopo futuro.
Mas como decidir se os requisitos são relevantes ou não?
Resposta simples: Defina a meta do projeto e faça a seguinte pergunta: Se não implementar este requisito, você terá algum problema para atingir a meta especificada? Caso contrário, este é um requisito irrelevante. Pergunte aos stakeholders se eles realmente desejam implementar esses tipos de requisitos.
Em suma, o documento de Especificação de Requisitos (SRS) deve abordar o seguinte:
- Funcionalidade do projeto (o que deve ser feito e o que não deve ser feito).
- Interfaces de software, hardware e interface do usuário.
- Critérios de correção, segurança e desempenho do sistema.
- Problemas de implementação (riscos), se houver.
Conclusão
Eu cobri quase todos os aspectos da medição de requisitos. Para ser específico sobre os requisitos, resumirei o teste de requisitos em uma frase:
“Os requisitos devem ser claros e específicos, sem incertezas, os requisitos devem ser mensuráveis em termos de valores específicos, os requisitos devem ser testáveis com alguns critérios de avaliação para cada requisito e os requisitos devem ser completos, sem quaisquer contradições”
O teste deve começar na fase de requisitos para evitar outros bugs relacionados aos requisitos. Comunicar com cada vez mais as partes interessadas para esclarecer todos os requisitos antes de iniciar a concepção e implementação do projeto.
Você tem alguma experiência em teste de requisitos de software?
Fique à vontade para compartilhá-los nos comentários abaixo.
Leitura recomendada
- Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
- Trabalho de assistente de controle de qualidade de teste de software
- Tutorial de teste destrutivo e teste não destrutivo
- Mapeamento mental em testes de software - maneiras de tornar os testes mais divertidos!
- Como testar um aplicativo sem requisitos?
- Curso de Teste de Software: Qual Instituto de Teste de Software devo ingressar?
- Escolhendo o teste de software como sua carreira
- Trabalho de freelancer de redator de conteúdo técnico de teste de software