TL;DR

Feedback in the project is crucial because it helps us to know project status. We explain what is common to project feedback and software testing. Read another post from the project management series. The post is based on a remarkable book written by Johanna Rothman, Manage It!

Without feedback, we do not know project status. Feedback informs us about project risks and how much is done.

The first time when a developer receives feedback on his code is during testing.

That testing could be done by a developer or a software tester. Serial lifecycles are predictive one because, in those lifecycles, developers receive feedback very late. On the other side of the spectrum is the agile lifecycle, when we receive feedback very early in each timebox. This is what makes agile so successful. In Agile in each timebox, we have two feedback loops.

Constant Feedback

Constant feedback is when the developer tests their code. It actually tests its own design concept, this is why we call this test-driven development. Developers usually use the testing framework of their choice (e.g. for Elixir project I use Espec) and test their concept by writing first failing test code, then code, and then code refactor:

Or as I do, by writing first failing code, then passing test, and then refactor:

By running the code using a testing framework, developers get run results or feedback. I often hear tester complaints that developers only test happy paths. But this is due to the project definition of done. If you put in the developer definition of done all the error codes, then he would also write tests for those cases.

Iteration Feedback

This feedback is done at the end of the day, timebox (sprint) demo, or at the release. Here testers do their magic. That magic is more effective if it is applied as often as possible (daily, sprint, or release).