book.fo

<?xml version="1.0" encoding="UTF-8"?>
<fo:root xmlns:fo="http://www.w3.org/1999/XSL/Format" font-size="12pt">
  <fo:layout-master-set>
    <fo:simple-page-master master-name="PageMaster-Left" page-height="174.5mm" page-width="108.0mm" margin-bottom="12.70mm" margin-left="6.35mm" margin-right="6.35mm" margin-top="6.35mm">
      <fo:region-body margin="0mm 0mm 0mm 0mm"/>
      <fo:region-after region-name="Left-footer" display-align="before" extent="0em"/>
    </fo:simple-page-master>
    <fo:simple-page-master master-name="PageMaster-Right" page-height="174.5mm" page-width="108.0mm" margin-bottom="12.70mm" margin-left="6.35mm" margin-right="6.35mm" margin-top="6.35mm">
      <fo:region-body margin="0mm 0mm 0mm 0mm"/>
      <fo:region-after region-name="Right-footer" display-align="before" extent="0em"/>
    </fo:simple-page-master>
    <fo:page-sequence-master master-name="PageMaster">
      <fo:repeatable-page-master-alternatives>
        <fo:conditional-page-master-reference master-reference="PageMaster-Left" odd-or-even="even"/>
        <fo:conditional-page-master-reference master-reference="PageMaster-Right" odd-or-even="odd"/>
      </fo:repeatable-page-master-alternatives>
    </fo:page-sequence-master>
  </fo:layout-master-set>
  <fo:page-sequence master-reference="PageMaster" initial-page-number="1">
    <fo:static-content flow-name="xsl-footnote-separator">
      <fo:block>
        <fo:leader leader-pattern="rule" rule-thickness="0.5pt" leader-length="33%"/>
      </fo:block>
    </fo:static-content>
    <fo:static-content flow-name="Left-footer">
      <fo:block font-size="9pt" border-top-width="0.5pt" border-top-style="solid" border-top-color="black">
        <fo:block margin="1em">
          <fo:page-number/>
        </fo:block>
      </fo:block>
    </fo:static-content>
    <fo:static-content flow-name="Right-footer">
      <fo:block text-align="outside" font-size="9pt" border-top-width="0.5pt" border-top-style="solid" border-top-color="black">
        <fo:block margin="1em">
          <fo:page-number/>
        </fo:block>
      </fo:block>
    </fo:static-content>
    <fo:flow flow-name="xsl-region-body">
      <fo:block>
  

  <fo:block page-break-before="always">
  
    
      <fo:block margin="1em"><fo:inline font-weight="bold">Ash</fo:inline>: <fo:inline font-style="italic">We were somewhere around the waterfall, on the edge of the software lifecycle, when the tests began to take hold. I remember saying something like:</fo:inline></fo:block>

<fo:block margin="1em">I feel a bit lightheaded. Maybe you should drive.</fo:block>

<fo:block margin="1em"><fo:inline font-style="italic">Suddenly, there was a terrible roar all around us, and the software was full of what looked like huge bugs, all swooping and screeching and diving around the computer, and a voice was screaming:</fo:inline></fo:block>

<fo:block margin="1em">Holy Jesus. What are these goddamn bugs?</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">Dr. Gonzo</fo:inline>: Did you say something?</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">Ash</fo:inline>: Hm? Never mind. It’s your turn to test.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">Ash</fo:inline>: <fo:inline font-style="italic">No point in mentioning these bugs, I thought. Poor bastard will see them soon enough.</fo:inline></fo:block>
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
    
  
</fo:block>
  <fo:block page-break-before="always" margin-top="75%" text-align="center" font-weight="bold">Concepts</fo:block><fo:block page-break-before="always" margin-top="80%" text-align="right" line-height="3em"><fo:block>challenging assumptions</fo:block><fo:block>Ask better questions - Listen!</fo:block><fo:block>Mule Testing - proactively testing assumptions</fo:block><fo:block>Mule Specs - automated assumption testing</fo:block></fo:block>
  Concepts
  
    
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">challenging assumptions</fo:block>
          <fo:block margin="1em">Many bugs can be prevented by challenging assumptions. Challenging the assumptions every one holds as well as paying attention to the seemingly small ones, will yield great results.</fo:block>

