DEV Community: Diego Yuri

Aprendendo sobre Teste Estático e Dinâmico

Diego Yuri — Fri, 10 Jan 2025 01:35:41 +0000

Fala, pessoal! Tudo bem com vocês?, Sejam muito bem vindos ao Aprendendo QA.
Hoje vamos falar sobre um ótimo tema no universo de testes de software: Testes Estáticos e Dinâmicos. Se você já ouviu falar desses termos, mas ainda não sabe exatamente o que significam ou como aplicá-los, fica tranquilo! Vou explicar tudo de forma simples, com exemplos práticos, para que você saia daqui dominando o assunto.

Então, pega um café, ajusta a cadeira e vem comigo entender como essas duas abordagens podem transformar a qualidade do seu software!

O que são Testes Estáticos e Dinâmicos?

Para começar, vamos esclarecer os conceitos básicos:

Teste Estático: É aquele em que analisamos o software (ou outros artefatos) sem executá-lo. É como revisar um texto antes de imprimir: você verifica se tudo está no lugar, se as regras foram seguidas e se não há erros evidentes.
Teste Dinâmico: Aqui, o software é colocado para rodar. A ideia é testar na prática para ver como ele se comporta em diferentes situações. É como ligar um carro recém-montado para garantir que ele funciona direitinho.

Ambos têm o mesmo objetivo: identificar problemas e garantir a qualidade do software. A diferença está na abordagem.

Teste Estático: Detectando Problemas Antes de Rodar

Como funciona?

No teste estático, você analisa os artefatos do software (como código, requisitos ou documentação) sem precisar executá-lo. Isso pode ser feito manualmente (como em revisões de código) ou usando ferramentas automáticas.

Exemplos práticos:

Revisar um documento de requisitos para encontrar ambiguidades ou inconsistências.
Usar ferramentas como SonarQube para identificar problemas no código, como variáveis não usadas ou violações de padrões.

Benefícios:

Detecta problemas cedo no ciclo de vida do desenvolvimento (SDLC), economizando tempo e dinheiro.
Ajuda a encontrar erros que não aparecem nos testes dinâmicos, como código inacessível ou falhas em requisitos não executáveis.
Melhora a comunicação entre as equipes ao alinhar expectativas desde o início.

Curiosidade:

Sabe aquele momento em que você pede para um colega revisar seu código antes de enviá-lo? Isso é uma forma de teste estático! Mas também existem métodos mais formais, como inspeções detalhadas com métricas e relatórios.

Teste Dinâmico: Colocando o Software à Prova

Como funciona?

Aqui, o software é executado em diferentes cenários para verificar seu comportamento. É o momento de ver se ele realmente faz o que deveria fazer.

Exemplos práticos:

Testar um formulário online para garantir que ele aceita apenas dados válidos.
Simular cenários de alta carga para verificar se o sistema suporta muitos usuários simultaneamente.
Usar ferramentas como Selenium para automatizar testes funcionais.

Benefícios:

Identifica problemas que só aparecem durante a execução, como erros de integração ou vazamentos de memória.
Valida a experiência do usuário e garante que o software funcione bem em diferentes ambientes.

Curiosidade:

Já usou um app que travou do nada? Esse é um problema que deveria ter sido detectado por testes dinâmicos!

Comparando Teste Estático e Dinâmico

Característica	Teste Estático	Teste Dinâmico
Execução do Código	Não executa o código	Executa o código
Objetivo Principal	Encontrar defeitos antes da execução	Verificar comportamento durante a execução
Custo	Geralmente menor	Pode ser maior devido à complexidade
Ferramentas Comuns	SonarQube, Checkstyle	Selenium, JUnit
Defeitos Detectados	Código inacessível, erros em requisitos	Bugs funcionais, gargalos de desempenho

Por que usar os dois juntos?

Os testes estáticos e dinâmicos não competem entre si; eles se complementam. Enquanto os testes estáticos ajudam a evitar problemas desde o início do projeto, os dinâmicos garantem que tudo funcione bem na prática. Pense neles como duas lentes diferentes para enxergar a qualidade do software: uma foca nos detalhes antes da execução e outra avalia o comportamento real.

Dica Lúdica: Entenda com uma Metáfora

Imagine que você está construindo uma casa:

O teste estático seria revisar a planta da casa antes de começar a construção. Aqui você verifica se tudo faz sentido no papel.
O teste dinâmico seria morar na casa pronta para ver se as portas abrem corretamente ou se as torneiras não vazam.

Viu só? Um complementa o outro!

Conclusão

Testes estáticos e dinâmicos são indispensáveis para garantir a qualidade do software. Saber quando usar cada um deles pode fazer toda a diferença na entrega de um produto confiável e eficiente. Então, da próxima vez que estiver planejando seus testes, lembre-se dessa dupla poderosa!

E aí, curtiu aprender sobre esses conceitos? Deixe nos comentários suas dúvidas ou experiências com testes! Até a próxima! 🚀

BDD - Desenvolvimento Orientado pelo Comportamento

Diego Yuri — Fri, 12 Jul 2024 04:37:15 +0000

Desenvolvimento Orientado pelo Comportamento(BDD)

Introdução ao BDD

Behavior-Driven Development (BDD) é uma abordagem de desenvolvimento de software que incentiva a colaboração entre desenvolvedores, testadores e stakeholders de negócios. O principal objetivo do BDD é garantir que todos os membros da equipe compreendam claramente os requisitos do sistema, descrevendo o comportamento desejado de um aplicativo em uma linguagem natural e acessível a todos os envolvidos.

Origem e Evolução do BDD

BDD evoluiu a partir do Test-Driven Development (TDD) e foi popularizado por Dan North em 2006. Ele surgiu como uma resposta às dificuldades enfrentadas com TDD, propondo uma abordagem que focasse mais no comportamento esperado do sistema do que nos detalhes técnicos dos testes. Com o tempo, BDD cresceu para incluir uma visão mais ampla da análise ágil e dos testes de aceitação automatizados, unificando pessoas técnicas e de negócios usando uma linguagem comum centrada no comportamento do usuário.

Princípios Fundamentais do BDD

Colaboração: Promove a comunicação contínua entre todos os stakeholders.
Linguagem Natural: Utiliza uma linguagem comum (Gherkin) para descrever requisitos e critérios de aceitação.
Documentação Viva: Os testes BDD servem como documentação atualizada do comportamento do sistema.
Ciclos Curtos de Feedback: Facilita a identificação e resolução rápida de problemas por meio de iterações curtas e frequentes.

