ScopeMaster-dez-testes-para-ótimas-histórias de usuários

Iniciar o teste da história do usuário

Na maioria das atividades de software, as histórias de usuários são um lembrete conciso das conversas entre o proprietário do produto, o desenvolvedor e o testador. Embora as histórias de usuários sejam muito curtas, o formulário é comumente mal utilizado e isso leva à ambiguidade, discussões desnecessárias e retrabalho. Neste artigo, definimos como testar histórias de usuários para que você possa garantir que suas histórias de usuários sejam de alta qualidade e reduzirão o retrabalho e encurtarão os prazos.

Tenho desfrutado de um debate considerável online sobre a validade de até mesmo pensar na qualidade da história do usuário. Se você aceita que histórias de usuários claras são úteis para um projeto, então o conceito de teste de histórias de usuários deve fazer sentido para você.

Aprenda estes dez testes para escrever ótimas histórias de usuários.

1. Limpar

Suas histórias de usuário devem ser claro e inequívoco. O proprietário do produto, o desenvolvedor e o testador devem ter um entendimento comum do que deve ser entregue no texto da história. Ao escrever suas histórias, presuma que, se elas puderem ser mal interpretadas, elas o serão. Além disso, certifique-se de que suas histórias incluam todas as funcionalidades necessárias (excluindo navegação).

Dica: Concentre-se na intenção funcional da história do usuário, por exemplo, “Como usuário_registrado, posso atualizar meu perfil”

Fundo

Provavelmente será mal compreendido

Analisamos mais de 100.000 histórias de usuários e descobrimos que a duração média das histórias é de 12 palavras. Matematicamente, existem mais de 80 bilhões de permutações de 12 palavras. Isso significa que há uma maneira quase infinita de os leitores interpretarem mal as histórias de usuários.

Histórias de usuários ruins causam retrabalho excessivo (±125 vezes)

Também estimamos que, em média, cada palavra de uma história de usuário leva a 125 termos de codificação. Isto significa que um erro (que pode levar a um mal-entendido) levará a um retrabalho considerável após o início da codificação.

O aumento do trabalho remoto significa que estamos mais dependentes da palavra escrita. Acertar as palavras é importante.

Teste automatizado de clareza

A maioria das histórias de usuários está sujeita a interpretações errôneas. O ScopeMaster® realiza análises linguísticas detalhadas de cada palavra da história do usuário para detectar o(s) significado(s) funcional(is). O mecanismo de análise é projetado especificamente com o propósito de desambiguar histórias de usuários de software (detecta padrões de sujeito, verbo e objeto no texto). Esta é a base de como o mecanismo de análise realiza “o que há de mais moderno em testes de mudança para a esquerda”.

O mecanismo de análise também realiza centenas de verificações linguísticas em busca de fraseologia e termos ambíguos que possam levar a interpretações incorretas da história do usuário. Esses testes são acumulados a partir dos ensinamentos de alguns dos principais especialistas em requisitos do mundo. (É como se todas as suas histórias de usuários fossem revisadas por especialistas).

2. Conciso

Mantenha-os curtos. As histórias não precisam ser longas para transmitir o significado funcional essencial. Uma ou mais frases curtas podem ser suficientes. Lembre-se de que os critérios de aceitação são complementares à história.

Dica: evite descrições sobre navegação, detalhes de implementação, critérios de aceitação e atributos de objetos.

Dica: Evite detalhes de implementação.

Dica: separe os critérios de aceitação da história de usuário principal.

Teste automatizado de concisão

O ScopeMaster® realiza análises detalhadas das palavras de cada história de usuário, destacando o uso excessivo de palavras desnecessárias.

Teste de requisitos estáticos

O ScopeMaster® executa centenas de testes em cada história de usuário. É como o SonarQube, mas para histórias de usuários.

Teste de história de usuário – captura de tela

3. Orientado ao usuário

Uma história deve ser escrita da perspectiva do usuário. A recomendação ágil típica é o formato:

Como um Tipo de usuário Eu quero executar_alguma coisa para que razão

Em alguns casos, o tipo de usuário pode ser outro software ou talvez até mesmo um dispositivo interagindo com o software, como um sensor.

Dica: Nunca escreva suas histórias da perspectiva do desenvolvedor.

Dica: Evite o termo geral do utilizador, em vez disso, use rótulos ricos e consistentes para tipo de usuário ou função, como Usuário Registrado ou visitante_não autenticado

Teste automatizado de detecção de usuário

O analisador ScopeMaster® detecta usuários candidatos em cada história. O ScopeMaster destacará instâncias de histórias que não possuem um usuário. Opcionalmente, você pode instruir o analisador sobre qual é a palavra do “usuário” em sua história.

