Introdução a teste de Software

Prévia do material em texto

Introdução a Teste de Software 
ROBSON GODOI 
(Baseado no material da TI.Exames) 
Recife, 07 de março de 2017 
 O que é testar? 
Encontramos na literatura algumas definições sobre que é a atividade de 
testar: 
 
▪ “Testar é analisar um programa com a intenção de descobrir erros 
e defeitos.” (Myers) 
 
▪ Testar é exercitar ou simular a operação de um programa ou sistema. 
 
▪ Testar é confiar que um sistema faz o que se espera que ele faça e não 
faz o que se espera que não faça. 
 
▪ Testar é medir a qualidade e funcionalidade de um sistema. 
 
▪ “O teste de programas pode ser usado para mostrar a presença de 
defeitos, mas nunca para mostrar a sua ausência.” (Dijkstra) 
Qual o objetivo dos testes? 
O objetivo principal dos testes é reduzir a probabilidade da 
ocorrência de um defeito quando o software estiver em produção, 
minimizando os riscos para o negócio e garantindo que as 
necessidades do cliente estão sendo atendidas 
“Uma pessoa inteligente resolve um problema. Uma pessoa sábia evitá-o”. [Einsten] 
 Erro, Defeito e Falha 
▪ Erro (error): é uma ação humana que produz um resultado 
incorreto. 
▪ Defeito (fault): A manifestação de um erro no software 
▪ Também conhecido como Bug 
▪ Se executado, o defeito pode causar uma falha 
▪ Falha (Failure): diferença indesejável entre o observado e o 
esperado. (Defeito encontrado) 
Falha é um evento; defeito é um estado do 
software, causado por um erro. 
Uma 
pessoa 
comete um 
erro ... 
… que cria 
um defeito 
no 
software… 
… que pode 
causar uma 
falha na 
operação 
 Erro, Defeito e Falha 
 Confiabilidade do Software x Defeit 
Confiabilidade do Software é a probabilidade que o software 
não causará uma falha no sistema por um tempo especificado, 
sob condições determinadas. 
▪ Pode existir um software livre de defeitos? 
▪ Por existir softwares confiáveis mas que possuem 
defeitos? 
 Confiabilidade do Software 
Confiabilidade 
Tempo 
Nenhuma falha encontrada = confiança 
Defeito encontrado 
▪ Softwares são escritos por humanos 
▪ As pessoas não conhecem e não dominam tudo; 
▪ As pessoas tem habilidades, mas não são perfeitas; 
▪ As pessoas cometem erros; 
 
▪ Softwares são desenvolvidos sob crescente pressão 
para entregá-los em prazos rigorosos 
▪ Sem tempo para checar as atividades realizadas; 
▪ Sistemas podem estar incompletos. 
 
▪ Se você já escreveu softwares.... 
Porque defeitos ocorrem no software? 
 Vale a pena investir em testes? 
▪ Reduz em 70% o índice de re-trabalho de correção de falhas em 
produção 
▪ Reduz em 50% do tempo de homologação de uma nova versão 
▪ Aumenta em 90% o índice de falhas detectadas antes da produção 
▪ Diminui em 95% os Abends em produção 
▪ Aumenta a abrangência dos testes 
Realidade atual do mercado de software 
▪ Complexidade dos softwares 
▪ Complexidade das equipes 
▪ Cronograma apertado para 
Desenvolvimento 
▪ Mercado/Cliente/Usuários mais exigentes 
▪ Menos tolerância a falhas 
▪ Menos tolerância aos atrasos das entregas 
Precisamos construir softwares 
MELHORES e mais BARATOS, de forma 
mais RÁPIDA 
 O custo da não-qualidade 
Estatísticas de mercado apontam que para cada R$ 1,00 investido 
no desenvolvimento e manutenção de software, entre R$ 2,00 e 
R$ 3,00 são gastos com re-trabalho. 
 
▪ Não se sabe o percentual de re-trabalho e quanto isso custa 
▪ O software ou parte dele tem de ser refeito 
▪ Não se sabe, através de métricas claras e precisas, quais são as principais 
áreas de produção que geram re-trabalho 
▪ A empresa não toma iniciativas para corrigir os problemas nas áreas de 
produção ineficientes 
 
