Comments by "" (@ContinuousDelivery) on "Where Do The Software Bugs Come From?" video.

  1. One persons "nah, you're just being a perfectionist" is most people's "why has my project ground to a halt and I can't change anything any more?" 😉
    23
  2. I think I said that in the video, not the names, I don’t much care if you call testers testers or QA people, but separate testing teams is certainly an anti-pattern.
    8
  3. I did say "less constrained" not "unconstrained" 😉
    6
  4. ​ @jimhumelsine9187  I guess the point that I am trying to make is that to me the requirements don't "belong" to someone else, they are owned by the development team. Sure, other people can suggest changes, but if the developers don't understand the problem well enough to build software that is in some sense functionally coherent that is still a development problem to me. The developers are the ones that are closest to the solution, whatever that may be. The problem specified may be the wrong problem to fix, and I think that is something that can be sensibly outside of the development team, but whatever software we create needs to make sense within our understanding of the problem and its solution. So that means that, to me, a "bug" is something that is within our understanding of the system but where it doesn't work properly in some way. Missing something in the requirements is a gap in our understanding of the system, but not really a bug, by that definition. Sure, pragmatically what I have described is not how lots of teams work, but I still think it makes sense as a model. So I aim to ensure that the system works, by which I mean that it fulfils all of the behavioural needs that we have identified, and got around to implementing so far. We will inevitably still miss things, but if they cause a failure on the delivery of the behaviour of the system that we have so far they are bugs, and if they are gaps in our understanding of the requirements I'd see those as "yet to be delivered features". I think that makes sense?
    5
  5. That is true, but what we can do is to take control of the things that we are in control of, and not abdicate responsibility for those things. I often see dev teams convincing themselves that they need to cut corners on quality. Few managers will say that explicitly, so take them at their word and take the time to build high quality software. We devs choose to cut corners because we are buying in to the wrong idea that that will save time, it won't. So if you manager says "we need to go fast" then work with quality because that is fastest!
    4
  6. The requirements can't put the bugs into the code, only developers can do that. The requirements may be terrible, and make it hard for the developer to understand the problem well, but it is still the developer who puts the bugs into the code.
    4
  7. 💯! I want to test all the awkward cases.
    2
  8. They all happen then, they may not be noticed till later if your tests are poor.
    2
  9. Checkout several of my older videos. My first on the channel was exactly that, but the sound and video editing has improved since https://youtu.be/xUi2951ufaw
    2
  10. In that case, I am not sure that it could 🤣
    2
  11. Thank you, I am pleased that you find them helpful.
    2
  12. Well, at least some of the data says he is wrong. But I agree that you should test that stuff. I think that unit testing alone is not enough and that functional testing alone is not enough, you need both. In my "Continuous Delivery" and "CD Pipelines" books I describe a deployment pipeline that includes both "Commit stage" testing (mostly unit tests) and "Acceptance stage" testing (functional tests). There is a play-list of videos on this channel on Acceptance testing and BDD that will describe the tests that find the config errors.
    1
  13. Thanks
    1
  14. Thanks
    1