4. Testável

Uma história pode ser testável se contiver declarações claras de funcionalidade. Use frases que inferem movimentação, armazenamento e recuperação de dados. Exemplos de histórias testáveis incluem frases como "atualizar perfil", “exibir relatório de vendas“, "enviar email". Escrever suas histórias dessa forma garantirá que a intenção funcional central seja clara. Isso fornece a base a partir da qual os cenários de teste podem ser gerados. O conjunto completo de testes geralmente dependerá de critérios de aceitação detalhados e complementares.

Dica: os critérios de aceitação detalhados são complementares à história de usuário principal e não incorporam critérios de aceitação ao texto da história de usuário.

Geração automatizada de testes

Como consequência de “conhecer” a intenção funcional da sua história de usuário, o mecanismo ScopeMaster® propõe cenários de testes e casos de testes essenciais que podem ser usados como base para testes funcionais. Os testes gerados pelo ScopeMaster são 100% alinhados à funcionalidade da história do usuário. Eles cobrem testes positivos e negativos. Eles podem ser considerados os testes mínimos essenciais que devem ser realizados. Esta é uma grande economia de tempo para profissionais de teste.

5. Mensurável

Refiro-me aqui à mensurabilidade do tamanho, especificamente usando o Ponto de função CÓSMICO (CFP) como base para o dimensionamento. É um padrão ISO maduro de segunda geração, adequado para todos os tipos de trabalho de software. As histórias de usuários só podem ser medidas se contiverem expressões claras de todos os movimentos de dados que serão necessários e medidos. A mensurabilidade ajuda significativamente no planejamento e na garantia de qualidade. O tamanho funcional não é o único atributo mensurável de uma história de usuário, mas é um dos mais importantes (porque está intimamente relacionado ao esforço para construí-la).

Dica: A falha na medição do tamanho adiciona incerteza ao trabalho do software.

Dica: Aprenda sobre a metodologia de dimensionamento COSMIC neste guia.

Fundo

A unidade básica de tamanho é o Ponto de Função CÓSMICO que é um padrão ISO para tamanho. Comece sua jornada de aprendizado com este atualizado, guia para software de medição.

Uma estimativa antecipada do CFP é muito útil, pois à medida que os detalhes do requisito se tornam conhecidos, essa estimativa aproximar-se-á de uma medição mais precisa.

Universalmente aplicável

Para aqueles que resistem a estimar ou medir o tamanho (funcional) dos requisitos, considere o seguinte. O tamanho mínimo de uma história de usuário é 2-3 CFP. O custo típico para desenvolver um CFP é $200 – $2000. O tempo necessário para estimar o tamanho é de cerca de 10 minutos por CFP manualmente ou 2 minutos com a ajuda da automação. Saber o tamanho é extremamente valioso para determinar quanto custará o projeto, quanto tempo levará e muito mais. Tanto a atividade de “conhecer o tamanho” quanto a de “executar o dimensionamento” reduzem a incerteza e melhoram a qualidade.

Estimativa de tamanho automatizada

O ScopeMaster foi originalmente projetado com o objetivo principal de determinar o tamanho funcional (pontos de função COSMIC e IFPUG) a partir de requisitos de software. As estimativas de tamanho do ScopeMaster foram validadas como estando normalmente dentro de 15% de um tamanho determinado manualmente. Isto não apenas reduz o trabalho de realização do dimensionamento, mas também ajuda a introduzir o dimensionamento formal de engenharia para aqueles que atualmente não têm conhecimento da existência de tais técnicas valiosas.

6. Consistente

Use palavras consistentes para ambos tipos_de_usuário e tipos_de_objetos em um conjunto de histórias de usuários. A nomenclatura consistente reduzirá confusão, defeitos, retrabalho e desperdício. Sistemas complexos e ambientes com muitos jargões tendem a ter o mesmo usuário ou objeto recebendo termos diferentes dos membros da equipe.

Verificações de consistência automatizadas

Após analisar o texto individual de cada história, o mecanismo ScopeMaster faz referência cruzada a todas as histórias de usuário dentro de um conjunto (ou lista de pendências). Ele identifica cada ocorrência de tipos de objetos e os apresenta em forma de tabela para que as inconsistências possam ser detectadas de maneira fácil e rápida.

7. Concluir

A falta de requisitos é uma das maiores causas de falhas em projetos de software. A maioria dos projetos aumenta de tamanho à medida que necessidades adicionais se tornam aparentes. Este aumento no escopo leva a mais trabalho, mais retrabalho, prazos estendidos, estouros de orçamento e, em alguns casos, fracasso competitivo do projeto. Embora a abordagem Ágil desencoraje o trabalho inicial excessivo, algum trabalho inicial de definição do escopo é essencial. Procure cuidadosamente os requisitos ausentes ao escrever suas histórias de usuário.