<fo:block margin="1em">Small things can be the most dangerous as they tend to go unnoticed, then gang up on you. It’s more common for projects to get overwhelmed by a build up of small things. The devil’s in the detail.</fo:block>

<fo:block margin="1em">To find assumptions, listen to the way people speak. Assumptions can found in sentences that contain:</fo:block>

<fo:list-block provisional-distance-between-starts="1em" provisional-label-separation="1em" space-after="12pt" start-indent="1em"><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>must, always, mandatory, required</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>impossible, inconceivable, never</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>should, ought</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>doesn’t make sense</fo:block></fo:list-item-body></fo:list-item></fo:list-block>

<fo:block margin="1em"><fo:inline font-style="italic">Doesn’t make sense is a favourite.</fo:inline> This planet is filled with humans who do many things that make more money than sense.</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">An Example!</fo:block>

<fo:block margin="1em">Consider the following story:</fo:block>

<fo:block margin="1em"><fo:inline font-style="italic">As a customer</fo:inline>  <fo:inline font-style="italic">I want to know the average activity</fo:inline>  <fo:inline font-style="italic">So that I can compare this month’s activity against the average</fo:inline> </fo:block>

<fo:block margin="1em">Sounds simple… but if you look a little deeper:</fo:block>

<fo:list-block provisional-distance-between-starts="1em" provisional-label-separation="1em" space-after="12pt" start-indent="1em"><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>What do we mean by ‘know’?</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>What do we mean by average? Geometric, harmonic or arithmetic mean?</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>What activity?</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>What do you mean by month? How many days are in it?</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Over what time span is the average calculated? Does it move?</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>How are the numbers rounded? How is the tie broken?</fo:block></fo:list-item-body></fo:list-item></fo:list-block>

<fo:block margin="1em">Remember, the most hidden assumptions are those you yourself hold. As a tester, you need to challenge yourself and question everything.</fo:block>
        </fo:block>
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">Ask better questions - Listen!</fo:block>
          <fo:block margin="1em">Everything that follows is a result of what you see here.</fo:block>

<fo:block margin="1em">Testing relies heavily on asking questions. Questions allow us to challenge assumptions, confirm what we already know and uncover the unknown. Coming up with the right questions and understanding what to do with the answers is a real skill. Consider yourself a detective or scientist, whichever you find more motivating.</fo:block>

<fo:block margin="1em">Have you read/seen ‘i Robot’? In the story, Detective Spooner has to solve a murder. It starts with him questioning a hologram of the victim, Dr Lanning. The hologram is a simple program, it can only give limited responses to specific questions.</fo:block>

<fo:block margin="1em">Detective Spooner collects pieces of information, assesses them and re-evaluates what he knows. He uses that to piece together the right questions, fueling the cycle until he uncovers the fundamental flaw that had made it into (mass) production.</fo:block>

<fo:block margin="1em">He could have asked the hologram many mindless questions, but that may never have allowed him to reach the right one. Testing can be as simple as asking questions but they are futile if you’re not listening to the answers and constantly evaluating what you know.</fo:block>

<fo:block margin="1em">Beware of robots.</fo:block>
        </fo:block>
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">Mule Testing - proactively testing assumptions</fo:block>
          <fo:block margin="1em">We were building a shiny new system that relied on data from a poorly understood legacy monster. Assumptions about this data were baked into our system. These unchallenged assumptions turned out to be wrong. Our shiny new system was no longer so shiny.</fo:block>

<fo:block margin="1em">The wider the belief in the assumption, the more it’s en-grained in the business, the greater the need for it to be tested.</fo:block>

<fo:block margin="1em">Why trust when you can know?</fo:block>

<fo:block margin="1em">An example Mule test (<fo:inline font-style="italic">it’s blogging by example!</fo:inline>)</fo:block>

<fo:block margin="1em">Start with the assumption: <fo:inline font-style="italic">“All products must have a category”</fo:inline> Find a way to challenge or validate it. In this case we would run a simple query against production data:</fo:block>
<fo:block font-size="10pt" border="thin" border-style="dotted" background-color="#F8F8F8" font-family="monospace" white-space-treatment="preserve" white-space-collapse="false" linefeed-treatment="preserve" margin="1em" padding="1em"><fo:inline font-weight="bold">SELECT</fo:inline> <fo:inline font-weight="bold">*</fo:inline> <fo:inline font-weight="bold">FROM</fo:inline> products <fo:inline font-weight="bold">WHERE</fo:inline> category <fo:inline font-weight="bold">IS</fo:inline> <fo:inline font-weight="bold">NULL</fo:inline>
</fo:block>

