10x - 100x mais rápido
1.000 vezes mais completo
Em média, executamos cerca de 1.000 testes por história de usuário. Esta é uma combinação de testes estáticos e dinâmicos. Este é um nível de escrutínio que não é normalmente alcançado com revisões manuais de histórias.
Quer saber mais? Leia os detalhes sobre o tipo de teste realizado pelo ScopeMaster.
O ScopeMaster fornece análises de requisitos de software que ajudam as equipes de entrega de software a entregar projetos de software com mais rapidez e segurança.
Se puder ser mal interpretado, será
Se uma história de usuário pode ser interpretada de forma diferente pelos leitores-chave (autor, usuário, testador, desenvolvedor), então é provável que um deles esteja trabalhando com um entendimento errado, gerando desperdício e retrabalho. É muito importante eliminar essas ambigüidades pela raiz.
125 razões para testar histórias de usuários
A proporção de palavras em uma história de usuário em relação ao número de tokens de codificação que normalmente vemos é de 1:125. Uma história de usuário de 12 palavras provavelmente acabaria se tornando cerca de 1.500 tokens de codificação, aproximadamente 300 linhas de código. Portanto, para cada minuto gasto na correção de uma palavra ambígua em uma história de usuário, você provavelmente economizará 125 minutos em codificação. Agora é um tempo bem gasto!
Teste de Extrema Esquerda
Testar histórias de usuários pode parecer uma ideia estranha, mas não é. Na verdade, é uma das coisas mais produtivas que você pode fazer em um projeto de software. É o epítome dos testes de extrema esquerda. Se você deseja se tornar um proprietário de produto mais bem-sucedido, comece a testar essas histórias o mais cedo possível. As histórias de usuários são uma expressão de requisitos em empreendimentos de software ágil. Como outras entregas de desenvolvimento de software, elas também estão sujeitas a erros. O desafio específico das histórias de usuários é que elas podem ser facilmente mal interpretadas, o que pode levar a muito desperdício de tempo e esforço. Na verdade, é mais provável que sejam mal interpretados do que não.
Como testar histórias de usuários
Então, como fazemos isso? Vamos começar com o básico. O que é um requisito de software empresarial?:
Um requisito (ou capacidade) real do negócio é “o que deve ser entregue para agregar valor ao negócio” (Robin Goldsmith). As histórias de usuários são os requisitos funcionais distintos que constituem esse recurso.
E se você não testar suas histórias de usuário?
Histórias de usuários ruins (ou requisitos ruins) são a causa raiz do 35% de defeitos de produção (Accenture, 2021). Um problema de requisitos que não é resolvido até fases posteriores do desenvolvimento/implantação pode custar de 75 a 1.000 vezes mais para ser corrigido do que se fosse corrigido antes do início da codificação.
Necessidade de disciplina para reduzir a ambigüidade
Quando escrevemos código, seguimos disciplinas para melhorar a legibilidade, reduzir a complexidade, aumentar a reutilização e muito mais. (Para saber mais sobre isso, leia o excelente Código completo, de Steve McConnell). Escrever histórias de usuários também justifica tal disciplina, especialmente para minimizar ambiguidade, inconsistência e complexidade. Na verdade, uma boa história de usuário pode ser um tanto enfadonha, pois é inequívoca. Esteja preparado para ajustar a forma como você escreve histórias de usuários, adote consistência e disciplina para eliminar ambigüidades. Felizmente, o ScopeMaster irá ajudá-lo a aprender à medida que avança.
Ferramentas relacionadas
Jsonlint é uma ferramenta online para testar a sintaxe de um arquivo json
Validador HTML é uma ferramenta online para testar a sintaxe HTML.
