test design - collaboration based

O que é collaborative user-story writting?

é a descrição de algo que o utilizador pretende fazer com o software, e tem valor para o user, para o comprador e para o sistema

Quais são os 3´C?

card → onde a história é escrita
conversation → história para entender a funcionalidade
confirmation → critérios para confirmar que funcionou como esperado (existe depois o acceptance criteria)

Qual é o formato geral da história?

As a (role) → Quem pretende usar
Quero (objetivo) → O que pretende fazer
Para (conseguir) → Qual beneficio

Quais as técnicas usadas para fazer as histórias?

brainstorming, mind mapping

O que oferece à equipa?

permite que a equipa tenha uma visão partilhada do que está a ser feito e entregue tendo em conta três perspetivas:
negócio; development; testing

O que significa a sigla INVEST?

Independentes;
Negociáveis;
Valiosas;
Estimáveis;
Pequenas e Estimadas.

Para que é que é usada a acceptance criteria?

Definir o scope da user story;
Chegar a um consenso entre os stakeholders;
Descrever cenários positivos e negativos;
Servir de base para o acceptance testing;
Permitir o planeamento e estimação certos.

Como escrever Acceptance Criteria?

Scenario Oriented → quando as mesmas pre condições e inputs dão outputs distintos nos diferentes cenários.
Rule-oriented → checklist de tudo o que deve acontecer , todas as coisas que podem acontecer (sejam ok ou não ok numa lista)
Ou regras próprias do tester

O que é Acceptance Test-Drivem Development?

Técnica onde os testes são definidos primeiro (test-first) e os casos de teste criados antes de implementar a user story.
Ou seja, os testes de aceitação são definidos antes de desenvolver a funcionalidades

Por quem são desenvolvidos esses casos de teste de aceitação?

São criados por diferentes pessoas com diferentes perspetivas (clientes, programadores)
E os casos de teste podem ser executados manualmente ou de forma otimizada.

Como fazer?

1º → workshop (specification workshop) de especificação onde a história de utilizador e os respetivos critérios de aceitação são analisados, discutidos e escritos pelos membros da equipa. É neste processo que as informações incompletas, as ambiguidades e defeitos são resolvidos.

2º → Criação dos casos de teste, que podem ser feitos pela equipa ou individualmente pelo tester. baseiam-se e critérios de aceitação

Como devem ser elaborados os casos de teste?

Devem ser expressos de forma a que os stakeholders entendam.

Normalmente os primeiros casos de teste são positivos, confirmando o comportamento correto do software, sem erros, tudo como esperado → o chamado basic flow (percurso normal e esperado)

Depois são elaborados os negative testing → para verem como o sistema reage a situações inválidas e incorretas (não significa que pretendem que falhe)

Depois devem abranger características de qualidade não funcional.

O que devem permitir os casos de teste?

Cobrir todas as caracteristicas, devem verificar todos os comportamentos e funcionalidades previstas na user story
Não devem ultrapassar a história nem verificar qualidades que não estejam
Dois test cases não devem detalhar a mesma caracterisitica

Como é que os testes de aceitação se podem transformar em requisitos executáveis?

se forem capturados num formato compativel com uma ferramenta de automatização de testes, os programas podem automatizar escrevendo o código