<fo:block margin="1em">If the assumption holds true then rest easy. If it turns out to be false, congratulations you have just prevented a major bug. Share it with the team and update your old assumption to include the new facts. In this example <fo:inline font-style="italic">“A product does not require a category”</fo:inline>.</fo:block>

<fo:block margin="1em">Mule testing has limits. It only helps you test assumptions that you know about. If the magic combination of data that breaks your assumptions doesn’t yet exist, it won’t fail. It only works with access to the latest production data.</fo:block>

<fo:block margin="1em">Why the name mule testing? Because some people got the wrong idea when we called it ass testing.</fo:block>
        </fo:block>
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">Mule Specs - automated assumption testing</fo:block>
          <fo:block margin="1em">In our last post we talked about mule testing. Assumptions need automation because they’re the foundation our systems are built upon; they can change at anytime. Mule specs are a way to automate mule tests.</fo:block>

<fo:block margin="1em">You can use any automated testing tool - the one your project already uses is probably fine. Unless it’s QTP. Below is the example from the last post in RSpec using the sequel gem.</fo:block>
<fo:block font-size="10pt" border="thin" border-style="dotted" background-color="#F8F8F8" font-family="monospace" white-space-treatment="preserve" white-space-collapse="false" linefeed-treatment="preserve" margin="1em" padding="1em">describe 'products' <fo:inline font-weight="bold">do</fo:inline>
  it 'do not require a category' <fo:inline font-weight="bold">do</fo:inline>
    sql <fo:inline font-weight="bold">=</fo:inline> <fo:inline font-weight="bold">&lt;&lt;-</fo:inline>SQL
      SELECT count(1) as row_count
      FROM product
      WHERE category IS NULL
    SQL

    at_least_one_row_exists sql
  <fo:inline font-weight="bold">end</fo:inline>
<fo:inline font-weight="bold">end</fo:inline>
</fo:block>

<fo:block margin="1em">We use two helper functions as we phrase our tests to expect either at least one result or no results.</fo:block>
<fo:block font-size="10pt" border="thin" border-style="dotted" background-color="#F8F8F8" font-family="monospace" white-space-treatment="preserve" white-space-collapse="false" linefeed-treatment="preserve" margin="1em" padding="1em"><fo:inline font-weight="bold">def</fo:inline> at_least_one_row_exists sql
  DB<fo:inline font-weight="bold">[</fo:inline>sql<fo:inline font-weight="bold">][</fo:inline>:row_count<fo:inline font-weight="bold">].</fo:inline>should <fo:inline font-weight="bold">!=</fo:inline> 0
<fo:inline font-weight="bold">end</fo:inline>

<fo:inline font-weight="bold">def</fo:inline> no_rows_exists sql
  DB<fo:inline font-weight="bold">[</fo:inline>sql<fo:inline font-weight="bold">][</fo:inline>:row_count<fo:inline font-weight="bold">].</fo:inline>should <fo:inline font-weight="bold">==</fo:inline> 0
<fo:inline font-weight="bold">end</fo:inline>
</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">Getting production data</fo:block>

<fo:block margin="1em">Mule tests require prod data, the older and less realistic it is, the less certainty you have in your assumptions. Running Mule Specs on production data doesn’t mean running them on production, that’s a really bad idea. Copy the data elsewhere before execution. We arranged a sync from production every night and our Mule Specs run against it. So, when we arrive in the morning we know that as of yesterday, all our assumptions are still true.</fo:block>

<fo:block margin="1em">Mule specs give us more than just a way of verifying assumptions. Written well, with good reporting, you produce verified documentation that’s updated every night when the mules run. Get the entire team involved. Ensure the analysts note their assumptions as they go and have the testers and developers implement them.</fo:block>

