A spec that can’t be tested is a starting pistol in a treasure hunt. The treasure is information, but not any old bit of information – you, as a tester, must get the same information that was given to the programmers.
Posted in QA
Tagged QA, Testing
From time to time I teach people some QA basics. I do this at start-up companies, since most established companies have someone in-house to train QA. A couple of times I trained experienced testers who only had to transition to a new technology, but usually I train newbies who were hired to be a lone tester. And one thing I’ve learned from doing this is that it’s a really bad first move for these testers.
Agile got (at least) one thing right: stop writing documents no one’s ever going to read. If you want to honestly assess what will or won’t be read – and therefore what should or shouldn’t be written – you should answer some basic questions.
Tools of the trade, 2014. Everything from bug tracking to HR.
First let me clarify – I’ve nothing against HR and their involvement in the hiring process. What I object to very specifically are two habits: letting HR choose who gets interviewed, and letting HR do the first interview and veto some of the candidates before they ever meet the technical writing team leader.
Usability testing for your information architecture – before you code.
Posted in QA, Reading
Three things some technical writers say that should serve as a warning sign that you may not want to hire them:
“I only need to understand it at the UI level”.
If you don’t understand how and why things happen, you’re no better than the user. Anyone can read a field label to understand what goes there.
“I don’t proofread.”
Some writers treat proofreading the way some programmers treat testing – as something lesser people should do. It’s the sign of a delusional ego or an unhelpful team member (or both). Note that this is not the same as saying “I’m really bad at proofreading myself”, which is only a problem for writers working on their own.
“I don’t accept client feedback”.
Another ego problem. Obviously some clients are to be ignored – we’ve all met some who gave utterly useless feedback just because they felt it was their duty to say something. But rejecting all client feedback off-hand is another way of saying “I refuse to learn from my mistakes”.
Written in collaboration with Efrat Wurzel
Three things some testers say that should serve as a warning sign that you may not want to hire them:
“I can’t understand a feature or start thinking about its tests until I use it”.
Obviously there are some things that will click better when working with the feature. But anyone who says they can’t do anything with a feature until they start working with it – not even with a good design and spec – doesn’t have the imagination and analysing skills for this job.
“I’m not an organised person, I don’t put effort into keeping my tests in order”.
Good luck figuring out what you did and didn’t test, three weeks into a four-week test “sprint”.
“I rely only on developers to understand a feature I’m testing”.
Developers can tell you what the feature does, not what it was intended to do. Testers who don’t understand the gap between these two ideas – and how many different elements go into creating this gap – don’t get how software is developed.
If you’re testing HTML5 mobile apps, you might want to read about code injections through the bar-code scanner, videos, Bluetooth and more.
Posted in QA, Reading