Automação Web - Cypress e Cucumber

​Sejam muito bem vindos, a essa imersão na qualidade de software.

Eu sou o Danilo e estarei aqui como o instrutor de vocês nesse primeiro curso sobre Automação de testes web com Cypress e Cucumber oferecido pela Garage Santty QA.

Primeiramente quero agradecer a todos por terem adquirido o curso, assim confiando no nosso trabalho e desejo que todo conteúdo atinja as expectativas de vocês.

Nesse curso teremos muitos assuntos interessantes, tanto para quem está iniciando na área, quanto para quem ja está na area e quer aprender algo novo seja para teu trabalho atual ou progredir na sua carreira.

O requisito principal desse curso é a vontade de realmente aprender algo novo. O foco do curso como já disse não é a parte de testes funcionais, mais teremos esse primeiro módulo sobre isso, para deixar todos mais tranquilo com os demais andamento do curso que será essencial, para entender pontos que trabalharemos nas automações.

No próximo video me apresentarei melhor para vocês, sobre quem eu sou, como iniciei na área, e minhas experiências nessa área tão incrível que é a Qualidade de Software, mas desde já deixo um canal aberto com todos vocês, com os meios disponíveis na plataforma e pelos grupos exclusivo de WhatsApp ou Telegram que estarei adicionando cada um de vocês, por isso é essencial deixar seu número de telefone e e-mail o mais atualizado possível, para que esse contato se torne mais efetivo.
Toda essa comunicação inclui dúvidas, criticas, sugestões de conteúdos ou qualquer outros assuntos que queiram falar sobre a área.

Espero que aproveitem demais todo conteúdo, assim como eu estou aproveitando para criar para vocês, da melhor maneira possível.

Abaixo deixo meu contato WhatsApp e Telegram:
Danilo Barbosa

​Minhas redes sociais:

LinkedIn: https://www.linkedin.com/in/danilo-santana-barbosa/

LinkedIn Garage Santty QA: https://www.linkedin.com/company/santty-garage/​

GitHub: https://github.com/dansantty/

Instagram: @dansantty

Discord: santtyd

YouTube: https://www.youtube.com/@santty.garage #emConstrução

Diante do grande crescimento da tecnologia no mundo, hoje temos uma gama enorme de produtos e serviços que dependem de um Sistema de informação. Esses sistemas mesmo sendo desenvolvidos por pessoas muito capacitadas tem a tendência a ter problemas, seja uma funcionalidade incorreta, uma falha de codificação, uma falha do servidor, uma regra de negócio não atendida etc...

Com esse cenário, surge uma profissão bem importante na área da tecnologia que é o Analista de Qualidade de Software, responsável por auxiliar, aplicar e evangelizar todo contexto de qualidade dentro de uma empresa ou projeto tecnológico

O que é qualidade de software?

ISO/IEC 9126

Segundo a norma ISO/IEC 9126 define qualidade de software como: A totalidade de características de um produto de software que lhe confere a capacidade de satisfazer necessidades explícitas e implícitas.

Pressman(1994)

Por outro lado, segundo Pressman, "Qualidade de software é a conformidade de requisitos funcionais e de desempenho que foram explicitamente declarados, a padrões de desenvolvimento claramente documentados, e a características implícitas que são esperadas de todo software desenvolvido por profissionais".

Qualidade de software é a capacidade de um sistema de informação atender todas as necessidades e funcionalidades de um determinado produto solicitado por um cliente ou empresa, seguindo bons padrões de codificação e processos, antes, durante e após sua implementação para se ter o menor número de falhas possíveis.

O que é teste de software?

Todos os processos e passos de validações executadas, que ajudam a investigar se um determinado sistema de informação atinge seu objetivo de funcionalidade com base em sua especificação e que ajudam a prevenir e identificar defeitos

​Não deixem de acessar o material complementar em materiais​

