Videocast Adaptworks #1 com Klaus Wuestefeld – XP, Computação Soberana e Afins

Inaugurando o nosso Videocast Adaptworks, Simone Pittner tem uma conversa bem legal com o Klaus Wuestefeld, pioneiro na adoção e evangelização de Extreme Programming no Brasil. Nessa conversa, Klaus fala sobre como anda o uso de XP pela comunidade brasileira, como é a relação do Scrum com  grandes organizações e principalmente, Klaus explica o conceito, criado por ele mesmo, de Computação Soberana.

Nenhum comentário »

Categorias deste post

Agile, Extreme Programming, Técnico, Videocasts

Introdução do Quadrante de Teste Ágil

Uma pergunta muito comum, quase sempre vinda de um profissional de testes, dento da linha ágil é: como vou testar no Scrum?
Essa pergunta geralmente é feita por falta de conhecimento em agilidade, e a resposta é que não existe fórmulas, padrões ou receitas de bolo de testar utilizando Scrum , XP, Kaban ou qualquer prática ágil para desenvolver um software.

Muitos tem sede de ter um processo, uma fórmula para trabalhar com testes em agilidade, mas isso é mais fácil do que imaginamos…
Mas antes vamos conceituar um pouco o porque disso.

 

Conceituação no modelo tradicional

No modelo que podemos chamar de tradicional temos duas abordagens distintas com algumas dimensões, além de separação clara de papéis e atividades. Enquanto parte dos profissionais de análise de negócio, arquitetura e gestão trabalhavam no desenvolvimento dos requisitos, o testador criava uma série de documentos para verificar se os requisitos estavam de acordo com o que foi pedido, mas muita coisa era perdida e o foco era (ou ainda é em algumas empresas) em pesadas documentações e checklists.
O Modelo V de Testes foi um guia por muito tempo neste ponto, trazendo quatro níveis e chamando estas etapas de Verificação: requisitos, análise, arquitetura e codificação (este compartilhado com o próximo grupo de nível).
Neste ponto os testadores também criavam os casos de teste, quando o time já estava na fase “codificação”

Quando chegava a fase em que um grupo de funcionalidades já estava apta a ser testada entramos na fase de validação, que consiste nos níveis: unidade, integração, teste a aceitação. Neste ponto começam os testes como conhecemos no modelo tradicional.

O Modelo V de testes foi utilizado por muitos como um guia para entender estes níveis e o que poderíamos fazer em cada um, e esta é a forma correta de utilizá-lo, mas remetendo sempre a termos testes no final do processo.

E como isso funciona dentro do Ágil?

 

O Quadrante de Teste Ágil

Já sabemos pelo post anterior o que é Agile Testing. Agora iremos aprender qual o guia que temos quando utilizamos práticas ágeis no projeto e queremos aplicar alguma abordagem ou técnica de teste.

O Quadrante de Teste Ágil foi criado por Brian Marick que introduziu uma série de termos para diferentes categorias de teste para alcançar diferentes propósitos através de um diagrama.

Quadrante Teste Agil

Este diagrama, dividido em quatro quadrantes reflete diferentes razões de teste. Nele já uma matriz dividindo testes que suportam o time e criticam o produto, que é dividido em foco no negócio ou foco em tecnologia.

Vale lembra desde agora que o quadrante é um guia, e não um processo!

Testes que suportam o time

Podemos dizer que os testes que suportam o time são os que ajudam os desenvolvedores, não somente testers, enquanto o produto é desenvolvido. Estes testes são mais voltados a qualidade e entendimento dos requisitos e arquitetura do que em testes como conhecemos de forma funcional.

Quadrante 1