Ferramentas Comuns de BDD

Cucumber: Linguagem de especificação: Gherkin. Integra-se com várias linguagens de programação como Ruby, Java, JavaScript. Permite escrever testes em linguagem natural compreensível por todas as partes interessadas.
SpecFlow: Versão do Cucumber para .NET. Linguagem de especificação: Gherkin. Integra-se com MSTest, NUnit e xUnit para testes de aceitação.
JBehave: Ferramenta de BDD para Java. Linguagem de especificação: Story. Facilita testes de aceitação integrando-se com JUnit.
Behat: Ferramenta de BDD para PHP. Linguagem de especificação: Gherkin. Integrado com bibliotecas PHP como Mink para testes de navegador.
Gauge: Ferramenta leve para criar especificações de teste. Suporta várias linguagens como Java, Ruby, C#, Python. Usa um formato de especificação simples e reusável.
Lettuce: Ferramenta de BDD para Python. Linguagem de especificação: Gherkin. Facilita a escrita de testes de comportamento de forma clara.
Concordion: Ferramenta de BDD para Java. Usa HTML para escrever especificações de teste. Testes são incorporados em documentos HTML.
Turnip: Extensão do Cucumber para Ruby. Linguagem de especificação: Gherkin. Focado em testes de aceitação para aplicações Ruby.

Implementação do BDD em Projetos

Passo 1: Definição dos Cenários

Comece identificando os cenários de uso mais importantes e descreva-os em linguagem natural utilizando a estrutura "Dado, Quando, Então".

Passo 2: Automação dos Testes

Utilize uma ferramenta BDD (como Cucumber) para automatizar os cenários descritos. Isso envolve a criação de "steps" que correspondem a cada etapa dos cenários.

Passo 3: Integração Contínua

Integre a execução dos testes BDD no seu pipeline de CI/CD. Isso garante que os testes sejam executados regularmente e que o feedback sobre o estado do sistema seja contínuo.

Tipos de Escrita para BDD

Método Imperativo

O método imperativo descreve o cenário passo a passo, detalhando ações, nomes de botões e páginas acessadas. É mais utilizado para pessoas que realizam testes manuais e sentem a necessidade de visualizar detalhadamente todos os passos de um cenário.

Exemplo:

Funcionalidade: Compra de Produto

Cenário: Compra de produto com sucesso
  Dado que o usuário está na página inicial
  Quando ele clica no link "Login"
  E preenche o campo de e-mail com "usuario@exemplo.com"
  E preenche o campo de senha com "senhaSegura123"
  E clica no botão "Entrar"
  Então ele deve ser redirecionado para a página "Minha Conta"

  Dado que ele está logado na página "Minha Conta"
  Quando ele pesquisa pelo produto "Smartphone XYZ"
  E clica no botão "Buscar"
  E clica no link do produto "Smartphone XYZ"
  E clica no botão "Adicionar ao Carrinho"
  Então ele deve ver uma mensagem "Produto adicionado ao carrinho"

  Dado que o produto está no carrinho
  Quando ele clica no ícone do carrinho
  E clica no botão "Finalizar Compra"
  E preenche o endereço de entrega
  E escolhe a forma de pagamento "Cartão de Crédito"
  E preenche os dados do cartão
  E clica no botão "Confirmar Compra"
  Então ele deve ver uma mensagem "Compra realizada com sucesso"

Desvantagens do Método Imperativo

Desgaste e Tempo: A escrita detalhada de cada passo pode ser desgastante e consumir muito tempo.
Rigidez: Pequenas mudanças na interface exigem uma revisão completa dos cenários, o que pode ser trabalhoso.

Método Declarativo

O método declarativo foca no comportamento do usuário e descreve os passos de forma mais abstrata, facilitando o entendimento e a manutenção.

Exemplo:

Funcionalidade: Compra de Produto

Cenário: Compra de produto com sucesso
  Dado que o usuário está na página inicial
  Quando ele faz login no sistema
  E pesquisa e seleciona o produto "Smartphone XYZ"
  E adiciona o produto ao carrinho
  E finaliza a compra com um cartão de crédito
  Então ele deve ver uma mensagem "Compra realizada com sucesso"

Vantagens do Método Declarativo

Simplicidade: Cenários mais curtos e de fácil compreensão.
Manutenção: Menos suscetível a mudanças na interface.

Sintaxe Gherkin

Gherkin é uma Business Readable Domain Specific Language, criada para descrever comportamentos desejados de um software, removendo os detalhes lógicos dos testes de comportamento.

Elementos do Gherkin

Given (Dado): Descrição das condições para o cenário ocorrer.
When (Quando): Descrição das ações que devem ocorrer quando o cenário for executado.
Then (Então): Descrição dos resultados esperados.
Funcionalidade: Define o conjunto de comportamento do sistema.
Contexto: Precondição que se repete para todos os cenários da funcionalidade.
Cenário: Identifica um fluxo por meio do comportamento do sistema.
Esquema do cenário: Informa que esse cenário irá utilizar um conjunto de dados para repeti-lo várias vezes com dados diferentes.

Boas Práticas para a Escrita do BDD

Flexibilidade: Não há certo ou errado entre os métodos de escrita apresentados; use o que for mais produtivo para o seu time.
Foco no Comportamento do Usuário: O comportamento do usuário deve ser o centro das atenções.
Escrita em Terceira Pessoa: Para manter o foco no usuário.
Objetividade: Cenários objetivos são mais fáceis de manter e menos propensos a falhas.
Colaboração: Envolva todo o time na escrita do BDD.

Como Levar a Abordagem BDD para o Seu Time

Los Tres Amigos

Também conhecido como Power of Three, este processo consiste em reunir o analista de negócios, um desenvolvedor e um QA para construir cenários e histórias coerentes e de valor para o usuário.

Analista de negócios: Foco nas regras de negócio.
Desenvolvedor: Verificação técnica e soluções alternativas.
Analista de qualidade: Levantamento de cenários não imaginados e questionamento de comportamentos adversos.

BDD Warriors

