A couple of months ago, there was a series of testing walkthroughs that were conducted for a certain project in our company. One of its outputs is a 9-page document that they’re intending to upload as is into our office wiki. The document is supposed to be a list of recommended best practices intended for testers to read. I wish someone had the time to go over it and clean it up first though. The content isn’t arranged well with repeated items and inconsistent usage of wordings in the first/second/third persons, active/passive voices, tenses, etc. Some of the bullet points I’m iffy about:
- Considering shared/common functionalities across our module or even in the whole project that could save effort in testing is also important. – Too vague. No clear tip or action item.
- Knowing what are the General Behaviours in the system – Too vague. And this is more of a ‘must’ rather than just a suggestion.
- I have also learned about the possibility of testing the function by parts and had to consider how I was going to accomplish testing the function in that way without redundant testing. – More of a feedback rather than a suggested best practice.
- Plan carefully which programs of the function needs to be prioritized. Consider impact if there is no “flow” in the priority. – I don’t get it.
- Know existence of similar functions. This will help potential saving of effort. – Too general.
- This helps avoid or minimize the risk of overtesting or bloated effort in testing. – This shouldn’t have its own bullet point.
- Planning is very important, be conscious on the effort spent, and as much as possible think of ways on how to reduce the estimates w/o risking quality. – While I agree that planning is important, this also reminds me of the following classic mistake:
shortchanged quality assurance – cut corners by eliminating design and code reviews, eliminating test planning and performing only perfunctory testing. result: product still too buggy to release. Shortcutting 1 day of QA activity early in the project is likely to cost you from 3 to 10 days of activity downstream (Jones 1994).
- SQL. Continuously improve your SQL and your SQL writing skills. – I wish this would also say how.
- Prepare background data beforehand. Ensure that initial data are available beforehand. – Can’t be ensured. Chances are you’ll still need to create more or other data as you go.
- For screens/grids using the same source code, no need to repeat test cases after confirming with the developer that they are the same. – No.
- No need to repeat test cases for different browsers – Depends. Just take our in-house bug tracking system when used with Google Chrome, for example.
- Knowing when to stop testing a particular program (i.e. avoid Over-testing) – Doesn’t answer or even suggest how.
I’m stopping at page 3. Need to get some sleep now.