Método Priscila de Araujo - Guia QA Do Absoluto Zero - Priscila de Araujo Caimi PDF

Licenciado para - Neimar pereira - 05802496622 - Protegido por Eduzz.
com
Método Priscila de Araujo: Guia QA do

absoluto Zero!
Uma metodologia validada que irá fazer você ser um(a) Analista de
Teste do Absoluto Zero
Autora: Priscila de Araujo Caimi

2
Licenciado para - Neimar pereira - 05802496622 - Protegido por Eduzz.com
Sobre o Livro
Este livro foi criado com o intuito de chegar até você que está cansado de
estudar, estudar e nunca sair do lugar. Aposto que talvez algum leitor tenha pensado
em desistir de migrar de carreira mais de uma vez só por não achar um roteiro de
estudo mesmo, alguém que te diga começa com isso e vamos evoluindo.
A partir disso foi criado este ebook, aqui você vai entender o que é, análise de
projeto, levantamento de requisitos, o que é necessário para criar e saber gerir e
executar um Plano de Teste, lidar com defeitos, conhecer processos que podem te
ajudar no dia a dia além de saber apresentar o seus resultados para o time.
Espero que este material ajude você na sua jornada de evolução.
3
Agradecimentos
Gostaria de agradecer a todos que passaram pela minha jornada profissional,

desde o primeiro estágio até meu cargo atual. Todas as experiências, desde as boas
até as não tão boas assim, fizeram eu me tornar uma profissional segura,
competente e que hoje consegue não só agregar na vida dos usuários mas também
na vida de mais de 20 mil pessoas que eu alcanço nas redes sociais.
Muito obrigada por participar da minha jornada, e espero fazer a diferença na

sua vida como você está fazendo na minha.
4
Sobre a autora
Priscila de Araujo Caimi é Engenheira de Software formada em Química

Industrial pela PUCRS em 2016, Tecnólogo em Análise e Desenvolvimento de
Sistemas pelo IFRS em 2021 e Pós em Marketing Digital pela Conquer em 2022.
Realizou migração de carreira no mesmo ano em que se formou em Química
Industrial e desde então tem dedicado estes anos a construir a sua carreira em
Qualidade de Software. Possui experiências desde processos, passando pelos
testes manuais e evoluindo a automação web, api e mobile. Durante o ano de 2021
decidiu ingressar nas redes sociais para compartilhar seu conhecimento adquirido
ao longo destes anos e mostrar que a migração e evolução de carreira não precisa
ser difícil partindo de uma metodologia eficaz de conhecimentos multidisciplinares.
Em 2022, lançou seu programa de mentoria individual e logo em seguida

realizou o lançamento do seu primeiro curso online onde ensina pessoas que estão
em migração e início de carreira, através do método que desenvolveu ao longo
destes anos fazendo com que sua curva de aprendizado e conhecimento fosse
exponencial. Através deste método busca alinhar, base sólida a evolução constante
além de Growth Mindset, para fazer com que os alunos não caiam em síndrome do
impostor e acreditem cada vez mais em seu potencial.
Hoje, ela lança este livro para ajudar a todos que queiram iniciar o seu roteiro
de estudos para se tornar uma Analista de Teste. Aqui você vai aprender todo
conhecimento básico ensinado dentro do seu curso e assim dar seus primeiros
passos como QA.
5
6
Sumário
Vamos começar pelo início 8

Benefícios do Teste de Software 8
Norma Técnica 9
Tipos de Testes de Software 9
Teste Funcional 9
Teste não Funcional 9
Teste Manutenção 10
Vamos criar “O Produto” 11
Levantamento de Requisitos 11
Critério de Aceite 11
Forma de escrita 12
Prioridade 14
Vamos aos Testes 15
Modelos de Qualidade de Software 15
Pirâmide de Teste 15
Anti padrões 17
Quadrante de Teste Ágil 17
Foco em Tecnologia 18
Suporte ao time 19
Foco em negócio 19
Crítica ao Produto 19
O que se ganha conhecendo os Padrões 19
Diferença de Cenário, Caso e Script de Teste 20
Gherkin vs BDD 21
Como escrever um bom cenário de teste 22
O passo a passo para a escrita 22
Estimativa 24
Pontos 24
Horas 25
Plano de Teste 25
Identificação do Plano de Teste 25
Estrutura dos Testes 26
Suíte 26
Feature 26
7
Caso de Teste 27
Bug Tracking e Reexecutando seu teste 28
Categorização 28
Bug 28
Erro 29
Falha 29
Ciclo de vida do Defeito 30
Prioridade e Severidade 33
Prioridade 33
Severidade 34
Análise de Causa Raiz 35
Diagrama de Ishikawa 35
Diagrama de Pareto 37
Os 5 Porquês 38
Cerimônia de Acompanhamento 41
Sprint Review 41
Tipos de Apresentações 42
Métricas 42
Slide 1 Apresentação 43
Slide 2 Overview 43
Slide 3 Impactos 43
Slide 4 Métricas 44
Slide 5 Atualizações 45
Slide 6 Sentimento do Time 45
Slide 7 Perguntas 45
Demos 46
Métricas + Demos 46
8
Capítulo 1: O que é Teste de Software
Vamos começar pelo início
Teste de Software é uma parte da cultura da qualidade de Software

responsável por testar e validar se o produto está conforme com os requerimentos
descritos pelo time de negócios.
Quando enumeramos as atividades de um profissional que trabalha com

Teste de Software, podemos citar as mais importantes como analisar, testar,
acompanhar andamento dos testes e verificar se existe ou não defeitos na
aplicação, além é claro de prezar pela qualidade e disseminar isso entre os
membros do time.
Benefícios do Teste de Software
O Teste de Software é muito importante no ciclo de desenvolvimento de

Software, ele é importante para diminuir o custo de retrabalho quando é encontrado
um defeito em produção, garantir a segurança de que os requerimentos
estabelecimentos pelo time de produto seja entregue sem nenhum defeito e em
consequência disso você garante a qualidade do produto e assim garantindo a
satisfação do cliente quando o produto for entregue.
9
Norma Técnica
Dentro da Engenharia de Software existe a norma ANSI/IEEE 1059 que

aborda temas relacionados ao processo de desenvolvimento e evolução dos
produtos. Infelizmente esta norma é paga e com um valor bem expressivo em dólar,
porém existem muitos materiais relacionados a esta norma de forma gratuita, e vou
te provar isso.
A norma aborda sobre levantamento de requisitos, bugs, erros, confiabilidade

e performance, e você irá constatar a maioria destes tópicos aqui neste e-book com
uma teoria mais aplicada ao dia a dia além de exemplos práticos.
Tipos de Testes de Software
Dentro deste ecossistema podemos dividir ele em três macros contextos de

teste de software.
Teste Funcional
Dentro dos testes funcionais podemos citar os testes do tipo Unitário,

Integração, Smoke ou Teste de Fumaça, Teste de Aceitação, entre outros.
Teste não Funcional
Nos testes não funcionais englobamos testes de Performance, Load,

Escalabilidade, Usabilidade, Volume de Dados, entre mais.
10
Teste Manutenção
Quando falamos dos testes de manutenção, abordamos testes que são

utilizados para dar suporte ao time, entre eles podemos citar, os testes de regressão
e de manutenção.
Mas não se preocupe com a quantidade de testes existentes dentro deste

