DEV Community

The Joel Test: 20 Years Later

Alex Fawkes on December 19, 2018

I'm getting a head start on celebrating the two-decade anniversary of The Joel Test. If you haven't heard of Joel Spolsky, or otherwise live under ...
Collapse
 
shalomb profile image
Shalom Bhooshi

So either you don't test, and you lose users, or developers end up doing the testing, which is like having surgeons clean the bedpans. That way there's no need to hire additional nursing staff!

Yeowch - I get the points about relying solely on automated testing but this one statement I really take issue with. Having worked as in QA/QE and in busy Operations, it really irks me that this is how Developers view their role as too-good-to-do-the-dirty work and consider the folks who pick up the excuse-my-french as beneath them. What's worse - most management seem to set this up as acceptable and perpetuate it.

Even in a setting with manual testers, the right thing to do is put everyone on the same stead and shift-left the testing concerns so QA are at the table when development is scoped out and the overhead is distributed with Developers doing the responsible upfront testing (TDD/BDD, Code Coverage, Unit/Integration and in cases Scale/Systems/E2E testing as well) and QA "assuring" Quality (Validation/Verification, Exploratory/Ad-Hoc Testing, Hard-to-automate testing).

So either you don't test, and you lose users ..

This is so undeniably true but manual QA isn't the escape hatch to the problem however - that leads to an upside down test pyramid and really slow delivery and grumpy engineers all over. Both automated and manual testing still have a place with sensible division of QA responsibilities across Dev and Manual Testers (arguably Ops as well if you buy into SRE/CRE).

Collapse
 
rnowif profile image
Renaud Humbert-Labeaumaz

I'm totally on board with what you just said. I am a developer but I don't think QA is a lesser job than a developer. A good QA is at least as valuable as a good developer and a bad QA is as dangerous as a bad developer.

Collapse
 
kyleljohnson profile image
Kyle Johnson
  1. Git is garbage - IMO
  2. Yes
  3. This assumes you have a separate development branch but ok. Yes. My TFS build/release pipeline runs on check-in of code.
  4. This assumes your software has bugs but if you do UAT (User Acceptance Testing) (I'm getting to this) then you virtually eliminate bugs. If you use TFS you don't need a separate bug database.
  5. Fix code before and while writing new code. Yes.
  6. Yes. This is actually a great point and practice. It hold developers accountable.
  7. No. Agile development is against written specs. User stories and lots of collaboration.
  8. Yes. I would love to have a door I could close.
  9. Yes. VS baby!
  10. Yes. The actual users. I will make my UAT point here. I'm not bashing QA folks but if you stress developer unit testing and set a UAT/QA culture you can get away with not having a separate QA team. It is better to have the people that will be using the software every day testing the software making sure requirements are met. While I will admit this opens yourself up to scope creep and a long UAT/QA phase but when your software finally make it to production it is essentially bug-free and you don't get feature requests for at least 6 months. Living the dream.
  11. You are crazy not to these days. This is why I love TFS. You get requirements, project, build and release management ALL-IN-ONE!
  12. My next hire will write code. BEWARE.
  13. Yes and it's amazing when it works.

Full disclosure: I'm a software development manager at a large company.

Collapse
 
jamie_hollern_33c987acbb7 profile image
Jamie Hollern

This blog comes up at number 2 for the search "Joel Test" on Google, and I've read it a few times since it was originally written. I smiled when I read point 8 (quiet working conditions) - written in a time before a pandemic had started a shift for many to remote working. Of course, the point is still just as relevant now.