What really difficult is for many companies to understand, is that in order for a test proces to be very effective, you'll need input to the test team that is really based on facts.
You can't test (or build) anything if the requirements are not very clear. They must never be ambigious, incomplete or very vague (or even incorrect).
Mind that: the reason why specifications are not clear can be because of an enormous amount of different causes. But that is not the point, they should always be as clear as possible. Otherwise the software testers can't do their jobs.
Now comes the hardest part: What really difficult is for CEO's, Managers and other business man is the way that they think:
"When I deliver facts to the developers and test team, then my results will be based on facts as well..."
And that is just NOT true!
The fact that Business Analysts worked 2 months to get the requirements clear, is NEVER a guarantee that the results of the testing on monday, will produce the exact same results if the tests would be repeated on tuesday.
(Testers need clear requirements more then anything, but.... they are not able to predict the future!!).
And the reasons why a test result on monday can have a different outcomes on the next day, is also enormous... But that is just not the point here... The main thing to understand is: Test results are NEVER facts...
It's better to see them just as 'a picture taken on a certain time, from a certain angle, with certain movement, that all in all give you some idea of what the status is.'
Try to understand:
Software testers need FACTS to be able to do their job, but the results of their work is NEVER a fact!
120 unieke bezoekers per week.
Uw banner ook hier?
Dat kan voor weinig.
Tweet naar @testensoftware
This website uses marketing and tracking technologies. Opting out of this will opt you out of all cookies, except for those needed to run the website. Note that some products may not work as well without tracking cookies.Opt Out of Cookies