2

I am a front-end Web developer who works for a small company. I also do some freelance work on the side occasionally. I would describe my skill set as more design-heavy than programming-heavy.

I have a pretty good set of tools for testing. My Mac runs OSX apps, IE6-11 with VirtualBox, and iOS Simulator; a Nexus 7 gives me an Android touch environment to round out the majority of browsers I should be testing.

What I'm lacking is any real QA protocol. My workflow usually consists of: Develop in Firefox, jump over to Chromium occasionally to make sure nothing obvious is going wrong, and then later in the process open up the VMs and start clicking around a bit to make sure nothing is really amiss.

This is hardly rigorous, definitely not standardized, and probably not even the best way to go about doing things. However, I can't imagine myself testing 10-15 browsers after every change either.

I'm not looking to do a tester's full-time job with the last ten percent of my time - I understand and respect the position's importance more than that. But in an imperfect world where I have to rely mostly on myself for testing, what are some good strategies for doing QA, striking a balance between thoroughness and efficiency?

If that's too broad of a question, I'd like to focus on front-end design specifically more than things like 'does the data validate'.

  • Pick the browsers you care the most about. Then figure out which workflows you care the most about. Test the cross product of those. Let the rest fall on the floor because they're less important and you don't have time for them. – user246 Feb 10 '15 at 15:01
  • Shouldn't the above comment be an answer? – Phil Kirkham Feb 10 '15 at 18:10
  • @PhilKirkham I would hope to see it elaborated if it became an answer! I can certainly pick browsers based on my analytics, but when the question asks for strategies, saying "figure out [a] workflow" isn't all that helpful. – Brendan Feb 10 '15 at 18:12
  • @Brendan Do you have automated tests in place, are you writing lots of unit tests with a sprinkle of GUI integration tests on top? – Phil Kirkham Feb 10 '15 at 21:41
  • @PhilKirkham Our back end guys do unit testing, hook into Travis CI, that sort of thing. On my side of things (mostly HTML/CSS/JS), I've never done any of that. I just spent the morning looking into Selenium today after seeing it pop so often on this site. I either never had the kind of work that would merit testing, or I had a QA guy around to help (and his help would consist of rigorous testing in different browsers). – Brendan Feb 10 '15 at 21:59
3

The basic strategy is risk assessment - where might the problems be and what will affect the users wallet?

1) Do you know what your users are using - are you going to bother testing on IE8? You say you don't want to test 10-15 browsers - where did you get that number from? If you developing on Chrome then no need to test on Chrome, test on FF and Safari and however many versions of IE you have to support. Do you test all on every change? No, work out what your changes do and if they are likely to affect functionality or display or both. Test with different browsers every testing session rather than every one every time. Look at your past bugs and work out which ones cause the problems and focus on those

2) Most programs follow the 80/20 rule or Pareto principle, 80% of the users spend their time in 20% of the features. Know the users and the important revenue earning workflow and make sure that works

and the usual tester answer is 'it depends' - you haven't give any details of your app. If it's free app and you don't care about the users, push out a build whenever you want. If you're building a banking app or medical app or health records then you're gonna have to be a lot more thorough.

Do better testing than 'click around' a bit - do a search for testing quick attacks or test heuristics cheat sheet and do some more intelligent testing

2

what are some good strategies for doing QA, striking a balance between thoroughness and efficiency?

Focus on priority and correctness.

  1. Find something important to prove to be working, like 'completing the registration process yields a new account'
  2. Describe explicitly how to execute the process and verify the result (the test case for correctness)
  3. Perform the test case against each browser that matters
  4. Automate it when you you have too many important things to prove than time to prove them

Thoroughness is just adding more correct tests. Efficiency is worthless if the tests aren't correct; once they are correct just automate them and throw them at an n-sized cluster for as much efficiency as you can afford.

I'd like to focus on front-end design specifically more than things like 'does the data validate'.

You may want to look into huxley.

From the readme: "Watches you browse, takes screenshots, tells you when they change". Might be the sort of thing to look into.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.