ecossistema, existe o tempo específico para você aprender cada uma destas
estratégias de teste, e você vai aprender em que momento deve estudar aqui neste
e-book.
11
Capítulo 2: Tudo começa pelo Critério de Aceite.
Vamos criar “O Produto”
O Critério de aceite é a definição do que o cliente deseja que seja

implementado em seu produto. Então uma boa escrita e análise dos requerimentos
do sistema para escrever um Critério de Aceite coerente impacta diretamente no
resultado da entrega do produto ao cliente e assim garantir a satisfação do cliente.
Levantamento de Requisitos
Uma pessoa que trabalha no levantamento de requisitos é responsável por

organizar e documentar toda a “bagunça” de ideias que se tem na estrutura inicial
de um projeto. Esta “bagunça” de ideias é organizar os dados retornados dos
clientes, protótipos, pesquisas de mercado e escrever toda a documentação técnica
pela área de negócio.
Critério de Aceite
Uma das partes do levantamento de requisitos é escrever os critérios de

aceite. O Critério de Aceite informa de forma simples, rápida e com uma linguagem
universal quem vai usar, o que vai usar e o porque deve ser implementado, desta
forma todos os integrantes do time e/ou qualquer pessoa que pegar aquela tarefa a
ser desenvolvida, terá não só o entendimento do que deve ser desenvolvimento
como também a empatia do porque o usuário necessita desta demanda, e isso é
super importante para a integração do time com o cliente.
12
Forma de escrita
Como dito anteriormente, a forma de escrita de um Critério de Aceite deve ser

a mais simples, intuitiva e clara possível. Eu, gosto muito de usar três palavras
chaves muito simples que fazem com que o entendimento e empatia seja gerado
dentro de cada critério:
- Eu: identifico a minha persona, ou sem linguagem técnica a pessoa

que irá executar a ação no sistema.
- Gostaria: aqui eu informo a ação que a minha persona deseja realizar
no sistema.
- Porque: neste porque eu dou o motivo daquela ação existir no sistema.
Então de forma bem simples eu consigo passar para todas as pessoas que
tiverem contato com a demanda, quem é o usuário que irá realizar a ação no
sistema, o que eu gostaria de realizar e o porquê de eu gerar o sentimento de
empatia com o cliente, e a justificativa daquela implementação.
Utilizando esta forma de escrita você ganha em vários aspectos entre eles
linguagem humanizada de escrita, engajamento na demanda por mostrar o quanto
ela irá agregar ao seu cliente além de trabalhar com a empatia do time no
desenvolvimento do produto e com o usuário que irá utilizar, isso faz com que o time
de desenvolvimento sinta-se envolvido naquela mudança de vida ao contrário de ser
apenas mais um software que eu estou construindo.
E, por que fazer isso? Imagine que, você quer desenvolver um Software, e te
dão duas opções de time para trabalhar no desenvolvimento, um time é engajado,
está programado a ser orientado a resultados inovadores, preocupado com o cliente
além de trabalhar com excelência de entrega pensando na mudança que irá trazer
ao cliente, e do outro lado você tem um time que pensa que, é somente mais um
13
software que será desenvolvido e entregue. Qual destes dois times você irá querer
que desenvolva a sua aplicação? Eu não sei você, mas eu com toda certeza escolho
o time número 1.
Agora vou te trazer um exemplo para isso ficar bem claro.
Referência da imagem: Simple Login Screen for Iphone por Rabia Israr no
https://www.figma.com/@rabiaisrar
Critério de Aceite
Eu, como usuário do aplicativo

Gostaria, de realizar o login
Porque, quero ter acesso a todas as funcionalidades que o App me
proporciona.
Quando você entrega uma Story(iremos ver isso mais para frente) ao time
para que seja desenvolvida e testada, você compreende que fica super claro quem
deseja realizar a ação (Eu), que ação será executada (Gostaria) e o porquê dela ser
realizada(Porque)?
14
Prioridade
Em conjuntura com a descrição do critério de aceite é necessário informar

também a prioridade daquela tarefa perante as outras que também serão criadas
para o projeto. A Prioridade é a categorização dada a tarefa para a sua ordem de
desenvolvimento, ou seja, quanto mais alta a prioridade mais rápido ela deve ser
iniciada.
Esta categorização existe para evitar que as tarefas sejam pegas de forma
aleatória e mais para frente no projeto, gere bloqueio ou defeito desnecessário visto
que o desenvolvimento foi realizado de forma desordenada.
A prioridade possui três status sendo eles, alto, médio e baixo. Uma
característica muito importante quando falamos de prioridade é que ela se torna
dinâmica durante o fluxo de desenvolvimento. E isso ocorre porque em algum
momento do ciclo de desenvolvimento a prioridade de entrega acaba mudando e
com isso os esforços são alterados para a nova tarefa e em consequência os status
também mudam para estar em coerência com esta mudança.
15
Capítulo 3: Primeiros passos com Qualidade de Software
Vamos aos Testes
Chegamos ao planejamento e execução das atividades de um Analista de

Teste, e com isso alguns tópicos devem ser abordados como os tipos de testes que
são mais executados, as formas que podem ser escritos, saber estimar seu trabalho
e por fim o Plano de Teste.
Modelos de Qualidade de Software

Para saber que teste deve ser executado, primeiramente você precisa saber
identificar em que momento do ciclo de desenvolvimento o time se encontra, para
assim identificar o teste e por consequência, seguir como uma estratégia de
aplicação do teste.
Com isso irei apresentar-te dois padrões de qualidades e um antipadrão e o

porquê deles serem usados.
Pirâmide de Teste
Um dos primeiros, se não o primeiro padrão de qualidade estabelecido para

garantir qualidade no desenvolvimento de software, o seu foco ao ser criado era
indicar em que fase cada testes deveria ser realizado para garantir que os testes
fossem realizados desde o momento da criação da primeira linha de código até os
testes de usabilidade realizado em parceria com o cliente.
Além de pensar em garantir a qualidade desde a concepção, ao seguir o

padrão da pirâmide de teste, iremos garantir que a relação custo/desenvolvimento
dos testes será baixa no início do desenvolvimento e irá aumentando conforme a
fase de implementação.
Ou seja, devemos focar em atingir coberturas de 100% na base da pirâmide

já que a relação custo/hora e custo/esforço será baixa, e conforme for aumentando o
nível da pirâmide esta relação irá subir proporcionalmente.
16
Referência da imagem: Pirâmide de Testes - Porque você precisa saber por

Aloisio Almeira no https://devporai.com.br/piramide-de-testes/
Como pode-se ver na imagem acima, a pirâmide de teste possui três

categorias sendo Testes Unitários, Testes de Serviço e no topo Testes de UI. E
dentro de cada uma destas categorias existem testes que podem ser executados em
cada uma destas fases.
Unitário Serviço UI
Testes Unitários Teste de Componente Teste de Usabilidade
Teste de Integração Teste de Acessibilidade
Testes Funcionais
Testes Exploratórios
Agora você deve estar se perguntando, entendi as categorias da pirâmide, os

testes que podem ser executados em cada categoria, mais em que momento do
ciclo de desenvolvimento é utilizada cada categoria?
Vamos imaginar que queremos construir uma casa e que cada função do
sistema é um lego, e para construir esta casa precisamos que todos os legos se
encaixem perfeitamente garantindo que a casa tenha funcionalidade de casa e não
funcionalidade de apartamento.
No contexto pirâmide de teste o ciclo de desenvolvimento inicia com o time de

desenvolvimento, então o primeiro teste que deve ser realizado nesta fase é o teste
unitário, assim o teste garante que a mínima função do sistema está sendo testada
17
de forma isolada, garantindo o seu funcionamento. No nosso exemplo da casa com