Um jogo que ensina de forma divertida como escrever cenários coerentes e objetivos utilizando o mínimo de linhas possíveis. Cada jogador recebe cartas com passos diversos (Given, When, Then) e, a cada rodada, complementa o cenário. O objetivo é completar cenários de forma eficaz e aprender a importância do trabalho em equipe na construção dos BDDs.

Conclusão

Behavior-Driven Development é uma abordagem poderosa que pode melhorar significativamente a qualidade do software e a comunicação entre os membros da equipe. Embora haja desafios na sua implementação, os benefícios superam as dificuldades, resultando em sistemas que melhor atendem às necessidades dos usuários e facilitam a manutenção e evolução contínua.

Idempotência: Conceito e Aplicação na Garantia da Qualidade de Softwar

Diego Yuri — Sat, 15 Jun 2024 00:36:43 +0000

1. Introdução

Você sabe ou já ouviu falar em idempotência?

Em matemática e ciência da computação, a idempotência é a propriedade que algumas operações têm de poderem ser aplicadas várias vezes sem que o valor do resultado se altere após a aplicação inicial. De acordo com a Wikipedia, isso significa que, após a primeira execução de uma operação idempotente, execuções subsequentes não terão efeito adicional. A idempotência é um conceito crucial na qualidade de software (QA), especialmente em serviços web e APIs, pois garante que sistemas sejam mais confiáveis e robustos.

2. Conceito e Exemplos de Idempotência

Em termos de métodos HTTP, a idempotência refere-se a métodos que podem ser chamados múltiplas vezes sem produzir resultados diferentes. Segundo a W3C, o resultado de uma solicitação executada com sucesso é independente do número de vezes que ela é executada. Por exemplo, em aritmética, adicionar zero a um número é uma operação idempotente, pois não altera o valor original.

No contexto de APIs REST, os seguintes verbos HTTP são considerados idempotentes: GET, PUT, DELETE, HEAD e OPTIONS. Por outro lado, o verbo POST não é idempotente. Métodos idempotentes são seguros, ou seja, não alteram o estado da aplicação, enquanto métodos não idempotentes podem alterar o estado.

3. Idempotência em APIs REST: Exemplos Práticos

POST: O método POST é usado principalmente para criar recursos. Cada requisição POST cria um novo recurso, alterando o estado da aplicação. Por exemplo, suponha que temos um endpoint "/user" que recebe um payload para criar um usuário:

{
    "name": "Lucas",
    "last_name": "Paixão",
    "city": "Araraquara"
}

Cada vez que esse endpoint é chamado, um novo usuário é criado, mudando o estado da aplicação e adicionando um novo registro ao banco de dados. Por isso, POST não é idempotente.

GET: O método GET é usado para recuperar dados. Ele é considerado idempotente porque, independentemente de quantas vezes seja chamado, a resposta será a mesma, sem alterar o estado da aplicação.

PUT: O método PUT é usado para atualizar recursos. Ele é idempotente porque, após a primeira chamada, chamadas subsequentes com o mesmo payload não alteram o estado da aplicação. Por exemplo, se enviarmos um payload para alterar a cidade de "Araraquara" para "São Paulo", a resposta será a mesma em chamadas subsequentes, com o estado da aplicação inalterado após a primeira atualização:

{
    "name": "Lucas",
    "last_name": "Paixão",
    "city": "São Paulo"
}

DELETE: O método DELETE é usado para remover recursos. Ele é idempotente porque, após a primeira chamada que deleta o recurso, chamadas subsequentes não terão efeito adicional, retornando o mesmo resultado. Por exemplo, ao deletar um usuário com "/user?name=Lucas", a primeira chamada remove o usuário e as seguintes confirmam que o recurso não existe mais, sem alterar o estado da aplicação.

4. Importância da Idempotência em APIs REST

A idempotência é crucial para garantir que os serviços que consomem APIs REST funcionem corretamente, mesmo em situações de erro ou duplicação de chamadas. Por exemplo, se ocorrer um timeout, é comum que o serviço faça uma nova chamada ao endpoint. Sem idempotência, chamadas duplicadas podem causar resultados inesperados ou exceções.

Implementar idempotência previne erros e garante que o sistema se comporte de maneira previsível e confiável, mesmo sob condições adversas. Isso é essencial para manter a integridade dos dados e a estabilidade do sistema.

5. Conclusão

Em resumo, a idempotência é um conceito fundamental para a qualidade de software, especialmente em serviços web e APIs. Ela garante que operações possam ser repetidas sem causar efeitos colaterais indesejados, aumentando a confiabilidade e a robustez do sistema. Ao implementar idempotência, prevenimos erros, melhoramos a experiência do usuário e garantimos a consistência dos dados. Portanto, adotar práticas idempotentes é uma estratégia vital na garantia da qualidade de software.

Fundamentos de Teste

Diego Yuri — Sun, 12 May 2024 04:16:50 +0000

1.1 O que é teste?

Teste de software é um processo essencial no desenvolvimento de sistemas, visando avaliar a qualidade de um programa de computador para garantir seu funcionamento conforme o esperado. Este processo envolve a identificação de defeitos e a verificação se o software atende aos requisitos especificados. O teste pode ser dinâmico, envolvendo a execução do software, ou estático, que inclui revisões e análise sem a execução do programa.

1.1.1 Objetivos do teste

Os objetivos do teste são diversos e variam de acordo com o contexto. Eles incluem avaliar produtos de trabalho, detectar falhas, garantir a cobertura necessária, reduzir o risco de qualidade inadequada, garantir conformidade com requisitos contratuais e normativos, fornecer informações aos stakeholders e criar confiança na qualidade do software. O principal objetivo é reduzir a probabilidade de defeitos quando o software estiver em produção, minimizando os riscos para o negócio e garantindo que as necessidades do cliente sejam atendidas.

1.1.2 Teste e depuração

O teste e a depuração são atividades distintas, mas complementares, no ciclo de desenvolvimento de software. Enquanto o teste identifica falhas no software, a depuração se concentra em encontrar e corrigir essas falhas. No teste dinâmico, quando uma falha é acionada, o processo de depuração envolve reproduzir a falha, diagnosticar a causa principal e corrigir essa causa. No teste estático, quando um defeito é identificado, a depuração se concentra em removê-lo diretamente do código, sem a necessidade de reproduzir a falha.

1.2 Por que os testes são necessários?

