tempo de Leitura: 7 minutos

o Sucesso de qualquer projeto depende da capacidade de uma equipe de desenvolvimento para atender as necessidades dos seus clientes. A comunicação entre o cliente e a equipe de Desenvolvimento desempenha um papel vital na entrega de uma solução que se adapta aos requisitos do produto e do mercado., As questões surgem se os clientes explicam suas necessidades muito vagamente e a equipe não pode entender requisitos claros e, eventualmente, o problema de negócios por trás deles. Imagine que você pede à sua equipe para permitir que os usuários procurem por um produto em uma livraria online por categorias. Você espera ter uma interface clara com links de categoria para clicar sobre eles (por exemplo, fantasia, não-ficção, histórico, etc.) Depois de duas semanas de desenvolvimento, você recebe um recurso de barra de pesquisa onde os usuários devem digitar na categoria que lhes interessa, em vez de navegar categorias pré-listadas., Enquanto isso também funciona, seu objetivo inicial era expor todas as categorias disponíveis e deixar os usuários explorar mais.

Este é o momento em que documentação de software de alta qualidade pode ajudar a evitar o problema. Histórias de usuário e critérios de aceitação (AC) como os principais formatos de requisitos de documentação. Uma história de usuário é uma descrição da linguagem natural de uma característica. Normalmente é acompanhado por critérios de aceitação.critérios de aceitação (AC) são as condições que um produto de software deve satisfazer para ser aceito por um usuário, um cliente ou outro sistema., Eles são únicos para cada história de usuário e definir o comportamento do recurso a partir da perspectiva do usuário final. Critérios de aceitação bem escritos ajudam a evitar resultados inesperados no final de uma fase de desenvolvimento e garantir que todos os stakeholders e usuários estão satisfeitos com o que eles recebem.

os critérios de aceitação são os requisitos funcionais de nível mais baixo

critérios de aceitação objectivos principais

clarificar os requisitos das partes interessadas é um objectivo de alto nível. Para tornar os propósitos de AC mais claros, vamos quebrá-los.,

AC define os limites das histórias do utilizador. Eles fornecem detalhes precisos sobre a funcionalidade que ajudam a equipe a entender se a história está concluída e funciona como esperado.

descrevendo cenários negativos. Yor AC pode exigir que o sistema reconheça entradas de senha inseguras e impeça um usuário de prosseguir. O formato de senha inválido é um exemplo de um cenário chamado negativo quando um usuário faz entradas inválidas ou se comporta inesperadamente. AC definir esses cenários e explicar como o sistema deve reagir sobre eles.comunicação de configuração., Critérios de aceitação sincronizam as visões do cliente e da equipe de desenvolvimento. Eles garantem que todos tenham uma compreensão comum dos Requisitos: os desenvolvedores sabem exatamente que tipo de comportamento o recurso deve demonstrar, enquanto os stakeholders e o cliente entendem o que é esperado do recurso.racionalização dos ensaios de aceitação. AC são a base do teste de aceitação de história do Usuário. Cada critério de Aceitação deve poder ser testado de forma independente e, por conseguinte, ter cenários claros de aprovação ou de avaria. Eles também podem ser usados para verificar a história através de testes automatizados.estimativa das características., Critérios de aceitação especificam exatamente o que deve ser desenvolvido pela equipe. Uma vez que a equipe tem requisitos precisos, eles podem dividir histórias de usuários em tarefas que podem ser corretamente estimadas.

critérios de Aceitação os tipos e estruturas

AC podem ser escritos em diferentes formatos. Há dois mais comuns, e a terceira opção é criar seu próprio formato:

• cenário orientado (Dado/Quando/Então)
• regra-orientado (lista de verificação)
• formatos personalizados

Como o primeiro e o segundo formatos têm estruturas muito específicas, nós vamos, principalmente, o foco sobre eles., No entanto, você pode achar que outros formatos se encaixam melhor no seu produto para que possamos brevemente tocá-los também.

critérios de aceitação orientados para cenários

Formato de escrita orientado para cenários AC é conhecido como o tipo dado/quando / então (GWT).

• Dado algum pré-requisito
• Quando eu faço alguma ação
• Então eu esperar algum resultado