legos, o teste unitário irá garantir que o lego irá sair com a sua função de lego.
Quando evoluído o desenvolvimento de Software as integrações começam a

ser realizadas, então a junção dos legos é necessária para que esta parede seja
erguida e tenha a funcionalidade de uma parede, e com isso alguns testes são
necessários para validar que a junção destes legos deu certo, nada foi danificado e
estes testes são Testes de Integração e de Componente.
E estas integrações ocorrem várias e várias vezes no desenvolvimento,

imagine que cada estrutura da casa que precisa ser desenvolvida irá passar por este
processo.
Quando finalizado o desenvolvimento da de cada funcionalidade da casa,

passamos para os testes de UI, onde serão validados testes de usabilidade,
acessibilidade, funcionais e exploratórios, para validar se mesmo depois da
integração tudo está de acordo com os critérios levantados pela área de negócio.
Anti padrões
Anti padrões nada mais é do que uma versão “distorcida” de uma padrão,
para a pirâmide de testes temos alguns como ice scream ou sorvete, cupcake,
colmeia, entre outros.
E estes padrões surgem de uma visão distorcida de qualidade que as

empresas pregam no seu dia a dia. Um exemplo bem simples que é a variação
sorvete da pirâmide de teste, onde a garantia de qualidade é garantida em maior
número nos testes manuais lá no final do processo, quase na entrega ao cliente,
fazendo assim com que os defeitos sejam descobertos somente lá no final do
processo elevando o custo para a sua correção.
Defeitos quando descobertos em fase inicial, durante o teste unitário o seu

custo para resolução é muito inferior, quando encontrados no final do processo onde
é preciso analisar o ponto em que o defeito realmente está. Lembra da história da
casa construída por legos, imagina encontrar uma infiltração? É necessário fazer
uma análise em toda a casa para ver em que ponto iniciou a falha e ir corrigindo até
a parede visualizar a infiltração.
Quadrante de Teste Ágil
Outro padrão que vem se difundido nos últimos anos é o Quadrante de Teste
Ágil, e ele vem com um contexto mais dinâmico e interativo. Ao contrário da
pirâmide o quadrante possui uma divisão em quatro quadrantes e com quatro
pilares, sendo eles:
- Foco em negócio
- Crítica ao produto
18
- Suporte ao time
- Foco em Tecnologia
Referência da imagem: Introdução do Quadrante de Teste Ágil por Elis

Nogueira no
https://blog.adaptworks.com.br/2013/11/introducao-do-quadrante-de-teste-agil/
Estes quatro pilares ajudam você a estruturar estratégias de melhoria e

qualidade contínua, dependendo do foco necessário. A melhor estratégia é seguir
sempre o conceito do quadrante que é seguir a ordem dos quadrantes indo do Q1
ao Q4, porém muitas vezes isso não se torna possível quando o produto já está em
desenvolvimento, ou trabalhamos com um sistema legado (sistema que já foi
desenvolvido e apenas o suporte ou funcionalidades incrementais são
implementadas) e então os pilares do quadrante ágil entram em ação.
Foco em Tecnologia
Quando é necessário melhor a qualidade em relação à tecnologia utilizada

pelo time, ou seja, melhor a qualidade de código, utilizamos os testes unitários e de
componentes para validar o nível da qualidade do código desenvolvido na aplicação.
Eu, Priscila ainda colocaria neste mesmo nível os testes de integração, lembra-se do
exemplo da casa? Assim eu validaria se o encaixe dos legos está correto.
19
Suporte ao time
Quando precisamos dar suporte ao time, introduzimos os testes funcionais,

análise de protótipo, documentação e realizamos simulações dos ambientes. Isso
faz com que seja testado se a “casa” está funcionando conforme o esperado, tendo
portas, janelas, sala, quarto, cozinha, banheiro, etc.
Foco em negócio
O assunto sendo foco em negócio, iniciamos os testes junto ou em prol da

qualidade do cliente. Podemos citar os testes exploratórios, usabilidade, aceitação e
alpha/beta, estes testes têm como premissa encontrar possíveis defeitos ou pontos
de melhoria que irão fazer a diferença no dia a dia do cliente no uso do sistema.
Crítica ao Produto
Este foco faz doer a ferida do sistema e as pessoas que desenvolveram, aqui
os testes são muitos específicos para determinadas ações como garantir que um
site de lançamento de um produto, show ou eventos festivos não caia durante o
período de compra (teste de carga e performance) ou que um sistema não seja
hackeado (teste de segurança). Ou seja, estes testes não são realizados a todo
momento como os anteriores, eles são normalmente executados em determinadas
épocas.
O que se ganha conhecendo os Padrões
Quando conhecemos e dominamos a essência da ideia dos padrões e

implementamos isso dentro de um time, isso nos faz ganhar alguns pontos muito
importantes.
São eles:
- Saber priorizar e escolher os testes: esta é a dúvida de um milhão

de reais de quase todo testador que inicia na área, que teste eu utilizo em tal
fase e o porquê? Quando se entende o conceito por trás das metodologias de
qualidade você sabe qual teste aplicar e em que momento, e o melhor, ainda
sabe criar um plano de implementação para propor ao time em que trabalha.
- Assertividade: Sim, ser assertivo no teste faz com que você gere
entrega de qualidade, adiantar teste ou executá-los em momentos incorretos
só irá fazer você perder tempo e não agregar qualidade ao time.
20
- Automação: Ah, o termo mais falado do momento. A estratégia nunca

é automatizar tudo que se vê, mas automatizar o que é importante e
estratégico, como testes unitários, integração e de componente, já que a
maioria dos problemas se encontram nestas fases.
- Qualidade: Bom, eu nem precisava citar este tópico porém é sempre

bom ressaltar o aumento da qualidade nos testes e no produto é evidente ao
se utilizar uma metodologia.
Diferença de Cenário, Caso e Script de Teste
Antes de entrarmos no assunto como escrever, precisamos saber as formas

possíveis de escrever. Para isso precisamos saber diferenciar as três formas de
escrita de teste existentes, sendo elas Cenário de Teste, Caso de Teste ou Script de
Teste.
Cada uma das formas possui uma peculiaridade e você provavelmente irá
passar por todas elas através do seu nível de evolução. E isso é super normal, pois
quando começamos a analisar um certa funcionalidade nós buscamos escrever
passo a passo da nossa execução através dos Scripts de Teste, de modo que se
precisarmos executar novamente não teremos problema, porém com o passar do
tempo evoluímos a nossa escrita e domínio do sistema e aí entram os Casos de
Teste, e quando temos domínio do negócio e pouco tempo para escrita utilizamos o
Cenário de Teste. Veja na tabela abaixo a diferenciação de cada uma destas formas.
Quesito Cenário Caso Script
Exemplo Testar se o Usuário “Testar se um código Ação – Clique no

consegue logar na de desconto pode ser botão X, Resultado –
aplicação aplicado em um A janela fechou.
produto em promoção”
Nível de Baixo Médio Alto

detalhamento
Quando Quando se possui um Descrevem o objetivo Quando não se tem

utilizado objetivo a ser testado. do teste, sem dar tanto domínio do
muitos detalhes sobre negócio e/ou é exigido
como executar alto nível de
detalhamento
21
Prós Da liberdade ao testar, Fácil reaproveitamento Pessoas com pouco

