{"id":935,"date":"2010-06-16T07:56:54","date_gmt":"2010-06-16T14:56:54","guid":{"rendered":"https:\/\/simpleprogrammer.com\/?p=935"},"modified":"2017-07-03T19:22:12","modified_gmt":"2017-07-03T23:22:12","slug":"agile-testing-is-different","status":"publish","type":"post","link":"https:\/\/simpleprogrammer.com\/agile-testing-is-different\/","title":{"rendered":"Agile Testing is Different"},"content":{"rendered":"

I come from a QA background.<\/p>\n

I started off my career doing testing.\u00a0 I learned about testing the same way I learned about development\u2026 reading lots of books and applying what I learned.<\/p>\n

This is how you are supposed<\/em> to do QA:<\/p>\n

    \n
  1. Write a test plan for the project.<\/li>\n
  2. Gather requirements.\u00a0 Put them into a repository and give them cold hard labels like REQ1.2.5.<\/li>\n
  3. Create test cases from the requirements.\u00a0 Store those test cases into a tracking system which can map them back to individual requirements.<\/li>\n
  4. Execute test cases, each test step should either pass or fail.\u00a0 Record the results.\u00a0 File any bugs found into the bug tracking system which maps the bug to the test that failed and the associated requirement.<\/li>\n<\/ol>\n

    There is more to it, but that is the basic outline.<\/p>\n

    But it doesn\u2019t work in Agile!<\/h2>\n

    Heck, it doesn\u2019t work anywhere.\u00a0 At least not the requirements part.\u00a0 That is the part that is always missing, or woefully inadequate.<\/p>\n

    Don\u2019t panic though.\u00a0 It makes sense.\u00a0 Let\u2019s think this through.\u00a0 The reason we all started jumping off the waterfall ship and into Agile is because we realized that it is almost impossible and certainly worthless to try and define requirements up front.<\/p>\n

    With that idea in mind, how do we test?\u00a0 How can we test in an Agile environment?<\/p>\n

    First goal is automation<\/h2>\n

    Let me explain to you why this is the most important part.\u00a0 It may seem a little out of order, but bear with me.<\/p>\n

    When you are doing iterative development, you are building things little by little.\u00a0 You’re not waiting until the end to test things, so there is a really good chance something you do in any iteration will break something you did earlier.<\/p>\n

    How do you deal with this?\u00a0 It\u2019s called \u201cregression.\u201d\u00a0 Yes, you probably need it in waterfall, but in Agile it is an absolute must, otherwise you\u2019ll find that for every step forward you take, you take a step backward as you fix something that you broke.<\/p>\n

    Running an Agile project without automation is like walking the tight-rope without a safety net, except the tight-rope is on fire, someone is strumming it like a banjo, and you’re wearing two left shoes.<\/p>\n

    People groan when I say this, but I firmly believe it and I have done it several times.<\/p>\n

    Part of every backlog\u2019s done criteria should be that it has automated tests!<\/p><\/blockquote>\n

    Unless you have automated tests for each piece of functionality you build (or at least the ones you care if they stay working), or an army of manual testers running your regression suite every iteration, your software will break in your customer\u2019s hands.<\/p>\n

    How to build an Internal DSL for Automated Functional Testing<\/a><\/p>\n

    Automated UI Testing Framework\u2026 A Real Example<\/a><\/p>\n

    Next goal is change the focus<\/h2>\n

    Testing is traditionally an activity that happens at the end of development and is the gate-keeping for software.\u00a0 It has to go through QA before it gets released.<\/p>\n

    That is not a good model for Agile, because what happens when there is a bug?\u00a0 If the testing happens at the end of the iteration and there is a bug found, there is no time to fix it.<\/p>\n

    What if we change the order of things, change the focus?<\/p>\n

    When you write your code, you write unit tests first, right?\u00a0 (Or if you like BDD, you write the specifications, or behaviors.)\u00a0 And you run them continuously as you’re working on your code to make sure you don\u2019t break them, right?<\/p>\n

    We can apply the same thing at the higher level.<\/p>\n