<fo:block margin="1em">Follow your heart, run with the mules every night.</fo:block>
        </fo:block>
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
  

  <fo:block page-break-before="always" margin-top="75%" text-align="center" font-weight="bold">Automation</fo:block><fo:block page-break-before="always" margin-top="80%" text-align="right" line-height="3em"><fo:block>when should we be doing automated testing?</fo:block><fo:block>Disposable Automation</fo:block><fo:block>the limits of automation</fo:block></fo:block>
  Automation
  
    
      
    
      
    
      
    
      
    
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">when should we be doing automated testing?</fo:block>
          <fo:block margin="1em">Automated tests, that are written <fo:inline font-weight="bold">before</fo:inline> the code; capture the intention of the code, inform design decisions, provide rapid feedback and let us know when we are done. All of this gets us thinking about testing and ensuring that our code can be automated.</fo:block>

<fo:block margin="1em">One view of test automation is to write it <fo:inline font-weight="bold">after</fo:inline> the system code has been written so the automation has to cope with less change. We’ve found this view doesn’t hold up in practice, firstly we spend a lot of time reverse engineering the code to automate it. Secondly, if the code is changing then this is when we need test automation the most to provide us with a safety net.</fo:block>

<fo:block margin="1em">Automated tests that are written <fo:inline font-weight="bold">after</fo:inline> the code do not directly inform the design nor do they provide rapid feedback. When writing automated tests in this way we need to ask ourselves; why are we taking this approach?</fo:block>

<fo:block margin="1em">If we are doing it to provide test coverage or run in the CI build then we are coming to the party late. Without visibility into what automation already exists we could be duplicating test effort. If these tests will help us build a better product then they should be written <fo:inline font-weight="bold">before</fo:inline> the code.</fo:block>

<fo:block margin="1em">If we are using automation to do exploratory testing and we intend to throw the automation code away afterwards then we can write the tests <fo:inline font-weight="bold">after</fo:inline>. Not all automation needs to be kept it just has to help us explore.</fo:block>
        </fo:block>
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">Disposable Automation</fo:block>
          <fo:block margin="1em">In our experience, testers have an unhealthy attachment to automated tests. We’re going to talk about times when throwaway automation is really helpful.</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">Record and playback</fo:block>

<fo:block margin="1em">Sick and tired of clicking through page after page to find what you want to test? Record your path, run it, and test what actually matters. Record and playback is quick and easy. The code it creates will make your eyes bleed which doesn’t matter as long you dump it as soon as you’re done with it.</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">Exploratory Automation</fo:block>

<fo:block margin="1em">Sometimes you need to test things that can’t easily be done manually. We were exploring a bug lurking deep within a server and found ourselves manually crafting HTTP headers in telnet. We realised it’s a lot easier to do this in code. So we did. We found the bug and threw the automation away.</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">Permutations and Combinations</fo:block>

<fo:block margin="1em">There’s an adage that you can’t test everything. Sometimes, your tester senses tell you to cover a part of the system thoroughly. This can be done with a script that generates the various combinations. Run it over night and don’t leave your number.</fo:block>

<fo:block margin="1em">Automation you decide to keep, you decide to maintain and “The things you own, end up owning you.” Tyler Durden</fo:block>
        </fo:block>
      
    
      
        <fo:block page-break-before="left">
          <fo:block font-weight="bold">the limits of automation</fo:block>
          <fo:block margin="1em">Automation testing is frequently evangelised as the cure-all of software quality woes. However automated testing has limits on its effectiveness. Understanding these limits will keep us from trying to automate something that should never be.</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">Scoping Limitations</fo:block>

<fo:block margin="1em">In an automated test, deviations from the norm are not necessarily reported as failures. We can work around that by writing more tests, each of them focusing on one factor of the system.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">Practical Limitations</fo:inline>: automation comes with a maintenance cost as the product evolves. This places practicality limits around what we automate. It’s not feasible to automate everything, as we must maintain everything. We need to be prudent about what tests we want to keep.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">Technological Limitations</fo:inline>: some testing activities are just not possible to automate, like user experience testing. As soon as we move into the area where subjective qualities are being measured automation breaks down.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">Usefulness Limitations</fo:inline>: automated tests do not provide equal value to the team. The high use post-deploy smoke test is more valuable than checking whether the user name field supports “Travis” as well as “Cornelius”. Just like we risk and value assess our manual testing effort we should be doing the same with automation.</fo:block>

