• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agile Testing e outros amendoins
 

Agile Testing e outros amendoins

on

  • 323 views

Palestra realizada para profissionais da Prefeitura Municipal de São José dos Campos, SP, a respeito de como avançar na agilidade, critérios de aceite e agile testing.

Palestra realizada para profissionais da Prefeitura Municipal de São José dos Campos, SP, a respeito de como avançar na agilidade, critérios de aceite e agile testing.

Statistics

Views

Total Views
323
Views on SlideShare
323
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • Independent As much as possible, care should be taken to avoid introducing dependencies between stories. Dependencies between stories lead to prioritization and planning problems. For example, suppose the customer has selected as high priority a story that is dependent on a story that is low priority. Dependencies between stories can also make estimation much harder than it needs to be. For example, suppose we are working on the BigMoneyJobs website and need to write stories for how companies can pay for the job openings they post to our site. Negotiable Stories are negotiable. They are not written contracts or requirements that the software must implement. Story cards are short descriptions of functionality, the details of which are to be negotiated in a conversation between the customer and the development team. Because story cards are reminders to have a conversation rather than fully detailed requirements themselves, they do not need to include all relevant details. However, if at the time the story is written some important details are known, they should be included as annotations to the story card, as shown in Story Card 2.1. The challenge comes in learning to include just enough detail. Valuable to Purchasers or Users It is tempting to say something along the lines of "Each story must be valued by the users." But that would be wrong. Many projects include stories that are not valued by users. Keeping in mind the distinction between user (someone who uses the software) and purchaser (someone who purchases the software), suppose a development team is building software that will be deployed across a large user base, perhaps 5,000 computers in a single company. The purchaser of a product like that may be very concerned that each of the 5,000 computers is using the same configuration for the software. This may lead to a story like "All configuration information is read from a central location." Users don't care where configuration information is stored but purchasers might. Estimatable It is important for developers to be able to estimate (or at least take a guess at) the size of a story or the amount of time it will take to turn a story into working code. There are three common reasons why a story may not be estimatable: Developers lack domain knowledge. Developers lack technical knowledge. The story is too big. First, the developers may lack domain knowledge. If the developers do not understand a story as it is written, they should discuss it with the customer who wrote the story. Again, it's not necessary to understand all the details about a story, but the developers need to have a general understanding of the story. Small Like Goldilocks in search of a comfortable bed, some stories can be too big, some can be too small, and some can be just right. Story size does matter because if stories are too large or too small you cannot use them in planning. Epics are difficult to work with because they frequently contain multiple stories. For example, in a travel reservation system, "A user can plan a vacation" is an epic. Planning a vacation is important functionality for a travel reservation system but there are many tasks involved in doing so. The epic should be split into smaller stories. The ultimate determination of whether a story is appropriately sized is based on the team, its capabilities, and the technologies in use. Testable Stories must be written so as to be testable. Successfully passing its tests proves that a story has been successfully developed. If the story cannot be tested, how can the developers know when they have finished coding? Untestable stories commonly show up for nonfunctional requirements, which are requirements about the software but not directly about its functionality.