criar seus próprios de código, baixo nível domínio conseguem
cenários de testes de reescrita, entender a
durante a execução e proporcionam funcionalidade do
assim encontrar flexibilidade e o uso da sistema de maneira
defeitos em lugares criatividade do mais acelerada.
não esperados. testador
Contra O testador precisa ter Necessário possuir Demanda muito tempo

domínio do negócio ao domínio do negócio. de escrita e
utilizar esta manutenção, além de
abordagem. não ser reutilizado
para outro script por
se tornar algo muito
específico, e por fim
não encontrar bugs
que podem ser
encontrados quando o
testador possui mais
liberdade de teste.
Gherkin vs BDD
Para quem já está na área de Teste há algum tempo já deve ter ouvido a
expressão “associação forte”, porém equivoca-se quem acha que o Gherkin só é
utilizado na automação de testes. E isso ocorre porque a linguagem Gherkin é
utilizada no framework de automação chamado Cucumber que como consequência
é utilizada na automação com BDD, e aí ocorreu esta analogia equivocada.
O Gherkin é uma linguagem universal para escrita, ela possui suporte para
diversas línguas facilitando assim a sua utilização como padrão na escrita tanto de
cenários de testes como na própria automação.
Para utilizar o Gherkin simplesmente basta conhecer as suas KeyWords ou

palavras chaves reservadas para determinar uma funcionalidade na escrita, veja
abaixo.
- Given (pt: Dado): utilizado para especificar uma pré-condição
necessária antes de iniciar o teste, é como se você fosse viajar e precisa
informar seu local de partida. Por se tratar de uma pré-condição deve ser
escrita no verbo passado.
22
- When (pt: Quando): Utilizado quando será executada uma ação de

que se espera uma reação vinda do sistema, que será validada no step
“Then”. Este passo vem escrito no presente;
- Then (pt: Então): valida se o resultado esperado aconteceu. Por se

tratar do resultado esperado, vem normalmente escrito na forma de futuro
próximo;
- And (pt: E): Caso seja necessário mais uma interação com o sistema
para complementar um fluxo, mas que não necessariamente se trata de uma
ação ou reação, se utiliza “And”;
- But (pt: Mas): Utilizado para realizar uma validação de contra partida
depois do “Then”;
Como escrever um bom cenário de teste
Escrever um bom Cenário de Teste não tem muito segredo para isso, e irei te
guiar durante esta jornada. Você deve ter observado que grifei a palavra cenário de
teste, ou seja, irei evoluir seus testes com este ebook indo de um Script de Teste
super detalhado e sem reaproveitamento nenhum, para a escrita de um Cenário de
Teste onde você irá poder aproveitar o seu tempo de escrita em mais de uma tarefa
de teste e eu irei te provar isso.
O passo a passo para a escrita
Antes de começar a escrita nós iniciamos um processo imersivo de análise

das funcionalidades, aqui eu gosto muito de fazer mapas mentais ou até mesmo
escrever em papel as funcionalidades macros de teste, isso faz com que eu veja o
todo e além disso, consiga visualizar as correlações existentes entre uma tarefa de
desenvolvimento e outra. E você sabe onde este processo irá lhe ajudar? Além do
entendimento do produto, você também ganha conhecimento dos testes que podem
ser agrupados e validados de uma única vez.
23
Vamos de exemplo:
Critério de Aceite 1:
Eu, como usuário
Gostaria, de ter um filtro por preço
Porque, assim consigo filtrar pelo mais caro ou mais barato
Eu, como usuário
Gostaria, de ter um filtro por categoria
Porque, assim consigo filtrar pela categoria do produto
Eu, como usuário
Gostaria, de ter um filtro por tamanho
Porque, assim consigo filtro pelo tamanho desejado
Aqui você já consegue ver que possuímos três critérios de aceite de tarefas
diferentes, onde cada uma irá implementar um filtro na página de resultado da
busca. Com isso eu gero uma conexão em comum para todas sendo elas:
- Eu me encontro em uma página de resultado de busca

- Quando o resultado é exibido
- Então os filtros devem aparecer
De forma bem simples e sem usar totalmente o Gherkin eu consegui escrever

de forma macro, o esboço do que será meu Caso de Teste. Bom vamos começar a
polir ele.
Irei ensinar algumas Keywords novas do Gherkin, o Esquema de Cenário

utilizado exatamente para exemplos como este de reaproveitamento de teste, e o
Exemplo que sempre vem acompanhando o Esquema de Cenário. Para você
conhecer e estudar todas as keywords existentes no Gherkin basta procurar no
google cucumber.io e ir nas documentações, que lá você irá encontrar toda
Referência sobre Gherkin.
Então partindo do primeiro resumo para o caso de teste final utilizando as

novas Keywords, o nosso cenário ficará assim.
Esquema do Cenário: Validar filtros
DADO que me encontro no resultado da busca (situação passada necessária

para iniciar os testes)
QUANDO clico no <filtro> (este filtro entre <> é o que nós chamamos de tags
dentro do esquema do cenário, fazendo assim com que qualquer variável seja
inserida ali)
ENTÃO os dados do filtro <filtro> devem ser exibidos (resultado esperado ao
clicar no filtro desejado)
24
Exemplos: (aqui serão inseridas as variáveis utilizadas nas tags)

|filtro| (cada tag inserida no teste deve estar na primeira linha, separada por |)
|preço| ( a partir da segunda linha serão colocadas as variáveis que serão
testadas, no nosso caso preço, categoria e tamanho)
|categoria|
|tamanho|
O Esquema de Cenário ele tem a função de loop, ou seja, para cada

execução será capturada uma nova variável, ou seja, a primeira execução irá pegar
o preço, na segunda a categoria e na terceira o tamanho. Isso faz com que em vez
de você escrever três cenários exatamente iguais e no futuro ser necessário realizar
manutenção de três cenários diferentes, você escreve apenas um, facilitando a sua
execução e manutenção futura.
Agora, caso não existissem as três opções de filtro, você simplesmente iria
escrever.
DADO que me encontro no resultado da busca

QUANDO clico no preço
ENTÃO os dados do filtro preço devem ser exibidos
E assim com a análise imersiva, mapeamento das funcionalidades,

agrupamentos das que podem ser testadas juntas, você consegue ganhar tempo e
ainda escrever cenários com qualidade.
Estimativa
Estimar seu trabalho vai fazer parte do seu dia a dia quando iniciar na área, e
isso é necessário para que o PO (product owner ou dono do produto) saiba quanto
tempo cada tarefa irá demorar para ser concluída.
Existem algumas formas de fazer isso, as mais comuns são através de horas
ou pontos (utilizado em metodologias ágeis). Iremos abordar estas duas formas
aqui.
Pontos
Os pontos normalmente têm um relacional a esforço, quanto maior o número
de pontos maior é o esforço para se executar determinada demanda. E para isso é
utilizado uma técnica que se chama Fibonacci. Esta é muito utilizada no SCRUM,
25
ela é utilizada durante a cerimónia de planning, e em consequência esta dinâmica

tem o nome de Planning Poker.
A imagem abaixo é o estilo de cargas utilizadas durante a dinâmica, esta

imagem pode ser vista no artigo que irei deixar nos materiais. Cada carta representa
um ponto e um tipo de esforço, de costume o time escolhe o máximo de pontos que
podem ser estimados e juntamente com isso o que cada carta irá representar.
Horas
Bom aqui não tem tanto mistério, quando o time opta por estimar em horas o
seu tempo de execução, você precisa ter noção de alguns elementos:
● Gerar ambiente
● Massa do teste
● Entendimento da tarefa para criar os cenários, casos ou scripts
● Execução
● Gerar report
Não se preocupe se você não tem experiência com isso, por isso estou
nivelando vocês para iniciar a prática e em consequência vocês terem uma noção
do tempo que vocês demoram.
Estes itens que eu ressaltei como elementos importantes para saber

