2015 Agile Testing Days

Created by Tim Steffens, last modified on Jul 18, 2016

Here are some of my learnings, inspirations and thoughts from the Agile Testing Days 2015 in Potsdam:

Exploratory Testing

Let's make exploratory testing part of our sprint cycle - everybody from the team should be involved!

  • Automated tests are not sufficient when dealing with an application that has a UI. 
    • Manual (and especially exploratory) testing can reveal bugs you would never have found with automated test.
  • Exploratory testing can be faster then traditional up-front planned tests.
    • Your gut-feeling can lead you quickly to the unstable parts of your software (associations when using the software, experience, knowledge of prior bugs etc.).
  • Exploratory testing must be done in a systematic and documented manner.
  • Exploratory test sessions can be very productive, if the whole team (and other relevant stakeholders) participates.
    • Different angles reveal more bugs!
    • Exploratory testing knowledge is spread.
    • Using & feeling your software gives you important insights!
    • See Exploratory Testing with the Team
  • Exploratory Testing might show you the need to improve parts of your automated tests

Related sessions:

Test Automation

  • At least one organization is happy with the Ice Cream Cone (see Quality Continuously Delivered) (big grin)
  • without IDE support Cucumber tests are very difficult to understand (from a technical point of view)
  • Test your Infrastructure
    • Code used for deployment automation is also code!
      • It has to be tested as well!
    • There are tools like kitchen and rspec to automate the tests for your infrastructure code (on integration level) - see Infrastructure under the Magnifying Glass
    • Unit Tests for deployment scripts make sense as well! (As soon as there are conditions & branches)
    • We should run tests for infrastructure code on each checkin
  • Think about employing properties based testing (Properties Based Testing)

Related sessions:

Product Development

  • Stop thinking that delivering software is the target.
    • ROI / earning money is the target!
  • Get fast feedback on impact (e.g. customer behaviour, production results, error rates ...).
  • Make ROI-Flow explicit and acknowledge all hypotheses
  • Prove that requirements are valuable
  • Build experiments that prove / disprove your assumptions
  • innovation lab => prove ideas in one week (with immediate customer feedback) 
  • software quality is limited by how well people creating software know what they want

Related Sessions:

Teaming & Agile Organization

  • "A good leader must be a good listener"
  • Embrace failure and be open about it
  • Help people make mistakes to get better
  • Be of service to your colleagues, give them a frame to flourish
    • Even offer help to your boss
  • Have fun at work, the smile-measure is important
  • Try to get out of comfort zone => new possibilities
    • e.g. make Java Developers use another language
    • break patterns
    • learn new approaches
  • Stress is necessary for developing stability (The tree-without-wind-thing)
  • Slow down: developers produce shit under pressure
  • As a manager you should trust to your developers (they want to do the right thing)
  • change starts with me

Related Sessions:

Personal

  • You can make a change, if you devote yourself to something.
    • This may open new worlds for yourself.
  • Changing the world is an acquired skill

Related Sessions:

General

  • Become aware of your assumptions & biases
    • document them
    • communicate them
  • don't try to anticipate all errors
    • do not recovers
    • create & monitor logs
  • Software craftsmanship from day 1
  • https://bitnami.com is an interesting cloud-platform

Related Sessions:

Tims personal TODOs: