• Are you in the right software testing job?

    “The only way to do great work is to love what you do” – Steve Jobs

    Two articles by Lou Adler published in May 2013,“There are only four jobs in the whole world – are you in the right one?” and “Rethinking work: Define the Actual job using the four work types”, created a watershed moment in my career. They made me sit up and realise that what I wanted to do, and what I was doing, were not the same thing, even though I had previously believed it to be so.

    It took me months of introspection to understand what it was that floated my boat, and what I wanted out of my career.

    Adler argues that there are only four types of job in the world: Thinkers, Builders, Improvers and Producers. He describes Thinkers as the strategists, the creators of new products and those that come up with big ideas and new ways of doing things, while the Builders take these and convert them into something tangible. Improvers, in turn, are those who make whatever has been built better. Lastly, the Producers deliver high-quality products and services to the customer.

    In these articles he explains that each person’s role within a company is a blend of each of these four job types, and how to articulate that role when recruiting. One thing that also became evident through additional reading and introspection was that every person’s career can be said to evolve through these four job types, a concept that Adler recently explored in a recent article, “Thinker. Builder. Improver. Producer. Which one is the right hire?”. Let me explain.

    When I started off my career in testing, I initially had no idea what I had to do. A more experienced colleague had to give me the rules of the game, and I followed them religiously. I was the Producer. As I gained more experience and confidence, I realised that I was able to slightly tweak the rules to get better and faster results, hence my ability as the Improver emerged. Later on (in fact much later on), with even more experience and the opportunity to continuously develop deeper insights (or more tacit knowledge), I was able to implement ideas from testing visionaries, and even build on them. I am still very much at this stage. I realise that, with a lot more experience and practice, I may perhaps one day be able to reach the Thinker space.

    Adler’s ideas tie in very nicely with the levels described by the Dreyfus and Conscious Competence models. The movement from novice to expert follows this evolution in one’s career nicely, and the four steps in acquiring new skills also complement this on so many levels.

    So, why this article and how is it relevant to software testing? There are two reasons.

    Firstly, I have noticed that a lot of testers are in testing simply because they match a job specification in terms of skills and experience. But they are in the job only because it seems to be the only one they can get, even though it’s not what they really want to do. For them, the challenge is to find out where their strength and passion really lie; that is, are they predominantly Producers, Improves, Builders or Thinkers? Once they understand this, they can begin directing their career in the direction of that passion and strength.

    Tying in closely with this, Adler wrote another article recently (“How to evaluate new job opportunities!”) in which he discusses the factors that motivate people in the workplace. It’s worth considering what types of motivation exist in both your current and ideal jobs while you are thinking about where your passion lies. It may turn out that that your true passion may lie outside testing, while for others it may very well lie inside testing, just on a different level or in a different context.

    Secondly, for the general testing population out there, every testing assignment is usually a mix of these four job types. You get to be creative in thinking out test cases (Thinker), then you get to create them (Builder), then you get to tweak them (Improver) and lastly you get to execute them (Producer)—sometimes hundreds of times. Understanding what these four job types are, and where your passion lies, will, I believe, help in achieving the right blend in the work you do every day—and in evaluating future assignments.

    Perhaps, as a novice in some practice or methodology of testing, you may find it very frustrating having to do a lot of repetitive Producer type work, but in future assignments you may want to experiment with varying the blend with more Improver/ Builder tasks, thus moving towards the creative side of testing. This sort of progression is hinted at in Adler’s article, “Thinker. Builder. Improver. Producer. Which one is the right hire?”, referenced above.

    Based on your new insights, it may very well be necessary to re-evaluate or re-negotiate your employment terms or job specification to obtain what Adler recommends, a performance-based job specification. Such job specification focuses on what needs to be accomplished; it’s also very much in line with Daniel Pink’s definition of moving to Motivation 2.0 (see his book called Drive) for personal development and increased productivity.

    In other words, you as the employee need to accomplish X, and are given the freedom to choose how you do it. It’s an outcomes-based performance measurement—compare it to the typical backward-looking specification that requires you to have X number of years’ experience of this and Y of that.

    I started this article with a quote from the late Steve Jobs about the link between loving your job and the ability to create great things. I strongly believe that all testers have the right—and maybe even the obligation—to love what they do, and so to do great work. The Adler model provides a valuable perspective to help testers assess their careers, and understand how to create a career in testing that suits their predisposition and goals. Work that they could love, in other words!

    After all, as principle six of the context-driven school tells us, testing should be a creative, “challenging and intellectual process”. As testers, we can be proud of, and motivated by, that possibility; ultimately we need to know that we deliver and contribute value.

    This article was first published by:http://www.ministryoftesting.com/2014/06/right-testing-job/


  • Ready Yourself for the Zombie Apocalypse (and Fundamentalism in IT)


    People wrap themselves in their beliefs. And they do it in such a way that you can’t set them free. Not even the truth will set them free. – Michael Specter

    A slogan I recently saw on a T-shirt got me thinking: ‘Fundamentalism stops a thinking mind.’ My thoughts turned to the prevalence of fundamentalism in the IT industry and how what starts as a great job or project can soon become overrun by mindless zombies leading to complete destruction.

    OK, it doesn’t quite degenerate into a set of ‘The Walking Dead’, but the consequences can be pretty harrowing for IT professionals and deliver unexpected (read: expensive and unsuitable) results for business.

    That’s because fundamentalism in IT kills any innovation, creativity and smarter working. Worse, it sucks the joy out of practicing IT. Fundamentalism means sitting in a job as opposed to following and building a career. I’ve had my share of sitting in dead-end, soul crushing and mind-numbing positions, unable to experience growth or be creative. It isn’t good.

    Looking back on those dead-end jobs, it’s clear that fundamentalism is a very real phenomenon. You’ll notice the hallmarks: people not allowed to ask why things work a certain way. New ideas not being taken seriously. Lip service paid to the importance of certain roles in IT. Enforcement of the ‘command-and-control’ mode of managing creative people.

    These symptoms inform the IT fundamentalist’s manifesto which values:

    ·        Comprehensive processes and tools over human creativity

    ·        Comprehensive documentation over real communication

    ·        Contract negotiation over delivering value

    ·        Doing things right over doing the right things

    ·        Theory over context.

    Unpicking the fundamentalist manifesto

    Fundamentalist-driven organisations engage in creating processes for the sake of creating processes, or enforcing tool usage without due consideration for why these processes or tools are necessary. This approach disregards the people element and fails to take reality into account, potentially resulting in wasted effort and fruitless expenditure.

    The same goes with comprehensive documentation, resulting in reams of paperwork that becomes instantly outdated the second it gets published. Robin Grace wrote an article to this effect: ‘It is time for Template Zombies to die’.

    Fundamentalists tend to look at any task or request from business as a contract negotiation – slapping very strict rules in place the moment business wants to change one pixel on an existing screen. There is management of scope creep… and then there is management of scope creep. Taking things overboard, results in politically-charged toxic environments that will make even established Machiavelli’s blush and shake their heads in disbelief.

    Just as ‘template zombies’ exist, there are those notation enforcers who follow a set of rules even to their own detriment. They end up doing things right, but not always doing the right things. Generally, rules are in place for good reasons; however, implementing and enforcing rules for the sake of implementing and enforcing them has never done anyone any good. Consider which is worse: people follow rules blindly without any regard of the bigger picture, or adhering to the spirit in which those rules are set.

    The ‘quality police’

    Finally, consider that fundamentalism in IT is mostly rooted in (sound) theory, but lacks due consideration of context. The implication is that decision makers sometimes tries to fit square pegs in round holes – without allowing for localised contextual variations. This results in wasted effort and disillusioned, unhappy employees.

    Now, don’t get me wrong. There is a time and place for structure in any IT operation, but not at the expense of common sense. And that is what experience (and the sometimes very painful lessons which comes with it) has taught me – always use common sense.

    Know and understand the ideal world, but implement for a specific context. There is no one-size-fits-all process, technology, documentation, rules, theory or anything that can be transposed to other situations without adjusting to localised contextual variables.

    A case in point, fundamentalism in the testing world partly contributed to a mentality called ‘the quality police’ where testers took adversarial and uncompromising stances in enforcing testing strategies. The quality police are heavily reliant on testing dogma, calling it ‘best practices’. This approach generated such a poor image of testing that many IT professionals still views testers through this lens – when testers should instead be viewed as providing a critical ‘helping hand’.

    If the quality police understood the aims of the context driven testing world, especially principle 2 ‘There are good practices in context, but there are no best practices’, it becomes clear that the circumstances would have dictated the approach for the given situation. This shift in view results in a cooperative and collaborative approach to testing, rather than an adversarial one.

    Bad weather and fundamentalist standards

    More recently, a storm has broken around the ISO 29119 proposal. Rob Marvin explains the rub of it, dubbing it ‘The software testing schism’. Following up, the SDTimes Editorial Board, argues along a similar line, saying it’s necessary to understand that “a testing world can’t be defined by a single set of standards or a dogmatic school of thought. It’s not either this or that. It’s all of the above. Testers must come at complex problems from a variety of ways, combining strategies that make sense in a given situation—whatever it takes to mitigate risks and ensure code and software quality. The means don’t matter, only the ends do.”

    In other words, the proposed ISO29119 standard runs the risk of becoming a fundamentalist stance, which could end up doing more harm than good.

    Similarly, we can see that even Agilists can run the risk of becoming fundamentalists themselves. It is good to constantly revisit and understand the Agile manifesto in this light and remember that there are no absolutes when developing software – and doubly so for Agile approaches.

    Trends over the last 3 decades have shown that roles, skills, tasks, ideas and methodologies in the industry have slowly moved through a maturity cycle which starts with novel, goes to out-of-the-box, is hailed as genius, and becomes pragmatic, to one overburdened by fundamentalism. Before you know it, the ‘template zombies’ apocalypse is underway, ably supported by the bot-like ‘quality police’. The result? The joy is sucked out of IT altogether.

    The trend towards fundamentalism is a stark warning to all IT practitioners: it is good practice to mature new roles, skills, tasks, ideas and methodologies. However, be practical about implementation and avoid over-complicating basic ideas with rigidity that leads to fundamentalism.

    About the Author

    Aldo Rall is a Principle Consultant at IndigoCube. He had his first software testing experience as a junior programmer in 1998 at the start of the Y2K bubble and, realising that testing offered wider contexts and perspectives for him professionally, has never looked back.

    Fortunate to gain exposure to a wide range of interesting opportunities in South Africa and the UK, Rall has mastered the practical elements of testing and best practices across a range of disciplines, assignments, projects, organisations and industries. What keeps him fascinated with testing is the constant change, which ensures there is always something new for everyone to learn, regardless of experience levels or qualifications.

    Rall’s greatest passion for testing lies in the ‘people’ dimension of the ‘people-process-technology’ mix, and how that translates into successful IT strategy, teams, projects and testers. He always looks for new ways to combine these perspectives into the daily testing lifecycle. He relishes any opportunity to develop and grow testing, testers and testing teams, and to help them reach maturity at both strategic and operational levels.

    This article was published by: http://www.ministryoftesting.com/2015/01/ready-zombie-apocalypse-fundamentalism/