estimar o seu trabalho também valem para o esquema de pontos.
Plano de Teste
Agora que você tem os conhecimentos necessários para iniciar o seu plano
de teste, vamos começar a entender a estrutura de um.
Identificação do Plano de Teste
Está será a primeira informação que você encontra em um Plano de Teste, e

alguns itens são adicionados aqui, entre eles citamos:
26
- Nome do Plano de Teste: o nome do plano de teste normalmente

segue um padrão estabelecido pela empresa, por exemplo, código do projeto
+ ano ou release de entrega.
- Analista de Teste responsável: O nome do Analista de Teste que está

responsável pelos testes do Plano deve ser descrito neste item para que caso
surjam dúvidas o mesmo seja acionado.
- Data prevista de início e Término: Estas datas indicaram a todos a data

de início e término planejado para a execução do Plano de Teste, está dada
costuma ser muito próxima do deploy.
- Prioridade: Em uma empresa não irá existir apenas o seu projeto,

existirão vários projetos por isso é necessário estabelecer a prioridade
daquele projeto perante os outros.
- Severidade: Assim como a prioridade, a severidade também está

correlacionada aos projetos da empresa.
Além dos dados essenciais informados, alguns outros pontos podem ser
informados como o Propósito do projeto, seu Público alvo e o Escopo que será
abordado no Plano.
Estrutura dos Testes
A estrutura do Plano de Teste é dividia em Suíte, Features, Casos de Teste e

em alguns momentos defeitos, vamos explorar cada uma delas:
Suíte
Fazendo correlações simples, vocês lembram do exemplo da casa não? A

entrega da casa é o nosso Plano de teste, as Suítes de Teste nada mais é do que
cada cômodo da casa, então teremos uma suíte para sala, outra para a cozinha e
assim por diante.
Então em termos técnicos Suíte de teste é uma coleção de Features utilizada

para validar um conjunto de micro funcionalidades e que no final somam-se e
entregam uma funcionalidade completa.
Feature
Cada Feature do sistema, funciona como uma micro funcionalidade do

sistema, quando se realiza o teste de uma Feature estamos testando uma
27
funcionalidade por completo do sistema, não existe teste de Feature sem ela estar
totalmente implementada.
No exemplo da casa, vamos supor que estamos testando a Suite sala e a

Feature janela, então ao testar na janela devemos validar se a mesma possui todos
os critérios de aceite estabelecidos pela área de negócio.
Caso de Teste
Casos de teste são as micros validações de uma Feature aqui são escritos os
testes de forma detalhada para validar se as tarefas foram desenvolvidas de acordo
com os critérios de aceite.
Voltando ao exemplo da casa, estamos na Feature da janela, então os casos

de teste podem englobar, como abre a janela, a cor, se vai ter cortina, o formato,
entre outras características que podem ter uma janela.
No fluxograma abaixo irei ilustrar o exemplo da casa e como eles podem estar
divididos.
Referência da imagem: Produzida pela própria autora
28
Capítulo 4: Caçador de Bugs (brincadeirinhaaa)
Bug Tracking e Reexecutando seu teste
Este módulo é focado para entender o conceito de Bug e como ele

pode afetar o seu dia a dia. Isso pode ocorrer durante a execução do seu
plano de teste, durante uma execução simples do seu dia a dia ou até mesmo
descobertos por outros membros do time ou em última instância encontrado
pelo cliente e chega ao time através do suporte da empresa.
Categorização
Bug
É como falamos de forma informal que um defeito foi encontrado no sistema.

Sendo assim um bug ou defeito por assim dizer é quando uma funcionalidade do
sistema não respeita as regras de negócio e/ou o critério de aceite estabelecidos
para aquela funcionalidade.
De forma ilustrativa podemos dizer:
QUANDO = funcionalidade a ser realizada

ENTÃO = resultado esperado
O defeito pode ser encontrado em dois momento neste caso, no

- QUANDO não deixando assim a ação da funcionalidade acontecer, ou
- ENTÃO o resultado da ação esperado ser exibido
29
Erro
O erro está diretamente relacionado ao código desenvolvido, os erros são

encontrados a nível de desenvolvimento. Neste específico tipo de defeito é causado
e encontrado por desenvolvedores.
Entre os erros encontrados pode ser citado, sintaxe do código, hardware

incompatível com o sistema, erro no teste unitário, erros de interface, entre outros.
Nestes casos os código em sua grande maioria nem chega a compilar ( gerar um
executável do programa).
Falha
Neste tópico entramos em erros de origem humana em sua essência. Esse

erro ocorre normalmente no sistema na sua fase inicial durante o levantamento de
requisitos e definições de arquitetura, podendo assim gerar inconsistência em
dados, erros de performance, erros de segurança, não deixar o sistema funcional,
regras de negócio não coerente gerando ambiguidades ou dúvidas na construção do
sistema.
30
Ciclo de vida do Defeito
Quando encontra-se um defeito durante o ciclo de desenvolvimento de um

software, muitas vezes nos questionamos de que forma ele deve ser tratado, como
um Story? task? e como ele anda no board? Tudo isso vai ser esclarecido para
vocês neste tópico.
Quando um bug é encontrado ele deve ser reportado ao time de

desenvolvimento com o máximo de informações possível para assim acelerar o seu
processo de correção e também assim gerar um documento que posteriormente
pode vir a se tornar uma das ferramentas para se encontrar a causa raiz do defeito.
A melhor forma de reportar um defeito ao encontrar é seguir este check list:
Evidência em print ou vídeo, se necessário realizar a narrativa para

ficar o mais claro possível
O Critério de Aceite irá ajudar o desenvolvedor a entender onde se
encontra o erro, pois assim ele lê, entende o famoso DADO, QUANDO,
ENTÃO e em conjuntura com a Evidência ele consegue iniciar a sua análise.
Cenário de Teste se houver o caso de teste em específico que foi
observado a falha, vincule ele ou transcreva para a descrição do defeito,
deixando destacado o ponto em que o defeito foi observado.
Requisições Web, se você souber analisar as requisições realizadas
pelo sistema, e através do log ver a possível falha através do stacktrace, irá
facilitar ainda mais a análise do desenvolvedor.
Prioridade, irá informar o quão rápido aquele defeito precisa ser
corrigido.
Severidade, informando o quão grave ele é dentro da aplicação.
Após saber abrir um defeito com todas as informações necessárias,

