Testes de Aceitação

Prévia do material em texto

Testes de Aceitação
Prof. D.Sc. Victor T. Sarinho
vsarinho@gmail.com
vsarinho@uefs.br
Tópicos
• Conceitos Iniciais
• Testes de Aceitação
• Frameworks de Testes de Aceitação
• Behavior Driven Development (BDD)
• Conclusões
• Exercício Gamificado
• Referências
Produção de Software (Visão Cliente)
Produção de Software (Visão Cliente)
Produção 
de 
Software 
(Visão 
Cliente)
Produção de Softwares 
(Visão Desenvolvedor)
Produção de Softwares 
(Visão Desenvolvedor)
Interação Cliente-Desenvolvedor
Interação Cliente-Desenvolvedor
Interação Cliente-Desenvolvedor
“Podemos dizer o que pensamos que é certo, ou o 
que nos pensamos que você acha que é certo?”
Solução???
Uma Sugestão!!
Mas onde está o Software 
para Testar???
Onde???
Solução!!!
O que é Aceitação?
• Contrato de comum acordo entre 
várias partes;
• Resignação de um indivíduo 
perante uma realidade adversa; (fonte: 
Wikipédia)
O que são Testes de Aceitação?
• Testes que verificam se o sistema 
atende as necessidades do cliente 
(usuário)
– Desenvolvedor não consegue prever 
como o usuário realmente usará um 
software
– Verificam se o sistema vai ser aceito pelo 
cliente
O que são Testes de Aceitação?
• Testes de aceitação podem ser:
– Um test-drive informal e rápido
– Testes mais planejados, executados ao 
longo de um período predeterminado
Tipos de Testes de Aceitação
• Testes de Aceitação do Usuário
– Realizados pelos trabalhadores 
diretamente no “chão de fábrica”
• Operational Acceptance Testing (OAT)
– Checagem para garantir que processos 
e procedimentos estão no lugar correto 
para que o sistema possa começar a 
funcionar
Tipos de Testes de Aceitação
• Testes de Aceitação do Usuário:
Tipos de Testes 
de Aceitação
• Operational 
Acceptance 
Testing 
(OAT):
Tipos de Testes de Aceitação
• Contratos e Regulação
– Sistema é checado contra critérios de 
aceitação em contrato, antes da aceitação final 
do sistema
– Sistema é testado para garantir que ele segue 
padrões governamentais, legais e de 
segurança
• Testes Alpha e Beta (de Campo)
– Teste final realizado pela equipe interna antes 
de ser liberado para o mercado
– Teste realizado por um grupo de consumidores 
selecionados
Pq Testes de Aceitação?
• MITO: Não é possível testar até que o sistema 
exista…
• QUESTÃO: Não posso verificar as regras do 
negócio antes de produzi-lo na pratica?
• FATOS:
– Testar é muito mais do que apenas “ver o que vai 
acontecer” ou “apenas executar casos de 
teste”!
– Documentos de requisitos podem e devem ser 
testados em relação aos objetivos do negócio ou 
projeto para assegurar completude e correção.
Pq Testes de Aceitação?
• MITO: Desenvolvedores devem pensar nos 
requisitos apenas no início do desenvolvimento, e 
se preocupar com testes apenas no final…
• QUESTÃO: Não posso planejar previamente como o 
sistema vai ser testado?
• FATOS:
– Testadores envolvidos durante a análise de requisitos é uma 
das melhores formas de se assegurar requisitos de boa 
qualidade
– Trocas tardias nos requisitos causam impacto nos testes
– Fundamental envolver usuários nos requisitos e nos testes!
Pq Testes de Aceitação?
• MITO: Requisitos são utilizados no teste, mas não o 
contrário…
• QUESTÃO: Testes não eliminam problemas em 
requisitos mal projetados?
• FATOS:
– Você não testa requisitos, mas testa a partir deles!
– É fácil escrever requisitos vagos ou ambíguos, que 
parecem estar ok. 
– Uma boa engenharia de requisitos produz melhores 
testes, e uma boa análise de testes melhora os 
requisitos!
Pq Testes de Aceitação?
• MITO: Se escrever testes é difícil, isto é somente 
um problema dos testadores…
• QUESTÃO: Testador agora sabe mais sobre o 
sistema do que o resto da equipe?
• FATOS:
– Nem todos os requisitos são criados de acordo com a 
mesma perspectiva do testador. 
• Para alguns dos requisitos fica fácil definir o teste, para outros um 
verdadeiro pesadelo!
– Especificar requisitos não funcionais testáveis tais 
como usabilidade ou desempenho é difícil
Pq Testes de Aceitação?
• MITO: Os testadores não precisam dos requisitos…
• QUESTÃO: Se uma especificação de requisitos representa 
o oráculo para o plano de testes, do que os testadores 
precisam então?
• FATOS:
– O sistema deve apoiar o negócio a atingir um objetivo, 
então o que o sistema realmente faz deve ser 
comparado com este objetivo.
– Sim, testadores precisam dos requisitos, caso contrário, 
você poderia argumentar que o que vem sendo 
executado não é realmente um teste!
Quando Executar Testes de 
Aceitação?
Sub-system
testing
Module
testing
Unit
testing
System
testing
Acceptance
testing
Component
testing
Integration testing User
testing
Quando Executar Testes de 
Aceitação?
Requirements
specification
System
specification
System
design
Detailed
design
Module and
unit code
and tess
Sub-system
integration
test plan
System
integration
test plan
Acceptance
test plan
Service Acceptancetest
System
integration test
Sub-system
integration test
Modelo V de Desenvolvimento:
Quando Executar Testes de 
Aceitação?
Modelo Ágil de Desenvolvimento:
Quando Executar Testes de 
Aceitação?
Como Executar Testes de 
Aceitação?
• Frameworks de Testes de Aceitação:
● Selenium
● FitNesse
● ItsNat
● Ranorex
● Robot Framework
● Test Automation FX
● Watir
● ...
Selenium
Selenium
public static void main(String[] args) {
 WebDriver driver; ...
 driver = new FirefoxDriver();
 String baseUrl = "http://newtours.demoaut.com";
 String expectedTitle = "Welcome: Mercury Tours";
 String actualTitle = "";
 driver.get(baseUrl);
 actualTitle = driver.getTitle();
 
 if (actualTitle.contentEquals(expectedTitle)){
 System.out.println("Test Passed!");
 } else {
 System.out.println("Test Failed");
 }
 driver.close();
 System.exit(0);
 }
