Having tested a lot of programs that create, read, and update data, I now have a quick attack toolkit that I can use to test out these apps. As I do these, I’m also learning a lot about the app and generating other test ideas, but these basic quick attacks often come up with a bug or two.
Atomic recently hosted a couple of students from the Kent County ISD doing a job shadow as part of the Groundhog Shadow Day. They spent an hour at a time with different people at Atomic, and I volunteered to be one of the people to be followed and questioned. It was a fun experience, made a nice change to the workday and was even productive as I was able to use them for some quick ad-hoc usability testing on one of the apps I was testing.
There, that was a simple blog post to write.
Well, some testers think it’s that simple, but there’s a more useful approach. To help remember it, use the RIMGEA testing mnemonic coined by Dr. Cem Kaner: Replicate it, Isolate it, Maximize it, Generalize it, Externalize it, And Say it Clearly and Dispassionately. Read more on I Found a Bug, What Next?…
Spell chequers are grate butt bee careful ore ewe mite still have sum miss steaks.
No, that’s not right.
Spell checkers are great but be careful or you might still have some mistakes.
That’s better; still not what I wanted though. Why is the “careful” bold? Read more on Spilling Cheques – On the Limitations of Testing Tools…
In my first few months after moving to Grand Rapids, I was a regular attendee at the monthly GR Tester Meetup. Swapping war stories about the latest bug you’ve found and the new devious way to crash an app was an easy way to meet new people. I’ve continued to try and attend these events as not only have I made friends there, but it’s a good way of learning more about my craft.
I have, however, also tried expanding my horizons and opened up to other disciplines and people — and luckily Grand Rapids offers a lot of opportunities.
One of the exploratory testing techniques I use is a ‘Follow The Data’ tour. For this test I follow a piece of data through the system from where it’s first introduced to where it’s stored, wherever it’s used, and where it’s displayed.
As well as checking that the data is actually used (there are times when input that is carefully validated is never actually used by the system) this technique can also lead to further test ideas.
If you find that the data is printed out, this can give you a test about whether non-printable characters can form part of the data. And if so, what happens to them? How long can the data be? What happens to the printout when the maximum length of data is used? will it wrap or print off the page or obscure other parts of the printout? Read more on Follow the Data…
Atomic Object is looking to hire two developers — junior or senior — in our Grand Rapids office. We’re also hiring designers and developers in Ann Arbor and Detroit.
What does Atomic do?
We create custom software products — mobile, web, desktop and embedded — for clients ranging from startups to the Fortune 500. Our typical projects are large and complex. Our success relies on smart designers and developers who can collaborate closely and work on self-managed teams to produce quality software that our clients love.
Why work at Atomic?
Here are a few more reasons why you should be considering working here: Read more on Hiring Developers in Grand Rapids, Ann Arbor & Detroit…
I recently read about what might be one of the worst movies ever made and clicked through to read some reviews and find out why it was so bad. Doing so, I discovered a list of bloopers appearing the film.
Reading about these bloopers was really useful and reminded me about some of the test techniques I use. Read more on Lights, Camera, Action, Bugs!…
As a tester, I learned the standard test techniques of boundary conditions, equivalence classes, state models, path analysis but I’m always on the look-out for new test ideas, how things can go wrong and the ways that people can use things that were never thought of.