"Drive by" testing

🙋 Questions
, ,
1

Bruce Lawson wrote about “Drive by accessibility tweaks”

Sometimes, if I’m fixing an unrelated bug I spot the opportunity to make a quick “drive-by” accessibility tweak that is quick and easy and will give a disproportionately big boost to the user experience for people with accessibility needs.

It got me thinking about whether it’s possible to do this through our daily testing activities?

It becomes more challenging if, as testers, we are unable to code, but maybe there are ways around it with pairing? Or is it possible to coach devs to look out for these things?

Posting here to see if anyone tackles this and has a story to share. :slight_smile:

1 Like
2

This is no different to the ‘scout’ rule of leaving things better than how you found them, and I believe that extends to a11y opportunities too.

3 Likes
3

Isn’t that what happens every time we’re exploring and find something odd that isn’t necessarily in our charter for the session?

4

Yes, I guess the difference is that as testers we aren’t always able to fix it there and then.

5

It is always great when you notice some bugs that are not related to your current test activities (e.g. which are relevant for prod), and because you’re already testing some changes in a feature, I always ask devs if they can fix it in the current feature branch but only if it is not bug-risky, simple, takes several minutes to fix, and there won’t be any regression. Otherwise, it’ll go as a separate ticket. The same goes for software accessibility. But you can’t add dozens of such small tweaks every time because they might be small, and it’s okay if you fix a couple of them, but if you have 20+ of this, it might be time-consuming and may affect the scope, plans, and estimates, etc, + some additional risks of regression. Accessibility is a system; you can’t just add ‘alt’ to 3 pictures and leave others without it. If you don’t have any of the accessibility features, don’t spend time on adding some small tweaks; it won’t give your product anything in terms of quality but it’ll cause just additional issues now and in the future.

1 Like
6

This really does require that the tester has easy to quickly whip together tools available to do a diversion with, but also that the org is actually agile and can deal with you raising unrelated tickets so long as they are easy to fix in the sprint.

I’m a big fan of drive-by testing because , by it’s very nature, it often let you re-surface bugs that people have “ignored” for some reason. Usually these are bugs like tidying up workflows to reduce the number of clicks for a user after some currect feature work has now made it easier to now do that tidying work on the product.

1 Like