Firstly here are some facts:
- Regression testing is most time consuming
- Testers generally don't like writing test steps in word-processing tools
- New generations who get used to YouTube nowadays have less attention span on reading texts.
Logically, a test process shall address to the biggest hurdle test teams face: regression testing. Sadly, I never see one even bother to mention it (and rarely mentioned at software testing conferences).
Let's say, a project follows a process, test plan, test design (in Word), after peer review, test executions, ..., etc. X number of defects were found. Now a new build comes, which includes several change requests of some new or updated functions besides bug fixes. Now as a test manager, do you ask your team just re-test bug fixes or a full regression test? As we all know, programmers do introduce accidental changes. The so-called standard process or documentation won't help you there. (In projects adopting agile or iterative methods, a new build comes out frequently).
My point: without effective and sustainable regression testing, testing processes lack of foundation.
Also consider this:
- How confident are you that ensure all testers update the test design/test steps to reflect new changes made to the system?
- How to prevent misunderstandings from reading the same test design document?
What's the solution? My answer is simple: executing tests as a part of Continuous Integration. As Lisa Crispin pointed out It would just be crazy to not do it (CI)". With tests being continuously executed in CI, then your test design/scripts are living things, not just lifeless paper documents.