Representa, basicamente, a principal prática de desenvolvimento ágil:  TDD – Test Driven Development.
Dentro deste quadrante temos duas práticas: teste de unidade, que valida uma pequena parte da aplicação como objetos e/ou métodos, e testes de componente que valida partes maiores da aplicação como um grupo de classes que provê o mesmo serviço. São usualmente desenvolvidos com ferramentas xUnit e medem a qualidade interna do produto.
Ao utilizar a técnica de TDD o programador pode desenvolver uma funcionalidade sem se preocupar em posteriormente alterar qualquer parte da aplicação, ajudando assim a tomar melhor decisões de arquitetura e design.
Não são destinados ao cliente, pois o cliente não irá entender os aspectos internos do desenvolvimento e não devem ser negociáveis com o cliente, pois a qualidade do código deve sempre existir e não ser negligenciada. Os testes desenvolvidos usualmente executados dentro de uma abordagem de Integração Contínua para prover um rápido feedback da qualidade do código.

Quadrante 2

Este quadrante também suporta o time de desenvolvimento, continua guiando o desenvolvimento, mas de uma maneira mais alto-nível focando mais em testes que o cliente entenda, onde este define a qualidade externa de que ele precisa.
Aqui o cliente define exemplos que serão usados para um entendimento maior do funcionamento da aplicação, e são escritos de forma com que o cliente ou papéis ligados a negócio entendam. Todo o teste executado aqui tem um foco no funcionamento do produto e alguns deles podem até mesmo ter uma pequena duplicação com alguns testes criados no Quadrante 1.
Testes testes focados no negócio também podem ser automatizados e, usualmente, a técnica de BDD – Behavior Driven Development é utilizada na escrita e execução automatizada destes exemplos.

Neste quadrante também podemos utilizar de pessoas com conhecimentos em UX para que, através de mockups e wireframes, o cliente possa validar a interface gráfica antes que o time comece a desenvolver esta camada.

Testes que criticam o produto

O termo “criticam” aqui não é apenas de forma destrutiva, mas também relacionados a melhoria. O foco é saber como iremos aprender a melhorar o produto, escrevendo, se necessário, mais critérios e exemplos.

Quadrante 3

As vezes mesmo criando diversos mecanismos para assegurar que estamos atendendo a necessidade do cliente através de critérios e/ou exemplos, pode acontecer de não atendermos realmente aquele desejo, ou mesmo o teste unitário e o teste através do BDD podem não ter um real valor.
Neste quadrante iremos realmente criticar o produto e executa-lo como um usuário real usando nosso conhecimento e intuição na utilização da aplicação. O cliente pode executar este tipo de tarefa, usualmente chamada de UAT – User Acceptance Testing, dando um feedback mais preciso, aceitando a funcionalidade, analisando possíveis novas funcionalidades. Esta ação pode ser também um dos critérios de DoD – Definition of Done de uma funcionalidade.
O ponto central deste quadrante, além do UAT, são os testes exploratórios. Utilizando esta técnica qualquer membro do time é capaz de, simultaneamente, aprender sobre a aplicação e executar mais testes, usando o feedback do último teste para a execução dos próximos e também é capaz de extrair novos critérios, sempre observando o comportamento da aplicação.

Quadrante 4

Os testes neste quadrante são os mais técnicos e criticam o produto em termos de performance, carga e segurança.
Nos dias de hoje negligenciar aspectos como performance podem tirar a vantagem competitiva de um cliente. Geralmente já conhecemos aspectos relacionados a performance e segurança quando refinamos algumas User Stories.
As técnicas aplicadas a performance, carga e segurança vão desde os níveis mais baixos (como um profiling de código) como a utilização de ferramentas que simulam diversos usuários simultaneamente.

Bom, agora você já sabe, conceitualmente, um pouco deste guia para iniciarmos atividades de teste de software dentro de uma equipe ágil. Vale ressaltar que todas as técnicas de teste e abordagens podem ser utilizadas, pois o quadrante é um guia e não um padrão 😉

2 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento

Abordagens Contraintuitivas para Estimativas, Prazo e Atraso – com Klaus Wuestefeld