Os testes desempenham um papel crucial no desenvolvimento de software, proporcionando uma forma eficaz de garantir a qualidade e confiabilidade dos produtos de software. Existem várias razões pelas quais os testes são necessários, cada uma contribuindo para o sucesso geral do processo de desenvolvimento. Vamos explorar essas razões em detalhes:

1.2.1 Contribuições para o sucesso dos testes

Os testes oferecem um meio econômico de detectar defeitos, permitindo sua remoção e contribuindo, assim, para a melhoria da qualidade do software. Além disso, eles proporcionam uma avaliação direta da qualidade dos artefatos em diferentes estágios do ciclo de vida do desenvolvimento de software, auxiliando nas decisões de progressão para as próximas etapas do processo. Os testes também garantem que as necessidades dos usuários sejam consideradas ao longo do ciclo de vida do desenvolvimento e podem ser necessários para atender a requisitos contratuais ou legais, bem como para cumprir normas regulatórias.

1.2.2 Testes e Garantia da Qualidade (QA)

Embora muitas vezes os termos "teste" e "garantia da qualidade" (QA) sejam usados de forma intercambiável, é importante reconhecer suas diferenças. Enquanto o teste é uma forma de controle de qualidade (QC), focado na detecção de defeitos, a QA é uma abordagem preventiva e orientada para o processo, visando a implementação e melhoria dos processos de desenvolvimento e teste. Enquanto o QC é corretivo e centrado no produto, a QA é preventiva e centra-se nos processos, buscando garantir que um bom processo resulte em um bom produto.

1.2.3 Erros, Defeitos, Falhas e Causas-raiz

Os erros humanos podem resultar na introdução de defeitos no software, que, por sua vez, podem causar falhas no sistema. Identificar a causa-raiz de um problema é essencial para evitar falhas recorrentes. A análise de causa-raiz é realizada para identificar as causas fundamentais de erros ou defeitos, permitindo sua remoção ou mitigação. Essa abordagem é fundamental para a melhoria contínua da qualidade do software e a prevenção de problemas futuros.

Em resumo, os testes são necessários para garantir que o software atenda aos requisitos de qualidade, atendendo às necessidades dos usuários e garantindo sua confiabilidade e desempenho adequados. Eles desempenham um papel crucial não apenas na detecção de defeitos, mas também na prevenção de problemas e na melhoria contínua dos processos de desenvolvimento de software.

1.3 Princípios de Teste

Ao longo dos anos, vários princípios de teste foram propostos para oferecer diretrizes gerais aplicáveis a todos os tipos de testes. Neste contexto, destacamos sete desses princípios:

O teste mostra a presença, não a ausência de defeitos.
Testes exaustivos são impossíveis.
Testes antecipados economizam tempo e dinheiro.
Os defeitos se agrupam.
Os testes se degradam.
Os testes dependem do contexto.
Falácia da ausência de defeitos.

1.4 Atividades de teste, Testware e Papéis no teste

O processo de teste é fundamental para garantir a qualidade de um produto de software. Embora possa variar dependendo do contexto, existem conjuntos comuns de atividades de teste que formam um processo de teste. Essas atividades são adaptadas de acordo com as necessidades específicas do projeto e são essenciais para alcançar os objetivos de teste.

1.4.1 Atividades e Tarefas de Teste

Planejamento do Teste
Monitoramento e Controle de Teste
Análise de Teste
Modelagem de Teste
Implementação do Teste
Execução do Teste
Conclusão de Teste

1.4.2 Processo de Teste no Contexto

O processo de teste é influenciado por diversos fatores contextuais, incluindo stakeholders, membros da equipe, domínio do negócio, fatores técnicos, restrições do projeto, fatores organizacionais e ciclo de vida do desenvolvimento de software. Esses fatores impactam a estratégia de teste, técnicas de teste, grau de automação e relatórios de teste.

1.4.3 Testware

O testware é o produto de trabalho de saída das atividades de teste e inclui diversos elementos, como plano de testes, casos de teste, scripts de teste, registros de testes e relatórios de defeitos. O gerenciamento adequado do testware é essencial para garantir a consistência e integridade dos produtos de trabalho.

1.4.4 Rastreabilidade entre a Base de Teste e o Testware

Para um monitoramento e controle eficazes dos testes, é importante estabelecer e manter a rastreabilidade entre os elementos da base de teste e o testware associado. A rastreabilidade permite avaliar a cobertura, determinar o impacto das mudanças, facilitar auditorias de teste e atender aos critérios de governança de TI.

1.4.5 Papéis no Teste

Existem dois papéis principais nos testes: gerenciamento de teste e testador. O papel de gerenciamento de teste é responsável pelo planejamento, monitoramento e controle das atividades de teste, enquanto o papel de testador foca nas atividades técnicas de análise, modelagem, implementação e execução de teste. Os indivíduos podem desempenhar esses papéis em momentos diferentes, dependendo do contexto e das necessidades do projeto.

1.5 Habilidades essenciais e boas práticas em testes

Habilidade é a capacidade de realizar uma tarefa com eficácia, uma aptidão que resulta do conhecimento, prática e aptidão de uma pessoa. Os testadores eficazes possuem habilidades essenciais que lhes permitem desempenhar bem seu trabalho. Eles não apenas realizam testes, mas também são membros ativos e eficazes de uma equipe, capazes de executar testes em vários níveis de independência.

1.5.1 Habilidades genéricas necessárias para testes

Conhecimento sobre testes
Meticulosidade e atenção aos detalhes
Boas habilidades de comunicação
Pensamento analítico e crítico
Conhecimento técnico
Conhecimento do domínio

1.5.2 Abordagem de equipe completa

Na abordagem de equipe completa, todos os membros da equipe têm a capacidade de executar qualquer tarefa e são responsáveis pela qualidade. A colaboração e comunicação são facilitadas pela co-localização da equipe, seja fisicamente ou virtualmente. Essa abordagem melhora a dinâmica da equipe, promove a comunicação e colaboração e permite o aproveitamento dos vários conjuntos de habilidades da equipe para o benefício do projeto.

1.5.3 Independência dos testes

A independência dos testes é crucial para a eficácia do processo de teste, pois permite que os testadores identifiquem diferentes tipos de falhas e defeitos em comparação com os desenvolvedores, devido às suas diferentes perspectivas e formações técnicas. No entanto, a independência não substitui a familiaridade, e diferentes níveis de independência podem ser necessários dependendo do contexto do projeto.