Existem alguns tipos de sistemas onde: 
 
▪ As falhas causam prejuízos diretos, ou 
▪ As falhas causam a perda de confiança do 
público (usuários) 
 O custo da falha 
 Por que testar um software? 
Todo o software visa atender a uma demanda: 
 
▪ Por questão de Qualidade 
▪ Por questão de Economia 
▪ Por questão de Segurança 
▪ Por questão de Confiabilidade 
▪ Por questão de Negócio 
 O custo da correção dos defeitos 
C
u
s
to
 d
a
 c
o
rr
e
ç
ã
o
 d
o
 d
e
fe
it
o
 
Fases do Desenvolvimento de Software 
Análise Especificação Construção Testes Produção 
A regra 10 de Myers indica que o custo da correção de um defeito 
tende a ser cada vez maior quanto mais tarde ele for descoberto. 
Defeitos encontrados nas fases iniciais da etapa de desenvolvimento do 
software são mais baratos de serem corrigidos do que aqueles 
encontrados na produção. 
 
Regra 10 de Myers 
 O custo da correção dos defeitos 
Progressão do tipo dez, cem, mil, de acordo com Rex Black 
Desenho 
Construção 
Produção 
100 
1000 
10 
 Porque testar é necessário? 
▪ Porque é provável que o software possua defeitos; 
▪ Para descobrir a confiabilidade do software; 
▪ Porque falhas podem custar muito caro; 
▪ Demonstrar as conformidades com os requisitos; 
▪ Para assegurar que as necessidades dos usuários estejam sendo 
atendidas; 
▪ Para reduzir custos; 
▪ Para avaliar a qualidade do software; 
 
 
Não devemos testar: 
 
▪ Para provar que o software não tem defeitos; 
▪ Apenas porque os testes estão incluídos no plano de projeto; 
Muitos Defeitos 
 
 
Baixa 
Qualidade do 
software 
Poucos Defeitos 
 
 
Alta 
 Avaliando a qualidade do software 
Alta 
Muitos Defeitos 
 
 
Baixa 
Qualidade do 
software 
Poucos 
Defeitos 
Q
u
a
li
d
a
d
e
 d
o
 t
e
s
te
 
Baixa 
Alta 
Poucos 
Defeitos 
Poucos 
Defeitos 
 Avaliando a qualidade do software 
 A abordagem tradicional dos testes 
▪ Mostrar que o sistema: 
▪ Faz o que deve fazer 
▪ Não faz o que não deve 
fazer 
META: Mostrar que o sistema funciona 
 
CRITÉRIO DE SUCESSO: Sistema em funcionamento correto 
RESULTADO: Sistema com defeitos 
 A melhor abordagem para o testes 
META: Encontrar defeitos 
 
CRITÉRIO DE SUCESSO: Sistema com falhas 
RESULTADO: Sistema com menos defeitos 
▪ Mostrar que o sistema: 
▪ Faz o que deve fazer 
▪ Não faz o que não deve 
fazer 
 O paradoxo do teste 
A proposta do teste é encontrar defeitos. 
 Encontrado defeitos a confiança é “destruída”. 
 
 
a)Proposta do teste: “destruir” a confiança do software 
b)Proposta do teste: Estabelecer a confiança 
A melhor maneira de estabelecer a confiança é tentar destruí-la. 
 Por que as empresas não testam? 
Teste não é uma atividade trivial porque: 
▪ Software é complexo 
▪ Software é intangível 
▪ Software é altamente modificável 
▪ Teste lida com pessoas 
▪ Há desconhecimento sobre a relação custo x 
benefício 
▪ Há falta de profissionais especializados 
▪ Há dificuldade em implantar um processo de teste 
▪ Há desconhecimento das técnicas adequadas de 
teste 
▪ Há desconhecimento de como planejar as atividades 
▪ Só se preocupam com testes no final do projeto 
 Conceitos iniciais 
Para que consigamos entender os conteúdos seguintes, é 
importante termos um perfeito entendimento dos conceitos 
abaixo: 
▪ Erro: engano, alguma coisa feita por humanos. 
▪ Defeito: o resultado de um erro. 
▪ Falha: diferença indesejável entre o observado e o esperado. 
▪ Depurar: descobrir e corrigir erros ou defeitos no código. 
▪ Testar: descobrir falhas através da execução do sistema. 
▪ Requisitos: regras de negócio do sistema. 
▪ Testware: todo o conjunto de documentação gerado pelo 
processo de teste de software. 
 Classificaçãodos Testes 
