4 ms·

If you remove the word 'perfectly', you're just saying that a dedicated QA team is cheaper than writing tests. I doubt that very much.

taeric 13y ago
You'd be surprised. Consider the effort many game studios go through to get the testing done on a game before release. It is a pipe dream to think that everything can have a full automated test suite written for it. I suspect that the only things this is true for, are things which have been written so many times as to be almost trivial. (Not that we don't make enough mistakes on those systems...) Though, maybe you were just questioning the "perfectly" portion. I mean "perfectly" in the sense of "validates all of the user's requirements." Not in the "covers all paths" or "anticipates all possible scenarios." Consider, crash test dummies. This is a form of testing that is far far far more expensive than having a complete model of the system. Yet, we still do them. We do not rely solely on them, you say? Of course not. Apologies if it sounded like that was my point. Edit: Also, it is also possible to use traditional QA tools without having a fully dedicated team. That is to say, unit tests are not a QA tool. Yet, we constantly try to replace the QA team with them.
- engrenage 13y ago
  You are proposing QA as an alternative to writing tests. That makes no sense. They serve different purposes.
  - taeric 13y ago
    Nonsense. I am proposing QA teams and tools in addition to all of the other tools that a development team uses. If you, as a developer, are having a hard time testing something, ask QA how they would test it. Make sure they will be able to test it. If after that interaction (or before) there is an easy way to construct your model such that this can be fully automated, do so. But, essentially, make sure you are working with QA. This would be akin to a football team ignoring the special teams and not considering them in any decisions. Sure, if you have a perfect offence this will work. Most of us do not. Edit: So, not sure why I began with "nonsense." Apologies for the tone on that.
    - engrenage 13y ago
      So your comments have nothing to do with testing in clojure or even code level automated testing in general, and this is just you telling 'most developers' that you think they should work with QA more?
      - taeric 13y ago
        Well... I jumped in at the discussion pivot regarding the concern over "writing fewer tests" being difficult. My point was simply if you want some good leads on which tests you need to focus on, coordinate with QA. Development shops tend to work in isolation to QA. Often, there is a sense of hostility between the groups. This makes zero sense. So, my point is to emphasis that all of the tools my direct pivot discussed were not necessarily created by the pilots/doctors/etc. Instead of the emphasis being on "having smart programmers that write lots of tests," lets move it to "having programmers that focus tests on problematic areas with insite gained from other teams." (That make sense?)

taeric 13y ago

You'd be surprised. Consider the effort many game studios go through to get the testing done on a game before release. It is a pipe dream to think that everything can have a full automated test suite written for it. I suspect that the only things this is true for, are things which have been written so many times as to be almost trivial. (Not that we don't make enough mistakes on those systems...) Though, maybe you were just questioning the "perfectly" portion. I mean "perfectly" in the sense of "validates all of the user's requirements." Not in the "covers all paths" or "anticipates all possible scenarios." Consider, crash test dummies. This is a form of testing that is far far far more expensive than having a complete model of the system. Yet, we still do them. We do not rely solely on them, you say? Of course not. Apologies if it sounded like that was my point. Edit: Also, it is also possible to use traditional QA tools without having a fully dedicated team. That is to say, unit tests are not a QA tool. Yet, we constantly try to replace the QA team with them.

engrenage 13y ago
You are proposing QA as an alternative to writing tests. That makes no sense. They serve different purposes.
- taeric 13y ago
  Nonsense. I am proposing QA teams and tools in addition to all of the other tools that a development team uses. If you, as a developer, are having a hard time testing something, ask QA how they would test it. Make sure they will be able to test it. If after that interaction (or before) there is an easy way to construct your model such that this can be fully automated, do so. But, essentially, make sure you are working with QA. This would be akin to a football team ignoring the special teams and not considering them in any decisions. Sure, if you have a perfect offence this will work. Most of us do not. Edit: So, not sure why I began with "nonsense." Apologies for the tone on that.
  - engrenage 13y ago
    So your comments have nothing to do with testing in clojure or even code level automated testing in general, and this is just you telling 'most developers' that you think they should work with QA more?
    - taeric 13y ago
      Well... I jumped in at the discussion pivot regarding the concern over "writing fewer tests" being difficult. My point was simply if you want some good leads on which tests you need to focus on, coordinate with QA. Development shops tend to work in isolation to QA. Often, there is a sense of hostility between the groups. This makes zero sense. So, my point is to emphasis that all of the tools my direct pivot discussed were not necessarily created by the pilots/doctors/etc. Instead of the emphasis being on "having smart programmers that write lots of tests," lets move it to "having programmers that focus tests on problematic areas with insite gained from other teams." (That make sense?)