# SESSION FOUR: CHECKIN | ANÁLISE DE SISTEMAS
Author: Igor Lima Charles
N°: 18
Grade: INFOA


## O QUE É E O QUE FAZ UM QA?

**QA = Quality Assurance**
* Garantia de Qualidade
* Analista de qualidade de software
* O QA é responsável por encontrar e reparar: erros, defeitos e falhas no software

**Bugs = falhas de software**

**Os bugs podem:**
- Prejudicar a experiência do usuário
- Vazamento de dados sensíveis
- Acidentes fatais

**O que causa os bugs?**
- Falha humana
- Diferença entre ambientes
- Falha na concepção do projeto ou na arquitetura
- Falha de Testes

**Como evitar os bugs?**
- Testes
- Técnicas de QA
- Técnicas e tipos

**QA's são guardiões da qualidade**
- Garantir que as regras de negocio estão sendo seguidas
- Garantir que o software está funcionando conforme o planejado
- Achar bugs/brechas nos softwares ou nas regras de negocio
- Mostrar para a equipe e empresa o valor dos testes
- Garantir que o usuário final não terá problemas no software

**Mantras**
- A qualidade de software é uma responsabilidade de todos
- Não somos inimigos dos desenvolvedores
- Testes não atrasam a entrega do software
- A qualidade de software é algo inegociável

## TIME ÁGIL

- Dev = desenvolvedor do código
- Product Owner (Io) = dono de produto
- Agile Master (AM) = busca sempre a melhor metodologia e deixar o time cada vez mais ágil, além de resolver conflitos (pessoas, internos, externos)
- Coordenador (Coord/Chefinho) = cuida da parte burocrática do capital humano

## FRONT END — BACK END

**Front-End:** qualquer tipo de interface gráfica que o usuário consiga enxergar ou interagir, como, por exemplo: tela de login, página inicial do facebook, etc.

**Back-End:** refere-se a parte lógica, sustentação, banco de dados, processamentos que está por trás do Front-End.

**Exemplificando:**
- **Front-End:** parte "bonita" que enxergamos da casa;
- **Back-End:** parte estrutural da casa que a mantém em pleno funcionamento.

## TESTES: FRONT—END
Devemos sempre testar a nossa feature, o primeiro passo é testar o fluxo principal, ou seja, aquilo que a feature principal foi designada a fazer, caso contrário, se não retornar, é um bug
Após realizarmos os testes dos fluxos principais, devemos realizar os dos fluxos alternativos, estes onde a maioria dos bugs dormem.

## TESTES: BACK—END
Diferentemente do Front-end, nós não temos acesso diretamente a uma interface, portanto, devemos testar o código em si e as respostas que este retorna, se está salvando no banco de dados, em suma, se está fazendo aquilo que foi designado para fazer.
Dentre algumas ferramentas que podemos utilizar está a API da POSTMAN.
As ações HTTP que as API's mais utilizam são:
* **GET** = é o ato de buscar algo, ou seja, output.
* **POST** = é o ato de enviar algo, ou seja, input.
* **PUT** = atualizar informações (atualiza todos os dados e informações).
* **PATCH** = atualizar informações (atualizar apenas um campo que houve alteração, algo que faz muita diferença na performance, todavia cada um tem sua importância).
* **DELETE** = utilizado para deletar a informação que queremos.

**Status code**
Peça fundamental, exerce a função de nos dizer por meio do código se a requisição foi feita ou não pela API.
* **200 = OK**.
* **404 - NOT FOUND**.
* **500 - INTERNAL SERVER ERROR**

## TEST CASE
É uma técnica de prescrita, onde mapeamos os cenários de teste, como estes testes devem ser executados e quais os resultados esperados a partir deles

**Como escrevemos-os**
Seguimos uma espécie de receita: partindo do *cenário*, sucedida pelo *step* e finalizada pelo *resultado esperado*

* **Cenário:** onde escrevemos tudo que de fato será testado na nossa funcionalidade
* **Step:** escrevemos as ações que iremos executar para realizar o teste do cenário
* **Resultado esperado:** escrevemos o resultado esperado (e satisfatório) que esperamos obter com tais testes

**Quando devemos escrevê-lo?**
Assim que o escopo do projeto for finalizado

## COMO REPORTAR BUGS & BOARD KANBAN (JIRA)
O KanBan serve para ajudar no processo de desenvolvimento de funcionalidades em qualquer área, ajuda o Agile Master a colher diversas métricas, como esta o andamento do desenvolvimento da funcionalidade, ter uma visão da data de entrega da funcionalidade, se existem impedimentos para finalizar a entrega desta, etc.

Ele divide-se em colunas verticais e cada individuo (DEV) que for desenvolver algum item, deve colocar o seu nome e arrastar o card até a coluna de desenvolvimento.

***Para reportarmos um bug***, devemos criar uma coluna especifica para isso e arrastar o card referente ao que desenvolvemos e está com defeito. Vale ressaltar que devemos descrever o que está acontecendo, colocando antes de tudo ***{BUG}***.

Após isso, devemos arrastar a tarefa {BUG} quanto a que está em pleno funcionamento para a parte que sinaliza que foi feito.

Além de tudo, é importante que mantenhamos o Jira **sempre atualizado**.

## TIPOS DE TESTES
Existem dois tipos de teste e cada um é aplicado por alguém especifico.
* **CAIXA BRANCA** = Avaliar o código do software, onde verificamos se ele está cumprindo com aquilo que foi proposto

* **CAIXA PRETA** = Avaliamos o software em si, sem acesso a ele.

* **Teste Funcional** = teste do tipo caixa preta e aplicado por QA's. Nele, é validado o software, critérios de aceite da equipe de produtos e é procurado bugs de modo funcional, e é testado todas as camadas do código.

* **Teste Unitário** = do tipo caixa branca e é aplicado pelos desenvolvedores. Nesse tipo de teste, com a ajuda de frameworks e MOS testa a menor parte possível do software validando entrada e saíde de dados por ele. Esse tipo de teste é de extrema essência para a validação do software.

* **Teste Componente/ Instrumentado/ UI** = Melhorar a forma de desenvolver o código

* **Teste Integrando** = Pode ser tanto de caixa branca quanto caixa preta, testa todas integrações, partes e API's do software de back-end quanto front-end e testá-las para saber se ambos estão funcionando perfeitamente e deste modo, valida.

* **Teste Regressivo** = Também é um teste tanto de caixa preta quanto caixa branca, geralmente é aplicado por QA's e também, desenvolvedores. É nada mais nada menos que testar novamente todas as partes que já foram testadas e que tudo esteja funcionando perfeitamente. É nesse teste que implementamos atualizações e funcionalidades.

* **Teste de Carga && Teste de Stress (Teste de Perfomance)** = Não é um teste funcional, ele não valida as funcionalidades em si, são aplicados normalmente por equipes maiores, como analistas de infraestruturas, etc.
No teste de estresse é voltado, por exemplo, para avaliar a quantidade de máquinas simultâneas conseguem acessar ao servidor.
E o teste de carga, verificar a quantidade de usuários simultâneos conseguem utilizar o software.

* **Teste de Usabilidade** = é aplicado pelos PIO's e pelos UX's, geralmente é realizado utilziando entrevistando o usuário, se ele consegue usar o software, quais dificuldades ou problemas ele está tendo, etc.

## O QUE É METODOLOGIA ÁGIL?
É uma série de conceitos, práticas e ferramentas que ajudam na gestão dos projetos.
É nome que se dá a um conjunto de metodologias que visam facilitar, por assim dizer, o desenvolvimento de algo.