Olá Galera, adicionei aqui um papo bem rápido para explicar para vocês sobre CTFL.

Vai estar disponível o link para download com o conteúdo de estudos imprescindível mesmo que não venham tirar a certificação.

1) O teste mostra a presença, não a ausência de defeitos. Os testes podem mostrar que os defeitos estão presentes no objeto de teste, mas não podem provar que não há defeitos (Buxton 1970). Os testes reduzem a probabilidade de defeitos não serem descobertos no objeto de teste, mas, mesmo que nenhum defeito seja encontrado, os testes não podem provar a corretude do objeto de teste.​

2) Testes exaustivos são impossíveis. Testar tudo não é viável, exceto em casos triviais (Manna 1978). Em vez de tentar testar exaustivamente, as técnicas de teste (ver capítulo 4), a priorização de casos de teste (ver seção 5.1.5) e os testes baseados em riscos (ver seção 5.2) devem ser usados para concentrar os esforços de teste.

3) Testes antecipados economizam tempo e dinheiro. Os defeitos que são removidos no início do processo não causarão defeitos subsequentes nos produtos de trabalho derivados. O custo da qualidade será reduzido, pois menos falhas ocorrerão posteriormente no SDLC (Boehm, 1981). Para encontrar defeitos logo no início, os testes estáticos (ver capítulo 3) e os testes dinâmicos (ver capítulo 4) devem ser iniciados o mais cedo possível.​

4) Os defeitos se agrupam. Um pequeno número de componentes do sistema geralmente contém a maioria dos defeitos descobertos ou é responsável pela maioria das falhas operacionais (Enders 1975). Esse fenômeno é uma ilustração do Princípio de Pareto. Os agrupamentos de defeitos previstos e os agrupamentos de defeitos reais observados durante o teste ou em operação são uma entrada importante para o teste baseado em risco (ver seção 5.2).

5) Os testes se degradam. Se os mesmos testes forem repetidos muitas vezes, eles se tornarão cada vez mais ineficazes na detecção de novos defeitos (Beizer 1990). Para superar esse efeito, talvez seja necessário modificar os testes e os dados de teste existentes, e talvez seja necessário escrever novos testes. Entretanto, em alguns casos, a repetição dos mesmos testes pode ter um resultado benéfico, por exemplo, em testes de regressão automatizados (ver seção 2.2.3).​​​

6) Os testes dependem do contexto. Não existe uma única abordagem universalmente aplicável aos testes. Os testes são feitos de forma diferente em contextos diferentes (Kaner 2011).

7) Falácia da ausência de defeitos. É uma falácia (ou seja, uma concepção errônea) esperar que a verificação do software garanta o sucesso de um sistema. Testar exaustivamente todos os requisitos especificados e corrigir todos os defeitos encontrados ainda pode produzir um sistema que não atenda às necessidades e expectativas dos usuários, que não ajude a atingir os objetivos de negócio do cliente e que seja inferior a outros sistemas concorrentes. Além da verificação, a validação também deve ser realizada (Boehm, 1981).​​


Abaixo deixarei o link para download do documento do ISTQB para certificação CTFL

Sugiro que pesquisem mais informações sobre a certificação em fontes relacionadas na internet.

Artigo sobre iniciar em testes de software:

https://medium.com/@dansantty/testes-de-software-p...

Estruturas de um bom teste - Cenário de teste

Antes de iniciar a escrita de um caso de teste, precisamos identificar o cenário em que estamos, não é simplesmente olhar para um funcionalidade e sair escrevendo passo de execuções sem se ter uma estrutura lógica e organizada do teste proposto.

Ex. “Um sistema de cadastro de perfil de um usuário do Facebook”
- Cadastro do usuário
- Login ( Acesso a aplicação )
- Adicionando amigos

Estruturas de um bom teste - Caso de teste

