O login na história do usuário envolve mais coisas do que você imagina. Por trás de uma entrada de dois campos pode haver processamento e complexidade significativos, por isso é muito importante dedicar algum tempo para acertar as palavras. Para começar, a redação deve ser clara, inequívoca, consistente, concisa, mas também completa.
Não existe uma história de usuário perfeita. Existe um espectro de qualidade, de ruim a bom. E a qualidade da história do usuário pode ser avaliada em pelo menos 10 critérios. Eu investigo aqui uma única história de usuário relacionada a um cenário comum – o processo de login – e vejo como podemos avançar na linha da qualidade.
A autenticação com um aplicativo de software, ou login, é encontrada em quase todos os aplicativos de software. É um recurso tão comum que a maioria dos desenvolvedores tentará reutilizar o código para implementar essa funcionalidade. No entanto, com que frequência pensamos em reutilizar o requisito? E quão grande e complicada é essa funcionalidade? E o que isso realmente significa quando fazemos login? Neste artigo, exploraremos essas questões e terminaremos com um conjunto de histórias de usuários reutilizáveis (de boa qualidade).
Seja preciso
Analisamos mais de 100.000 histórias de usuários no ScopeMaster e estimamos, em média cada palavra de uma história de usuário descreve 25 linhas de código, portanto, um erro em uma palavra de uma história de usuário pode ter um impacto profundo no esforço e no tempo de desenvolvimento.
Uma história de usuário bem formada evitará discussões desnecessárias, reduzirá o retrabalho e diminuirá significativamente o tempo de desenvolvimento, por isso vale a pena perder tempo acertando as palavras.
Lembremos que uma história de usuário é escrita para vários leitores e para mais de um propósito. As duas mensagens principais que uma história de usuário deve transmitir são:
- Quem é o usuário e de quais funcionalidades ele precisa. (Quem e o que)
- Por que isso é importante (por que)
Para a história do usuário de login, você pode começar com isto:
Como usuário, quero fazer login.
Mas esta é uma história de usuário ruim e explicaremos o porquê. Isso deixa uma série de perguntas sem resposta, o que realmente significa “login”. O que “usuário” realmente significa? Todos nós podemos pensar que sabemos o que esses termos significam, mas vale a pena olhar mais de perto; na verdade, pode ser necessário que muita coisa aconteça nos bastidores, durante a autenticação com um aplicativo. Vejamos o que realmente pode acontecer quando fazemos login em um aplicativo da web.
Um cenário de login
Aqui está um cenário típico de login na web bem-sucedido:
- Digite um nome de usuário e uma senha. O nome de usuário geralmente é o endereço de e-mail do usuário.
- Clique em enviar, o nome de usuário/e-mail é pesquisado. Se achado,
- uma versão criptografada da senha é então comparada com a versão criptografada armazenada.
- O perfil é atualizado com a data e hora de login mais recente.
- O sistema realiza uma pesquisa de grupos (ou funções) e associações de grupos,
- Finalmente, é mostrada ao usuário uma tela que ele tem direito de ver com base no resultado das etapas anteriores.
Agora, este é um cenário bastante básico, o processo de login pode ficar muito mais complicado, por exemplo, pode envolver serviços de autenticação federados, registro de eventos e muito mais, mas vamos ficar com o mais simples por enquanto.
A língua inglesa tem mais de 150.000 palavras que podemos usar, e praticamente em qualquer ordem, por isso as alternativas são praticamente infinitas. O objetivo da história é comunicar, e não há necessidade de ser complexo se pudermos expressá-lo de forma simples. Esta é apenas uma versão de como seria a história do usuário:
Como usuário registrado, posso me autenticar em meu perfil. O sistema também deve procurar meu group_membership. Ele também deve recuperar o grupo [informações para determinar quais recursos tenho permissão para acessar].
Aqui está a análise detalhada realizada pelo ScopeMaster:
O uso de colchetes diz ao ScopeMaster para ignorar algum texto ao determinar o significado funcional.
Como você pode ver, as etapas funcionais são determinadas e então mapeadas para Movimentos de Dados (a unidade do Ponto de Função COSMIC).
Portanto, esta versão da história é muito melhor porque é:
- Orientado ao usuário (registered_user presume que essa pessoa já deveria existir).
- De valor
- Conciso (não detalhado, referindo-se apenas aos tipos de objetos, não às suas propriedades individuais)
- Completo (descreve todas as principais etapas funcionais desta história de usuário)
- Considerável, em 9 pontos de função CÓSMICA.
- Inequívoco (mapeado com sucesso para etapas funcionais)
- Não projeto (não especifica como deve ser nem como deve ser codificado).
Considerações adicionais. Caminhos alternativos (testes negativos)
Os outros caminhos também precisam ser considerados no contexto da essa história, e provavelmente deve ser adicionado separadamente como critério de sucesso:
- Meu ID de usuário está incorreto – exibir uma mensagem de erro
- minha senha não corresponde – exibe uma mensagem de erro
- minha senha expirou – exibir uma mensagem de erro
- minha conta foi desativada – exibir uma mensagem de erro
- Posso fazer login, mas não sou membro de uma função com nenhuma permissão – exibir uma mensagem de erro
Histórias de usuários relacionadas
Agora que cobrimos a história básica do usuário de login, podemos prosseguir criando histórias para o seguinte.
- Palavra-chave esquecida
- Mudar minha senha.
- Armazenar um cookie para lembrar minha identidade
- O administrador pode acionar uma redefinição da minha senha.
- Registre-se como usuário
- O administrador pode me registrar em meu nome
- Sincronizar ou compartilhar meu ID com outro sistema de autenticação (por exemplo, Facebook)
Estes serão assunto de artigos futuros, portanto fique atento.
Espero que você tenha achado este artigo útil. Agora sugiro que você dê uma olhada 10 testes para escrever ótimas histórias de usuários
Colin.
Considere o seu público
Considere o público de sua história de usuário:
Os diferentes leitores de uma história de usuário
Todos esses leitores devem ser capazes de ler a história do usuário e obter o mesmo entendimento a partir dele. Os leitores podem ter objetivos e perspectivas diferentes, mas a história deve significar a mesma coisa para todos os leitores. Se diferentes leitores puderem interpretar a história de maneira diferente, considere reformulá-la. No desenvolvimento ágil de software, as histórias de usuário são escritas como um espaço reservado para uma conversa, mas é comum que histórias de usuários são frequentemente a única articulação de requisitos. E por isso é essencial que sejam cuidadosamente redigidos.
Deixe a IA ajudá-lo a aperfeiçoar a história do usuário de login
Teste suas histórias de usuário enquanto você as escreve
.
Gere scripts de testes automaticamente
.
Próximo:
Para ler mais, saiba mais sobre como melhorar as histórias de usuários em geral. Em nosso próximo artigo sobre a qualidade da história do usuário.
Aprenda 10 etapas para melhorar suas histórias de usuários, que você pode aplicar em seus projetos de software atuais.