Recently I was reflecting on the many different occasions on projects where I’d witnessed assumptions being made regarding test and project strategies as an acceptable practice. Situations such as the following :-
1) Maintaining test environments with unmonitored and, as a result, unknown and unrepeatable data, under the assumption that it is the functionality of the application that is important and the data it is fed is immaterial.
2) Testing end user sessions on a different platform, under the assumption that there will be very little difference in functionality (”Firefox on Ubuntu is the same as on Windows”)
3) Pointing new-starters to a wiki-page, under the assumption that anything else they need to know shall be relayed by ‘asking around’
4) Arranging development teams such that each person only has deep understanding of one part of the system, under the assumption that all issues that arise will be easily solved by experts collaborating at short notice.
5) Loading test environments with various non-production-like configurations, under the assumption that removing them and accessing the system from an external network will be exactly the same as interaction from an end user
6) Writing test suites and user acceptance scenarios without involving the business, under the assumption that the dev and test teams know how the end user will interact with the application just as much as the business
7) Remaining with a project strategy that clearly isn’t working, under the assumption that because everyone knows how it works it cannot be improved
8 ) Believing that exploratory testing involves dividing up areas of the system for QAs to play with for a few days, under the assumption that it shall be as effective as the clearly defined, structured practice outlined by Cem Kaner & co.
9) Writing automation test suites with no clear structure or framework, under the assumption that this produces a full regression suite and the product is thus well tested.
All the above examples are illustrations of assumptions that have been made on the SDLC. Each one lowers the quality bar and introduces unknown levels of doubt to the project model.
Whilst it is perfectly understandable and normal that cost, time and resource restrictions always play a part in the decision-making for and during a project (e.g. building a smaller test environment than the production equivalent due to financial constraints, removing functionality from the backlog in order to release earlier), these are value-based decisions with a known consequence.
There is a clear dividing line between these project decisions, based on factual origins and known consequences, and those based on unfounded assumptions producing unknown results. The latter is where quality is lost in projects.
