SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.
SlideShare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.
Successfully reported this slideshow.
Activate your 30 day free trial to unlock unlimited reading.
Palestra apresentada dia 10/11/2012 no Rio Agile Talks (@rioagile) mostrando a importância do Agile Testing e das visões que mudam sobre modelos, como o quadrande de Brian Merick que pode ser mudado/atualizado pelo novo uadrante proposto por Elisabeth Hendrickson, mas onde uma coida não muda: a pirâmide de automação de teste
Palestra apresentada dia 10/11/2012 no Rio Agile Talks (@rioagile) mostrando a importância do Agile Testing e das visões que mudam sobre modelos, como o quadrande de Brian Merick que pode ser mudado/atualizado pelo novo uadrante proposto por Elisabeth Hendrickson, mas onde uma coida não muda: a pirâmide de automação de teste
1.
Todas as abordagens de teste
dentro do ágil!
@eliasnogueira
2.
Elias Nogueira
Tester, professor
http://about.me/eliasnogueira
@eliasnogueira
TDC - The Developers Conference
TestDay
Jenkins User Conference – São Paulo
6.
Agile Testing
Agile Testing é uma prática de Teste de
Software que segue os princípios do
desenvolvimento ágil
7.
Agile Testing
Feedback contínuo
Entrega de valor ao cliente
Comunicação face-to-face
Coragem
Simplicidade
Resposta a mudanças
Auto-organização
Foco em pessoas
9.
Testadores hoje
Não sabem o que é Ágil
Não sabem programar
O desenvolvedor é seu maior inimigo
Programador frustrado ou querendo ser BA
Não querem “passar trabalho”
10.
Separação clara dos papéis
Desenvolvedores ágeis são “test infected”
Agile Testers e Desenvolvedores colaboram
Agile Testers colaboram com o usuário
TODO O TIME é responsável por teste!
Todos devem entender do negócio
AUTOMATIZAM!!!
13.
Inicio da entrada da qualidade no produto
Tem um suporte de refatoração
É a base de uma suíte de automação
TODO O TIME é responsável por teste!
Todos devem entender do negócio
14.
Build Tools
• Judson/Jenkins
Unit Test Tools
• xUnit
• Mocking
15.
Testar os serviços da aplicação sem UI
Preenche o gap entre Unit x UI
Descrita de uma forma clara para o cliente
Tanto tester quanto dev podem criar
Podemos referencia-lo como “integração”
• API Test
• Integration Test
• Component Test
16.
BDD Tools
• Cucumber
• Jbehave
• SpecFlow
Unit Test Tools
• xUnit
Fixture Tools
• Fitnesse
17.
Teste da UI / E2E
Focar em smoke tests
Mais caro e mais frágil
Desenvolvido no final do ‘done; de teste
Usualmente fácil para testadores ágeis
20.
TDD – Test Driven Development
Pequeno mal entendido
Sou pago pra desenvolver, não testar
“Done” é quando eu dou checkin
Todos conhecem o código
O projeto é curto
Não há cliente
21.
BDD – Behavior Driven Development
BDD pode ser visto como uma técnica
de desenvolvimento ágil que encoraja
colaboração entre os
desenvolvedores, analistas, QA e o
pessoal não técnico (stackeholders)
para o sucesso de um projeto
Éder Ignatowicz (@ederig)
22.
BDD – Behavior Driven Development
BDD pode ser visto como uma técnica
de desenvolvimento ágil que encoraja
colaboração entre os
desenvolvedores, analistas, QA e o
pessoal não técnico (stackeholders)
para o sucesso de um projeto
23.
BDD – Behavior Driven Development
O suficiente é o suficiente
Entregar valor para os stackholders
Tudo é comportamento
24.
BDD – Behavior Driven Development
User Story
Feature: <description of the feature>
As a <user/actor>
I want <goal to be achieved>
so that <the reason you want to achieve the goal>
Funcionalidade: <descrição da funcionalidade>
Como um <usuário/ator>
Eu quero <meta a ser alcançada>
De modo que <a razão para alcançar a meta>
25.
BDD – Behavior Driven Development
Acceptance Criteria
Scenario: <description of the test>
Given <a known state>
When <an event occurs>
Then <then this should happen>
Cenário: <descrição do teste>
Dado <um estado conhecido>
Quando <um determinado evento ocorre>
Então <isso deve ocorrer>
26.
BDD – Behavior Driven Development
Funcionalidade: Leitor de tipos de Triângulo
Para conhecer o tipo de um triângulo
Como um aluno da matemática
Eu quero informar os tamanhos do lado de um triângulo e saber qual seu tipo
NARRATIVA
Um triângulo com todos os lados iguais é chamado Equilátero
Um triângulo com dois lados iguais é chamado Isósceles
Um triângulo com todos os lados diferentes é chamado Escaleno
FORA DE ESCOPO
- Validar triângulos inválidos
- Exibir o triangulo graficamente
- Validação de entrada de dados do usuário
http://www.bugbang.com.br/entendendo-bdd-com-cucumber-parte-i/
27.
BDD – Behavior Driven Development
Cenário: Consultando um triangulo Escaleno
Dado que eu estou na página de consulta de triângulos
Quando quando eu informo os lados do triangulo
| lado1 | lado 2 | lado 3 |
| 3 | 4 | 5 |
Então o sistema informa que o triangulo é “Escaleno”
28.
ATDD – Acceptance Test Drive Development
ATDD é uma prática onde todo o
time, colaborativamente, discute
critérios de aceitação através de
exemplos antes de começar o
desenvolvimento. Também garante
que todos tenham a mesma definição
do done.
30.
ATDD – Acceptance Test Drive Development
Exemplo
Os usuários agora precisam utilizar senhas seguras
(string de, no mínimo, 6 caracteres com pelo menos
uma letra, um número e um símbolo)
31.
ATDD – Acceptance Test Drive Development
Discutir o requisito
Durante uma reunião de planejamento
O que acontece se o usuário inserir uma senha não segura?
E se o usuário colocar um espaço?
Como fica as contas já existentes?
32.
ATDD – Acceptance Test Drive Development
Destilar em um formato amigável
Pensando em um formato para ferramenta
Teste: Validar senhas válidas e inválidas
Ação Argumento
O teste deve ser válido p@ssw0rd
O teste deve ser válido @@@000dd
O teste deve ser válido p@ss w0rd
O teste deve ser inválido password
O teste deve ser inválido p@ss3
O teste deve ser inválido passw0rd
O teste deve ser inválido @@@000
33.
ATDD – Acceptance Test Drive Development
Desenvolver o código
Implementação em qualquer formato
public class ValidateLoginPage {
WebDriver driver;
public String loginValidation(String username, String password) {
driver.findElement(By.id(“user”)).sendKeys(username);
driver.findElement(By.id(“passwd”).sendKeys(password);
driver.findElement(By.id(“submit”).click();
String result = driver.findElement(By.cssSelector(“result”)).getText()
}
}
34.
ATDD – Acceptance Test Drive Development
Desenvolver o código
Implementação em qualquer formato
public class TestLogin {
WebDriver driver = new FirefoxDriver();
@Test (dataProvider = ”data")
public String testAllScenarios (String username, String password, String
result) {
ValidateLoginPage testLogin = new ValidationLoginPage(driver);
String result = testLogin.loginValidation(username, password);
Assert.assertEquals(expected, result);
}
@DataProvider(name = ”data”)
public Object[][] createData() {
Object[][] obj ={{”fred","p@ssw0rd",”Valid Password"},
{{”jack","passw0rd",”Invalid Password!”}
}
35.
ATDD – Acceptance Test Drive Development
Demostrar o teste
Execução do teste em ambiente controlado
37.
Testes Exploratórios
Simultâneamente ....
... aprender sobre o software
... desenvolver mais testes
... executar testes
Usando o feedback do último teste para
executar o próximo!
38.
Todos os testes unitários Essa user story de
Passaram com sucesso! segurança passou nos meus
A build está OK! teste de aceitação!
Alguém já se deu conta que o
usuário pode colocar ele mesmo
como administrador?
39.
SBT - Session Based Testing
Charter
Explorar áreas/features [com
recursos, condições , restrições] para descobrir
informação
Explorar o site em diversos browsers e
configurações para descobrir riscos
relacionados a configurações não suportadas
40.
SBT - Session Based Testing
Charter
Descrição e objetivo
Tempo
Área de Concentração
Setup
Observações
Bugs