Selenium
package newproject;
import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.firefox.FirefoxDriver;
public class PG2 {
 public static void main(String[] args) {
 System.setProperty("webdriver.firefox.marionette","C:\\geckodriver.exe");
 WebDriver driver = new FirefoxDriver();
 String baseUrl = "http://www.facebook.com";
 String tagName = "";
 
 driver.get(baseUrl);
 tagName = driver.findElement(By.id("email")).getTagName();
 System.out.println(tagName);
 driver.close();
 System.exit(0);
 }
}
Selenium
Selenium
Selenium
FitNesse
FitNesse
FitNesse
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
• Extensão do Desenvolvimento Orientado a Testes 
(TDD)
 Histórias ao invés de apenas testes codificados
• Baseado em uma linguagem de script simples e 
específica do domínio
 Formulário Gherkin: 
https://docs.cucumber.io/gherkin/
 Ferramenta colaborativa: https://hiptest.com/
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Behavior Driven Development 
(BDD)
Cucumber
Cucumber
Cucumber
jBehave
jBehave
jBehave
jBehave
Conclusão
Conclusão
Conclusão
Extra
 Acceptance Test Driven Development (ATDD):
https://www.youtube.com/watch?v=uPgTvZO5la
Y
Exercício Gamificado
 The BDD Game:
 Equipes receberão uma história e 4 possíveis 
cenários referentes a mesma;
 Afirmativas para Given, When e Then serão 
fornecidas para serem encaixadas em cada 
cenário;
 Equipes são desafiadas para conseguirem 
formar em menos tempo as sentenças de cada 
cenário de forma correta;
 Ganha a equipe que conseguir formar cenários 
corretos antes das demais concorrentes.
Referências
• Somerville, I. Capítulos sobre Verificação, 
Validação e Testes de Software
• http://en.wikipedia.org/wiki/Acceptance_testin
g
• Revisão e Inspeção de Software, COS722 
- Engenharia de Software Orientado a 
Objetos, Guilherme Horta Travassos, 
www.cos.ufrj.br/~ght
• https://docs.cucumber.io/gherkin/reference/
Testes de Aceitação
Prof. D.Sc. Victor T. Sarinho
vsarinho@gmail.com
vsarinho@uefs.br