There is a general problem in software, more pronounced in minimalist Agile efforts, of documents that look good at the time of writing, but do a poor job of transferring information. I call these “stump” documents because readers are stumped when they try to learn from them.
You might say I learned this lesson as a technical writer, too.
As a lead tester, you fall somewhere on a scale between being completely passive about bug fixes and being in complete control of them. If you are completely passive, you are managing neither the product nor its quality. If you are in complete control, you are managing both. Neither of these situations is good for you; what you should be doing is managing the quality.
Testing your product? Remember the UI.
PragDave on why Agile (as a noun) is dead, and how agility can replace it.
Written in collaboration with Efrat Wurzel
The basic premise of QA is that developers – being human – make mistakes; but too many testers think that developer mistakes are limited to the code they write. The truth is that developers can misunderstand the spec, forget a part of it, never notice that a spec is updated and so on. Some didn’t actually make a mistake – they were simply never shown a spec; they developed a feature based on what they were told, by someone who was told it by someone else, and so on.
These questions are for experienced candidates, not aspiring writers, and are meant to reveal general attitudes and methods. You want to see how people think, and how they act and react to other writers.
The Oxford comma, or serial comma, is the comma that sometimes appears in a list before the last “and”, “or” and so on. It has somehow become a battleground of punctuation, because some people always use it while others never do, and emotions run high.
As a version’s release date approaches, and bugs and untested features are looming large, there is a temptation (not usually in the QA department) to recruit people from outside the QA to help the testing effort. This, I’m going to argue, is not at all a good idea. It relies on false assumptions, is not at all cost-effective and is easily surpassed by the alternative: bringing in extra testers.
At Infinite Undo, eleven test automation lessons learned the hard way.
And at Adactio, on why your website doesn’t have to look the same on every browser.
