Testing in a Dirty System (Environment)

Means by “dirty environment”

If you are accustomed to work in a systematical process, understanding the meaning of “dirty system” may be difficult because I am such a person. However, a dirty system can be explained by this; normally traditional, agile or iterative software development methodologies has stages like analysis, development, implementation and testing; every stage has responsible so that every groups produce an output and then finally a software production is come out. As a test engineer, every output can be tested or used as inputs to test another output but if you don’t have an inputs, you will have to face a dirty system. To sum up; a dirty system is a development environment which may possibly has no requirements and/or analysis and/or reference points, lack of documentations, lack of a repeatable test process, even the programmers had already quit the job or there is no testing environment for some test cases. Also we can comment on the place of the group of testing/QA in your organization, because your group might be not considered by your boss/director or whoever want to control you as important role as you did so this can cause demoralization. If you are a test engineer, quality assurance engineer or whatever role you have in QA team, your responsibility is clear; which you have to define the defects or anything leading defects, and report them, and make them eligible for every responsible in the group.

What does Randall W. Rice suggest in his book named "Testing Dirty Systems", he solves the problem by spend the testing time of 1/3 for working on how to run the test cases and the 2/3 of the testing time for execution of the test cases. But the quality of the test can be as good as the quality of your testing environment. And He also divides the testing process for a dirty system into 6 steps testing activities which are shown in the following table:


In conjunction with the definition of the smart in terms of testing by Ivar Jacobson, test engineer in the un-smart environment works as a collector of developer but in a smart environment test engineer is very welcomed people. The definition by Jacobson is below
  • Unsmart with Testing – having two classes of people – developers and testers. Unsmart projects testers are “the cleaners in the software world” – picking up the mess left by the developers
  • Smart with Testing – the whole team is jointly responsible for quality and testers are first-class citizens


Popular posts from this blog

Selenium Error "Element is not currently interactable and may not be manipulated"

Change Default Timeout and Wait Time of Capybara

Page-Object Pattern for Selenium Test Automation with Python

Performance Testing on CI: Locust is running on Jenkins

How to Set Shared Preferences in Espresso Test for Kotlin and Java