precisamos entender como ele se comporta dentro do ciclo de desenvolvimento
como um todo.
31
Nós temos dois fluxos macros, sendo o fluxo de um defeito novo e o fluxo de
um defeito que já existe ou existiu em algum momento no sistema e por algum
motivo voltou acontecer e com isso necessitou ser aberto.
Vamos iniciar com o mais fácil, um defeito que é a primeira vez em que foi
aberto. Quando um defeito é aberto pelo QA, ele é considerado como uma “bug”
dentro das ferramentas, após isso algum desenvolvedor dentro do time irá pegar ele
para si e iniciar a análise/correção do item. Após a sua correção é enviado para
teste e assim iremos re-testar ou como a literatura informa realizar o teste de
confirmação para confirmar se o defeito foi corrigido, e aqui dividimos o fluxo e isso
tudo porque existe o condicional está funcionando? Se for corrigido este defeito será
fechado, se ele não foi corrigido ele será devolvido para o time de desenvolvimento
com as evidências necessárias para indicar que o problema ainda persiste.
Mas e se o defeito tiver sido corrigido, porém foi gerado um outro defeito?
Excelente pergunta. Iremos finalizar o defeito corrigido, porém iremos abrir um
defeito e informar que este defeito foi encontrado a partir do defeito X.
Porém existem alguns outros status que podem ser atribuídos aos defeitos,
fazendo com que eles não sigam o fluxo de desenvolvimento.
32
E isso pode ocorrer por alguns motivos que irei enumerar alguns abaixo:
- Duplicado, por incrível que pareça isso pode ocorrer dentro dos times,
o report duplicado de defeitos fazendo assim com que o próximo criado seja
duplicado. Quando isso ocorre, o desenvolvedor envia para o QA, o defeito
duplicado para assim ser finalizado.
- Inválido, este tipo de defeito pode ocorrer por que o QA escreveu o

teste de forma incorreta, isso pode acontecer por inúmeros motivos sendo
alguns deles, documentação ambígua, definições não documentadas da
história de desenvolvimento, etc.
- Não pode ser resolvido, este tipo de status são em casos muito raros
e específicos. Para um desenvolvedor colocar um status deste é porque a
correção daquele defeito está fora do time para resolução, por exemplo,
tecnologia não suporta, bug do framework de desenvolvimento, o custo do
desenvolvimento pode ser tão alto quanto a sua manutenção posterior.
- Não reproduzido, em quase todas as empresas que eu trabalhei já me
deparei com este tipo de defeito, ele acontece em momento específico, ou
somente em uma máquina, e o pior de todos não existir log para conseguir
pelo menos rastrear o porquê daquele problema. Quando este tipo de erro
ocorre o desenvolvedor envia para o QA com a mensagem que não foi
possível reproduzir e assim o defeito acaba sendo finalizado sem solução, ou
33
alguns times decidem deixar o defeito em backlog para quando for pego
novamente o mesmo já está criado.
Prioridade e Severidade
Prioridade
Ao trabalharmos na criação de Stories de desenvolvimento, precisamos

entender o conceito de priorização de demandas, pois isso vai interferir diretamente
na ordem de desenvolvimento das tarefas.
Mas como isso funciona? Quanto maior a prioridade mais urgente a tarefa
precisa ser desenvolvida, existem 3 nível de prioridade:
● Alta
● Média
● Baixa
Vamos trazer um exemplo para ficar claro. Tenho lá as minhas telas do figma
e preciso estabelecer a ordem de prioridade nas tarefas que eu criei nas aulas
passadas.
Como vocês devem pensar, de forma simplificada:

● Quais são as ordens das telas
● Qual é o pré-requisito de cada tela
● Cada tela tem ao menos uma Storie
Quando você consegue ver os pré-requisitos de cada tela, você consegue ver
quais tem que ser desenvolvidas antes e como consequência estas tarefas deverão
possuir uma prioridade mais alta do que as que vem depois, isso faz com que:
34
● Não se tenha gargalos durante o desenvolvimento, e assim deixando

uma parte do time parada
Para ficar visível, faça uma timeline com a ordem que as tarefas precisam ser
desenvolvidas conforme o seu pré-requisito, pois se existe um, o mesmo precisa ser
desenvolvido antes. Ao fazer desta forma você irá visualizar bem mais fácil a
prioridade das demandas.
Uma observação bem importante sobre Prioridade é que ela pode sofrer
alterações durante o ciclo de desenvolvimento, ou seja, um item que hoje se
encontra como baixa, pode ser alta em algum momento, vice e versa.
Severidade
Assim como a prioridade está relacionada à prioridade das demandas serem

desenvolvidas, a severidade está relacionada ao quão bloqueante aquele defeito
pode ser na aplicação.
A Severidade é dividia em 5 tipos:

● Crítico: sistema bloqueado
● Alta: sistema não está bloqueado, mais impede que funcionalidades
não críticas, não sejam realizadas com bom funcionamento
● Médio: Pode ser causada por algum tipo de instabilidade, porém não
afeta a funcionalidade do sistema.
● Baixo: Não causa nenhum tipo de quebra no sistema.
● Cosméticos: São elementos visuais no sistema.
A severidade ao contrário da prioridade é estabelecida pelo time de

qualidade, visto que os agentes da qualidades são as pessoas mais indicadas a
dizer o quão bloqueantes aquela tarefa ou defeito tem dentro da funcionalidade ou
da aplicação como um todo. Além disso, ela nunca muda, a prioridade dependendo
do momento do desenvolvimento pode sofrer alteração, porém com a severidade
isso nunca irá ocorrer.
35
Análise de Causa Raiz
A análise de causa raiz é utilizada para estudar e analisar a causa real de um

problema existente que não está de acordo com algum padrão de qualidade
estabelecido pelo time ou até mesmo a companhia como um todo.
Quando utilizamos esta abordagem para tratarmos destes problemas,

buscamos encontrar a sua real causa e atacar o “foco” do problema no qual
chamamos de causa ou causas em caso de mais de um ponto, assim evitamos que
este problema volte a acontecer a curto, médio ou longo prazo dependendo da
situação.
Mas para utilizarmos a Análise de Causa Raiz (RCA) na sua fase de melhoria
contínua do processo podemos utilizar mais de um processo de qualidade, hoje irei
abordar os três mais utilizados e falados nas bibliografias.
Diagrama de Ishikawa
O Diagrama de Ishikawa ou Causa e Efeito, é utilizado para detectar os

efeitos que possíveis causas acarretam dentro do processo. Ele pode ser utilizado
na prevenção quando já conhecemos possíveis causas que podem acontecer dentro
do sistema, ou trabalharmos de forma reativa quando o problema já aconteceu e
buscamos encontrar a causa para ser corrigido.
Para utilizarmos o diagrama, podemos aplicar a técnica dos 6M’s para

determinar de forma macro as causas que o sistema pode ter, sendo elas:
- Materiais: quando lidamos com itens físicos, verificando e validando

assim a sua integridade e estabilidade.
- Meio ambiente: é o ambiente que seu produto está sendo desenvolvido
e todas as interferências que ele possui, no caso do desenvolvimento de
software podemos falar de memória, banco de dados, infra estrutura, entre
outros.
36
- Método: verificar a metodologia utilizada para o desenvolvimento.

- Mão de obra: aqui falamos dos integrantes do time.
- Máquina: neste caso, é a máquina utilizada por cada elemento do time.
- Medição: Esta relação é mais para empresas que precisam ser
medidos, aferidos e instrumentações de materiais.
Após indicarmos as 6 possíveis causas que podem afetar o objetivo final,

podem ainda subcategorizar se julgar necessário, em casos de sistemas complexos
ou problemas muito específicos.
Após debater com o time e até mesmo outras áreas se assim for necessário,
passamos para a etapa de criar planos de ação para realizar as melhorias
necessárias para que as causas sejam atacadas e assim o efeito causado seja
solucionado.
37
Diagrama de Pareto
O diagrama de Pareto é um técnica de qualidade usada para gerar métricas

quantitativas dos problemas ocorridos durante o ciclo de desenvolvimento, estes
problemas podem englobar, defeitos, feedbacks e qualquer outra “causa” que por
consequência tenha um efeito.
Ele é um ferramenta poderosa quando aliado a outras técnicas de qualidade