O caso de teste pode ser definido como um sub-cenário de teste, numa estrutura hierárquica um Cenário de Teste pode possuir n’ casos de teste. Um caso de teste é uma instrução passo a passo de uma execução de teste, o mesmo deve ter uma descrição resumida(o que o caso realiza), passos de uma execução, parâmetros de uma execução, e os resultados esperados.
Quando pensamos em um caso de teste não só devemos pensar nos caminhos felizes de um fluxo, como também nos caminhos alternativos, afinal a maioria dos defeitos encontrados se dão nesses fluxos. As duas maneiras mais utilizadas para detalhes de uma execução são a Tradicional(step by step) e o famoso BDD.

Estruturas de um bom teste - Step by Step

Step by step ou passo-a-passo é um tipo de escrita tradicional para um caso de teste, nela é definida uma forma detalhada de cada passo da sua execução onde nos obriga a termos uma evidência de cada resultado obtido.

Ex. “Cenário: Login” - “Caso de teste: Login com sucesso no app”
Passo 1 - Digitar nome de usuário
Resultado: Usuário preenchido e visualizado com sucesso
Passo 2 - Digitar senha
Resultado: Senha preenchida e oculta no formato ‘****’
Passo 3 - Clicar no botão entrar

Resultado: Acesso efetuado com sucesso na Home do app​

Estruturas de um bom teste - BDD​

Behavior Driven Development ou Desenvolvimento guiado por comportamento, a princípio essa metodologia de escrita foi criada para auxiliar no desenvolvimento de uma aplicação onde os desenvolvedores antes de escrever qualquer código, escreviam o comportamento que aquela funcionalidade deveria ter, assim assumindo que as regras de negócios estariam sendo atendida bem como pessoas menos técnicas envolvidas no projeto poderiam entender do que se tratava cada implementação. Porém sua utilização não foi bem como esperado, com os desenvolvedores utilizando cada vez menos essa prática, os analista de automação foram absorvendo essa ideia e utilizando esse método para escrever seus códigos de automação, isso cada vez mais se aproximou da comunidade e hoje também utilizamos para escrever detalhes para testes funcionais.

No BDD a maneira de escrita é bem mais objetiva do que detalhada, pois nela escrevemos diretamente os passos que temos e suas entradas e ao final do fluxo definimos o resultado esperado, uma particularidade é que temos um padrão de escrita desse processo seguido pelos blocos DADO, QUANDO, ENTÃO e com exceções E.

Ex. “Cenário: Login” - “Caso de teste: Login com sucesso no app”
Dado que eu digite nome de usuário
E minha senha
Quando clicar no botão entrar
Então acesso com sucesso a Home do app

Vamos praticar?

Selecionando uma das funcionalidades abaixo com seus requisitos, vamos criar aqui cenários de testes seguindo qualquer um dos dois tipos de escritas mencionados.
Lembrando que podem pesquisar sobre as escritas em fontes externas e ao final, precisamos postar nossos casos de testes na comunidade, para validarmos juntos.

​CADASTRO DE USUARIO

• Sistema deve permitir somente um cadastro por email

• Os campos de cadastro são e-mail, nome, telefone, senha e foto

• Somente os campos e-mail, senha e nome são obrigatórios

• A senha deve obrigatoriamente conter letra, número e caractere especial(min. 6, max. 10)

• Deve haver a possibilidade do usuário criar seu cadastro a partir da sua conta gmail

ACESSO AO SISTEMA

• Permitir que o usuário acesse o sistema

• Necessário possibilidade de recuperação de senha

• Existir validações para cenários adversos na tentativa de login com algum erro

POSTAGEM DE FEED

• Possibilidade do usuário postar um feed com foto e comentário

• Obrigatoriamente o usuário deve ao menos incluir uma foto na sua postagem

• Comentário na postagem não é obrigatório

• O usuário deve ter a possibilidade de apenas recortar sua foto antes da postagem

• Quando houver comentário o sistema deve ter a capacidade de identificar palavras ofensivas e ocultar

​