\ncom o Ward Cunningham sobre a import\u00e2ncia dos testes para a evolu\u00e7\u00e3o de um sistema, decidi assistir uma palestra
\nsobre o framework que ele inventou para testes de aceita\u00e7\u00e3o: FIT<\/a><\/span>. O ponto principal
\nda palestra foi mostrar a import\u00e2ncia dos testes de aceita\u00e7\u00e3o como meio de comunicar requisitos. Eu j\u00e1 ouvi muitas
\nconversas por aqui sobre a utiliza\u00e7\u00e3o da palavra “teste”, pois muitos podem achar que o \u00fanico objetivo de um teste
\n\u00e9 encontrar erros (e sabemos que, apesar de eficientes, testes n\u00e3o provam a aus\u00eancia de bugs). Ao inv\u00e9s de “teste”,
\nos apresentadores tentaram usar o termo “documento”, pois os testes de aceita\u00e7\u00e3o no FIT s\u00e3o p\u00e1ginas HTML contendo
\ntexto e tabelas com exemplos que especificam o comportamento esperado do sistema. O mais interessante \u00e9 que o
\ndocumento \u00e9 algo execut\u00e1vel. Com isso voc\u00ea tem como especificar os crit\u00e9rios de aceita\u00e7\u00e3o de uma hist\u00f3ria antes de
\nter a implementa\u00e7\u00e3o pronta (a id\u00e9ia de escrever testes antes do c\u00f3digo aplicada num contexto mais amplo).
\nAo implementar a funcionalidade esperada, voc\u00ea utiliza ferramentas como os testes de unidade e
\nTDD<\/a><\/span> para garantir
\na qualidade do c\u00f3digo. Por\u00e9m o desenvolvedor \u00e9 tamb\u00e9m respons\u00e1vel por fazer o teste de aceita\u00e7\u00e3o passar. Para isso,
\nvoc\u00ea precisa escrever um Fixture<\/a><\/span>, que na verdade \u00e9 uma classe
\nque ser\u00e1 chamada pelo framework e te dar\u00e1 acesso aos dados escritos no documento FIT. A partir da\u00ed, voc\u00ea faz as
\nchamadas necess\u00e1rias ao c\u00f3digo da sua aplica\u00e7\u00e3o e avalia os resultados de acordo com as expectativas descritas no
\ndocumento FIT. Abaixo s\u00e3o duas tabelas que fizemos para especificar uma parte de um sistema de venda online de
\nservi\u00e7os de internet:<\/p>\n
A sess\u00e3o que escolhi participar depois do almo\u00e7o foi do outro inventor do Scrum<\/a><\/span>: Na segunda metade da tarde, resolvi assistir \u00e0 apresenta\u00e7\u00e3o de 3 papers, numa trilha chamada “Agile Stories”. Esse artigo foi bem interessante: eles mostraram uma forma efetiva de estruturar e automatizar a implanta\u00e7\u00e3o da sua Essa apresenta\u00e7\u00e3o foi, por enquanto, a pior da confer\u00eancia. Foi o oposto da palestra do Ken Schwaber A \u00faltima palestra do dia foi sobre m\u00e9tricas \u00e1geis. Eu achei bem interessante a distin\u00e7\u00e3o entre “Diagn\u00f3sticos” e “M\u00e9tricas” \u00c9 preciso tomar cuidado com as m\u00e9tricas que voc\u00ea escolhe para avaliar o desempenho de uma equipe \u00e1gil, afinal \n","protected":false},"excerpt":{"rendered":" Resumo do terceiro dia de confer\u00eancia: uma sess\u00e3o pela manh\u00e3, quatro na parte da tarde e eu descobri que estou ficando m\u00edope :-) Storytelling with FIT – Steve Freeman e Mike Hill Depois da sess\u00e3o de ontem com o Ward Cunningham sobre a import\u00e2ncia dos testes para a evolu\u00e7\u00e3o de um sistema, decidi assistir uma […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[6,7,19,29,48,60,85],"class_list":["post-10","post","type-post","status-publish","format-standard","hentry","category-uncategorized","tag-agile","tag-agile2006","tag-conference","tag-fit","tag-metrics","tag-quality","tag-thoughtworks"],"_links":{"self":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts\/10","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/comments?post=10"}],"version-history":[{"count":0,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/posts\/10\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/media?parent=10"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/categories?post=10"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.dtsato.com\/blog\/wp-json\/wp\/v2\/tags?post=10"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"Storytelling](\"http:\/\/static.flickr.com\/60\/198570183_f271fddb95_m.jpg\")
<\/a><\/p>\nAgile Quality: A Canary in a Coal Mine – Ken Schwaber<\/h3>\n
\nKen Schwaber<\/a><\/span>. Ele falou sobre a import\u00e2ncia da qualidade como
\natributo essencial num sistema de software: devemos nos preocupar com a qualidade desde o in\u00edcio. O custo para
\ncolocar a qualidade depois \u00e9 muito alto, podendo at\u00e9 levar um projeto ao fracasso no longo prazo devido \u00e0 perda
\nde vantagem competitiva. Quando mais tempo voc\u00ea gasta lidando com defeitos no seu sistema, menos tempo sobre para
\npensar no valor que ele est\u00e1 trazendo para o neg\u00f3cio. E o principal objetivo de qualquer sistema de software
\ndeve<\/b> ser agregar valor ao neg\u00f3cio. Na sua palestra, Ken tentou mostrar a import\u00e2ncia da qualidade para um projeto de software e defendeu a id\u00e9ia de que cortar qualidade deve ser uma decis\u00e3o de neg\u00f3cio<\/a><\/span>.<\/p>\nAgile Stories – Research Papers<\/h3>\n
\nFalarei um pouco sobre cada um dos papers nos t\u00f3picos abaixo:<\/p>\nThe Deployment Production Line – Jez Humble, Chris Read e Dan North<\/h3>\n
\naplica\u00e7\u00e3o em diferentes ambientes (teste, integra\u00e7\u00e3o, aceita\u00e7\u00e3o, …). O artigo explica de forma mais detalhada a id\u00e9ia
\nda linha de produ\u00e7\u00e3o que eles desenvolveram num projeto da ThoughtWorks<\/a><\/span>. O interessante
\n\u00e9 que eles automatizaram o processo de tal forma que qualquer pessoa podia fazer o deploy de qualquer vers\u00e3o do sistema
\nem qualquer ambiente com poucos cliques. \u00c9 interessante ressaltar tamb\u00e9m o modo em que eles quebraram as depend\u00eancias
\npara acelerar a execu\u00e7\u00e3o dos testes nos diferentes ambientes, paralelizando em v\u00e1rias inst\u00e2ncias separadas do
\nCruise Control<\/a><\/span> a execu\u00e7\u00e3o dos testes de unidade, testes de aceita\u00e7\u00e3o nos
\ncen\u00e1rios de sucesso (smoke tests<\/i>, que rodam mais r\u00e1pido), testes de aceita\u00e7\u00e3o nos cen\u00e1rios mais complicados (demoram
\nmais), testes de performance, etc. Com isso, um determinado build<\/i> vai ganhando “medalhas” conforme passa em
\ncada etapa de teste, ficando f\u00e1cil de saber quando ele pode ou n\u00e3o ser implantado em ambiente de produ\u00e7\u00e3o.<\/p>\nThe Cost of Code Quality – Yuri Kharmov<\/h3>\n
\nque eu tinha acabado de assistir. O autor defendeu a id\u00e9ia de que nem sempre precisamos
\nnos preocupar com a qualidade quando escrevemos c\u00f3digo. O principal argumento dele \u00e9: toda preocupa\u00e7\u00e3o com
\nqualidade tem um custo associado e voc\u00ea deve consider\u00e1-lo na hora de usar t\u00e9cnicas como TDD ou Integra\u00e7\u00e3o Cont\u00ednua,
\nem outras palavras, n\u00e3o \u00e9 um grande problema ter um sistema cheio de bugs se eles n\u00e3o te atrapalham.
\nDuas coisas me incomodaram: em primeiro lugar ele transpareceu n\u00e3o entender a verdadeira ess\u00eancia de
\nTDD<\/a><\/span> como uma
\nferramenta que possibilita o Design Incremental<\/a><\/span>.
\nSegundo, quando perguntaram para ele ao final da palestra quantas vezes ele discutia sobre qualidade de c\u00f3digo com
\no cliente, ele respondeu “Quase nunca”. Como ele pode julgar pelo cliente o valor da aus\u00eancia ou n\u00e3o de bugs se ele
\nnunca discute sobre isso?<\/p>\nAppropriate Agile Measurement: Using Metrics and Diagnostics to Deliver Business Value – Deborah Hartmann e Robin Dymond<\/h3>\n
\nproposta pelos autores:<\/p>\n\n
\n“You get what you measure”<\/i>. Outra coisa que eles mostraram foi um template<\/i> para ser utilizado na hora de
\ncriar uma m\u00e9trica \u00e1gil, com pontos que te fazem pensar sobre o verdadeiro valor que aquela m\u00e9trica ir\u00e1 representar
\nquando estiver medindo o sucesso do seu software.<\/p>\n