Last Friday I attended a presentation hosted by some client IT people for their colleagues (same company, same department). The aim of this presentation was to show "improvements in development process" the presenters have introduced in their project. It was a common knowledge that their had major quality issues in the team and they somehow managed to handle it (at least reduce it). After getting familiar with their ideas - I have to admit I’m disgusted.
Here’s what they came up with:
- It’s bad to rely on developer’s tests as developers are always in hurry, because they have next tasks in queue (!)
- Developers don’t understand well the context of what they do, so they are not the proper people to do any tests (!!)
- Developers think only about the proper way to use the software they made and that’s why they don’t test the negative conditions / scenarios (!!!)
Looks hilarious? Wait until you see what they’ve proposed to do to fix that…
- When developer think his job is done (code is ready) he asks an analyst to come to developer’s PC and test the software there (before any commit…). (FACEPALM)
- They decided to do first wave of tests on development environments, because compilation in CI rig takes a lot of time (and they break it quite often). (FACEPALM x2)
- They insist that they are facing a special, very difficult scenario, because sometimes they can see their test results after End-of-Month processing (so they have to wait for it…). (FACEPALM x3)
Honestly, it’s just the essence of cr@p I’ve heard and even if it happened few days ago, I’m still boiling inside. I was amazed that they got any quality improvement anyway, until I’ve heard that they’ve discovered “peer-review” (at least one reasonable decision).
I will leave all that without any more comments. For you own consideration.