Interviews of Thought Leaders - Alan Page (final part)

The first part of the interview with Alan Page was read and appreciated by many. All, many thanks for your responses and questions. For me, some of the things mentioned by Alan are sure to change my approach to testing in subtle but fundamental ways. Well, here is the second and final part of Alan's interview:

7. What skills and qualities would you look for if you interview a software test engineer for the purpose of hiring?

[Alan] I interview a lot of candidates on my new team, so I can pull from recent experience. As hinted above, I look for a passion for learning – I try to find out how and when testers learn more about what they do – I want to understand what they know about testing and how they form their opinions about testing. Problem solving relates pretty well to this, and also to test investigation and debugging. I don’t ask the silly “how many piano tuners are in the world” type of questions – instead, I usually just ask test candidates to troubleshoot some random problem – e.g. an application won’t start, what do you do? This gives me some insight into methodology, problem analysis and creativity. I also look for test design (or test aptitude). For example, I may ask how to test a random number generator or a string search function. Both of these examples are simple on the surface, but have a lot of deeper problems under the covers. Good test candidates can see the whole problem quickly and get creative on testing the challenging parts (I left the details vague on purpose - don’t want to ruin the “fun” for potential candidates).

8. What advice would you give to the software test leads/ test managers working in various organizations? What should they do if they want to progress in their testing career?

[Alan] A big part of your role as a test lead or manager is to make sure that your team is performing and growing. The work you assign for your team needs to be challenging, yet achievable. As a lead or manager, you need to base your success on your team’s success – and take the heat if/when things don’t go well. I sometimes see test managers who have good ideas, but think that mandates are the only way to make change. Managers need to learn other methods of organizational change and use a variety of approaches when they want change to happen. I also encourage test managers to stay involved in the testing process. Some managers think that test management is just about management, and not about testing – these managers almost always fail.

9. Many software testing professionals find effort estimation a bit challenging. What advice can you give to arrive at a fairly accurate estimate, especially in automation projects?

[Alan] First off, as you may know, I’m not really a fan of GUI automation – but it can work if planned correctly. If you can involve development in the estimate – e.g. if programmers and testers can come up with the estimate together, you may get closer. The problem is that there usually too many “unknown unknowns” in GUI automation efforts – if you make programmers aware of this, they are more prone to add the appropriate testability features (e.g. an object model) to the UI so it can be tested in a less fragile manner.

Beyond that, normal estimation practices apply – break tasks down into the smallest unit possible – preferably a day or less. This makes it much easier to know when you’re behind (or ahead of) schedule before it’s too late, but more importantly, makes you take the time to fully understand the task in front of you.

10. We know that you handle sizable responsibilities. In addition, you are a frequent conference speaker and author. Could you give us some tips on how do you manage your time and energy so successfully?

[Alan] I don’t work 80 hour weeks – at least I don’t think I do. I have a job, I have stuff I do that’s related to my job (blogging, speaking, writing, etc), and I have my personal and family time. But I don’t really segregate them – they all sort of merge together into the 16 or 17 hours I’m awake every day. Sometimes I take care of personal stuff (I try to run 3-5 miles every day) or blog during the day, and I usually work from home for an hour or two at night after the kids go to sleep on whatever is important.

As far as managing my time, it’s very scrum-like. I have a “product backlog” of everything I do in my outlook tasklist. It includes my work projects and personal things (like “do my taxes”, or “set up conference with teacher”). Some items are recurring. My scrum team of 1 does 1-day sprints – each morning, I go through everything on the todo list for today and prioritize. Some items get deferred if I know they aren’t critical for that day, and sometimes I’ll add things. I don’t get through everything I plan every day, but I put the unfinished items back in the backlog and re prioritize the next day. It may sound a little silly (I don’t actually think of it as scrum-like when I’m doing it), but it’s the only way I can stay on top of everything I’m doing.

I frequently remind people (and myself) that there is always time to do whatever you want – you just need to make the right choices to make that time for yourself. You may think, for example, that you don’t have a single spare moment the entire week – but if you were so sick you couldn’t get out of bed for two days, I bet you’d be able to “catch up” within a week. As long as you’re healthy, take the time to invest in what you think is important, and your task list will work itself out. (note – I blogged about this here if you need clarification or elaboration)

Of course, knowing when to say “no” is also critical. I hate to turn down writing or speaking requests, but I still have to do it more often than I’d like.

11. Do you think that you made the right choice in selecting software testing as a career?

[Alan] Absolutely – I never thought I would be a software tester this many years, but I can’t imagine doing anything else. At one point in my career, I briefly entertained the idea of becoming a sw developer, and was even assigned some feature work and bug fixing on a few different occasions at Microsoft (I have written functionality that shipped with Windows and Windows CE). On both occasions, however, I realized that my heart was in testing (for example, I enjoyed investigating and fixing the bugs far more than writing features from specifications. I’m sure I’ll be a tester until I retire – and I hope that’s a long time from now, because I’m still having fun and enjoying the job a lot.

12. Finally, would you like to share any other advice/ wisdom with us readers?

[Alan] –Sure - The biggest advice I can share is to focus on learning and develop your own thoughts and opinions. I see too many testers chasing after silver bullets and shiny objects – blindly trusting testing advice from tool salesmen and self-proclaimed testing experts. If you haven’t learned enough and practiced enough to form your own opinions and build your own toolbox of testing approaches, you have little chance of success.

Many thanks to Alan for taking his valuable time to pen his thoughts on pertinent questions from all of us in the software testing space.

Please comment if you have any related questions. I will do the same.