Esta abordagem foi herdada de behavior-driven development (BDD) e fornece uma estrutura consistente que ajuda testadores definir quando começar e terminar o teste de um determinado recurso., Ele também reduz o tempo gasto na escrita de casos de teste como o comportamento do sistema é descrito antecipadamente.,

Cada um dos critérios de aceitação escritos neste formato tem as seguintes instruções:

1. Cenário – o nome para o comportamento que será descrito
2. Dado – o início do estado do cenário
3. Quando a ação específica que o usuário faz
4. Então o resultado da ação de “Quando”
5. E – usado para continuar qualquer uma das três afirmações anteriores

Quando combinado destas demonstrações abranger todas as ações que um usuário leva para concluir uma tarefa e experimentar o resultado.

vamos ver alguns exemplos.,

exemplo 1

História do utilizador: como utilizador, quero ser capaz de recuperar a senha da minha conta, para que possa aceder à minha conta no caso de me esquecer da senha.,igated para a página de login

Quando o usuário: O usuário selecionado esqueceu a opção de palavra-passe

E: Inserido um e-mail válido para receber o link de recuperação de senha

Então: O sistema de enviado o link para inserir o e-mail

Dado: O usuário recebeu a ligação através do e-mail

Quando: O usuário navegou através do link recebido no e-mail

Então: O sistema permite que o usuário defina uma nova senha

Exemplo 2

Usuário história: Como um usuário, eu quero ser capaz de pedir o dinheiro de minha conta no ATM, para que eu seja capaz de receber o dinheiro da minha conta rapidamente e em lugares diferentes.,tampa

E: a pistola contém dinheiro

Quando: o cliente solicita o dinheiro

em Seguida: certifique-se a conta é debitada

E: garantir o dinheiro é dispensado

E: assegurar que o cartão é devolvido

critérios de Aceitação 2:

Dado: que a conta é exagerada

E: o cartão é válido

Quando: o cliente solicita o dinheiro

: – assegurar a rejeição de mensagem é exibida

E: garantir o dinheiro não é dispensado

Regra orientada critérios de aceitação do formato

Em alguns casos, é difícil para caber critérios de aceitação para o Dado/Quando/Então estrutura., Por exemplo, GWT dificilmente seria útil para os seguintes casos:

• Você está trabalhando com histórias de usuário que descrevem a funcionalidade de nível do sistema que precisa de outros métodos de garantia de qualidade.o público-alvo para os critérios de aceitação não necessita de detalhes precisos dos cenários de ensaio.
• cenários GWT não se encaixam na descrição de restrições de design e experiência do usuário de uma característica. Os desenvolvedores podem perder uma série de detalhes críticos.

pode abordar estes casos com o formato AC orientado por regras.,

a forma orientada a regras implica que existe um conjunto de regras que descrevem o comportamento de um sistema. Com base nestas Regras, você pode desenhar cenários específicos.

geralmente, os critérios compostos usando este formulário parecem uma simples lista de balas. Vejamos um exemplo.

exemplo

História do usuário: como usuário, eu quero usar um campo de pesquisa para digitar uma cidade, nome ou rua, de modo que eu poderia encontrar opções de hotel correspondentes.,

critério básico de aceitação da interface de pesquisa

• o campo de pesquisa é colocado na barra superior
• a pesquisa começa assim que o utilizador clica em “Procurar”
• o campo contém um espaço com um texto de cor cinzenta: “para onde vai?”
• O espaço desaparece assim que o usuário começa a digitar
• a Pesquisa é realizada se um usuário digita uma localidade, nome do hotel, na rua, ou tudo combinado
• a Pesquisa é em inglês, francês, alemão e ucraniano
• O usuário não pode digitar mais de 200 símbolos
• A pesquisa não oferece suporte a símbolos especiais (caracteres)., Se o utilizador escreveu um símbolo especial, mostre a mensagem de aviso: “a entrada de pesquisa não pode conter símbolos especiais.”

outros formatos

a maioria das histórias de usuário pode ser coberta com dois formatos mencionados acima. No entanto, você pode inventar seus próprios critérios de aceitação dado que eles servem seus propósitos, são escritos claramente em Inglês claro, e não pode ser mal interpretado. Algumas equipas até usam texto simples.,