Verificação automatizada de integridade

O mecanismo de análise ScopeMaster identifica todas as ocorrências de um object_type em um conjunto de histórias de usuário. Em seguida, ele executa uma análise CRUD. para identificar histórias potencialmente perdidas. O ScopeMaster até sugere qual pode ser a história que falta.

Obter uma compreensão completa de todo o escopo de um projeto no início de seu ciclo de vida é extremamente valioso para os gerentes de projeto.

8. Único

Todos os requisitos devem ser únicos. Requisitos duplicados são um problema que tende a ser mais prevalente em projetos maiores.

Verificação automatizada de exclusividade

O mecanismo de análise ScopeMaster identifica todas as ocorrências de um object_type (e intenção funcional associada) em um conjunto de histórias de usuário. Onde houver duas histórias que realizam a mesma operação CRUD em um objeto, elas serão destacadas.

9. Valioso

Todas as histórias de usuários devem ser valiosas para o “negócio”. É apropriado desafiar o valor e a importância de cada história de usuário, para que apenas a funcionalidade mais importante seja entregue. Se uma história de usuário não puder ser rastreada até a entrega de um resultado comercial mensurável, ela pode não ser valiosa e talvez deva ser retirada do escopo. O valor financeiro real da história pode ser difícil de medir, usando o tamanho funcional (CFP) como base para o valor (especialmente para a medição do valor agregado EVM).

10. Sem design

As histórias de usuários não devem referir-se à tecnologia usada para entregá-las. Este nível de detalhe pode ser incluído como complemento à história do usuário para ajudar a fornecer contexto sobre “como” ela deve ser entregue. Isto é particularmente adequado para aspectos não funcionais de como a funcionalidade será alcançada.

Verificação automatizada de linguagem técnica

O mecanismo de análise ScopeMaster procura centenas de frases técnicas e outras terminologias inadequadas para histórias de usuários.

Recomendação

Deixe o ScopeMaster testar suas histórias de usuários para você, basta importar e pressionar o botão verde, sua análise de linguagem inteligente avaliará a qualidade e fará recomendações para melhorar suas histórias de usuários.

Conclusão

À medida que avançamos para um trabalho mais remoto, aumenta a nossa dependência da palavra escrita no desenvolvimento de software. Gaste tempo para acertar as palavras. Histórias de usuários de boa qualidade são a base de um software de qualidade. Você deve testar histórias de usuários antes de começar a codificar, para evitar perda de tempo.

Cada um desses 10 testes representa um atributo de qualidade de uma boa história de usuário. Você pode usar isso como uma lista de verificação para executar cada história de usuário que você escreve. Testar histórias de usuários renderá dividendos significativos, reduzindo o retrabalho, reduzindo o aumento do escopo e reduzindo a volatilidade do escopo. E se você quiser fazer isso mais rápido, experimente o ScopeMaster, ele faz o trabalho pesado dos testes de histórias de usuários.

Histórias de usuários ágeis

Muitos Agilistas usam o Lista de verificação de INVESTIMENTO critérios para histórias de usuários originalmente de Bill Wake:

EUindependente
Negociável
Vvalioso
Eestimável
Sshopping center
Testável

Cuidado ao usar INVEST

O autor original aponta que INVEST é um subconjunto incompleto de atributos.
Não reconhece que as histórias dos utilizadores podem ser interdependentes.
Requer que as histórias sejam orientadas para o usuário.
Não insiste que as histórias sejam inequívocas.
Não reconhece os perigos de trabalhar com uma compreensão incompleta do escopo.
Não incentiva a análise disciplinada (nomeação consistente, orientada ao usuário, concisa)
Não exige que as histórias sejam mensuráveis (embora se refira a Estimável, este é um critério muito vago).

A criação original do INVEST também menciona que as tarefas devem ser tratadas de forma diferenciada e a sigla SMART aplicada:

Específico
Mensurável
Alcançável
Realista
Tempo limite

Sempre achei as verificações SMART eficazes e apropriadas para as tarefas, mas não para histórias de usuários.

Por que deveríamos escrever histórias de usuários melhores?

Como todos os tipos de trabalho de conhecimento, a anotação de histórias de usuários (ou requisitos de software) está sujeita a erros. Esses erros precisam ser resolvidos antes que o software seja desenvolvido, caso contrário, eles consomem muito tempo e são caros demais para serem resolvidos uma vez. É mais provável que uma história de usuário escrita por uma pessoa tenha o potencial de ser mal interpretada por seus leitores.