<fo:block font-weight="bold" margin-left="1em" margin-right="1em" margin-bottom="1em" margin-top="1em*2">Conflicting Limitations</fo:block>

<fo:block margin="1em">The limitations we touched on they fall into two categories; those that force us to be smarter about the small set of tests we automate and those that drive us to want more tests. We can’t have both. How we deal with this is what makes a good tester.</fo:block>
        </fo:block>
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
  

  <fo:block page-break-before="always" margin-top="75%" text-align="center" font-weight="bold">Guidance</fo:block><fo:block page-break-before="always" margin-top="80%" text-align="right" line-height="3em"/>
  Guidance
  
    <fo:list-block provisional-distance-between-starts="1em" provisional-label-separation="1em" space-after="12pt" start-indent="1em"><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>testing large datasets - an introduction</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
  
  
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
        
          testing large datasets - an introduction
          <fo:block font-size="10pt" border="thin" border-style="dotted" background-color="#F8F8F8" font-family="monospace" white-space-treatment="preserve" white-space-collapse="false" linefeed-treatment="preserve" margin="1em" padding="1em">require 'cromulent_testing'

describe 'automated testing,' <fo:inline font-weight="bold">do</fo:inline>
  describe 'to involve the whole team' <fo:inline font-weight="bold">do</fo:inline>
    it 'should make it easy for the team to contribute'
    it 'should include everyone in defining specifications'
    it 'should support the developers'
    it 'should be in the same language as the code'
  <fo:inline font-weight="bold">end</fo:inline>

  describe 'to be an asset' <fo:inline font-weight="bold">do</fo:inline>
    it 'should make it easier for the product to change'
    it 'should drive the domain model'
    it 'should generate human understandable documentation'
    it 'should cover the boring, repetative work'
    it 'should cover the high risk areas'
  <fo:inline font-weight="bold">end</fo:inline>

  describe 'to be maintenable' <fo:inline font-weight="bold">do</fo:inline>
    it 'should be organised in a way that makes sense'
    it 'should be easy to see why it failed'
    it 'should be discrete'
    it 'should be written as though it were production code'
  <fo:inline font-weight="bold">end</fo:inline>

  describe 'to do it poorly' <fo:inline font-weight="bold">do</fo:inline>
    it 'should be done after the manual testing'
    it 'should be done by a separate team'
    it 'should be done by people who don\'t understand testing'
    it 'should be implemented by people who are not skilled in coding'
    it 'should summon a balrog!'
  <fo:inline font-weight="bold">end</fo:inline>
<fo:inline font-weight="bold">end</fo:inline>
</fo:block>

        
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
  

  <fo:block page-break-before="always" margin-top="75%" text-align="center" font-weight="bold">People</fo:block><fo:block page-break-before="always" margin-top="80%" text-align="right" line-height="3em"/>
  People
  
    <fo:list-block provisional-distance-between-starts="1em" provisional-label-separation="1em" space-after="12pt" start-indent="1em"><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Do you know about test fatigue?</fo:block></fo:list-item-body></fo:list-item><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Dealing with test fatigue</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
  
  
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
        
          Do you know about test fatigue?
          <fo:block font-style="italic" border="thin" border-style="dotted" background-color="#F8F8F8" margin="1em">
<fo:block margin="1em">Fatigue is a normal result of working, mental stress, overstimulation and understimulation, jet lag or active recreation, depression, and also boredom, disease and lack of sleep.[1]</fo:block>
</fo:block>

<fo:block margin="1em">We could rewrite the above quote to be:</fo:block>

<fo:block margin="1em">Test fatigue is a normal result of testing, delivery pressures, thrashing, uninteresting work, disenfranchisement, mechanical work, bad practices and working overtime.</fo:block>

<fo:block margin="1em">What’s wrong with that?</fo:block>

<fo:block font-style="italic" border="thin" border-style="dotted" background-color="#F8F8F8" margin="1em">
<fo:block margin="1em">…mental fatigue, in turn, can manifest itself both as somnolence (decreased wakefulness), or just as a general decrease of attention, not necessarily including sleepiness. Decreased attention is known as ego depletion and occurs when the limited ‘self regulatory capacity’ is depleted. It may also be described as a more or less decreased level of consciousness. In any case, this can be dangerous when performing tasks that require constant concentration, such as driving a vehicle… [or testing][1]</fo:block>
</fo:block>

