These days reality of software development is completely different from the era of waterfall model. In water fall model software development model all the requirements are documented and frozen before implementation. Client is not allowed to change the requirements. But these days no one has time to wait for so long else there are competitors who bring the product faster and capture the maximum market.
I wonder the day would come where client would say that I have only 60 minutes to develop this product and I pay you billion dollars for it. Can you imagine the chaos? People are finding these days hard to spend resources on requirement phase. As agile methodology emphasize on less document work. All the communication taken place through mails and chat. Client keeps asking for new features and architecture keeps changing technology as it does not fit in the existing technology.
Now the main challenge is faced by the development team who implements the requirements and Test team who test the application. I think it’s main concern to both because they find lost in the chaos. In this chaos tester complains that without requirement document how can I raise a bug?
I wonder having said correct requirement would solve the problem of having good oracles with us. Isn’t it these oracles are used to win the dispute with developer if the requirements are correct and they implemented differently? But think again does it solve the real problem.
I think its bliss not to have written requirement. Project takes turn as you grow and keep changing till the customer is not satisfied. What is a use of the software if it does not solve the real problem inspite of you having clear precise requirement document. There are crucial projects like NASA or medical software for which extensive documentation might be helpful.
Oracle: is the principle or mechanism by which the tester recognizes the problem
Let’s assume that you are a tester of a project where you don’t have good enough oracles. Now how do you raise a bug? What kind of oracles you would use? How do you know that it’s valid bug?
May be below few questions would help you to some extend:
- What is the real problem this application is trying to solve?
- Is there a bug repository? Can I find some pattern in bugs?
- Can you access the application? Is it possible to explore and learn the application?
- Can I imagine and act like a real user?
- Do I really understand the quality criteria for the software?
- Search for tacit knowledge
- Discuss with developers, product owners, leads or senior stakeholders
And the last most important thing is use Michael Bolton’s heuristic HICCUPPS to kick start testing for such kind of projects.