Aprofundando os Conhecimentos em Testes de Software: Diferenciando Tipo e Nível de Teste

Diego Yuri — Sun, 04 Feb 2024 01:38:12 +0000

Ao abordarmos o processo de garantia de qualidade de software, deparamo-nos com termos e conceitos que, à primeira vista, podem parecer complexos e até confundíveis (especialmente quando ainda não os compreendemos completamente). Um ponto crucial nessa discussão é a distinção entre Tipos de Testes e Níveis de Testes, uma distinção que frequentemente causa confusão, especialmente entre os iniciantes. Vamos, então, explorar essas diferenças e fornecer uma explicação mais clara sobre o assunto.

Tipos e Níveis de Testes: Entendendo as Diferenças

Tipos de Testes

Os tipos de testes estão diretamente ligados ao propósito específico do teste, determinando se este será funcional, de desempenho, entre outros

Níveis de Testes

O nível de teste, por sua vez, descreve o momento em que o teste ocorre durante o ciclo de desenvolvimento. Este aspecto considera se o teste é realizado em um sistema já desenvolvido ou durante sua construção.

Para o BSTQB (Brazilian Software Testing Qualifications Board) em seu documento base de estudo (Syllabus) disponível em Base de estudo, eles também definem níveis de testes como grupos de atividades de teste que são organizados e gerenciados juntos, descrevendo/executando testes em determinado nível de desenvolvimento do projeto, desde as unidades individuais ou componentes até os sistemas completos ou, quando aplicável, em sistemas de sistemas.

No livro "Jornada Ágil de Qualidade", os níveis de teste são explorados, destacando a capacidade de agrupá-los para identificar responsabilidades, o tamanho do objeto de teste e a semelhança com o ambiente de produção. Os níveis típicos como: unidade, integração, sistema e aceitação, podem ser categorizados em baixo e alto nível.

Baixo Nível de Testes

Os testes de baixo nível são direcionados à verificação de componentes individuais do sistema, sendo os desenvolvedores os principais responsáveis por sua execução. Após assegurar a qualidade das partes mais fundamentais do sistema por meio dos testes de unidade, as partes maiores são testadas em conjunto durante os testes de integração. Exemplos incluem:

Testes Unitários
- Também conhecidos como Teste de Componentes ou Teste de Unidade.
- Focam nos menores blocos construtivos do sistema.
- Baseiam-se no funcionamento interno de componentes individuais.
- Podem exigir testes funcionais e não funcionais*(Tipo de teste).*
- Geralmente executados pelo desenvolvedor.
Testes de Integração
- Realizados após os testes unitários.
- Concentram-se nas interações entre componentes ou sistemas.
- Verificam se o sistema se comporta corretamente quando partes são combinadas.
- Podem exigir testes funcionais e não funcionais*(Tipo de teste).*.

Alto Nível de Testes

Os testes de alto nível visam testar produtos completos, fornecendo informações sobre a qualidade do sistema. Estes são realizados após os testes de baixo nível e, frequentemente, em diferentes etapas da validação do sistema. Os principais testes de alto nível incluem:

Testes de Sistema
- Envolvem o teste funcional ou integrado do sistema completo.
- Concentram-se no comportamento e capacidades globais do sistema.
- Objetivos incluem a redução de riscos e a validação do sistema como um todo.
- Exemplos de testes: usabilidade, acessibilidade, desempenho, segurança (pentest), portabilidade, regressão.
Testes de Aceitação
- Executados pelo usuário ou cliente.
- Validam se o sistema atende aos requisitos originais.
- Realizados após os testes de sistema bem-sucedidos.
- Objetivos incluem estabelecer confiança na qualidade do sistema como um todo e verificar se os comportamentos funcionais e não funcionais estão de acordo com o esperado.
- Exemplos de testes: aceitação do usuário,aceitação do contrato,alpha, beta, ATDD, testes A/B, LRR, HRR.

É crucial lembrar que não existe uma abordagem única para testes, ou seja, não necessáriamente seguiriamos o fluxo baixo nivel para alto nivel. A flexibilidade na aplicação dos níveis de teste é essencial para adaptar o modelo à realidade do contexto em que será utilizado, a imagem a seguir demonstra um pouco essa questão

Compreendido os niveis de testes, iremos agora se aprofundar um pouco mais nos tipos de testes

Tipos de Teste

Quando falamos de tipo de testes, estamos falando da "forma" que determinada coisa será testada e seu proposito. Lembrando que essa "Forma" de testar que logo iremos descrever melhor, pode ser alocada em quaisquer niveis de testes, sendo alguns mais habitual, outros não.

Para falarmos de tipo de teste, inicialmente vamos a sua definição
contida lá naquela base de estudo do BSTQB
Eles definem os tipos de teste em 4 principais(Que podem ter ramificações)
Sendo eles:
1 -Teste funcional
2 -Teste não funcional
3 -Teste caixa-branca
4 -Teste relacionado à mudança

Mas vejamos, Muito usa-se no mercado outras nomenclaturas, ou, aquilo que eu chamo de ramificações desses tipos de testes inicial definido.
Irei primeiro basear-se em 4 topicos desses tipo de testes, e posteriormente em um segundo post, irei aprofundar nossos conehcimentos geral nos tipos de teste.
irei trazer uma base sobre os 4 diferente tipospara compreendermos o contexto geral dos tipos de testes

1 - Teste Funcional

O teste funcional em um sistema visa avaliar as funções que o software deve executar, com base nos requisitos funcionais, que podem ser descritos em diversas formas, como especificações de requisitos, épicos, histórias de usuários, casos de uso ou especificações funcionais. Essas funções representam o "o que" o sistema deve realizar.

A realização de testes funcionais ocorre em todos os níveis de teste, sendo que cada nível pode ter um foco diferente. O teste funcional utiliza técnicas de caixa-preta para avaliar o comportamento do software, derivando condições e casos de teste sem a necessidade de conhecimento interno da implementação. A cobertura funcional é uma medida de eficácia, calculada como a porcentagem de elementos funcionais abordados pelos testes, identificando potenciais lacunas de cobertura.

