I started thinking over the weekend about challenges I remember being set early in my testing career. Ones that were designed to appear simple on the outside but had hidden complexities once you started to dive deeper.
For the purposes of simplicity, letās say weāre all presented with this calculator.
What kind of information do you want to know about it?
Would you like to know how stable the site is, who could use it, how accurate it is, accessible, what problems users have with it, its costs, if itās compliant to standards, if itās connected to some other trackers/subsystems, what data it collects from you, how it compares with other calculators, how itās integrated, if itās compatible and what it is compatible with, identify what functions it has, see if you can stress it or the site, compare the online one with pocket calculator, verify itās functions, do we want to make a list of online calculators, do you care about the site or the functions of the site, or a single element - which one specifically? do you want to know if itās indexed and SEO score, do you want to find/trigger errors - what type? etcā¦etcā¦
To start testing you need a mission, otherwise, you have no start or end.
Have you decided yet what your mission is for us as tester(consider youāre a stakeholder)?
Thereās a bit of a difference between the product requirements/specs/use-cases and what a stakeholder requires from you.
Of course you can also test without a stakeholder requiring you anything, but for the purpose of efficiency/cost/speed, maybe youād want to only look after and reveal to him the problems or information about the product that he cares about.
Another parallel: Do you go to the doctor and ask for all the tests available, without telling him anything? Even though you actually feel like you have a cough and would like to know what chest/throat problems you might have.
Anyway, above I raised already some various testing ideas and information objectives which could be used as charters to start identifying problems with the application under test.
This post was intended as a bit of fun to get people thinking outside of the box, like all posts in the āHow To Testā category. Itās not something that people should feel an obligation to participate in if theyād rather not.
Iām very familiar with Cemās work having taken both BBST and RST training
Who is this testing this for?
Who are the intended users of this calculator? (Any group in specific this designed for?)
Is this going to be used as a āsoft calculatorā?
What would you like to find out?
Do you have any concerns in particular youād like tester to explore?
Is historical input info important to you? Or any of your users?
It may be confusing to some users as what/if they have clicked on a button. User experience can be made a lot better in comparations to other calculators
I would make some assumptions for starting my testing.
Seeing you donāt want to be the stakeholder, Iāll assume the owner of the site is the stakeholder. Without being able to contact him, Iām going to try to guess some of his intentionsā¦
Ideally youād have some clear goals of this owner.
The calculators seem to be the entry point to the site.
The purpose for the owner is most probably to gain some money out of ads.
Some things to test about the site could be around these topics:
the basic calculator operations are reasonably accurate, have similar display and interaction to other known calculators.
site is up most of the time - reliability of server and error handling of the apps;
google ads integration and ads blockers avoidance;
Heather - Iām laughing at all of the responses, as these are the type of questions we see on our team. But as my team regularly is given projects without definition - exploratory testing is the name of the game. Then we set requirements as we go.
So Iād start with clicking the buttons to see what they do. If I click on the 3, I expect a 3 to display, etc. Understanding basic calculator functions, I would make sure that those basic functions work - does 1 + 2 = 3? If not, we have a problem.
Interesting readingā¦ I am currently testing a calculator, with the difference being there are no manual input fields, values are selection only and it is a desktop based app. Our testing has to cover the visual display (on various devices, OS and DPI) and functionality (including the correct output). These requirements create a whole lot of complexity and additional testing. Doesnāt help when you have a really tight deadline and new test builds are being thrown at you regularly.
Iād start by asking myself these big questions and plan my test around the answers. Iād probably find more questions and answers as I started the actual testing.
What do I expect the calculator to do, and how will I know if it works? - add, subtract, multiply, divide, etc. - save values from memory, recall them, etc. - function in full screen mode or regular screen mode - etc.
What āunexpectedā user behaviors might break it? - double-clicking really quickly - typing letters instead of numbers - hold down a key longer than usual - etc.
What browser settings might break it? - using an ad blocker - changing security settings - disabling popups - etc
Can I break it by interrupting my internet connection or slowing down my internet speed?