Testers, what is your favourite thing to test, and why?
I love a text input field.
They are quite simplistic, yet there is so much to them!
What are the minimum and maximum lengths? Can it be overloaded?
Are there any restricted characters? What about emojis?
What happens with leading or trailing spaces? Are they trimmed? Blocked?
What error messages can you trigger?
Is there pre-populated text?
Please share what yours is. Maybe I and others will learn about things to test we haven’t heard of before!
Share here and on Lee’s LinkedIn post (if you’re on LinkedIn).
I typically can develop a tool to process and compare the data
as it do it iterativ, by the needs I found myself and the project having during the journey, it goes fast and is perfectly tailored. I can add anything I find useful.
make the data more human readable (e.g. replacing numbers with their enum string values)
it is still much space left for exploration, trying out different scenarios. The tool … is just a tool, not a replacement of people.
data is most time easy track- and traceable
it is about testing big parts of a system in my cases. Errors in the output can result from bugs at nearly any place of the systems I work with.
I really like the mixture of creating my tool on the journey while testing. And then having a satisfying tool.
Because, you will never get a second chance to make a first impression.
And, the same will also apply to the apps that we are testing.
What do I do to do this?
Assume the persona of a literal beginner. In some cases, can also get someone not from the project.
Try to navigate through the flow on your own. Asking questions to self? Is it clear? Is it what I expect from this app?
Think of myself as a potential buyer of this app who is worried if this app is really genuine and then look for slopiness or typo kind of bugs in the app.
Just cover the entire flow and expect the app to recover smartly from any mild nuances.
Extremely well coded applications. Why? I don’t want to spend all day reporting low-level dross that should never have made it as far as me. I want to have to work really hard to find bugs, and I’m not happy unless I’m pushing myself to the limit. That’s how you learn, or at least one way.
I love to investigate so called “intermittent faults”, especially if they result in data loss or corruption. Why? Because extremely few faults genuinely are intermittent. Almost every fault is 100% repeatable once you find the root cause. If a bug appears to be intermittent, it usually means there are one or more factors that you are not taking into account. The challenge is to identify, measure and control them. And that’s really hard if you don’t know what they are.
People’s patience. Why? Payback for testing mine, although it will never be enough.
My favorite thing to test is user interfaces (UI) because it’s where functionality meets design, and small details can greatly impact user experience. Testing UI allows me to ensure that an application is not only working as intended but also intuitive and enjoyable for users. I enjoy catching those subtle issues that might disrupt a seamless experience, like responsiveness, alignment, or accessibility, and making sure the final product feels polished and user-friendly.
A complex application that spans over a lot of different parts of a big system, where my appetite for learning broad rather than deep becomes really useful. Sometimes I am recruited as an architect bc I know how everything works together. Being a guru on some little complex part does not rock my boat.