| name | jira-casos-teste-api-story |
| description | Criar casos de teste funcionais de API a partir de uma User Story do Jira e de um arquivo Swagger/OpenAPI local, propor a lista para aprovacao e, somente depois, criar uma subtask por caso de teste com o prefixo [Caso de Testes]. Use quando o usuario fornecer a chave da historia, o caminho do Swagger/OpenAPI e quiser seguir o fluxo de revisar antes de criar as subtasks no Jira. |
| metadata | {"short-description":"Casos de teste de API a partir de historia Jira"} |
Jira Casos de Teste API Story
Transforme uma historia do Jira em casos de teste funcionais de API prontos para revisao e, depois da aprovacao explicita do usuario, em subtasks no Jira.
Use os valores fornecidos pelo usuario como entradas explicitas do fluxo.
Entradas esperadas
jira_ticket: chave da User Story, por exemplo ATD-54
jira_site: identificador do Jira, por exemplo juliodelima.atlassian.net
api_spec_path: caminho local do Swagger/OpenAPI, por exemplo docs/swagger.yaml
Se o jira_site nao vier informado, tente inferir a partir dos recursos acessiveis do Atlassian. Se isso falhar, peca somente esse valor.
Fluxo
- Ler a User Story no Jira.
- Extrair objetivo, criterios de aceitacao, regras de negocio e subtasks existentes.
- Ler o arquivo OpenAPI em
api_spec_path.
- Mapear os endpoints, metodos, payloads e respostas que cobrem os criterios da historia.
- Definir os casos de teste funcionais cobrindo:
- fluxo principal
- fluxo alternativo, quando relevante
- fluxo de excecao, quando relevante
- Evitar duplicidade. Junte validacoes sobrepostas em um caso mais forte quando isso mantiver a cobertura.
- Propor a lista de casos de teste ao usuario e esperar aprovacao.
- Somente apos aprovacao explicita, criar uma subtask por caso de teste na historia.
Regras dos casos de teste
Cada caso de teste proposto deve conter:
Titulo
Flow: Main, Alternative ou Exception
Operação: metodo e endpoint
Corpo da Requisição, quando aplicavel
Status Code da Resposta
Corpo da Resposta, quando aplicavel
Regras de revisao
Antes de criar qualquer item no Jira:
- apresente a lista de forma clara e objetiva
- destaque suposicoes feitas
- mantenha o texto curto, mas pronto para execucao
- aguarde aprovacao explicita do usuario
Se o usuario ajustar cobertura, payloads ou respostas esperadas, revise a proposta antes de criar as subtasks.
Regras de criacao no Jira
Depois da aprovacao:
- crie cada caso como subtask filha de
jira_ticket
- use o prefixo
[Caso de Testes] no resumo da subtask
- mantenha o titulo curto e orientado a acao
- descreva o caso com estas secoes:
Titulo
Flow
Operação
Corpo da Requisição
Status Code da Resposta
Corpo da Resposta
- nao crie subtasks duplicadas
Estrutura preferida da descricao:
Titulo
<titulo do caso>
Flow
Main|Alternative|Exception
Operação
<METODO> <ENDPOINT>
Corpo da Requisição
```json
{ ... }
```
Status Code da Resposta
<status>
Corpo da Resposta
```json
{ ... }
```
Omita as secoes de corpo quando nao se aplicarem.
Validacoes finais
Antes de apresentar a proposta ou criar as subtasks, confirme:
- cada criterio de aceitacao relevante para a API esta coberto
- os casos nao estao duplicados
- metodo e endpoint batem com o OpenAPI
- payloads seguem o schema do contrato
- status codes e erros negativos sao suportados pelo contrato
- a proposta respeita o fluxo de aprovacao antes da criacao
Notas de execucao
- Leia os arquivos locais antes de assumir detalhes.
- Se a historia e o OpenAPI entrarem em conflito, sinalize o conflito e diga qual fonte foi seguida.
- Quando o contrato nao detalhar completamente a resposta, inclua apenas os campos estaveis e relevantes para a validacao.
- Nao crie subtasks antes da aprovacao explicita do usuario.
Exemplos de disparo
Use $jira-casos-teste-api-story para ATD-54 em juliodelima.atlassian.net usando docs/swagger.yaml.
Crie casos de teste de API a partir da historia ATD-54 e do arquivo docs/swagger.yaml, proponha antes de criar no Jira.
Leia a historia no Jira, monte os casos de teste funcionais de API e so crie as subtasks depois que eu aprovar.