Baixe Estudo Para a P1 de Teste de Software e outras Notas de estudo em PDF para Tecnologia de Informação, somente na Docsity!
Estudo Para a P1 de Teste de Software
1. Fundamentos de Teste de Software: Erro, Defeito e Falha
No contexto de teste de software , erro , defeito e falha são termos essenciais para compreender a natureza dos problemas que podem surgir no desenvolvimento e execução de sistemas. Cada um deles representa diferentes aspectos de um problema de qualidade de software, desde sua origem até o impacto no usuário final. Vamos explorar esses termos em detalhes:
1. Erro - Definição : O erro (também conhecido como “mistake” ou “bug”) é um engano ou equívoco cometido por um desenvolvedor ou analista durante o processo de desenvolvimento de software. Ele geralmente ocorre por falta de entendimento dos requisitos, interpretação incorreta da lógica, falhas de comunicação ou lapsos durante a codificação. - Origem : Os erros são introduzidos durante as fases de planejamento, design ou codificação do software. - Exemplo : Um desenvolvedor comete um erro ao interpretar um requisito e implementa uma lógica incorreta para o cálculo de desconto em um sistema de vendas. O erro aqui está no código, mas o usuário final ainda não experimentou o problema. - Prevenção : Revisões de código, comunicação clara e entendimento dos requisitos são algumas práticas que ajudam a prevenir erros. 2. Defeito - Definição : Um defeito (também conhecido como “fault” ou “bug”) é o resultado de um erro que está presente no código ou em qualquer outro artefato do sistema, como documentos de requisitos, design ou configuração. O defeito pode ou não ser notado imediatamente; ele só se torna visível quando o software é executado e uma falha ocorre. - Impacto : O defeito é um problema no código que pode levar o sistema a um comportamento inesperado ou incorreto. Embora ele esteja latente no sistema, nem sempre será detectado, a menos que a condição específica que o ativa ocorra. - Exemplo : Seguindo o exemplo anterior, o erro de interpretação do desenvolvedor se traduz em um defeito na lógica do sistema de cálculo de desconto, onde o desconto aplicado é de 20% em vez de 10%, como solicitado. Esse defeito será ativado sempre que um cliente tentar realizar uma compra qualificada para o desconto.
- Prevenção e Detecção : Revisões de código, testes de unidade e de integração são métodos eficazes para detectar defeitos antes que eles cheguem ao usuário final. 3. Falha
- Definição : A falha é o comportamento incorreto do sistema percebido pelo usuário final como resultado de um defeito. Ou seja, uma falha ocorre quando um defeito no sistema é ativado durante a execução, levando o software a apresentar um comportamento anômalo ou incorreto, que afeta a experiência do usuário.
- Impacto : A falha é o que o usuário experimenta como um problema direto. Ela pode ter um impacto mínimo, como uma exibição gráfica incorreta, ou um impacto crítico, como uma operação financeira incorreta. A gravidade da falha depende do defeito e do contexto de uso.
- Exemplo : O usuário final tenta aplicar um desconto em uma compra e percebe que o sistema oferece um desconto incorreto de 20%, quando deveria aplicar apenas 10%. Isso é uma falha observável para o usuário e pode afetar a confiabilidade e a usabilidade do sistema.
- Prevenção e Correção : Uma combinação de testes de sistema, testes de aceitação e manutenção corretiva são necessários para prevenir e corrigir falhas. A prevenção ocorre identificando e corrigindo defeitos antes que o sistema entre em produção, enquanto a correção ocorre por meio de atualizações e patches após a identificação da falha. Relação entre Erro, Defeito e Falha
- Erro → Defeito → Falha : Essa sequência descreve como um problema se manifesta ao longo do ciclo de vida do software. Um erro cometido pelo desenvolvedor (por exemplo, má interpretação de um requisito) se transforma em um defeito no código ou no design. Esse defeito pode eventualmente causar uma falha durante a execução, que será visível para o usuário final.
- A correlação é, portanto, causal e sequencial: erro leva a defeito , e defeito pode levar a falha , mas não necessariamente todas as etapas ocorrerão. Por exemplo, alguns defeitos podem nunca causar uma falha se a condição para ativá-los nunca ocorrer. Importância da Identificação e Correção
- Correção de Erros e Defeitos : Identificar e corrigir erros e defeitos durante as fases iniciais do desenvolvimento reduz o número de falhas no produto final. Testes de unidade e revisões de código ajudam a detectar erros antes que se transformem em defeitos funcionais.
- Correção de Falhas : o Testes de Sistema e Aceitação : Testes de sistema e aceitação ajudam a detectar falhas antes da entrega ao cliente. o Manutenção Corretiva : Quando uma falha é identificada em produção, a equipe de desenvolvimento aplica correções e, se necessário, realiza testes de regressão para garantir que o defeito original foi resolvido. Conclusão
- Erros, Defeitos e Falhas são termos que descrevem o ciclo de vida dos problemas de qualidade em software, desde sua origem até o impacto no usuário. Entender a diferença entre esses conceitos ajuda as equipes a estabelecerem processos eficazes de garantia de qualidade, prevenindo falhas e corrigindo problemas antes que afetem os usuários.
- A abordagem sistemática para prevenção e detecção, como o uso de Test- Driven Development (TDD) e outras práticas de desenvolvimento, é essencial para manter a qualidade e a confiabilidade do software. Isso também permite um ciclo de desenvolvimento mais eficiente e focado na resolução de problemas antes que eles cheguem ao cliente final.
2. Value-Based Software Engineering
Value-Based Software Engineering (VBSE) , ou Engenharia de Software Baseada em Valor , é uma abordagem de desenvolvimento de software que enfatiza a importância de alinhar o desenvolvimento com os objetivos e valores do negócio. Introduzido por Barry Boehm, o VBSE considera que as decisões de engenharia de software devem ser guiadas não apenas por aspectos técnicos, mas também pelo valor que o software traz aos stakeholders e pela priorização de funcionalidades de acordo com seu impacto econômico. Principais Conceitos do VBSE
- Foco em Valor de Negócio : o No VBSE, todas as decisões de desenvolvimento são orientadas pelo valor que uma funcionalidade traz ao cliente ou ao usuário final. Isso significa que o desenvolvimento deve priorizar funcionalidades que atendam às necessidades mais críticas e agreguem o maior valor ao negócio.
o As funcionalidades são analisadas quanto ao impacto que trazem para os objetivos organizacionais, como aumento de receita, redução de custos ou melhoria da satisfação do cliente. o Exemplo: Uma empresa pode priorizar funcionalidades de segurança e conformidade em um software bancário, pois essas funcionalidades possuem um alto impacto no valor e na confiança do cliente.
- Prioridade Baseada em Retorno sobre o Investimento (ROI) : o O VBSE utiliza o Retorno sobre o Investimento (ROI) para priorizar as funcionalidades que devem ser desenvolvidas primeiro. Funcionalidades que oferecem um ROI alto são priorizadas para garantir que o investimento em desenvolvimento gere o máximo de retorno possível. o O ROI é calculado considerando o valor que uma funcionalidade agrega versus o custo de sua implementação e manutenção. o Exemplo: Em um projeto de e-commerce, uma funcionalidade que permite recomendação de produtos com base no histórico de compras pode ser priorizada, pois aumenta a probabilidade de vendas adicionais, trazendo um ROI elevado.
- Engajamento dos Stakeholders : o A prática do VBSE envolve a participação ativa dos stakeholders (clientes, usuários, gerentes de produto, etc.) no processo de desenvolvimento. Eles ajudam a definir e priorizar funcionalidades, permitindo que as decisões sejam orientadas pelas reais necessidades do negócio. o Essa colaboração entre as equipes técnicas e os stakeholders promove o alinhamento entre o software e as expectativas de valor do cliente. o Exemplo: Em um projeto de desenvolvimento de um aplicativo móvel, os stakeholders podem definir que uma funcionalidade de fácil navegação e checkout rápido é essencial para os usuários e deve ser priorizada.
- Avaliação de Risco e Valor : o O VBSE considera os riscos associados a diferentes funcionalidades e decisões de desenvolvimento. Funcionalidades de alto valor, mas também de alto risco, são tratadas com cuidado, pois podem impactar significativamente o projeto se falharem. o As decisões são guiadas por uma análise de custo-benefício que avalia tanto o valor quanto o risco, priorizando a mitigação de riscos em funcionalidades críticas. o Exemplo: Em um sistema de saúde, a funcionalidade de armazenamento seguro de dados médicos pode ter alto valor e alto risco. O VBSE permite
o Durante o desenvolvimento, as métricas de valor são monitoradas para avaliar o impacto das funcionalidades e o progresso em direção aos objetivos de valor. Esse monitoramento contínuo permite que a equipe ajuste as prioridades e recursos conforme necessário. o Se uma funcionalidade não está trazendo o valor esperado, pode ser descartada ou modificada para melhor atender às necessidades do negócio.
- Entrega e Avaliação de Valor Pós-Lançamento : o Após a entrega, o impacto das funcionalidades no valor do negócio é avaliado. Feedback de usuários, métricas de uso e indicadores financeiros ajudam a determinar se o software atendeu às expectativas de valor e se ajustes adicionais são necessários. o O feedback pós-lançamento também ajuda a equipe a planejar futuras melhorias e priorizar novas funcionalidades de acordo com o valor que agregam. Benefícios do VBSE
- Alinhamento com os Objetivos de Negócio : o O VBSE garante que o desenvolvimento de software esteja alinhado diretamente com os objetivos estratégicos e necessidades dos stakeholders, reduzindo o desperdício e maximizando o retorno sobre o investimento.
- Otimização do Uso de Recursos : o Ao focar em funcionalidades de alto valor, o VBSE permite que as equipes de desenvolvimento utilizem recursos de maneira eficiente, priorizando as funcionalidades que trazem maior benefício.
- Maior Satisfação do Cliente : o Com o envolvimento ativo dos stakeholders, o VBSE assegura que o software atenda às expectativas do cliente e agregue valor, resultando em maior satisfação e lealdade do cliente.
- Redução de Risco : o A abordagem de valor permite que a equipe identifique e trate funcionalidades de alto risco com prioridade, mitigando potenciais problemas antes que afetem o produto final. Desafios e Limitações do VBSE
- Dificuldade em Medir o Valor :
o A determinação do valor de funcionalidades específicas pode ser subjetiva e variar entre os stakeholders. Isso pode dificultar a priorização objetiva das funcionalidades.
- Curva de Aprendizado : o Implementar o VBSE pode exigir treinamento e adaptação. Equipes acostumadas a métodos tradicionais podem precisar de tempo para ajustar suas práticas ao novo enfoque em valor.
- Foco Excessivo em Funcionalidades de Alto Valor : o Focar apenas em funcionalidades de alto valor pode fazer com que o desenvolvimento negligencie funcionalidades menos valiosas, mas que ainda são essenciais para a experiência do usuário.
- Custo Inicial de Implementação : o A análise de valor e o engajamento contínuo dos stakeholders podem aumentar o custo inicial de desenvolvimento. No entanto, a longo prazo, os benefícios geralmente superam esses custos. Exemplo de Implementação do VBSE em um Projeto de Software Imagine que uma empresa está desenvolvendo um sistema de gestão de estoque. Com a abordagem VBSE, o projeto pode seguir as seguintes etapas:
- Identificação de Funcionalidades de Valor : o Em workshops com os stakeholders, identifica-se que a funcionalidade de rastreamento em tempo real do inventário e a geração automática de pedidos são de alto valor para os clientes.
- Avaliação de Custo-Benefício : o O rastreamento em tempo real é priorizado por trazer maior retorno financeiro ao reduzir os custos de estoque. A geração automática de pedidos também é avaliada por seu impacto em economia de tempo.
- Planejamento Baseado em Valor : o O desenvolvimento inicia com o rastreamento em tempo real, alocando mais recursos para garantir que essa funcionalidade seja entregue primeiro.
- Monitoramento de Valor e Ajustes : o Durante o desenvolvimento, métricas de uso e feedback dos stakeholders são monitorados. Se a geração de pedidos é avaliada como menos crítica que uma nova funcionalidade sugerida, a equipe ajusta as prioridades.
- Avaliação Pós-Lançamento :
assertEquals(5, calculator.add(2, 3)); } o Como o método add ainda não foi implementado, este teste falha.
- Green (Fazer o Teste Passar) : o O próximo passo é escrever o código mínimo necessário para fazer o teste passar. Não é uma implementação completa, apenas o suficiente para que o teste seja bem-sucedido. o Essa abordagem minimalista ajuda a evitar o excesso de desenvolvimento e a focar na resolução do problema de forma eficiente. o Exemplo: java public class Calculator { public int add(int a, int b) { return a + b; } }
- Refactor (Refatorar o Código) : o Com o teste passando, o desenvolvedor revisa e melhora o código. Nesta etapa, o foco é melhorar a legibilidade, eficiência e qualidade do código, sem alterar sua funcionalidade. o A refatoração é uma parte essencial do TDD, pois permite que o código seja continuamente melhorado e simplificado, mantendo-se funcional. o Exemplo: ▪ Se o código add fosse mais complexo, poderíamos refatorá-lo aqui, mantendo o teste bem-sucedido. Este ciclo é repetido continuamente para cada nova funcionalidade ou melhoria, criando uma base de testes sólida que facilita a detecção de defeitos e proporciona uma estrutura de desenvolvimento mais disciplinada. Vantagens do TDD
- Maior Qualidade do Código : o A abordagem TDD leva a um código mais limpo, modular e de fácil manutenção. Como os testes são escritos antes do código, eles ajudam a
definir o que o código deve fazer, levando a uma implementação mais direcionada.
- Detecção Precoce de Defeitos : o Os testes são escritos no início do processo, o que significa que defeitos são detectados assim que o código é escrito. Isso reduz significativamente o custo e o tempo de correção.
- Facilita a Refatoração Segura : o A base de testes criada com o TDD permite que o desenvolvedor refatore o código com segurança, pois a funcionalidade já foi testada. Isso ajuda a manter o código organizado e sustentável ao longo do tempo.
- Documentação Implícita : o Os testes de TDD atuam como uma forma de documentação do sistema. Eles descrevem como o código deve se comportar e podem ser usados como uma referência para novos membros da equipe.
- Desenvolvimento Guiado por Testes : o O TDD encoraja uma abordagem de "fazer o que é necessário" e evita a criação de funcionalidades que não agregam valor diretamente ao usuário. Os desenvolvedores focam em atender os requisitos definidos pelos testes, que são baseados nos requisitos do negócio. Desvantagens do TDD
- Tempo de Desenvolvimento Inicial : o O TDD exige que os desenvolvedores escrevam testes antes de implementar o código, o que pode aumentar o tempo de desenvolvimento inicial. Em ambientes de desenvolvimento ágeis, isso pode ser visto como uma barreira inicial.
- Cobertura de Testes Nem Sempre Ideal : o O TDD depende da qualidade dos testes escritos. Se os testes não forem abrangentes ou bem planejados, eles podem não cobrir todos os cenários críticos, deixando áreas vulneráveis a defeitos.
- Curva de Aprendizado : o Para desenvolvedores que não estão acostumados com o TDD, pode haver uma curva de aprendizado significativa. A abordagem requer uma mentalidade diferente, focada em testes desde o início, o que pode ser difícil para equipes que não estão familiarizadas com a prática.
- Dependência de Testes Automatizados :
- Refatorando o Código (Refactor) : o Com o teste passando, refatoramos o código para melhorar sua estrutura ou corrigir quaisquer problemas de desempenho ou legibilidade. o Neste exemplo, o código está simples e não requer refatoração, mas em sistemas maiores, essa etapa pode envolver a divisão de métodos longos, renomeação de variáveis para maior clareza, etc.
- Criando Novos Testes para Aumentar a Cobertura : o Após implementar a primeira funcionalidade, é importante adicionar testes adicionais para cobrir diferentes casos, como pedidos com quantidades negativas, preço unitário zero, etc. **java @Test public void shouldReturnZeroForZeroQuantity() { Order order = new Order(0, 10.0); assertEquals(0.0, order.calculateTotal()); } @Test public void shouldReturnZeroForZeroUnitPrice() { Order order = new Order(2, 0.0); assertEquals(0.0, order.calculateTotal()); }
- Behavior-Driven Development (BDD) Behavior-Driven Development (BDD)** , ou Desenvolvimento Orientado a Comportamento , é uma abordagem de desenvolvimento de software que foca no comportamento esperado do sistema, descrito de forma colaborativa entre todos os envolvidos, como desenvolvedores, testadores e stakeholders não técnicos. O BDD visa
facilitar a comunicação e garantir que o desenvolvimento esteja alinhado com as expectativas do cliente. Principais Conceitos do BDD O BDD baseia-se na ideia de que o software deve ser desenvolvido em torno de comportamentos esperados que agreguem valor ao usuário. Para isso, ele utiliza uma linguagem comum que todos, independentemente do nível técnico, podem entender. Aqui estão os principais conceitos:
- Cenários de Uso em Linguagem Natural : o O BDD usa uma linguagem simples e estruturada (frequentemente chamada de "Gherkin") para descrever os comportamentos esperados do sistema. o Os cenários são escritos de forma que qualquer pessoa possa entender, usando uma estrutura como: ▪ Dado : Descreve o estado inicial do sistema antes do comportamento ser testado. ▪ Quando : Define a ação ou evento que está sendo testado. ▪ Então : Declara o resultado esperado do sistema após a ação ser realizada. o Exemplo de Cenário : gherkin Feature: Login no sistema Scenario: Usuário com credenciais corretas faz login com sucesso Dado que o usuário está na página de login Quando ele insere um nome de usuário e senha corretos Então ele deve ser redirecionado para o dashboard
- Foco em Valor de Negócio : o O BDD foca em desenvolver funcionalidades que realmente tragam valor ao negócio. Isso ajuda a garantir que os recursos do projeto sejam direcionados para partes que atendam diretamente às necessidades dos usuários finais. o Antes de desenvolver uma funcionalidade, pergunta-se “Por que estamos fazendo isso?” e “Qual valor essa funcionalidade trará?”. Assim,
Desafios e Limitações do BDD
- Curva de Aprendizado : o Implementar BDD pode exigir treinamento e adaptação. Equipes que não estão acostumadas com o desenvolvimento orientado a comportamento podem enfrentar desafios para adotar a prática e entender os princípios.
- Cenários Verbosos e Complexos : o Em projetos grandes, os cenários de BDD podem se tornar extensos e complexos, dificultando a manutenção. Isso pode tornar o processo de automação e manutenção dos testes mais demorado e custoso.
- Dependência de Ferramentas e Linguagens Específicas : o Ferramentas de BDD como Cucumber e SpecFlow introduzem uma dependência de tecnologias específicas. É importante garantir que as ferramentas escolhidas se integrem bem ao ambiente de desenvolvimento.
- Risco de Focar Demasiadamente na Especificação : o Há o risco de gastar muito tempo criando cenários de teste excessivamente detalhados. Isso pode desviar a equipe de desenvolvimento do trabalho de construção de funcionalidades e valor direto para o cliente. Ferramentas de BDD Populares
- Cucumber : o Uma das ferramentas de BDD mais populares, o Cucumber permite que cenários escritos em Gherkin sejam vinculados a código de teste. Ele suporta várias linguagens, incluindo Java, JavaScript, Ruby e Python. o O Cucumber executa cenários de comportamento e gera relatórios, facilitando o monitoramento e a revisão dos testes.
- SpecFlow : o Uma ferramenta de BDD para a plataforma .NET, que permite criar especificações legíveis e executáveis, semelhantes ao Cucumber. o É amplamente usado para integrar cenários de BDD em projetos desenvolvidos em C#.
- JBehave : o Uma ferramenta BDD para Java, que também permite escrever testes com cenários em linguagem natural. É útil para equipes que trabalham em ambientes de Java e desejam adotar o BDD.
- Behave : o Ferramenta de BDD para Python que permite escrever cenários de comportamento em Gherkin e vinculá-los ao código de teste Python. É útil para equipes que trabalham com a linguagem Python. Processo de Trabalho em BDD
- Identificação de Funcionalidades : o A equipe colabora com os stakeholders para identificar funcionalidades essenciais e definir quais comportamentos devem ser atendidos para alcançar o valor de negócio esperado.
- Especificação de Cenários : o Para cada funcionalidade, são definidos cenários de comportamento que descrevem como o sistema deve responder a diferentes situações. Esses cenários são escritos em linguagem natural e seguem o padrão “Dado- Quando-Então”.
- Automação e Desenvolvimento : o Os cenários são vinculados a testes automatizados. A equipe desenvolve a funcionalidade, executando testes para garantir que o comportamento atenda às especificações.
- Execução e Revisão Contínua : o Conforme o desenvolvimento avança, os cenários de BDD são executados continuamente, garantindo que o comportamento esperado seja mantido. A equipe revisa e ajusta os cenários conforme necessário. Exemplo Completo de BDD com Cucumber e Java Imagine que estamos desenvolvendo uma funcionalidade de login. Aqui está um exemplo de como o processo de BDD seria com Cucumber e Java: Cenário em Gherkin: gherkin Feature: Login no Sistema Scenario: Login com credenciais corretas Dado que o usuário está na página de login Quando ele insere seu nome de usuário e senha corretos Então ele deve ser redirecionado para a página inicial do sistema
public void redirecionar_para_pagina_inicial() { // Código para verificar o redirecionamento para a página inicial } @Então("ele deve ver uma mensagem de erro {string}") public void exibir_mensagem_de_erro(String mensagem) { // Código para verificar a mensagem de erro } } Conclusão O Behavior-Driven Development (BDD) é uma abordagem poderosa para garantir que o desenvolvimento esteja focado em comportamentos que realmente trazem valor ao cliente. Ele facilita a comunicação entre equipes técnicas e não técnicas, melhora a documentação e incentiva a automação de testes. No entanto, é importante equilibrar a criação de cenários detalhados com o desenvolvimento das funcionalidades principais, evitando que o processo de especificação se torne um gargalo. Quando implementado de forma eficaz, o BDD ajuda a criar software mais robusto, confiável e alinhado com as necessidades do cliente.
5. Testes de Caixa-Preta e Caixa-Branca
Os Testes de Caixa-Preta e Caixa-Branca são abordagens amplamente usadas no teste de software. Ambos têm o objetivo de garantir que o software atenda aos requisitos funcionais e não funcionais, mas diferem significativamente em termos de foco e abordagem.
1. Teste de Caixa-Preta (Black-Box Testing) - Definição : O teste de caixa-preta é uma abordagem onde o testador avalia a funcionalidade do software sem conhecer o código ou a estrutura interna. O teste foca nas entradas e saídas do sistema, verificando se ele cumpre os requisitos e produz os resultados esperados. - Objetivo : Validar o comportamento do software do ponto de vista do usuário final, garantindo que o sistema atenda aos requisitos especificados e lida corretamente com diferentes entradas. - Abordagens Comuns :
o Teste Funcional : Avalia se o sistema realiza as funções esperadas, de acordo com os requisitos. o Teste de Interface : Verifica se os módulos e componentes do sistema se comunicam corretamente. o Teste de Requisitos : Assegura que o software atenda aos requisitos do cliente, testando entradas válidas e inválidas.
- Técnicas de Teste de Caixa-Preta : o Particionamento de Equivalência : Divide as entradas possíveis em classes de equivalência. Cada classe representa um conjunto de dados com comportamento esperado similar, e apenas uma amostra de cada classe é testada. o Análise de Valor Limite : Testa as entradas nas bordas das classes de equivalência para capturar potenciais defeitos. o Tabela de Decisão : Define as combinações de entradas e suas respectivas saídas, ajudando a garantir que todas as condições sejam cobertas. o Teste de Transição de Estado : Avalia como o sistema responde a mudanças de estado, considerando entradas e ações específicas que provocam transições entre estados.
- Vantagens : o Perspectiva do Usuário : Testa o sistema do ponto de vista do usuário, validando se ele cumpre os requisitos e funciona como esperado. o Aplicável a Diversos Níveis de Teste : Pode ser usado para testes de unidade, integração, sistema e aceitação. o Facilidade de Execução : Como não requer conhecimento do código, pode ser realizado por testadores sem experiência técnica profunda.
- Desvantagens : o Cobertura de Código Limitada : Como o teste é baseado nas entradas e saídas, ele não revela falhas na lógica interna. o Dependência de Requisitos : A eficácia do teste depende da qualidade dos requisitos e especificações fornecidos.
- Exemplo de Teste de Caixa-Preta : o Suponha uma função de transferência bancária que permite transferir até R$10.000,00. Para testar, utiliza-se o particionamento de equivalência, testando valores dentro e fora do limite, como R$5.000,00 (dentro do limite) e R$15.000,00 (fora do limite).