Vídeo da palestra sobre Abordagens Contraintuitivas para Estimativas, Prazo e Atraso em Projetos de Software, feita por Klaus Wuestefeld (nosso instrutor no curso de imersão em Extreme Programming ) durante o AgileVale 2013.

Nenhum comentário »

Categorias deste post

Agile, Extreme Programming, Técnico

O que é Agile Testing?

Primeiramente para entender Agile Testing temos que dar uma olhada no Manifesto Ágil
Em um grande resumo o manifesto coloca que temos entregas de valor em um curto espaço de tempo.

Muitas práticas são utilizadas por um time ágil referente a teste. Programadores utilizam TDD (Test Driven Development) para desenvolver código com uma maior qualidade. Com ele os programadores escrevem testes para um pequeno pedaço de uma funcionalidade no ciclo do TDD (falha na primeira vez, é refatorado até possuir o comportamento esperado. Sempre que é alterado ou melhorado passa por este processo).
Esta prática não é somente usada exclusivamente por equipes ágeis, mas como uma forma inteligente de pensar no design de software e agir de forma a prevenir os defeitos futuros.

Mas TDD não é teste. É uma maneira que temos de pensar no design do software e garantir que este, se alterado, continuará a funcionar. Se alguma inconsistência for encontrada frente a alguma modificação, facilmente com um conjunto de testes que asseguram o comportamento do software, podemos detectar e alterar/refatorar o ponto de inconsistência.

Alguns acham que TDD é aplicar Agile Testing, mas ele é muito mais que isso….

Times

Dentro de uma equipe ágil possuímos, basicamente, dois times:

Time do Cliente: todos que estão do lado do negócio no projeto (product owner, business experts, business analyts). Este time escreve histórias e funcionalidades que o time de desenvolvimento entrega.

Time de Desenvolvimento: todos que entregam código são parte integrante deste time, onde o papel de cada um por ser misto ou variado. Eles transformam todas as histórias do time do cliente em software.

Estes dois times trabalham próximos uma grande parte do tempo e se transformam em um único time com um objetivo em comum: entregar valor para a organização.

 

E o testador?

Falando do conceito de time para o Time do Cliente, os testadores são membros parciais do negócio, ajudando-os a descobrir requisitos e exemplos e também ajudando o time a expressar requisitos como testes.
Testadores também são parte do Time de Desenvolvimento advogando por qualidade à favor do cliente e ajudando o time a entregar o máximo de valor ao negócio.

Muitos times não possuem membros se intitulando testadores. Entretanto o time precisa de alguém que ajude o Time do Cliente a escrever histórias e características, a escrever testes para elas, garantir que elas estão atendendo as necessidades e, automatizar os testes de regressão (para termos um feedback rápido e contínuo sobre a qualidade/saúde do software).

O que é então Agile Testing?

Agile Testing é um conjunto de práticas, seguindo o Manifesto Ágil, que incorpora todas as técnicas de teste comumente utilizadas por profissionais de teste, tendo um grande foco em automação. A principal função é de criticar o produto, ou seja, constantemente garantir que o que está sendo especificado e desenvolvido realmente atende as necessidades do cliente e irá entregar valor ao negócio.

 

O que é um Testador Ágil?

Um Testador Ágil é aquele profissional que abraça as mudanças, colabora com pessoas técnicas e de negócio e entende o conceito de usar testes para documentar requisitos e guiar o desenvolvimento.
Ele tende a ter bons conhecimentos técnicos para colaborar com o time de desenvolvimento a automatizar os testes e também para explorar o sistema a procura de comportamentos, testes e problemas.

Ser um testador ágil está ligado muito mais a atitude e comportamento do que conhecimento técnico. Ele olha para o produto como um todo, com uma visão de usuário e/ou cliente, que é o fator mais importante. Assim ele consegue tanto interrogar o Time do Cliente quanto a requisitos e funcionalidades como guiar o desenvolvimento, através de testes, exemplos e ferramentas, para que o Time de Desenvolvimento tenha também a visão do valor que cada um destes itens tem para o produto final.

 