<fo:block margin="1em">This is a big topic, we have a lot more to say…stay tuned.</fo:block>

<fo:block margin="1em">[1]: http://en.wikipedia.org/wiki/Fatigue_(medical)</fo:block>
        
      
    
      
        
          Dealing with test fatigue
          <fo:block margin="1em">Here are the problems we raised in our last post and ways we deal with them.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">working overtime</fo:inline> - You can’t test tired. If you’re going to be working overtime for several hours, have a break. Take time away from the project and go out for dinner, like a second lunch. Adjust the workplace to your style, watch YouTube together and take frequent communal breaks.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">delivery pressures</fo:inline> - The more pressure the team is under, the more likely they are to make mistakes and the more you need to test. DON’T PANIC. The less time you have the more you need to get it right the first time.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">thrashing</fo:inline> - Make a task list of what needs doing and divvy up the work. Stop people from interrupting (think: cone of silence) by politely explaining the urgency of what you’re working on. Remember, prioritisation! It’s normally better to finish some things than to partially complete lots of them.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">uninteresting work</fo:inline> - Spice up boring work by trying it in a new way. Any technique will do, invent your own or try something from your favourite testing blog. You can make work fun.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">mechanical work</fo:inline> - Automate it, computers love repetitive tasks. Even if you dispose of it later, you’re saving time. Delegate it to the development team, they love repetitive tasks.</fo:block>

<fo:block margin="1em"><fo:inline font-weight="bold">bad practices &amp; disenfranchisement</fo:inline> - Why are you doing this to yourself? Good testers are a rare breed. Other companies want you, we want you. If you can’t fix it, leave.</fo:block>
        
      
    
      
    
      
    
      
    
      
    
      
    
  

  <fo:block page-break-before="always" margin-top="75%" text-align="center" font-weight="bold">Stories</fo:block><fo:block page-break-before="always" margin-top="80%" text-align="right" line-height="3em"/>
  Stories
  
    <fo:list-block provisional-distance-between-starts="1em" provisional-label-separation="1em" space-after="12pt" start-indent="1em"><fo:list-item><fo:list-item-label end-indent="1em"><fo:block>*</fo:block></fo:list-item-label><fo:list-item-body start-indent="body-start()"><fo:block>Chicken Little</fo:block></fo:list-item-body></fo:list-item></fo:list-block>
  
  
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
    
      
        
          Chicken Little
          <fo:block margin="1em"><fo:inline font-style="italic">Once upon a time there was a tiny chicken [tester] named Chicken Little. One day Chicken Little was scratching in the garden when an acorn fell on her head.</fo:inline> <fo:inline font-style="italic">“Oh,” cried Chicken Little, “The sky is falling! I must go tell the king [project manager].”</fo:inline></fo:block>

<fo:block margin="1em">It’s important to remember that this is a tester who really cares, we need to harness their passion. A panicked approach causes stress and real problems get lost in the noise. The tester will lose credibility, become marginalised and burnout.</fo:block>

Harness the passion!

<fo:block margin="1em">We need to work closely with these testers who are emotionally invested and vulnerable to criticism. How they arrived at this behaviour is irrelevant. Two things we’ve found that help are to teach them prioritisation and to value quality over quantity.</fo:block>

Teach them to prioritise

<fo:block margin="1em">Ask them to rank bugs in the order they would like them fixed. If they struggle, begin by ranking one critical and one trivial bug. This forces them to understand some bugs are more important than others. Once they’re all ranked, discuss at which point we could release with the remaining bugs.</fo:block>

Value them

<fo:block margin="1em">Publicly acknowledge them for finding the good bugs. Let them see their good bugs being fixed. Recognise their less important bugs and use their prioritisation to explain why they won’t be fixed.</fo:block>

<fo:block margin="1em">Teach them how to find the important bugs … coming soon</fo:block>

<fo:block margin="1em"><fo:inline font-style="italic">…and they all lived happily ever after.</fo:inline></fo:block>
        
      
    
      
    
  

</fo:block>
    </fo:flow>
  </fo:page-sequence>
</fo:root>