Os tipos e técnicas de testes podem ser classificados em: 
Caixa branca: técnica de teste que avalia o comportamento 
interno do componente de software. Trabalha diretamente sobre o 
código-fonte. 
Caixa preta: são conduzidos na interface do software, sem preocupação 
com a estrutura lógica interna do software. 
 Mitos sobre testes 
Alguns mitos e inverdades sobre a atividade de testes: 
 
▪ O testador é inimigo do desenvolvedor 
▪ A equipe pode ser formada pelos desenvolvedores menos 
qualificados 
▪ Quanto estiver tudo pronto, o sistema vai para teste. 
 Visão geral de processos 
Um processo é formado por atividades inter-relacionadas com um objetivo 
especifico. Possui entradas de dados e produtos, para, através da 
identificação dos recursos necessários ao processo, transformar estas 
entradas nos objetivos desejados. 
Tarefa 
Regras 
Funções 
Regras 
Funções Funções 
Saídas Entradas 
Tarefa Tarefa 
Regras 
 Ciclo PDCA 
A P 
C D 
Melhoria contínua 
Passo-a-passo 
Aperfeiçoament
o contínuo da 
qualidade 
Plan (Planejar) 
Do (Executar) 
Check (Verificar) 
Act (Agir) 
Consolidação do nível alçado 
 
 
Escala de tempo 
N
ív
e
l 
d
e
 M
a
tu
ri
d
a
d
e
 
 Introdução ao processo de teste 
Cenário atual: 
• Testes são realizados como uma etapa do processo de desenvolvimento 
• Pressões sobre prazos fazem com que o esforço de testes seja reduzido 
ou até mesmo eliminado 
• O objetivo é assegurar que as especificações foram construídas 
• Testes são realizados pelos desenvolvedores ou analistas de sistema 
• Testes são realizados ao final do desenvolvimento 
• Não há garantias de que o software foi testado adequadamente 
 Introdução ao processo de teste 
Cenário desejável: 
• O teste é tratado como um processo independente, porém altamente 
integrado ao processo de desenvolvimento 
• Os testes são iniciados paralelamente ao processo de desenvolvimento 
• Testes realizados por equipes altamente qualificadas e especializadas 
Ciclo de Testes 
A 
A B 
 
Inicio dos 
testes 
 
Inicio do 
desenvolvimento 
B 
Requisitos 
A B 
Ciclo de Desenvolvimento 
 Objetivo do processo de teste 
Permitir o teste de softwares usando pessoal técnico 
qualificado, ferramentas adequadas e base em metodologia 
aderente ao processo de desenvolvimento da organização 
 Verificação e Validação 
O processo de teste é dividido em duas grandes áreas: 
Verificação 
Responde se o sistema 
foi construído 
corretamente 
Validação 
Responde se 
construímos o sistema 
correto 
 O modelo “V” 
A estrutura do modelo V é uma aproximação do processo de testes que pode ser 
integrada com todo a processo de desenvolvimento. O modelo V representa o 
desenvolvimento versus o teste. 
 
O modelo V focaliza-se em testar durante todo o ciclo de desenvolvimento para 
conseguir uma detecção adiantada dos erros. 
 Modelo do ciclo de processo de teste 
O ciclo de vida do processo de teste é formado por diversas etapas. 
Apresentamos aqui um modelo de macro atividades. Existem outros modelos de 
ciclo de vida de processo de teste, como por exemplo o Test Management 
(TMAP) ou o modelo 3P x 3E* 
Modelo 3P x 3E. Fonte: Rios, E. & Moreira, T. Teste de Software. 
 Fluxo básico de atividades 
Requisitos do 
Software 
 
Dados para Teste 
 
Software 
 
Resultados Obtidos 
 
Comparação 
Resultados 
Esperados 
Relatórios de 
Teste 
Análise sobre o 
Software 
• O software atende aos requisitos 
ou 
• O software não atende aos 
requisitos 
Planejamento do 
Teste 
 Principais envolvidos no processo de teste 
