Testing

• What's wrong with: "I dont write any tests since I am not a tester"? How to change their behavior?
  • A. Work on yourself before trying to change others. consider for yourself:
    • Why is the suggested practice/tool any better than the current way of doing things?
    • Can you explain the value in the proposed change?
    • Can you lead by example?
    • Do you have enough patience and skills to teach others?
  • B. Roles
    • In a Scrum context, there is no "tester", "programmer" or "architect", we are all professional engineers that deliver value through collaboration
    • I see this a lot, that people are focused on their role or job title, forgetting the bigger picture of the team and purpose of the work they are doing
    • Are we 1 team that focuses on the Sprint Goal?
    • No matter what, do we stand together and support each other?
    • Are we doing whatever is necessary to deliver a usable product every Sprint?
  • C. Done?
    • "How do you know when you are done?"
    • What is on our Definition of Done?
    • How can we build a usable, tested and fully integrated product increment every Sprint?
    • Are we doing that already? Why not?
  • D. Tests are as important as documentation
    • Documentation is needed, and one good way to document how software *must work are tests
    • I emphasize must since documentation only documents how the software might work
    • We learned too often that documentation gets out of sync too easily
  • E. Quality
    • Quality is everyone's responsibility in a Scrum Team
      • There is no QA Team in a Scrum context, which means the whole Scrum Team is responsible for delivering high-quality software that works and is fully tested
    • Quality attributes that are important
      • Does it work at all? Does it work well?
      • Is it deployed and usable? Are the users able to access it?
      • Is it useful? Is it successful? Does it make the impact we wanted? -> Value is key
• Reasons why you should write tests in the first place
  • You get a bug report and want proof when the bug is fixed: This is a good practice before fixing bugs
  • You implement a new feature and write a test beforehand to see when the new feature is done
  • You want to prevent regression
    • As an agile developer, you change code all the time, either because
      • You do TDD
      • You follow the Boy Scout rule and refactor your code
      • Your client/customer changes his mind (which is even more likely)
    • Changes in your code will break other code. So you have a test around it to know if everything is still green (=OK)
  • Documentation goes out of date sooner or later
    • Tests document how the system works and additionally they are executable
    • Note about “documentation” vs “tests”
      • Documentation normally describes what the system should or might do
      • Tests describe and make sure what the system does do
• Reasons for automated tests
  • Are tests that run on certain events on a certain machine. Typically on a build server on check in
  • Continuous integration follows this practice
  • A. Faster feedback
    • everyone can immediately see if the latest code change, broke something
  • B. Saves time
    • Testing is boring, repetitive, humans are slow, and needs to be done very often during the day
  • C. Safety net for code changes
    • Because of this fast feedback that we get from tests, we are not afraid to change our code
    • Although we should "Never change a running system", with tests we can easily verify if our change broke something
  • D. Testers are humans, and humans make mistakes
    • A tester will decide what to test, and what not. He will maybe make mistakes during testing
• Agile Testing: A Practical Guide for Testers and Agile Teams: 7Key Factors for Agile Testing Success
  • Use the Whole Team Approach
  • Adopt an agile testing mindset
  • Automate regression testing
  • Provide and obtain feedback
  • Build a foundation of core agile practices
  • Collaborate with customer
  • Look at the big picture