Mathias Bogaert
Posts: 618
Nickname: pathos
Registered: Aug, 2003
|
Mathias Bogaert is a senior software architect at Intrasoft mainly doing projects for the EC.
|
|
|
|
Revealing Oracles
|
Posted: Mar 2, 2012 10:19 AM
|
|
|
This post originated from an RSS feed registered with Java Buzz
by Mathias Bogaert.
|
Original Post: Revealing Oracles
Feed Title: Scuttlebutt
Feed URL: http://feeds.feedburner.com/AtlassianDeveloperBlog
Feed Description: tech gossip by mathias
|
Latest Java Buzz Posts
Latest Java Buzz Posts by Mathias Bogaert
Latest Posts From Scuttlebutt
|
|
This guest blog post is part of an Atlassian blog series raising awareness about testing innovation within the QA community. You can find the other posts in this series under the QA Innovation tag. This post is written by Anne-Marie Charrett, a testing coach and trainer with a passion for helping testers discover their testing strengths and become the testers they aspire to be. “An oracle is a principle or mechanism by which you recognize a problem.”(1) Oracles can be found everywhere. Take a look at this ad below: By comparing a taxi ride to a plane journey, the ad successfully highlights the unfairness of charging for cargo baggage. They then use this as a selling point for their airline. We use oracles in testing to discover bugs. We can’t test without them. If you test you’ve used oracles. If you’ve found bugs, you’ve used an oracle. A popular but limited test oracle is the product requirements. By comparing the product being tested to the requirements, helps us to identify problems either with the product or with the requirements. This can be limiting because requirements are often incomplete, out of date or non-existent. Fortunately, there are many other oracles available to us in testing(2). Even when requirements appear complete, testers often unknowingly use other oracles. Examples of other oracles may be a different version of the product, a customer support ticket or a user manual. If you’ve ever raised a bug outside requirements you’ve used a different oracle. Its not always easy to recognize potential problems and testability goes a long way to helping you create oracles. It takes skill to be able to develop your own oracles but this is essential skill if you want to be a skilled tester. It’s helpful to have a taxonomy of oracles to call on when needed. Fortunately, testers such as Cem Kaner, James Bach, Michael Bolton and Doug Hoffman(3) have systematically examined oracles and have made this knowledge available for other testers to use. Bug reports become more credible when you know your oracle. Instead of relying on tester opinion or intuition – describe a bug in terms of the oracle you used. Compare: “the form on this webpage is unfriendly” to “I compared this form to our competitors. They use less steps to complete the process, and in my opinion this makes the page less friendly to use”. The first bug report relies on opinion only. The second bug report uses a “consistency with comparable product” oracle to help explain my decision making. This makes for a more persuasive bug report. To recognize problems that interest our stakeholders requires their input. Easier said than done when often stakeholders are not available, they don’t know themselves what they want or its impractical to ask them and often as tester’s we end up making best case assumptions. Tester’s have to be brave enough to go beyond what stakeholders see as problems. We’re there to “see” stuff that others don’t”. We’re there to question, to discover dilemmas. [...]
Read: Revealing Oracles
|
|
Previous Topic