Analista de Teste Testador Usuários 
Gestor da Qualidade 
Responsável pelas ações de 
controle de qualidade dos 
produtos 
Líder do projeto de Teste 
Responsável por liderar e planejar 
o projeto de teste 
Arquiteto de Teste 
Responsável por montar e 
disponibilizar o ambiente 
de teste 
Responsável pela modelagem 
e elaboração dos casos de 
teste e scripts de teste 
Responsável pela execução 
dos casos de teste e pela 
documentação dos resultados 
Responsável pela avaliação 
e aceitação do sistema 
 Princípios gerais do teste de software 
Alguns princípios foram sugeridos ao longo dos últimos 40 anos: 
 
• Princípio 1: Teste demonstra a presença de defeitos 
• Princípio 2: Teste exaustivo é impossível 
• Princípio 3: Teste antecipado (iniciar o quanto antes) 
• Princípio 4: Agrupamento de defeitos (20/80) 
• Princípio 5: Paradoxo do Pesticida 
• Princípio 6: Teste depende do contexto 
• Princípio 7: A ilusão da ausência de erros (deve atender as necessidades dos 
usuários) 
Fonte: Certificação em Teste Foundation Level Syllabus – Versão 2007br 
Principais organizações e institutos envolvidos 
A disseminação dos processos de teste é relativamente nova no Brasil. 
Algumas organizações/institutos criados estão tendo a missão de 
profissionalizar a atividade no país. 
 
 
▪ALATS – Associação Latino Americana de Teste de Software 
 CBTS – Certificação Brasileira de Teste de Software 
▪QAI – Quality Assurance Institute 
 CSTE – Certified SoftwareTester 
▪BSTQB – Brazilian Software Testing Qualifications Board 
 CTFL – Certified Tester Foundation Level 
▪ISEB – Foundation Certificate in Software Testing 
 Certificação em teste de software 
▪Norma IEEE 829 
 Define normas e padrões ao processo de teste e qualidade do produto. 
▪ISO 9126-1 
 Define as características da qualidade do software 
 A Norma IEEE 829 
 Exercícios de revisão 
Indique se é verdadeiro ou falso: 
 
a – ( ) O testes devem ser realizados para mostrar a ausência de defeitos. 
b – ( ) Caixa branca são testes baseados em um exame rigoroso do detalhe 
procedimental. Caminhos lógicos e colaborações entre componentes são 
testadas. 
c – ( ) O processo de teste deve ser independente do processo de desenvolvimento, 
porém integrado. 
d – ( ) Verificação e Validação são técnicas de teste de software. 
e – ( ) A equipe de testes pode ser formada por desenvolvedores menos qualificados. 
f – ( ) Um processo é formado por atividades inter-relacionadas com um objetivo 
especifico. Possui entradas de dados e produtos, para, através da 
identificação dos recursos necessários ao processo, transformar estas 
entradas nos objetivos desejados. 
 Correção dos exercícios 
Indique se é verdadeiro ou falso: 
 
a – (F) O testes devem ser realizados para mostrar a ausência de defeitos. 
b – (V) Caixa branca são testes baseados em um exame rigoroso do detalhe 
procedimental. Caminhos lógicos e colaborações entre componentes são 
testadas. 
c – (V) O processo de teste deve ser independente do processo de 
desenvolvimento, porém integrado. 
d – (F) Verificação e Validação são técnicas de teste de software. 
e – (F) A equipe de testes pode ser formada por desenvolvedores menos 
qualificados. 
f – (V) Um processo é formado por atividades inter-relacionadas com um objetivo 
especifico. Possui entradas de dados e produtos, para, através da 
identificação dos recursos necessários ao processo, transformar estas 
entradas nos objetivos desejados. 
 Considerações Finais 
• Teste é um projeto - e como tal deve ser planejado 
• Teste é um projeto integrado ao projeto de desenvolvimento 
• Testar reduz riscos do negócio 
• Não dá para planejar sem saber o tamanho do seu projeto 
• O Plano de Teste é o instrumento básico de planejamento de 
projetode teste 
• Os artefatos devem estar sob gerência da configuração 
• Deve ser possível, a partir dos requisitos do negócio, rastrear-se os 
artefatos de teste 
“ In god we trust. Everything else we test…” 
Duvidas?????