O projeto e a execução de testes funcionais podem exigir conhecimentos específicos, como compreensão do problema de negócios que o software resolve. As características de qualidade podem ser classificadas como funcionais e não funcionais, sendo que o teste funcional se concentra nas subcaracterísticas relacionadas à funcionalidade, como adequação funcional, corretude, completude e adequação à tarefa.

Em resumo, o teste funcional consiste em uma série de subtestes, especialmente utilizando técnicas caixa-preta, para garantir que o software desempenhe efetivamente as funções planejadas, com ênfase nas características de qualidade funcionais.

2 - Teste Não Funcional

Os testes não funcionais abrangem a avaliação de características gerais de sistemas e softwares, como usabilidade, eficiência de performance e segurança. Ao contrário de uma percepção comum, esses testes são aplicáveis em todos os níveis e devem ser realizados o mais cedo possível para evitar descobertas tardias de defeitos não funcionais, que podem ser prejudiciais ao sucesso do projeto.

Assim como nos testes funcionais, as técnicas caixa-preta podem ser utilizadas para derivar condições de teste e casos de teste para os testes não funcionais. Por exemplo, a análise do valor limite pode ser empregada para definir condições de tensão em testes de performance. A eficácia dos testes não funcionais é medida pela cobertura não funcional, expressa como a porcentagem de elementos não funcionais abordados pelos testes, identificando possíveis lacunas de cobertura.

A modelagem e execução de testes não funcionais podem exigir habilidades especializadas, como o conhecimento de fraquezas inerentes a um projeto ou tecnologia, como vulnerabilidades de segurança associadas a linguagens de desenvolvimento específicas. Além disso, considerações sobre a base de usuários, como os funcionários de sistemas de gerenciamento de unidades de saúde, podem ser relevantes.

Os testes não funcionais incluem avaliação de desempenho, compatibilidade, usabilidade, adequação, confiabilidade, segurança da informação, manutenibilidade e portabilidade. Esses testes verificam aspectos gerais da aplicação, independentemente das regras de negócio específicas, abrangendo desde o desempenho até a segurança e a usabilidade.

3 - Teste Não Funcional

O teste caixa-branca é uma abordagem derivada de testes que se concentra na estrutura interna ou na implementação do sistema. Essa estrutura interna engloba elementos como código, arquitetura, fluxos de trabalho e fluxos de dados dentro do sistema.

A eficácia dos testes caixa-branca é medida por meio da cobertura estrutural, que representa a extensão em que determinados elementos estruturais foram testados, expressa como uma porcentagem do tipo de elemento a ser coberto. No nível de teste de componente, a cobertura de código é avaliada com base na porcentagem do código do componente testado, podendo abranger aspectos específicos, como a porcentagem de instruções executáveis ou a porcentagem de resultados de decisões testados. No teste de integração de componentes, o foco pode ser na arquitetura do sistema, incluindo interfaces entre componentes.

A modelagem e execução do teste caixa-branca podem demandar habilidades e conhecimentos especializados, como a compreensão da construção do código (por exemplo, o uso de ferramentas de cobertura de código), a avaliação do armazenamento de dados (como a análise de consultas de banco de dados) e a interpretação correta dos resultados de ferramentas de cobertura.

Em resumo, o teste caixa-branca é uma abordagem que se baseia na estrutura interna do sistema, envolvendo o código, arquitetura e fluxos de dados, e sua eficácia é avaliada por meio da cobertura estrutural. Esse tipo de teste é também conhecido como caixa de vidro ou estrutural.

4 - Teste relacionado à mudança

Quando ocorrem alterações em um sistema, seja para corrigir defeitos ou introduzir novas funcionalidades, é crucial realizar testes para garantir que as mudanças foram implementadas corretamente e não causaram efeitos colaterais indesejados.

Tipos de Testes:

Teste de Regressão:
- Objetivo: Detectar efeitos colaterais indesejados das alterações.
- Candidato à automação.
Teste de Confirmação (Reteste):
- Objetivo: Confirmar se o defeito foi corrigido.

Abrangência dos Testes:

Esses testes devem ser aplicados em todos os níveis de testes, independentemente do estágio do desenvolvimento do software. Em ciclos de desenvolvimento ágil, a frequência desses testes é aumentada para garantir uma validação contínua das alterações realizadas.

Descrição Adicional:

O Teste de Confirmação envolve a execução de testes após a correção de um defeito, utilizando todos os casos de teste que falharam devido ao defeito corrigido.

O Teste de Regressão consiste na execução de testes para detectar efeitos colaterais indesejados resultantes das alterações realizadas no sistema.

Esses testes desempenham um papel crucial na manutenção da integridade do software durante seu ciclo de vida, assegurando que cada modificação contribua para uma melhoria contínua e não introduza novos problemas.

Os tipos de testes apresentados neste artigo abrangem diferentes aspectos e requerem especificidades para cada contexto de aplicação. Embora não tenhamos abordado detalhadamente as ramificações e especificidades de cada tipo de teste neste artigo, pretendo explorá-las em futuras publicações.

Nessas futuras discussões, poderemos examinar mais de perto as nuances dos testes e as diferentes abordagens comumente utilizadas em cada contexto específico. Isso inclui a exploração das ramificações de testes normalmente empregadas nos tipos de teste discutidos aqui.

Por enquanto, agradeço pela leitura e espero que este artigo tenha proporcionado uma compreensão no entendimento de niveis e tipos de testes.
Se houver alguma dúvida ou sugestão, sinta-se à vontade para compartilhar.

Muito obrigado!

Aprenda a implementar cucumber ao Cypress em testes automatizados

Diego Yuri — Sat, 30 Dec 2023 23:30:55 +0000

Neste artigo, iremos explorar uma abordagem para implementar Cucumber com Cypress em projetos de automação de testes. Antes de iniciarmos, precisamos que se tenha instalado e configurado os seguites pré-requisitos

Após a instalação dos itens, Vamos confirmar que o Node foi configurado corretamente.
Abra o terminal e execute os comandos npm -v para verificar a versão do Node.js.

npm -v

Se a versão for exibida corretamente, a configuração foi bem-sucedida.