Sobre o autor:

Embora vários títulos já exercidos no mercado (Arquiteto de Teste, Engenheiro de Teste, Analista de Teste) Elias Nogueira é essencialmente um testador: alguém com uma grande curiosidade de como o software comporta através de diversas situações/contextos.

É consultor e instrutor em qualidade de software, blogueiro e palestrante já tendo trabalhado nas mais diferentes segmentos como bancos, telecos, governo, varejo, qualidade de dado e geoprocessamento. Elias também é instrutor associado na Adaptworks no curso de Agile Testing.
Acredita que a qualidade do software é dever de todos e, quando há um papel especifico para isso, que este deve saber sobre os dois mundos do desenvolvimento de software: técnico e negócio.

http://about.me/eliasnogueira
@eliasnogueira
http://sembugs.blogspot.com

4 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento

Testes devem ser independentes

Testes devem começar dessa forma:

Primeiro, Deus criou o céu e a terra…
E Deus disse, “Haja luz”…

E devem terminar da seguinte:

a besta que viste, era e não é, está para emergir do abismo e caminha para a destruição

Quando você começa a escrever o teste, não deve existir nenhuma dependência com o estado de um teste anterior. Se você vai usar o banco, ele deve estar vazio. Se vai usar uma classe que guarda estado em um campo static (ugh!), precisa (além de refatorar esse código), reiniciá-la.

Tem uma razão para que isso seja feito. Cada teste deve se comportar como um experimento que sempre dará o mesmo resultado (desde que você não mude o código) não importa quantas vezes você o rode.

Porque você quer isso? Para que não aconteçam falsos negativos e nem falsos positivos. Seus testes precisam ser confiáveis ou você vai passar a ignorá-los.

Imaginem o seguinte caso:


public void testaQueSalvaOsDados(){
	//Código que salva "bobagem"
	
	String dado = //código que recupera "bobagem";
	assertEquals("bobagem", dado);
}

public void testaQueListaDados(){
	List<String> dados = //código que busca todos os dados;
	
	assertEquals(1, dados.size());
	assertEquals("bobagem", dados.get(0));
}

Se você rodasse esses testes, o segundo teste passaria apenas na primeira vez. Após isso, ele iria falhar no primeiro assert (o do tamanho da lista).

Esse é um caso bem óbvio de utilização de efeitos colaterais de outro teste. E pode acontecer coisa pior. Imagine que depois de rodar os testes a primeira vez, você quebra o “código que busca todos os dados” e ele passa a trazer apenas o primeiro encontrado. Você terá um bug muito difícil de encontrar, porque os testes passam.

Novamente, esse é um caso bem óbvio. Interações bem mais sutis que essas podem acontecer e você vai sofrer muito para encontrar.

Por isso, sempre que seu teste causar algum efeito colateral, desfaça esse efeito. A sanidade dos programadores que vão dar manutenção no seu código agradece.

Se quiser aprender mais sobre testes, dê uma olhada em nosso treinamento Scrum Developer Skills.

Nenhum comentário »

Categorias deste post

Agile, Técnico

Tiny Types

Enquanto eu resolvia o primeiro desafio de expressividade que postei no VidaGeek.net, me deparei com uma situação comum para programadores Java.

Eu precisava que a classe java.lang.String fosse capaz de fazer coisas (como inverter a string) que ela não é.

A solução mais comum seria criar uma classe Strings (seguindo o padrão da java.util.Collections) que conteria o comportamento.

Daí para usá-la, seria da seguinte forma:


Strings.inverte(suaString);

O problema é que isso espalha o comportamento que deveria pertencer à String (que não temos como alterar).

Ao invéz de solucionar o problema dessa forma, resolvi usar um Tiny Type para encapsular essa string (chamei de BinaryString).

Essa BinaryString é capaz de se inverter, além de eu poder dar os nomes que eu quiser para os métodos (deixando mais expressivo).

