Leaving your job and training your replacement? There are four simple rules to effective knowledge transfer: create independence, work together, plan and give yourself the time to do these things.
First and foremost: assume that you will not be available to answer any more questions after you leave. Even if you’re staying in the same company, just in a different role, you need to teach as if you’re joining the mission to Mars. If you create a dependence on yourself by constantly saying “oh, just e-mail me when you need this” you’re going to make life very hard (and unimpressive, from the bosses’ point of view) for yourself and for the person you’re teaching. In a related note, nothing is too trivial for a knowledge transfer. If you know it, your replacement needs to know it.
Don’t do a Show and Tell. Work together: write documents, write code, write tests. You teach much more when working than when explaining some theory in front of a slide show, and seeing how your replacement works will tell you where to put some extra effort.
Plan your work. If you don’t have a plan you’ll jump around, which is both confusing and liable to make you forget whole topics. You also can’t asses times without a plan of what you’re going to cover.
Which brings us to time. You have to be realistic about how long you need to spend on a knowledge transfer; one day is not enough. And don’t forget – there is only so much information a human can pick up in a single day, so if you’re planning a series of twelve hour days – you’re planning to waste half of your time.
In a lot of offices, if you’re not typing or clicking – you’re not working. It’s an odd view for any member of an industry that prides itself on thought and creativity. To analyse a problem, understand it and come up with a creative solution to it, you need to think about it. Thinking, for most people, requires not doing.
So stop. Think. You’ll do better.
If you’re getting dirty looks from your boss, employ some body language. Frown, tap your pen on your lip or your thumb on the space bar, stare at your computer screen as if the answer is about to jump out of it. This is universal for “I’m thinking in the most useful manner possible” and is usually enough.
And if all else fails, just follow this time honoured tradition: go think in the toilet.
If you’re working on a product and have no particular understanding of UX, you can still do a basic UX review to stop the most obvious disasters. This will not be as good as getting a UX expert or experienced UX-QA to review the product, but it will be much better than nothing.
Ever see a bad actor? One who reads the lines in the weird, stilted intonation of an automated phone system without any emotion or thought? If you test only by the testing script, without ever re-writing it or improvising around it, you are the QA equivalent of a fourth-grader in the school’s talent show. There is absolutely no way not to think of new tests while working; you are doing your product a disservice if you ignore these thoughts.
First, believing a test script is perfect is to ignore the premise of your profession – nothing is perfect. Second, even if the script were perfect according to the information available at the time of writing, surely you must have learned or thought about something new since then. Third, let’s say you’re wrong and the test you thought of is irrelevant or silly – at least you learned; your next test script will be better.
So please – don’t ignore yourself while testing. Your creativity is one of the reasons you’ve not been automated away.
We’ve all worked with testers who were bad at their job; it was frustrating and felt like a giant waste of time and effort. But hold on to those bad testers: they’re more useful than you think.
All of your assumptions about address fields are wrong.
Some bugs, even quite severe ones, can seem to your users like very nice features. Bugs that are likely to reach this status are those that make work smoother at the expense of security (for example, not enforcing part of the permissions mechanism), faster by letting users skip steps that should be mandatory (for example, leaving fields blank) or simpler by making assumptions (for example, setting default values where a user should really be forced to make a choice). When you fix these bugs, your users won’t thank you. In fact, they might complain; as far as they’re concerned you just damaged their user experience.
Designing something? “Simplicity doesn’t happen accidentally. It needs to be actively cultivated. Complexity is what happens when you aren’t paying attention”.
Technical writers have a very clear goal: explain the interface. That means they notice, instantly, when it’s inexplicable. If your interface is a confusing mess with overly-complicated procedures, buttons that make no sense, important options hidden in sub-menus and related options kept a mile apart, it’s not only hard to use – it’s hard to explain.
So if you, as the QA, are not sure about your UX – ask your technical writers. They know, and are quietly seething. And if you ask nicely, they’ll give you a well-worded document explaining just how bad it all is, saving you lots of work.