como a vista anterior. Enquanto uma analisa de forma qualitativa (Diagrama de
Ishikawa ) o diagrama de Pareto faz a análise quantitativa das causas e assim,
poder atacar as causas mais significativas ou seja as que mais ocorrem dentro do
sistema.
Abaixo temos um exemplo de diagrama de Pareto extraído da Wikipedia.
Referência da imagem: Diagrama de Pareto por Wikipedia no

https://pt.wikipedia.org/wiki/Diagrama_de_Pareto
Mas agora você deve estar se perguntando como que analisamos os dados
do gráfico. Na imagem em questão possuímos dois eixos verticais, do lado esquerdo
está em números do tipo decimais e do lado direito consta a sua representação em
porcentagem, enquanto que no eixo horizontal é descrito as causas agrupadas em
38
categorias. Então conseguimos pegar uma causa e analisar tanto em números,

quanto em porcentagem ela está afetando a produção.
Ainda pode-se utilizar uma versão mais micro, onde se analisa além das
causas as suas subdivisões, assim quando elegido a causa que será tratada,
pode-se analisar qual subcausa deve ser atacada primeiro, isso faz com que o
tempo voltado para a correção de uma sub-causa seja mapeado também, por isso
só é utilizado quando existem um número grande de subcategorias para serem
abordadas e quando as mesmas não podem ser ajustadas em um único processo.
Os 5 Porquês
Está para mim é a técnica que irá fazer você aumentar o seu nível de
criatividade, envolvimento com a demanda e seu pensamento a curto, médio e longo
prazo. E isso tudo através da técnica de realizar dos 5 porquês.
Tudo começa com um efeito, algum problema tendo em vista o ocorrido, e a

partir disso são realizados 5 questionamentos com a mesma palavra: Porquê? Isso
faz com que as pessoas envolvidas na dinâmica, explorem os mais variados lados
possíveis para assim chegar ao maior número possíveis que podem ter causado ou
poderá causar determinada situação.
Nesta técnica não existe uma pergunta específica para seu utilizada em
conjunção com o porquê, os porquês irão se suceder da análise da resposta do
porquê anterior.
39
Abaixo é possível visualizar um exemplo extraído de um artigo.
Referência da imagem: O que é e como usar a metodologia 5 porquês por

Pinterest no https://br.pinterest.com/pin/51017408269912838/
40
Capítulo 6: O óbvio precisa de dito e informado a todos
Acompanhamento e entrega do
Projeto
O Quality Assurance ou QA, além do planejamento do levantamento de

requisitos e planejamento da execução dos testes, ele também é responsável por
acompanhar o andamento da Sprint do ponto de vista dos testes, além é claro de
entregar o projeto com todos os dados de execução durante o período de
desenvolvimento.
Para você entender melhor como seria este fluxo de acompanhamento e

entrega, o fluxograma abaixo foi desenhado.
As reuniões de acompanhamento são realizadas a cada semana para

conseguir mapear com antecedência bloqueios e impedimentos que possam estar
no radar e serem solucionados antes mesmo de afetar o planejamento da entrega.
Já as reuniões de Review são realizadas em time que praticam o SCRUM como
metodologia de desenvolvimento, esta reunião é realizada ao final de cada sprint
para mostrar aos Stakeholders (donos do produto) como que está o andamento do
projeto, durante esta reunião podem ser feitas apresentações com métricas e/ou
demos do produto.
41
Cerimônia de Acompanhamento
Esta é uma cerimônia essencial para quem quer ter sucesso na entrega do
produto, muitas vezes adaptei a cerimônia por uma apresentação bem elaborada,
auto entendível enviado através dos meios de comunicação da empresa. E por que
isso, está cerimônia não é nada que esteja em alguma metodologia de
desenvolvimento como SCRUM, KANBAN ou qualquer outra, está cerimônia é um
momento onde o QA pode expressar por números a qualidade do produto.
Não é um trabalho fácil, pois é necessário separar um tempo para conseguir

gerar filtros na ferramenta de gerenciamento de tarefas, e por consequências estes
filtros gerarem dados que ao serem adicionados a um B.I (Business Inteligence) ou
no meu caso Excel, gráficos são gerados automaticamente e assim podem ser
utilizados para analisar o andamento da Sprint.
Se você já estudou sobre burndown ou burnup no SCRUM, são alguns dos

gráficos que podem ser utilizados nestas cerimônias. Outros gráficos sobre métricas
de defeitos, andamento previsto vs realizados dos testes, também podem ser
incluídos nesta apresentação, estes gráficos darão embasamento para a sua
conclusão no final, e reforçando o seu parecer.
Sprint Review
A reunião mais esperada da Sprint para os utilizadores de SCRUM ou alguma

variação desta metodologia. Como dito anteriormente as pessoas envolvidas neste
tipo de reunião é o PO (Product Owner ou Dono do Produto), Stakeholders,
gerentes, coordenadores e o time de desenvolvimento. Sim, em alguns casos esta
reunião pode conter muitas pessoas interessadas com o andamento do projeto, e
42
detalhe, quanto mais atrasado o projeto mais, pessoas surgem nesta reunião para
entender e questionar o porquê do atraso.
A preparação do material para esta reunião deve ser feita com cuidado e
todas as informações necessárias para afirmar o status atual do desenvolvimento.
No próximo capítulo iremos visualizar as variações de apresentações e como
organizar os dados para uma apresentação de alto impacto.
Tipos de Apresentações
Existem 3 tipos de formas de se apresentar os dados dentro de uma reunião

de Sprint Review. Através de métricas, onde os gráficos falarão por eles mesmo o
que está ocorrendo, possuímos a opção de Demos que nada mais é do que gravar o
sistema funcionando mesmo que contenha defeitos. E por último podemos ter um
misto das duas opções, indicando em métricas os dados mais importantes e depois
uma demonstração do que foi desenvolvimento na última Sprint.
Métricas
Quando trabalhamos em uma apresentação categorizada por métricas,

devemos saber escolher as métricas que se conectam de forma a contar uma
história, sendo ela boa ou nem tanto assim, já que os números falam por si só.
Eu escreveria um roteiro de apresentação com sete (7) slides, pois do ponto

de vista econômico da empresa, estamos ocupando tempo de pessoas com
valor/hora alto então o tempo tem que ser performático e assertivo. E eu vou mostrar
para vocês o meu roteiro de apresentação:
43
Slide 1 Apresentação
Neste slide você deve situar a pessoa em qual projeto e interação (sprint) em
que ele se encontra. Por isso informe no título do slide o nome do projeto e no
subtítulo a interação.
Slide 2 Overview
Vamos agora dar um overview dos números gerais do projeto na totalidade.
- Informe o número de Stories prontas para desenvolvimento

- Quantas estão em backlog (estórias que o time pegou para
desenvolver durante a sprint)
- Quantas estão em desenvolvimento
- Quantas foram entregues
- Percentual de completude.
Desta forma você no segundo slide já conta toda a história do projeto de

forma resumida, facilitando assim a análise das pessoas com pouco tempo, pois se
os números estiverem no esperado, eles talvez não se interessem por dados mais
detalhados, porém se os números não estiverem no esperado, os outros gráficos e
métricas serão necessários para explicar o porquê destes números.
Slide 3 Impactos
Aqui iremos detalhar todos os impactos conforme a sua severidade, isso inclui
defeitos, tarefas ou situações que bloqueiam o desenvolvimento. A ordenação dos
bloqueios devem ser feitas em ordem descrente, onde os mais impactantes veem
primeiro e baixando a severidade até chegar na de nível baixo.
44
Aqui aconselho vocês a utilizarem uma tabela bem simples para ficar bem
visual os dados.
Tarefa Severidade Bloqueia Time Data de

