5 ms·

I think the valuable purpose you are describing of QA is better achieved by having a UX team earlier in the pipeline.

• davedx 7y ago
  We have both, and I'm really glad we do. A good QA team tests more than just "funtionality" and "usability" -- they test the product in its entirety, and notice all sorts of things that non-QA people would miss. Our QA people also often poke the database and look at REST request/responses too. I think going without this kind of full spectrum testing is just shooting yourself in the foot. You can totally do continuous delivery but still use a QA team.
• jedieaston 7y ago
  I always liked Basecamp's approach on this, which was that every team working on a widget (or part of a widget), had to be composed of 2 developers for 1 designer, so the designer was continually involved in whatever they were working on to give a UX perspective. https://basecamp.com/shapeup/2.2-chapter-08#team-and-project-sizes https://basecamp.com/shapeup/2.2-chapter-08#team-and-project...
• jayd16 7y ago
  I do support constant deployments to the QA environment (also a no-no apparently). That can keep the QA team involved at all times. I wouldn't suggest waiting on large changes before having QA do a pass.
  • stallmanite 7y ago
    Literally constant? As in whilst attempting to replicate a bug the software could change out from underneath the tester? Would that complicate things or am I misunderstanding something about the process?
    • jayd16 7y ago
      Hmm you're right. We CI to a dev environment that QA pulls in at their discretion.
      • hawaiianbrah 7y ago
        Do you mean you CD to a dev environment?
        • jayd16 7y ago
          yes
• andrethegiant 7y ago
  Shameless plug: I'm working on a tool that creates on-demand staging environments for the purpose of getting your UX team to give feedback earlier in the dev cycle. https://featurepeek.com https://featurepeek.com