Agora, criaremos uma pasta para o projeto e abriremos-a no Visual Studio Code. Após isso No terminal( CTRL + SHIFT + ' ) do VS Code, execute o comando:

npm init -y

Isso criará o arquivo package.json na pasta. Em seguida, instalaremos o Cypress e o plugin do Cucumber:

npm install cypress --save-dev
npm install cypress-cucumber-preprocessor --save-dev

Após a instalação, abra o Cypress para criar uma estrutura inicial do projeto:

npx cypress open

No Cypress, clique em "E2E Testing", escolha um navegador (por exemplo, Electron), crie um novo arquivo de especificação e execute o teste de exemplo, feito isso podemos fechar o cypress.

Neste ponto, é fundamental entender a estrutura das pastas do projeto. Teremos duas pastas principais: Cypress e Node_Modules. Além disso, serão encontrados os seguintes arquivos essenciais: Cypress.config.js, package-lock.json e package.json.

Para iniciar a configuração do Cucumber, acessaremos o arquivo Cypress.config.js, onde importaremos o plugin necessário. Na primeira linha do código, adicionaremos o seguinte comando:

const cucumber = require('cypress-cucumber-preprocessor').default;

Feito isso, dentro deste mesmo arquivo, iremos adicionar a configuração do preprocessor dentro do Module.exports. Dentro da função setupNodeEvents, adicionaremos o seguinte comando:

on('file:preprocessor', cucumber())

Assim, o código neste momento ficará assim:

const cucumber = require('cypress-cucumber-preprocessor').default;
const { defineConfig } = require("cypress");

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('file:preprocessor', cucumber())

    },
  },
});

Além disso, dentro do bloco e2e, adicionaremos a localização das features. Embora isso possa ser configurado conforme preferência, por padrão, manteremos as features dentro da própria pasta e2e. A configuração será da seguinte forma:

specPattern: "cypress/e2e/step_definitions/*.feature"

Isso indica que nossos arquivos .feature estarão dentro da pasta STEP_DEFINITIONS na pasta e2e.

O arquivo final terá a seguinte aparência:

const cucumber = require('cypress-cucumber-preprocessor').default;
const { defineConfig } = require("cypress");

module.exports = defineConfig({
  e2e: {
    setupNodeEvents(on, config) {
      on('file:preprocessor', cucumber())

    },
    specPattern: "cypress/e2e/step_definitions/*.feature"
  },
});

Entretanto, neste momento, a pasta necessária ainda não foi criada no projeto. Dentro da pasta e2e, encontraremos apenas o arquivo exemplo que criamos anteriormente ao abrir o Cypress. Portanto, podemos acessar a pasta e2e, excluir o arquivo de exemplo (spec.cy.js), e dentro desta mesma pasta, criar a pasta step_definitions.

Essa organização é crucial para estruturar o projeto de forma clara, eliminando arquivos desnecessários e preparando o terreno para a inclusão das definições de passos do Cucumber.

Com a estrutura inicial ajustada, é hora de realizar as configurações necessárias no arquivo package.json. Isso é crucial para garantir que o Cucumber e o Cypress funcionem harmoniosamente. Adicione a seguinte configuração dentro do bloco

"cypress-cucumber-preprocessor": {
  "nonGlobalStepDefinitions": true,
  "stepDefinitions": "cypress/e2e/step_definitions"
}

Explicando cada parte:

nonGlobalStepDefinitions: Este é um comando padrão do plugin e é essencial para o seu correto funcionamento.
"stepDefinitions": "cypress/e2e/step_definitions": Aqui, especificamos o caminho para a pasta que contém as definições de etapas dos nossos testes. No exemplo, estamos definindo que nossos arquivos .js de definição de etapas estão na própria pasta step_definitions.

A estrutura final do seu arquivo package.json pode se assemelhar a este exemplo:

{
  "name": "artigo1",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC",
  "devDependencies": {
    "cypress": "^13.6.2",
    "cypress-cucumber-preprocessor": "^4.3.1"
  },
  "cypress-cucumber-preprocessor": {
    "nonGlobalStepDefinitions": true,
    "stepDefinitions": "cypress/e2e/step_definitions"
  }
}

Essas configurações são cruciais para garantir que o ambiente esteja devidamente preparado para a integração do Cucumber com o Cypress, e que as definições de etapas estejam devidamente reconhecidas.

Neste ponto, todas as configurações essenciais foram realizadas para criar um ambiente de trabalho alinhado com o escopo do projeto. É importante destacar que seguimos uma abordagem específica para organizar nossos arquivos.

Na raiz da pasta STEP_DEFINITIONS, a prática será deixar nossos arquivos .feature. Mas a organização não para por aí. Dentro da pasta STEP_DEFINITIONS, criaremos uma pasta para cada feature. Isso significa que na raiz teremos o arquivo .feature correspondente, e dentro da pasta, teremos outros elementos relacionados a essa feature.

Este método de organização facilita a manutenção e compreensão do projeto, tornando a estrutura mais intuitiva. Afinal, um arquivo .feature na raiz representa a feature em si, enquanto a pasta com o nome da feature contém elementos adicionais relacionados a ela.

Essa abordagem flexível e intuitiva proporciona uma experiência mais clara e eficiente ao trabalhar com os testes e cenários definidos no projeto.

o nosso exemplo, o escopo do projeto se apresenta conforme a imagem abaixo:

Vale ressaltar que este tutorial não visa aprofundar-se no ensino detalhado das ferramentas, mas sim orientar sobre como implementar o Cucumber com Cypress. Inicialmente, abordaremos a utilização prática dessas ferramentas, proporcionando um entendimento gradual.

Vamos começar criando, na raiz da pasta step_definitions, o arquivo .feature para nosso projeto, nomeando-o como form.feature. A seguir, apresentarei um exemplo prático, delineando os passos do BDD (Behavior-Driven Development):

Feature: Form

Scenario: Valid Form
Given que o site seja acessado
When preencher o formulário
Then Valido o acesso

Este cenário fictício representa a interação com um formulário em um site. Durante a execução dos testes, cada passo (Given, When, Then) será associado a ações específicas no código de automação.

O intuito é proporcionar uma visão inicial do funcionamento do BDD/Cucumber no projeto, partindo de um exemplo simples.

Após criar e configurar o arquivo .feature, avançaremos para a criação da estrutura de funções. Dentro da pasta step_definitions, criaremos uma subpasta chamada form. Dentro dessa subpasta, será criado o arquivo form.js.

Para cada feature testada, será necessário implementar/importar os códigos dos passos do Cucumber, como Given, When, Then. Portanto, adicionaremos o seguinte código nos arquivos .js:

import { Given, When, Then } from 'cypress-cucumber-preprocessor/steps';

Este trecho de código localiza o caminho configurado no cypress.config.js, acessando o diretório steps.

O arquivo .js ficará da seguinte forma:

import { Given, When, Then } from 'cypress-cucumber-preprocessor/steps';

Given("que o site seja acessado", () => {
    cy.visit("https://vinothqaacademy.com/demo-site/");
    cy.title().should('eq', 'Demo Site – Registration Form – Vinoth Q.A Academy');
});

When("preencher o formulario", () => {
    cy.get('#vfb-5').type('Yuri');
    cy.get('#vfb-7').type('Lima');
    cy.get('#vfb-31-1').click();
    cy.get('#vfb-14').type('teste@teste.com');
    cy.get('#vfb-3').type('99');
    cy.get('#vfb-4').click();
});

Then("Valido acesso", () => {
    cy.title().should('eq', 'Demo Site – Dynamic Transaction – Vinoth Q.A Academy');
});

Aqui, utilizamos Given, When e Then em vez do habitual it do Cypress, construindo assim nosso ambiente conforme necessário. No exemplo, o passo Given valida o acesso ao site, onde é visitado e confirmado pelo título. O passo When realiza o preenchimento do formulário, e, por fim, o passo Then valida a página seguinte, para onde é redirecionado após o envio do formulário.

Essa abordagem básica exemplifica o comportamento do BDD/Cucumber no projeto, destacando a naturalidade da linguagem de especificação.

Ressalta-se a necessidade do entendimento do BDD e Cucumber, onde a nomenclatura inicial após abrir a função (Given, When, Then) deve ser exatamente a mesma definida no arquivo .feature.

No nosso exemplo:

Given("que o site seja acessado", () => {
    cy.visit("https://vinothqaacademy.com/demo-site/");
    cy.title().should('eq', 'Demo Site – Registration Form – Vinoth Q.A Academy');
});

A frase "que o site seja acessado" deve ser estritamente idêntica à linha "Given que o site seja acessado" contida no arquivo .feature. Qualquer divergência nesses pontos resultará na falha da execução do teste.

Na imagem a seguir, podemos visualizar a execução do teste.

Espero que tenham apreciado o conteúdo e que seja produtivo para vocês. Para qualquer assistência adicional, estou à disposição.

Obrigado!

Simplificando Testes: Por que Talvez Você Não Precise de Cucumber e Page Object ao testar usando Cypress

Diego Yuri — Mon, 18 Dec 2023 16:43:32 +0000

Explorando a relação entre Cypress, Cucumber (BDD) e PageObject

Olá! Eu sou o Yuri.

Hoje vamos discutir a interação entre Cypress, Cucumber (BDD) e PageObject no contexto de testes automatizados. Recentemente, tenho dedicado tempo para aprimorar meus conhecimentos em testes automatizados, especialmente no que diz respeito ao Cypress. Durante a formação que participei esse ano (FormaNT), adquiri uma base de conhecimento em Selenium, Cucumber e BDD. Inclusive, compartilhei essas experiências em um vídeo no meu canal, onde apresento um escopo de projeto relacionado a Cucumber: TDD e BDD: Como esses conceitos se relacionam com Testes de Software.

Ao explorar o Cypress, notei uma conexão direta entre Cypress e Selenium, uma ferramenta que já conhecia e havia utilizado com o Cucumber. Paralelamente, percebi que muitos dos conteudos de aprendizado que encontrei relacionado ao Cypress também enfatizavam e traziam o conceito de PageObject.

Enquanto buscava integrar o Cucumber ao Cypress, percebi que, embora o Cypress facilite muitas coisas, a introdução do PageObject tornava a implementação mais complexa. Isso me fez questionar a utilidade do PageObject em projetos que poderiam ser mais eficientes sem ele.

Durante essa jornada, Busquei conteudos que comentavam esse ponto que observei, e acabei encontrando uma live muito interessante, que me ajudou a contextualizar esse ponto. Você pode assisti-la aqui: Por que QAs usam Page Objects com Cypress?.

Com todo conhecimento adiquirido nessas pesquisas, cheguei a alguns entendimentos, e que gostaria de compartilha-los para que possamos refletir nos nossos conceitos de qualidade.

1. Cucumber com Cypress: É a combinação ideal?

Desde o início dos meus estudos com Cypress, considerei a implementação do Cucumber, pois o vejo como um excelente framework. No entanto, ao estudar o Cypress por si só, percebi que a utilização do Cucumber poderia ser redundante, uma vez que a estrutura do Cypress já permite uma diversificação eficiente dos cenários e contextos de teste. A integração do Cucumber dependerá do projeto e da importância dos passos definidos.

Em breve, vou compartilhar um vídeo demonstrando como integrar o Cucumber com o Cypress. No entanto, é fundamental avaliar se a utilização do Cucumber é realmente necessária, considerando as capacidades nativas do Cypress.

2. Utilização de PageObject

A utilização do PageObject, especialmente no contexto do Cypress, pode introduzir complexidade desnecessária. A própria ferramenta oferece funcionalidades, como Commands, que permitem a criação de funções chamadas apenas nos testes principais e podem ser reutilizadas conforme necessário. Em projetos extensos, é possível segmentar os Commands para áreas específicas, como Login ou Cadastro, seguindo o conceito de "Função-Teste" no ambiente Cypress.

3. Aprofundando o conhecimento: Application Actions

O blog do Cypress apresenta um artigo relevante sobre a relação
entre PageObject e uma abordagem baseada em Application Actions. Essa reflexão visa aprofundar o entendimento sobre as diferentes abordagens e incentivar uma revisão da forma como aplicamos esses conceitos. Ambas as abordagens são válidas, e a escolha entre usar ou não o PageObject deve ser orientada pelas necessidades específicas do projeto.
Compreender os conceitos da ferramenta, assim como a melhor forma de implementar, pode nos levar a um caminho no qual podemos decidir a utilização ou não tanto dos Application Actions quanto dos pageObjects
Voces podem ver o artigo para uma compreensão melhor a seguir Application Actions: Use Them Instead of Page Objects

Essas reflexões visam aprimorar nossos conceitos de qualidade e proporcionar uma visão mais clara sobre a implementação eficiente de testes automatizados. Fique atento para futuras discussões e compartilhamento de conhecimento!