software testing

  • Agile testing: Did your paradigm shift?

    Agile testing: Did your paradigm shift?

    Agile techniques are becoming mainstream as companies gear up to deliver the software they need to meet rapidly shifting consumer needs and intense competition. However, it's also clear that many companies are struggling with testing in this new, agile world.

    "I've been observing this issue for quite some time now, and I think the root cause is that development teams are not making the mindset or paradigm shift from the old-style Waterfall method to agile. Rather, they seem to be talking the agile talk, but not walking the agile walk," says Aldo Rall, principal consultant at IndigoCube. "Testing is particularly vulnerable to this because its role within the agile universe is significantly different from its traditional one."

    Rall explains that whereas the Waterfall methodology sees the software passing from one role to the next, agile requires the whole team to be accountable. In particular, agile testing ceases to be a discrete phase of software development and becomes a continuous activity owned by the whole team.

    He explains: "Within the agile world, the tester no longer acts as the 'quality police', but rather uses a broad set of cross-functional knowledge and analytical skills collaboratively with fellow team members to find ways of delivering working software successfully. Agile testers work as part of the team, not in isolation at distinct points in the process."

    Certain issues show that teams are failing to address the changeover to agile effectively. These include the failure to address quality properly, not seeing testing as a continuous process or even outsourcing it, and a lack of effort in helping testers to adopt the agile mindset.

    Agile testing requires much of the basic checking of the software to be automated in order to free up the tester to take on this broader role—uncovering hidden assumptions and helping to build a common understanding of what the project is trying to achieve. In this context, one has to remember that software is really the company's customer interface: there's no latitude for bugs and other examples of failed development.

    Research by IBM[1] shows that even though most testers use some flavour of agile, they are not experiencing the benefits. They spend their time in three broad areas: testing itself, navigating development delays and missing functionality, and dealing with unplanned activities unrelated to testing. As a result, 54 percent end up deferring testing and 33 percent de-scoping it—all of which reduces efficiency, leading to waste.

    Even more telling, the research shows that almost half of the respondents (49 percent) spend eight of their 40 weekly work hours (20 percent of their working time) on non-testing work, while more than a third (36 percent) spend 50 to 100 percent of their time on non-testing activities! It seems that ad-hoc requests are the biggest culprit for this sorry state of affairs.

    In summary, Rall argues, the shift to agile means moving beyond just simply adopting certain techniques or methodologies; it's necessary to start living agile's underlying values. The IBM research clearly shows that testers are well aware of the problem, and that they need to move beyond "agile in name" to becoming "agile through and through."

    Rall concludes: "That's why the first item on the agenda should be to change the mindset of the testing team. If they don't understand the rationale for the change and its underlying concepts, you will end up with a mess—and set them up for failure."

    [1] IBM, The future of software testing: Where do testers spend their time? October 2014.

  • Presentations

    Business Analysis Presentations

    How is Analysis done in Agile 

    Lifting the Lid on Business Analysis 

    To BA or Not to BA

    Hints and Tips for a BA 

    Career in Business Analysis 

    Sign Off Blues

    The Need for Good Enterprise Analysis

    Successful Agile Teams Understand How
    To Do Analysis

    Can the Business Analyst be responsible for the system getting hacked?

    part 1

    part 2

    Agile and DevOps Enterprise Presentations

    The Agile Enterprise: Moving beyond Scrum

    Challenges faced by Testers working on Agile Teams

    A Collaborative Approach to Quality in the Agile Enterprise

    Successful Agile Teams understand how to do Analysis

  • 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: