Tag Archives: feedback

Five People and Their Thoughts (Part 6)

Some engaging articles I’d like to share today:

  • The Failures of ‘Intro to TDD’ (by Justin Searls, about classic test-driven development, code katas, what TDD’s primary benefit actually is, mocks, and discovery testing)
  • Branching is Easy. So? Git-flow Is Not Agile (by Camille Fournier, on Git, tooling, teams, developing software with agility, how easy it is to create feature branches with Git, and some reasons why you don’t need it)
  • What’s Wrong With Estimates? (by Yorgos Saslis, about estimates, why we are being asked to provide estimates, and the pitfalls of the ways we are using them)
  • A New Social Contract for Open Source (by Eran Hammer, on open-source, free code but paid time, sponsorship, making clear rules and specifying benefits, and sustainability)
  • Introducing Example Mapping (by Matt Wynne, about conversations to clarify and confirm acceptance criteria, feedback, colored index cards, and the benefits of writing examples when exploring a problem domain)

Light-Bulb Moments After Reading An Agile Testing Book

I recently finished reading Lisa Crispin and Janet Gregory’s ‘More Agile Testing‘ book and it made me think about problems that I think we need to take care of at work, some of which are:

  • Not enough specification by example before proceeding to coding phase. Although we do planning stages and have product owners that provide us with feature requirements written in statements, I feel that we often still don’t cover all the necessary examples required by our stories.
  • Zero automated unit and integration tests on complex legacy systems. This really hurts, especially on short testing iterations, because automated end-to-end regression tests can only do so much and manual acceptance tests are just not enough to provide a high level of confidence about system quality.
  • Technical debt. Rushed feature releases has left us very minimal time for refactoring sections of code that have always been a pain to develop and fix. Code reviews are usually non-existent too.
  • Minimal testing visibility outside the sprint team. Programmers I work with know how I do testing – my capacity and the quality of information I provide. Other members of the team do not see as much and this causes delayed feedback, and brings in a somewhat different set of problems – only the tester knows how much testing coverage has been reached, teammates do not know how to help, among others.