Agile Testing e outros amendoins Agile Testing e outros amendoins Presentation Transcript

  • Agile Testing ... e urs m n o s o t a e d in o G bieM rir a rl oea R b r P p t M ld o et e a ea o o o l S oJ s d s a p sA r 0 2 ã oé o C m o, b/ 12
  • ApresentaçãoRoberto Pepato Melladorpepato@gmail.com@rpepato Gabriel de Souza P. Moreira+ 15 anos de experiência em desenvolvimento, consultoria e gspmoreira@gmail.comgestão de projetos de sofware; @gspmoreiraFormação: + 10 anos de experiência em arquitetura, análise e desenvolvimento de software;Graduado em Ciência da Computação - Universidade SãoJudas Tadeu Formação:Pós-Graduação em Tecnologia de Sistemas Orientados àObjetos - Faculdade Senac Graduado em Ciência da Computação - UNIVAPMBA em Gesão Estratégica e Econômica de Projetos - Mestrado em Engenharia de Software - ITAFundação Getúlio Vargas - FGVSPMestrado em Informática (em curso) - Instituto Tecnológicode Aeronáutica - ITA
  • AgendaFazendo Ágil / Sendo ÁgilValoresTestesDemoQuestões
  • Sua empresa/equipe está fazendo ágil ?
  • O que é fazer ágil pra você ?
  • Por que você está fazendo ágil ?
  • É porque todos estão nessa ?Porque esse é o novo hype ?
  • E aí, agile está funcionandopara você ? Qual sua dor ?
  • Você está fazendo ágil melhor do que quando começou ?
  • Agile está resolvendo seus problemas ?Ou você é um escravo dele ?
  • Qual é a receita de bolo ?
  • Scrum ? XP ? FDD ? Crystal ?
  • No Silver Bullet
  • Scrum ? XP ? FDD ? Crystal ?
  • Já pensou em parar de fazer ágil e começar a ser ágil ?
  • Fazer ágil atinge um muro
  • Como suportar ocrescimento com agile ?
  • Não signfica que os itens à direita são dispensáveis
  • Pensar Ágil + Fazer Ágil = Ser Ágil
  • Papéis ? Pra onde eu vou ?
  • EquipeÊ f e o p p is n s ns aé ? a• D sc p p p is e tid d s eao l a é d a a e e ivC lr d h ri ? uua e eó t• D ix a c issl e e e s o a fírm uT d s e t n m s ol a d rm ne o o sna o em u r iaia e t ? m g• P re j tstd ot e aêmu o (o o im ) nA in r aõ s ã fe ? s f m ç e no l m o u U e s ae e s a p rd s
  • - + Em Resumo
  • User Stories• In e e d n d p n et• Ne oia l g tb e• Va a lt ues r utm r l b o sr o c s es u e o• Es a b t tl im a e• Sm l al• Tet l sb ae
  • User Stories - Critérios de AceitaçãoE pesmd th s x rsa e l aeD c m na sp s õ s ep c ta o u e t u oiç e e x et ivs m aD t m a s a s r et po t e r in m e et ia s rna e ó áD vrmsr sr s e c ne eeia e ecit p l l t a o ieS oecit a t d in iod c dicço ã sr s ne o íc a o ifaã a sN od vmsr o p xs u mga d n m r ã ee e c m l a o e rn e ú eo e
  • User Stories - Critérios de AceitaçãoC m d so r o cit io ? o o ec bir s r r s é Oq e im ot t p r a p m naã ? u é p r ne aa im l e t o a e ç E q e irut c s etr p d s c m ot m u cc s n ia a s ia o e e o p r r â ó a d f m dee t ? e o a if ne r r Oq e o e c nee d erd n eeu ã d u p d ao t r e r o a xc ço e c a uasr? m et ia ó
  • User Stories - Exemplo“C m c ne d sjp g r c na o cr od cé it” o o l t ee a a a o t c m at e rd o ie , o ã Cit io: r rs é D v aea V a M s rade m ra E pes ee cit is, at cr A eicn x rs r e D v rc sr in r Cu ee eua D e’s l b D v rc sr ate c mn m r iná o ee eua cr s o ú eo vl õ id D v rc sr ate ep a o ee eua cr s x ird s õ D v rc sr e l it d cr of ecd o ee eua s oim e o at o xe id ã i
  • Tipos de TesteT s d U a ila e et e sbid d eT s d I ef e e sáio et en r c d U u r e taT s d P r r ac et e ef m n e e oT s d Srs et e t s e eT s d I e rço et en gaã e tT s U it io et ná e r
  • “ T he main thing that distinguishes legacy codefrom non-legacy code is tests, or rather a lack of tests” “ Legacy code is code without tests”
  • “Em 2010, programar sem TDD chega a ser anti- ético” - QCon SP 2010 “... para responder a questão do como começarno ágil, o primeiro passo é: TDD ...” - AgileVale - ITA - SJC, 2011 Klaus Wuestefeld
  • Demo !!
  • Bowling Game• Scenario: Gutter Game• Given a new game• When I roll 20 balls into the gutter• Then the score should be 0• Scenario: Perfect Game• Given a new game• When I perform 12 strikes• Then the score should be 300
  • Referências
  • Referências
  • Referências
  • Referências
  • F r m na uila a n d m er e t t d s a e o a s iz• V u l td 2 1 isaSu io 0 0• R sap r ht:/ w .jba s o / sap r eh re - t / we rin.c mr h re/ p w t e P gin aa isaSu ioq e aoee rd tid d e em e l - p r V u l td u f rc po uiv a e p r it u v eeu ã d t t u it io d nr d IE xc ço e e e ná s e t aD ss r o• N n – ht:/ w .n n.og u it t / w u it r p w Fa e ok p nS uc p r T s s náio rm wr O e - o re aa et U it s e r• S eF w ht:/ w .s efw r/ p c l - t / w p co .og o p w l Fa e ok p nS uc p r uilaã d B D rm wr O e - o re aa t ço e D iz
  • Dúvidas ?
  • Obrigado ! :)