Mas a maior vantagem de ter usado esse Tiny Type é que ele me abriu possibilidades que não existiam no código sem ele e eu mudei completamente a solução que pretendia criar. A nova solução ficou (na minha opnião) mais elegante e expressiva.

Se tiverem maior interesse sobre Tiny Types, eu escrevi sobre o assunto aqui e tem um post do Darren Hobbs que é onde eu entrei em contato com o assunto.

Além disso, no nosso novo treinamento Scrum Developer Skills, vários assuntos relacionados à expressividade são abordados, incluindo Tiny Types.

4 Comentários »

Categorias deste post

Técnico

Coding Dojo na AdaptWorks

Nesta última terça-feira, 12 de Abril, tivemos mais um Codigo Dojo na AdaptWorks. Claro, a chuva que caiu no final da tarde atrapalhou um pouco, mas mesmo assim tivemos uma boa quantidade de participantes.

Desta vez resolvemos mudar o condutor do Dojo e o escolhido foi o Juliano Alves (obrigado, Juliano).

Jonas e Juliano, apresentando as opções para o problema

Apesar de algumas pessoas reclamarem, parece que Java continua sendo o “common ground” para a maioria dos participantes. Não que seja um problema, mas alguns gostariam de uma pequena mudança, conhecer uma outra linguagem.

Platéia atenta, mas participativa

Algumas pessoas talvez se sintam constrangidas em participar de um Coding Dojo – algumas por não se acharem com conhecimento suficiente ou por acharem que isso é para um nível mais alto de programação. E para estas situações, é importante lembrar que um Coding Dojo não é criado para mensurar o seu “traquejo” na linguagem, e sim mostrar (e usar) boas práticas em programação.

"Pair Programming", uma das práticas mais usadas

Inclusive, na Retrospectiva feita ao final da sessão, um dos comentários positivos foi a diferença positiva sentida quando praticando “pair programming”. E é por aí que as coisas se encaminham.

Nenhum comentário »

Categorias deste post

Agile, Dojo, Técnico

Coding Dojo em Smalltalk

Graças a colaboração e boa vontade do Guiseppe Proment da Fujitsu, ontem realizamos uma nova sessão de Coding Dojo em Smalltalk e utilizamos o Pharo pra suíte de testes. Poucos participantes conheciam Smalltalk e só o Guiseppe tinha experiência com o Pharo, o que tornou a sessão ainda mais interessante. No começo a maioria sentiu-se fora da sua zona de conforto, mas na retrospectiva todos chegaram a conclusão de que essa sensação era muito positiva.

No dojo anterior a esse (desculpem por não divulgarmos) contamos com a ajuda do Diogo Baeder que coordenou muito bem a sessão de Dojo em Javascript e o uso do QUnit que era desconhecido pela maioria dos participantes.

Esse tipo de apoio dos participantes tem ajudando em muito, tornando as sessões ainda mais atrativas e evitando que percam interesse no Dojo e que ele acabe “morrendo”.

Platéia


Veja todas as fotos do Dojo

Participe da nossa lista de discussão

1 Comentário »

Categorias deste post

Técnico

Coding Dojo

Ontem (27/07) organizamos outra sessão de Coding Dojo aqui na AdaptWorks, especialmente dessa vez contamos com novos participantes da Gonow e da Fujitsu, que enriqueceram muito o Dojo.
Coding Dojo

Agradeço a participação e paciência de todos.

Veja todas as fotos do Dojo

3 Comentários »

Categorias deste post

Técnico

Coding Dojo

Realizamos outra sessão de Coding Dojo no dia 18/05 aqui na AdaptWorks. Dessa vez além de ter fluído melhor, conseguimos organizar melhor o Dojo e os participantes por sua vez estão mais colaborativos e cada vez mais disciplinados.

coding dojo

Veja todas as fotos do Dojo

1 Comentário »

Categorias deste post

Técnico