Why test processes/documentation mostly are waste of time?

By mark

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.