responsável abertura
Informe aqui o Informar qual Informar aqui Informar que é o Informar a data
número da tarefa nível de tudo que ela time responsável que foi
criada para severidade que bloqueia, desde para que resolva descoberto este
acompanhament ela se encontra bugs a tarefas ou o impedimento impacto
o qualquer outra
tarefa que não
necessariamente
se encontra no
board
Este slide é super importante, por que ao falarmos sobre estes pontos em
reuniões ou até mesmo apenas enviar a apresentação por e-mail, quem ler pode
ajudar de alguma forma com a possível ou até mesmo a solução do bloqueio.
Slide 4 Métricas
Aqui vamos iniciar a análise de dados mesmo, informar por números em uma
planilha, gráficos ou até mesmo cruzar gráficos se você utiliza dados coerentes para
isso.
Alguns gráficos que podem ser incluídos neste slide:

- andamento dos testes
- tarefas pendentes vs tarefas pendentes bloqueadas
- tarefas pendentes vs tarefas bloqueadas
45
Slide 5 Atualizações
Neste slide é interessante informar se ocorreu alguma alteração dentro do

time, isso pode ir desde atualização de ferramenta, melhoria contínua, ou até
mesmo aumento ou redução do quadro de funcionários. Isso fará com que todos
estejam na mesma página do que ocorreu na última semana.
Slide 6 Sentimento do Time
Este slide só deve ser utilizado por times maduros, pois você irá lançar um
formulário do nível de sentimento do time em relação às suas demandas, e este
formulário pode ter o ranking desde não sei o que estou fazendo aqui, até o achei
meu propósito.
Para os gestores isso faz com que saia dos números e eles tenham empatia
pelo lado “humano” do seu funcionário, e daqui a pouco tomar alguma ação para
melhorar o sentimento do time em relação ao seu trabalho.
Slide 7 Perguntas
Fique disponível para perguntas caso alguma tenha ficado e no final do slide
você pode colocar em um canto o seu nome e os meios de contato que as pessoas
podem acessar.
Ao entregar um resumo semanal com todas estas informações, você só não

irá agradar ao time e gestores com o andamento do projeto, como também irá se
destacar no quesito liderança.
46
Demos
Reuniões de demos são quando você grava a funcionalidade sendo

executada e assim durante a apresentação você mostra elas através dos vídeos.
Para ficar mais bonito, você pode fazer um mockup tanto de uma tela desktop se for
o caso ou de um celular para dar uma imersividade maior as pessoas que estão
presentes ali naquela apresentação.
Referência da imagem: Google imagens
Métricas + Demos
Quando a escolha é de um mix das duas técnicas é necessário pensar na

priorização de dados, uma boa forma de fazer isso é uma apresentação resumida
com dados principais sendo Slide 1, Slide 2, Slide 3 + demos, colocar uma tela de
informando “informações complementares” e nisso você entra com os Slides 4, 5 e
6. Desta forma você prioriza a entrega e visualização dos dados necessários e se
47
surgir algum interesse por parte dos participantes você poderá assim explanar os
outros assuntos.
48
49

Método Priscila de Araujo - Guia QA Do Absoluto Zero - Priscila de Araujo Caimi PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Método Priscila de Araujo - Guia QA Do Absoluto Zero - Priscila de Araujo Caimi PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Licenciado para - Neimar pereira - 05802496622 - Protegido por Eduzz.

Método Priscila de Araujo: Guia QA do

Autora: Priscila de Araujo Caimi

Espero que este material ajude você na sua jornada de evolução.

Gostaria de agradecer a todos que passaram pela minha jornada profissional,

Muito obrigada por participar da minha jornada, e espero fazer a diferença na

Priscila de Araujo Caimi é Engenheira de Software formada em Química

Em 2022, lançou seu programa de mentoria individual e logo em seguida

Vamos começar pelo início 8

Capítulo 1: O que é Teste de Software

Vamos começar pelo início

Teste de Software é uma parte da cultura da qualidade de Software

Quando enumeramos as atividades de um profissional que trabalha com

Benefícios do Teste de Software

O Teste de Software é muito importante no ciclo de desenvolvimento de

Dentro da Engenharia de Software existe a norma ANSI/IEEE 1059 que

A norma aborda sobre levantamento de requisitos, bugs, erros, confiabilidade

Tipos de Testes de Software

Dentro deste ecossistema podemos dividir ele em três macros contextos de

Dentro dos testes funcionais podemos citar os testes do tipo Unitário,

Teste não Funcional

Nos testes não funcionais englobamos testes de Performance, Load,

Quando falamos dos testes de manutenção, abordamos testes que são

Mas não se preocupe com a quantidade de testes existentes dentro deste

Capítulo 2: Tudo começa pelo Critério de Aceite.

Vamos criar “O Produto”

O Critério de aceite é a definição do que o cliente deseja que seja

Uma pessoa que trabalha no levantamento de requisitos é responsável por

Uma das partes do levantamento de requisitos é escrever os critérios de

Como dito anteriormente, a forma de escrita de um Critério de Aceite deve ser

- Eu: identifico a minha persona, ou sem linguagem técnica a pessoa

Agora vou te trazer um exemplo para isso ficar bem claro.

Eu, como usuário do aplicativo

Em conjuntura com a descrição do critério de aceite é necessário informar

Capítulo 3: Primeiros passos com Qualidade de Software

Vamos aos Testes

Chegamos ao planejamento e execução das atividades de um Analista de

Modelos de Qualidade de Software

Com isso irei apresentar-te dois padrões de qualidades e um antipadrão e o

Um dos primeiros, se não o primeiro padrão de qualidade estabelecido para

Além de pensar em garantir a qualidade desde a concepção, ao seguir o

Ou seja, devemos focar em atingir coberturas de 100% na base da pirâmide

Referência da imagem: Pirâmide de Testes - Porque você precisa saber por

Como pode-se ver na imagem acima, a pirâmide de teste possui três

Testes Unitários Teste de Componente Teste de Usabilidade

Teste de Integração Teste de Acessibilidade

Agora você deve estar se perguntando, entendi as categorias da pirâmide, os

No contexto pirâmide de teste o ciclo de desenvolvimento inicia com o time de

de forma isolada, garantindo o seu funcionamento. No nosso exemplo da casa com

Quando evoluído o desenvolvimento de Software as integrações começam a

E estas integrações ocorrem várias e várias vezes no desenvolvimento,

Quando finalizado o desenvolvimento da de cada funcionalidade da casa,

E estes padrões surgem de uma visão distorcida de qualidade que as

Defeitos quando descobertos em fase inicial, durante o teste unitário o seu

Quadrante de Teste Ágil

Referência da imagem: Introdução do Quadrante de Teste Ágil por Elis

Estes quatro pilares ajudam você a estruturar estratégias de melhoria e

Quando é necessário melhor a qualidade em relação à tecnologia utilizada

Quando precisamos dar suporte ao time, introduzimos os testes funcionais,

O assunto sendo foco em negócio, iniciamos os testes junto ou em prol da

O que se ganha conhecendo os Padrões

Quando conhecemos e dominamos a essência da ideia dos padrões e

- Saber priorizar e escolher os testes: esta é a dúvida de um milhão