às Vezes, o critério pode ser especificado como um exemplo de comportamento do sistema:

Um simples conjunto de AC para senhas por Mark Levison para agilepainpainrelief.com

Esta abordagem fornece orientações claras para o recurso de senha de teste.

funções responsáveis e como os critérios de aceitação são criados

alguns dos critérios são definidos e escritos pelo proprietário do produto quando ele ou ela cria o backlog do produto. E os outros podem ser especificados pela equipe durante as discussões de histórias de usuários após o planejamento sprint., Não há recomendações rigorosas para escolher a pessoa responsável por escrever os critérios. O cliente pode documentá-los se tiver amplo conhecimento técnico e de documentação do produto. Neste caso, o cliente negocia os critérios com a equipe para evitar mal-entendidos mútuos. Caso contrário, os critérios são criados por um proprietário de produto, Analista de Negócios, Analista de requisitos, ou um gerente de projeto.,

O processo inicia-se com a história de usuário priorização e termina com a negociar os detalhes com toda a equipe

Principais desafios e as melhores práticas de escrita critérios de aceitação

os critérios de Aceitação de parecer como se eles são muito fáceis de escrever. Apesar de seus formatos simplistas, a escrita representa um desafio para muitas equipes. Vamos dar uma olhada mais profunda nas melhores práticas que ajudam a evitar erros comuns.

Document criteria before development. Os critérios de aceitação têm de ser documentados antes do início do desenvolvimento real., Desta forma, a equipe provavelmente irá capturar todas as necessidades do cliente com antecedência. No início, é suficiente definir os critérios para um pequeno número de histórias de usuário para preencher os backlogs para duas sprints (se você praticar Scrum ou um método similar). Têm de ser acordadas por ambas as partes. Em seguida, os critérios de aceitação documentados são usados pelos desenvolvedores para planejar o processo técnico.não torne o ar condicionado demasiado estreito. Os critérios de aceitação podem ser muito específicos vivendo pouco a nenhuma opção de manobra para os desenvolvedores. Para evitar isso, lembre-se que AC deve transmitir a intenção, mas não uma solução final., Além disso, o AC estreito pode ser desprovido de múltiplos comportamentos de usuário que não são cobertos.mantenha os seus critérios alcançáveis. Este ponto se cruza com o anterior. Critérios de aceitação eficazes definem o mínimo razoável de funcionalidade que você é capaz de entregar. Mas caso sucumbas a descrever todos os pequenos detalhes, há o risco de a tua equipa ficar presa a centenas de pequenas tarefas.manter AC mensurável e não demasiado largo. Critérios de aceitação amplos tornam uma história de usuário vaga., Critérios de aceitação eficazes devem delinear o escopo do trabalho para que os desenvolvedores possam planejar e estimar seu esforço corretamente.evitar pormenores técnicos. Como mencionamos, os critérios de aceitação devem ser escritos em Inglês claro. Isto irá torná-los claros e fáceis de entender para todos: os seus stakeholders ou gestores podem não ter antecedentes técnicos.

alcançar consenso. O mesmo problema pode ser resolvido de forma diferente por uma equipe e partes interessadas, dependendo de seus pontos de vista. Certifique-se de que comunicou o seu ar condicionado às partes interessadas e chegou a um acordo mútuo., O mesmo se aplica aos membros da equipa. Todos devem rever o AC e confirmar que entendem e concordam com cada linha.

Write testável AC. Isso permitirá que os testadores para verificar que todos os requisitos foram cumpridos. Caso contrário, os desenvolvedores não entenderão se a história do usuário estiver completa.

palavra Final

não negligencie os critérios de aceitação, uma vez que eles – sendo simples e acessível – resolvem múltiplos problemas de uma só vez., Eles documentam as expectativas dos clientes, fornecem uma perspectiva de usuário final, clarificam os requisitos e impedem a ambiguidade, e eventualmente ajudam a garantia de qualidade a verificar se os objetivos de desenvolvimento foram cumpridos. Independentemente de usar ou não Métodos Ágeis, certifique-se de escolher o melhor formato ou experimentar com os seus próprios. Diferentes tipos de histórias de usuário e, eventualmente, recursos podem exigir diferentes fromats e testar os novos que trabalham para você é uma boa prática.