Agile Testing, por Carolina Borim

Post on 01-Dec-2014

370 views 2 download

description

Nessa palestra, a intenção é fazer uma descrição temporal da evolução do teste de software até chegarmos no conceito de Agile Testing. Além disso, apresenta-se as características esperadas de um agile tester, bem como ferramentas e metodologias para o aprimoramento da Qualidade na entrega de produtos de software.

Transcript of Agile Testing, por Carolina Borim

Agile TestingA Qualidade de Software no Desenvolvimento Agile

C a r o l i n a B o r i m

Agenda

Quem sou eu? O que é Qualidade? Por que Testar? Uma perspectiva - Waterfall O Manifesto Ágil Uma Nova Perspectiva – Agile Tester O Que Mudou Na Minha Vida? E o Software Livre? Contatos

2

3

Quem sou eu?

4

O QUE É QUALIDADE?

5

Se tratando de Software

O que é qualidade?

● Qualidade de um produto é dada pela diferença entre as características observadas e as características que foram especifcadas.

● Pontos de vista diferentes != diferentes requisitos

● Qualidade não pode ser uma entidade abstrata

● Objetivo concreto

● Conhecer com precisão o objetivo que se pretende alcançar

6

O que é qualidade?

Satisfazer o cliente

Mas basicamente

● Número e severidade de defeitos residuais do processo de testes é aceitável

● O software é entregue dentro do prazo e custos

● Atende às expectativas

● Foi construído de maneira que possa ser mantido de forma efciente

9

Por que testar?Testar software é simples?

Por que testar?

90% dos sistemas são liberados com defeitoMódulos não operam corretamente quando combinados

Programas tão difíceis de usar, que são descartados

Programas que simplesmente param de funcionar

10

O que é testar?

Testar – executar de forma controlada e avaliar o comportamento baseado no especifcado

Quando testes são realizados dentro das melhores práticas, contribui-se também para a melhoria da qualidade e redução de custos

11

Por que testar?

Importância de se investir em testes:

– Reduzir custos

– Ao investir em testes, investimos na prevenção de defeitos

–Validamos se a aplicação está em conformidade com as necessidades e expectativas do cliente

12

Quais as consequências disso?

Maior satisfação do usuário

Maior redução das incertezas que cercam o software

Redução no custo de manutenção em produção

Mais confança no produto

Mais conhecimento do negócio

13

UMA PERSPECTIVA

14

O processo de desenvolvimento tradicional - Waterfall

O Modelo Cascata (Waterfall)

15

16

17

O manifesto ágilSuas principais características

O Manifesto

“Estamos descobrindo maneiras melhores de desenvolver software fazendo-o nós mesmos e ajudando outros a fazê-lo. Através deste trabalho, passamos a valorizar:”

■ Indivíduos e interação entre eles mais que processos e ferramentas

■ Software em funcionamento mais que documentação abrangente

■ Colaboração com o cliente mais que negociação de contratos

■ Responder a mudanças mais que seguir um plano

18

O Manifesto

■ Implementar mudanças de forma mais efciente – documentação viva;

■ Produtos com qualidade elevada – expectativas claras;

■ Menos retrabalho – colaboração;

■ Melhor alinhamento das atividades dos diferentes papéis no projeto – fuxo mais regular.

19

collaboration

20

21

Uma nova perspectivaAgile Tester

Testador Ágil

Testadores ágeis são muitas vezes conhecidos como analistas de qualidade (QAs), engenheiros de software em testes, engenheiros de testes, lideres de qualidade, entre outras varianças.

22

Uma ideia

“Desenvolvimento de software não é uma atividade altamente previsível nem repetitiva, mas sim uma atividade empírica. Agile enfatiza o controle do processo empírico.” – Paulo Caroli.

23

Como trabalham?

Defensor do cliente

Defensor do produto

–Kick – of & Desck check

Trocando sempre de função

Intolerante a falhas

Constante interação com usuário

24

Habilidades

Desenvolvimento de Software – o que e quando automatizar

Senso Crítico – Identifcar o atual nível de qualidade

Foco no usuário – identifcar causas de problemas

Clara comunicação – trabalhar em conjunto com todos os membros do time

Generalista – observar o que testar e quando testar

25

Habilidades

Responsabilidades compartilhadas

Sem papél específco

Foco na entrega de valor

26

Responsabilidade

Não devem ser responsáveis apenas por aferir a qualidade, mas também por ensinar aos demais membros do time sobre a cultura de qualidade e garantir entregas

Lembre-se: qualidade não é algo fabricado ou criado após algumas linhas de código

Lembrar também: Did the right thing & did the thing right?

27

Mas e o tal BDD?

BDD Behaviour Driven Development – reframming do TDD

É implementar uma aplicação a partir da descrição do seu comportamento sob a perspectiva do Stakeholder

Entender o mundo do stakeholder

Escrever software que interessa – que tem valor!

28

Princípios

Enough is enough – o sufciente, adivinhe? É sufciente!

Entregar valor ao stakeholder

Tudo é comportamento – podemos usar sempre o mesmo pensamento e a mesma construção de linguagem para descrever o comportamento. Tanto em nivel de código quanto em nível de aplicação

29

Princípios

“ BDD stories and scenarios are specifcally designed to support this model of working and in particular to be both easy to automate and clearly understandable by their stakeholders “ The R-Spec Book

30

31

O que mudou na minha vida?

E o Software Livre?.

Ferramentas & Tecnologias

32

Cucumber

Junit

Rspec

Selenium WebDriver

Jmetter

Divirta-se!!

33

34

Missões ambiciosasExigem ideias disruptivas

Obrigada!Carolina Borim

cborim@thoughtworks.com

Skype: carolinaborimFacebook: Carolina BorimTwitter: @CarolinaBorim