Escrevendo casos de teste de aceitação

Estamos integrando um processo de teste em nosso processo SCRUM. Minha nova função é escrever testes de aceitação de nossos aplicativos da web para automatizá-los posteriormente. Eu li muito sobre como os casos de teste devem ser escritos, mas nenhum me deu conselhos práticos para escrever casos de teste para aplicativos Web complexos e, em vez disso, lançaram princípios conflitantes que achei difíceis de aplicar:

• Os casos de teste devem ser curtos: tome o exemplo de um CMS. Casos de teste curtos são fáceis de manter e identificar as entradas e saídas. Mas e se eu quiser testar uma longa série de operações (por exemplo, adicionar um documento, enviar uma notificação para outro usuário, o outro usuário responder, o documento mudar de estado, o usuário receberá um aviso). Parece-me bastante que os casos de teste devem representar cenários completos. Mas posso ver como isso produzirá documentos de teste abertamente complexos.

• Os testes devem identificar entradas e saídas:: E se eu tiver um formulário longo com muitos campos em interação, com comportamentos diferentes. Escrevo um teste para tudo ou um para cada um?

• Os casos de teste devem ser independentes: Mas como posso aplicar se o teste da operação de upload exige que a operação de conexão seja bem-sucedida? E como isso se aplica à escrita de casos de teste? Devo escrever um teste para cada operação, mas cada teste declara suas dependências ou devo reescrever o cenário inteiro para cada teste?

• Os casos de teste devem ser levemente documentados: Este princípio é específico para projetos Agile. Então, você tem algum conselho sobre como implementar esse princípio?

Embora eu achasse que escrever casos de teste de aceitação seria simples, fiquei impressionado com todas as decisões que tinha que tomar (FYI: sou desenvolvedor e não testador profissional). Portanto, minha principal pergunta é: Quais etapas ou conselhos você tem para escrever casos de teste de aceitação sustentável para aplicativos complexos. Obrigado.

Editar : Para esclarecer minha pergunta: Estou ciente de que o teste de aceitação deve começar com o requisito e considerar todo o aplicativo como uma caixa preta. Minha pergunta está relacionada às etapas práticas para escrever o documento de teste, identificar os casos de teste, lidar com dependências entre testes ... para aplicativos Web complexos

Nos meus pacotes de aceitação, evitei usar controles específicos da tecnologia, ou seja, para aplicativos da Web não use css, não use elementos html se você precisar preencher um formulário, faça os detalhes nas etapas para configurar o SUT e não os testes de aceitação reais

Eu uso pepino para minha aceitação e tenho o seguinte

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

este exemplo está de volta por um aplicativo Web, mas ainda posso usar o teste para testar em um aplicativo de desktop, pois as etapas são usadas para configurar o SUT e não os testes de aceitação

este teste fica no final de uma compra que vai

Gerar -> Confirmar -> Pagamento -> Imprimir recibo

o teste acima é para a etapa de pagamento, as outras etapas são configuradas em outros testes, pois o aplicativo pode configurar nesses estados com ações de dados ou http. Nesse caso, o pagamento tem um dado que executa as etapas de confirmação e a confirmação faz o gerar etapas para que fiquem um pouco quebradiças a cada minuto

Primeiro, você precisa definir o Teste de aceitação .

O que você parece descrever é integração ou teste do sistema .

Portanto, embora eu não concorde 100% com as definições da wikipedia, elas ainda são amplamente válidas.

Basicamente, o objetivo do teste de aceitação é verificar se os processos "comerciais" que utilizam o software que você construiu realmente funcionam conforme o planejado e são adequados ao objetivo - com dados da vida real. Portanto, você não cria casos de teste como os testes de unidade ou o resto. Não é para ser projetado da mesma maneira.

A pergunta a fazer é "como o sistema é usado?". Então, vamos testá-lo da maneira que deveria ser usado. É claro que agora você veste seu chapéu de engenharia e repassa religiosamente os requisitos de negócios para obter seus casos de teste. Isso pressupõe que você tenha requisitos de negócios bem escritos.

Caso contrário, não é tarde demais, você deve sentar-se com o (s) usuário (s) ou seus representantes (e o analista de negócios e a pessoa de design técnico) e anotar o que eles esperam que o software entregue em termos comerciais ( com a ressalva óbvia de que isso é tarde demais, mas é melhor começar tarde do que nunca - e, é claro, não introduzir novos recursos). É assim que seus casos de teste serão.

Outra maneira de fazer isso (novamente se você tiver esse documento) é seguir o manual do usuário. Embora essa seja uma etapa removida dos requisitos reais de negócios, apenas deve ser usada se tudo mais falhar.

Quando você compra um carro, geralmente não se aprofunda profundamente (a menos que você seja um mecânico de automóveis). Apenas sente-se ao volante e verifique o conforto, a usabilidade, a aparência, os sons ... ou seja, o material geral. Você geralmente confia que, se o carro chegou à sua mão em primeiro lugar (pelo menos para um carro novo), ele geralmente é seguro e bem construído (há uma garantia, você fez o trabalho em casa e olhou as especificações ...) Então agora você verifica se este é o carro que você desejará dirigir nos próximos anos.

Mesmo com software.

As informações conflitantes podem ser frustrantes e difíceis de generalizar e aplicar à sua situação específica. Portanto, você pode ter que fazer o que funciona melhor no seu contexto.

Não sou muito fã de documentos de teste longos e usei recursos visuais com bastante eficiência em alguns projetos menores. Tente isso? Como um fluxograma (ou qualquer outro diagrama UML, como um diagrama de estados etc.), em vez de usar apenas texto? Indique entradas, saídas, condições, loops, faixas, estados, interações com outros componentes, etc. e, em seguida, indique se eles foram bem-sucedidos, com falha, transferidos, outros (?) Com base em seus critérios.

Pode ser um pouco de trabalho no começo, mas pode ajudar a mantê-lo são a longo prazo. Qualquer que seja o método que você escolher, quanto mais você trabalhar com ele, melhor será o resultado.

HTH, e boa sorte!

KM

Eu acho que você já estabeleceu alguns bons critérios. Seu segundo ponto é uma boa maneira de definir os escopos para seus testes, e sugiro também testar condições de erro e bufixes (eu defendo que toda correção de bug venha com pelo menos um novo teste de unidade). Pode parecer avassalador agora, mas apenas mergulhe e, depois de obter um pouco de experiência, reconhecer o que faz bons testes se tornará mais fácil.