After 25 years or so in the IT industry, and with the vast majority of my experience being in testing, I rarely find myself surprised by even the most nonsensical stuff that crosses my virtual desk. It often feels like the same mistakes and traps are being made and fallen into by a new generation of testers or the same old things get rebranded as the latest shiny thing.
I’ve seen it come and go with the “testing is dead” narrative. I’ve seen automation via screen comparison noted as a ridiculous idea while now being touted as the next big thing. I’ve witnessed the ridicule around record & playback as an automation technique, while I’m now inundated with marketing for automation tools that magically instruct computers how to do stuff apparently “without any code”. I’ve become conditioned to the nonsense and I’m well aware that everything comes and everything goes, so my attention is rarely distracted away by such obviously ridiculous “trends” in the testing industry.
But I recently came to realise that my capability to be surprised in this industry hasn’t been completely destroyed, it has merely been dormant. Thanks to Eric Proegler posting a link to a YouTube video on the Association for Software Testing‘s Slack, my surprise (and, along with it, a hefty dose of dismay) has been awoken from its slumber.
The video in question is titled “Fake Experiance on Software Testing” by Venkata Krishna (published on February 6th, 2022):
While I’m at pains not to give this abomination any oxygen, the video has already been viewed over 131,000 times as I write so calling it out here seems worthwhile even if it adds another click or two to this incredible view count. It’s worth noting that the video has over 2,700 likes and has received over 270 comments, some (rightly) calling it out as promoting unethical practice but the vast majority sadly praising it as being useful.
The typo in the titling of the video and the fact that it was recorded on a computer running an unregistered copy of Windows gives an indication of the standard of the material to come. Venkata’s introduction sets out his purpose for producing this video:
“how to put the fake experience on software testing… what are all the major challenges you may face and how to overcome those challenges – and how to happily do your work even though you go with fake experience”.
This stunning opening gambit originally made me think that the video must itself be a fake or some kind of joke piece, but alas I was mistaken. Disturbingly, he claims that the video was made in response to requests from his subscribers.
His early advice is to do one “real-time project” for manual and automated testing before claiming fake experience, claiming that “there is no issue” in doing this to get into a company (this claim is repeated frequently throughout the video).
He advises applicants to approach those “good” small consultancies who can provide fake experience documents (and even payslips, bank statements, etc.) to help them clear background checks by employers when applying for jobs (Venkata reminds his viewers not to ask him specifically for the names of consultancies providing such “services”).
Heading into the workplace after clearing any checks using the fake experience documents, he suggests that the tester be careful with the questions they ask or “risk being identified as a fake resource”. He claims that “automation is all about Selenium” and, for any question they might be asked, the solution is “already in Google”. Both “manual” and “automated” testing are described in very simplistic ways and requiring little skill or knowledge to “get by” without arousing suspicion as a “fake resource”.
If the tester can survive two to three months without being found out, then “no-one will stop you” and if they somehow manage to do the work, “no-one will touch you”. He mentioned that there are so many jobs in the US and India with so much demand that it’s easy to use fake experience to land a position.
One of the more obvious challenges of this approach (!) is that “you might not be able to do the work”, in which case Venkata advises relying on friends with actual experience as testers or utilizing a “job support service”. If the tester really can’t do the work, the employer might re-do their background checks and flag you as fake. In this case, he said HR will be the first to start asking questions, such as “is your experience real or fake?”, and the tester should always say their experience is real and suggest that HR should contact their previous employer. Acting confident (while you lie) here is the key, apparently. If HR really do re-check and the tester’s fake experience is revealed, the tester should offer to resign and then leave. There is no problem here, “It’s software, everything is soft, you won’t go to jail”.
While Venkata rightly suggests that it can be hard to find your first testing job (and claims that there are “no fresher jobs” in his market), these facts don’t justify encouraging candidates to misrepresent themselves (essentially, committing fraud). This reflects badly not only on the people following this path, but more generally on the testing industry. The reputation of some outsourced testing companies already isn’t great and this kind of “advice” to fraudulently join them only serves to devalue testing and diminish its reputation even further.
It is on those of us who employ testers to provide entry-level opportunities into our industry, maybe via apprenticeship style models, where keen new testers can learn their craft and not have to be dishonest in doing so. There are excellent examples in India of companies and communities around testing who are treating the craft with care and promoting its value – Moolya and The Test Tribe immediately come to my mind. Publishing blogs, articles and other materials that can point potential new entrants into testing towards better quality resources seems important to me. This blog is a small attempt to do this, but these words are very unlikely to attract 100,000+ readers!
I remain surprised that anyone would publish a video recommending this fraudulent behaviour, along with the many justifications they make for doing so. A job in the testing industry can be varied, fulfilling and intellectually challenging – it’s not a place to live a fake life. For anyone looking to enter the testing industry, I hope you will choose to look for guidance and help from professional testers passionate about their craft rather than doing yourself a disservice by “faking it”.
A relatively rare scheduling of the online version of the Rapid Software Testing Explored course for Australasian timezones presented me with an invitation from presenter Michael Bolton to act as a “peer advisor” for the course running from 7-10 February.
I had already participated in RST twice before, thanks to in-person classes with Michael in Canada back in 2007 and then again with James Bach in Melbourne in 2011, so the opportunity to experience the class online and in its most current form were both very appealing. I was quick to accept Michael’s offer to volunteer for the duration of the course.
While the peer advisor role is voluntary and came with no obligation to attend for any particular duration, I made room in my consulting schedule to attend every session over the four days (with the consistent afternoon scheduling making this a practical option for me). Each afternoon consisted of three 90-minute sessions with two 30-minute breaks, making a total of 18 hours of class time. The class retailed at AU$600 for paying participants so offers incredible value in its virtual format, in my opinion.
As a a peer advisor, I added commentary here and there during Michael’s sessions but contributed more during exercises in the breakout rooms, nudging the participants as required to help them. I was delighted to be joined by Paul Seaman and Aaron Hodder as peer advisors, both testers I have huge respect for and who have made significant contributions to the context-driven testing community. Eugenio Elizondo did a sterling job as PA, being quick to provide links to resources, etc. as well as keeping on top of the various administrivia required to run a smooth virtual class.
The class was attended by over twenty students from across Australia, New Zealand and Malaysia. Zoom was used for all of Michael’s main sessions with breakout rooms being used to split the participants into smaller groups for exercises (with the peer advisors roaming these rooms to assist as needed). Asynchronous collaboration was facilitated via a Mattermost instance (an open source Slack clone), which seemed to work well for posing questions to Michael, documenting references, general chat between participants, etc.
While no two runs of an RST class are the same, all the “classic” content was covered over the four days, including testing & checking, heuristics & oracles, the heuristic test strategy model & product coverage outlines, shallow & deep testing, session-based test management, and “manual” & “automated” testing. The intent is not to cover a slide deck but rather to follow the energy in the (virtual) room and tailor the content to maximize its value to the particular group of participants. This nature of the class meant that even during this third pass through it, I still found the content fresh, engaging and valuable – and it really felt like the other participants did too.
The various example applications used throughout the class are generally simple but reveal complexity (and I’d seen all of them before, I think). It was good to see how other participants dealt with the tasks around testing these applications and I enjoyed nudging them along in the breakouts to explore different ways of thinking about the problems at hand.
The experience of RST in an online format was of course quite different to an in-person class. I missed the more direct and instant feedback from the faces and body language of participants (not everyone decided to have their video turned on either) and I imagine this also makes this format challenging for the presenter. I wondered sometimes whether there was confusion or misunderstanding that lay hidden from obvious view, in a way that wouldn’t happen so readily if everyone was physically present in the same room. Michael’s incredibly rich, subtle and nuanced use of language is always a joy for me, but I again wondered if some of this richness and subtlety was lost especially for participants without English as their first language.
The four hefty afternoons of this RST class passed so quickly and I thoroughly enjoyed both the course itself as well as the experience of helping out in a small way as a peer advisor. It was fun to spend some social time with some of the group after the last session in a “virtual pub” where Michael could finally enjoy a hard-earned beer! The incredible pack of resources sent to all participants is also hugely valuable and condenses so much learned experience and practical knowledge into forms well suited to application in the day-to-day life of a tester.
Since I first participated in RST back in 2007, I’ve been a huge advocate for this course and experiencing the online version (and seeing the updates to its content over the last fifteen years) has only made my opinions even stronger about the value and need for this quality of testing education. In a world of such poor messaging and content around testing, RST is a shining light and a source of hope – take this class if you ever have the chance (check out upcoming RST courses)!
(I would like to publicly offer my thanks to Michael for giving me the opportunity to act as a peer advisor during this virtual RST class – as I hope I’ve communicated above, it was an absolute pleasure!)
The rapid rise of the digital economy became twice as important after layering on a worldwide pandemic. With every company having to become a software company, enterprise application development speed, volume, cost, quality, and risk are key determinants that define who survives and who does not. The pressure on application development teams to build more software faster and cheaper often runs counter to the objectives of software quality and managing risk.
Join Steve Hendrick, Research Director at Enterprise Management Associates, to hear key findings from a recent worldwide survey about software quality. This webinar will look at the characteristics and differences between software quality leaders and followers. Key to this discussion of software quality is the impact that people, process, and products are having on enterprise software quality. Completing this view into software quality will be a discussion of best and worst practices and their differences across three levels of software quality leadership.
While the opening gambit of this promo literally makes no sense – “The rapid rise of the digital economy became twice as important after layering on a worldwide pandemic” – the webinar sounded like it at least held some promise in terms of identifying differences between those “leading” in software quality and those “following”.
The survey data presented in this webinar was formed from 316 responses by Directors, VPs and C-level executives of larger enterprises (2000 employees or more). The presenter noted specifically that the mean enterprise size in the survey was over 11,000 employees and that this was a good thing, since larger enterprises have a “more complex take on DevOps”. This focus on garnering responses from people far away from the actual work of developing software in very large enterprises immediately makes me suspicious of the value of the responses for practitioners.
Unusually for surveys and reports of this type, though, the webinar started in earnest with a slide titled “What is Software Quality”:
While the three broad software quality attributes seem to me to represent some dimensions of quality, they don’t answer the question of what the survey means when it refers to “software quality”. If this was the definition given in the survey to guide participants, then it feels like their responses are likely skewed to thinking solely about these three dimensions and not the many more that are familiar to those of us with a broader perspective aligned with, for example, Jerry Weinberg’s definition of quality as “Value to some person”.
The next slide was particularly important as it introduced the segmentation of respondents into Outliers, Laggards, Mainstreamers and Leaders based on their self-assessment of the quality of their products:
This “leadership segmentation” is the foundation for the analysis throughout the rest of the webinar, yet it is completely based on self-assessment! Note that over half (55%) self-assess their quality as 8/10, 9/10 or even 10/10, while only 11% rate themselves as 5/10 or below. This looks like a classic example of cognitive bias and illusory superiority. This poor basis for the segmentation used so heavily in the analysis which follows is troubling.
Moving on, imagine being faced with answering this question: “How does your enterprise balance the contribution to software quality that is made by people, policy, processes, and products (development and DevOps tools)?” You might need to read that again. The survey responses came back as follows:
Call me cynical but this almost impossible to answer question looks like it resulted in most people just giving equal weight to all of the five choices, so ending up with just about 20% in each category.
It was soon time to look to “agile methodologies” for clues as to how “adopting” agile relates to quality leadership segmentation:
It was noted here that the “leaders” (again, remember this is respondents self-assessing themselves as quality leaders) were most likely to represent enterprises in which “Nearly all teams are using agile methods”. A reminder that correlation does not imply causation feels in order at this point.
The revelations kept coming, let’s look at the “phases” in which enterprises are “measuring quality”:
The presenter made a big deal here about the “leaders” showing much higher scores for measuring quality in the requirements and testing management “phases” than the “mainstreamers” and “laggards”. Of course, this provided the perfect opportunity to propagate the “cost of change” curve nonsense, with the presenter claiming it is “many times more expensive to resolve defects found in production than found during development”. He also sagely suggested that the leaders’ focus on requirements management and testing was part of their “secret sauce”.
When the surveyed enterprises were asked about their “software quality journey over the last two years”, the results looked like this:
The conclusion here was that “leaders” are establishing centres of excellence for software quality. There was a question about this during the short Q&A at the end of the deck presentation, asking what such a function actually does, to which the presenter said a CoE is “A good way to jumpstart an enterprise thinking about quality, it elevates the importance of quality in the enterprise” and “raises visibility of the fact that software quality is important”. An interesting but overlooked part of the data on this slide in my opinion is that about 20% of enterprises (even the “leaders”) said that their “focus on agile and DevOps has not had any impact on software quality”. I assume this data didn’t fit the narrative for this highly DevOps-focused webinar.
Attention then turned to tooling, firstly looking at development tools:
I find it interesting that all of these different types of development tooling are considered “DevOps tools” and it’s surprising that only around half of the “laggards” even claim to use source code management tools (it’s not clear why “mainstreamers” were left off this slide) and only just over half of the “leaders” are using continuous integration tools. These statistics seem contrary to the idea that even the leaders are really mature in their use of tooling around DevOps. (It’s also worth noting that there is also considerable wiggle room in the wording of this question, “regularly used or will be used”.) Deployment, rather than development, tooling was also analyzed but I didn’t spot anything interesting there, apart from the very fine-grained breakdown of tooling types (resulting in an incredible 19 different categories).
The presenter then examined why software quality was improving:
Notice that the slide is titled “Why has your software quality been improving since 2019?” while the actual survey question was “Why has your approach to software quality improved since the beginning of 2019?” Improvements in approach may or may not result in quality improvements. Some of the choices for response to this question don’t really answer the question, but clearly the idea was to suggest that adding more DevOps process and tooling leads to quality improvements while the data suggests otherwise (more around business drivers).
Moving from the “why” to the “how” came next (again with the same subtle difference between the slide title and the survey question):
There are again business/customer drivers behind most of these responses, but increased automation and use of tooling also show up highly. A standout is the “leaders” highlighting that “our multifunctional teams have learned how to work more effectively together” was a way to improve quality.
Some realizations/revelations about quality followed:
There were at least signs here of enterprises accepting that improving quality takes significant effort, not just from additional testing and tooling, but also from management and the business. The presenter focused on the idea of “shifting left” and there was a question on this during the Q&A too, asking “how important is shift left?” to which the presenter said it was “very important to leaders, it’s a best practice and it makes intuitive sense”. But he also noted that there was an additional finding in the deeper data around this that enterprises found it to be a “challenge in piling more responsibility on developers, made it harder for developers to get their job done, it alienates them and gets them bogged down with activities that are not coding” and that enterprises were sensitive to these concerns. From that response, it doesn’t sound to me like the “leaders” have really grasped the concept of “shift left” as I understand it and are still not viewing some types of testing as being part of developers’ responsibilities. The final entry on this slide also stood out to me (but was not highlighted by the presenter), with 17% of the “leaders” saying that “software quality is a problem if it is too high”, interesting!
Presentations like this usually end up talking about best practices and this webinar was no different:
The presenter focused on the high rating given by the “leaders” “adoption of quality standards (such as ISO)” but overlooked what I took as one of the few positives from any of the data in the webinar, namely that adopting “a more comprehensive approach to software testing” was a practice generally seen as something worth continuing to do.
The deck wrapped up with a summary of the “Best Practices of Software Quality Leaders”:
These don’t strike me as actually being best practices, rather statements and dubious conclusions drawn from the survey data. Point 4 on this slide – “Embracing agile and improving your DevOps practice will improve your software quality” – was highlighted (of course) but is seriously problematic. Remember the self-assessed “leaders” claimed that their software quality was increasing due to expanding their “DevOps processes and toolchain”, but correlation does not imply causation as this point on this final slide implies. This apparent causality was reinforced by the presenter’s answer to a question during the Q&A also, when asked “what is one thing we can do to improve quality?”. He said his preference is to understand the impact that software quality has on the business, but his pragmatic answer is to “take stock of your DevOps practice and look for ways to improve it, since maturing your DevOps practice improves quality.”
There were so many issues for me with the methodology behind the data presented in this webinar. The self-assessment of software quality produced by these enterprises makes the foundation for all of the conclusions drawn from the survey data very shaky in my opinion. The same enterprises who probably over-rated themselves on quality are also likely to have over-rated themselves in other areas (which appears to be the case throughout). There is also evidence of mistakenly taking correlation to imply causation, e.g. suggesting that adding more DevOps process and tooling improves quality. (Even claiming correlation is dubious given the self-assessment problem underneath all the data.)
There’s really not much to take away from the results of this survey for me in helping to understand what differences in approach, process, practice, tooling, etc. might lead to higher quality outcomes. I’m not at all surprised or disappointed in feeling this way, as my expectations of such fluffy marketing-led surveys are very low (based on experiencing of critiquing a number of them over the last few years). What does disappoint me is not the “state of software quality” supposedly evidenced by such surveys, but rather the state of the quality of dialogue and critical thinking around testing and quality in our industry.
While writing my last blog post, a review of Cal Newport’s “Deep Work” book, I reminded myself of a topic I’ve been meaning to blog about for a while, viz. the power of the pause.
Coming at this from a software development perspective, I mentioned in the last blog post that:
“There seems to be a new trend forming around “deployments to production” as being a useful measure of productivity, when really it’s more an indicator of busyness and often comes as a result of a lack of appetite for any type of pause along the pipeline for humans to meaningfully (and deeply!) interact with the software before it’s deployed.”
I often see this goal of deploying every change directly (and automatically) to production without the goal being accompanied by compelling reasons for doing so – apart from maybe “it’s what <insert big name tech company here> does”, even though you’re likely nothing like those companies in most other important ways. What’s the rush? While there are some cases where a very quick deployment to production is of course important, the idea that every change needs to be deployed in the same way is questionable for most organizations I’ve worked with.
Automated deployment pipelines can be great mechanisms for de-risking the process of getting updated software into production, removing opportunities for human error and making such deployments less of a drama when they’re required. But, just because you have this mechanism at your disposal, it doesn’t mean you need to use it for each and every change made to the software.
I’ve seen a lot of power in pausing along the deployment pipeline to give humans the opportunity to interact with the software before customers are exposed to the changes. I don’t believe we can automate our way out of the need for human interaction for software designed for use by humans, but I’m also coming to appreciate that this is increasingly seen as a contrarian position (and one I’m happy to hold). I’d ask you to consider whether there is a genuine need for automated deployment of every change to production in your organization and whether you’re removing the opportunity to find important problems by removing humans from the process.
Taking a completely different perspective, I’ve been practicing mindfulness meditation for a while now and haven’t missed a daily practice since finishing up full-time employment back in August 2020. One of the most valuable things I’ve learned from this practice is the idea of putting space between stimulus and response – being deliberate in taking pause.
Exploring the work of Gerry Hussey has been very helpful in this regard and he says:
The things and situations that we encounter in our outer world are the stimulus, and the way in which we interpret and respond mentally and emotionally to that stimulus is our response.
Consciousness enables us to create a gap between stimulus and response, and when we expand that gap, we are no longer operating as conditioned reflexes. By creating a gap between stimulus and response, we create an opportunity to choose our response. It is in this gap between stimulus and response that our ability to grow and develop exists. The more we expand this gap, the less we are conditioned by reflexes and the more we grow our ability to be defined not by happens to us but how we choose to respond.
Awaken Your Power Within: Let Go of Fear. Discover Your Infinite Potential. Become Your True Self (Gerry Hussey)
I’ve found this idea really helpful in both my professional and personal lives. It’s helped with listening, to focus on understanding rather than an eagerness to simply respond. The power of the pause in this sense has been especially helpful in my consulting work as it has a great side effect of lowering the chances of jumping into solution mode before fully understanding the problem at hand. Accepting the fact that things will happen outside my control in my day to day life but that I have the choice in how to respond to whatever happens has been transformational.
Inevitably, there are still times where my response to stimuli is quick, conditioned and primitive (with system 1 thinking doing its job) – and sometimes not kind. But I now at least recognize when this has happened and bring myself back to what I’ve learned from regular practice so as to continue improving.
So, whether it’s thinking specifically about software delivery pipelines or my interactions with the world around me, I’m seeing great power in the pause – and maybe you can too.
I’ve just finished reading Deep Work by Cal Newport and I found it engaging, interesting and applicable. While reading it, there were many reminders for me of the work of Michael Bolton and James Bach around “deep testing”.
Cal defines “Deep Work” as:
Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.
while “Shallow Work” is:
Non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend to not create much new value in the world and are easy to replicate.
He argues that:
In an age of network tools… knowledge workers increasingly replace deep work with the shallow alternative – constantly sending and receiving email messages like human network routers, with frequent breaks for quick hits of distraction. Larger efforts that would be well served by deep thinking…get fragmented into distracted dashes that produce muted quality.
I’m sure that anyone who has worked in an office environment in the IT industry over the last decade will agree that their time has been impacted by distractions and a larger proportion of the working day has become occupied by shallow work. As if open plan offices weren’t bad enough on their own, the constant stream of pulls on your attention from email, Slack and social media notifications has resulted in a very distracted state becoming the norm.
One of the key messages Cal delivers in the book is that deep work is rare, valuable and meaningful:
The Deep Work Hypothesis: The ability to perform deep work is becoming increasingly rare at exactly the same time it is becoming increasingly valuable in our economy. As a consequence, the few who cultivate this skill, and then make it the core of their working life, will thrive.
He makes the observation that, even in knowledge work, there is still a tendency to focus on “busyness”:
Busyness as a Proxy for Productivity: In the absence of clear indicators of what it means to be productive and valuable in their jobs, many knowledge workers turn back toward an industrial indicator of productivity; doing lots of stuff in a visible manner.
I’ve seen this as a real problem for testers in many organizations. When there is poor understanding of what good testing looks like (the norm, unfortunately), it’s all too common for testers to be tracked and measured by test case counts, bug counts, etc. These proxies for productivity really are measures of busyness and not reflections of true value being added by the tester. There seems to be a new trend forming around “deployments to production” as being a useful measure of productivity, when really it’s more an indicator of busyness and often comes as a result of a lack of appetite for any type of pause along the pipeline for humans to meaningfully (and deeply!) interact with the software before it’s deployed. (I may blog separately on the “power of the pause” soon.)
On the subject of how much more meaningful deep work is, Cal refers to Dreyfus & Kelly’s All Things Shining book and its focus on craftsmanship:
A … potential for craftsmanship can be found in most skilled jobs in the information economy. Whether you’re a writer, marketer, consultant, or lawyer: Your work is craft, and if you hone your ability and apply it with respect and care, then like the skilled wheelwright [as example from the Dreyfus & Kelly book] you can generate meaning in the daily efforts of your professional life.
Cultivating craftsmanship is necessarily a deep task and therefore requires a commitment to deep work.
I have referred to software testing as a craft since I first heard it described as such by Michael Bolton during the RST course I attended back in 2007. Talking about testing in this way is important to me and, as Cal mentions, treating it as a craft that you can become skilled in and take pride in all helps to make life as a tester much more meaningful.
The second part of Cal’s book focuses on four rules to help achieve deep work in practice, viz. work deeply, embrace boredom, quit social media, and drain the shallows. I won’t go into detail on the rules here (in the interests of brevity and to encourage you to read the book for yourself to learn these practical tips), but this quote from the “drain the shallows” rule resonated strongly and feels like something we should all be trying to bring to the attention of the organizations we work with:
The shallow work that increasingly dominates the time and attention of knowledge workers is less vital than it often seems in the moment. For most businesses, if you eliminated significant amounts of this shallowness, their bottom line would likely remain unaffected. As as Jason Fried [co-founder of software company 37signals] discovered, if you not only eliminate shallow work, but also replace this recovered time with more of the deep alternative, not only will the business continue to function; it can become more successful.
Coming back to Cal’s definition of “deep work”:
Professional activities performed in a state of distraction-free concentration that push your cognitive capabilities to their limit. These efforts create new value, improve your skill, and are hard to replicate.
When I read this definition, it immediately brought to mind session-based test management (SBTM) in which timeboxed periods of uninterrupted testing are the unit of work. I’ve seen the huge difference that adoption of SBTM can make in terms of encouraging deeper testing and improving testing skills. Thinking about “deep testing”, Michael Bolton and James Bach have described it as follows:
Testing is deep to the degree that it has a probability of finding rare, subtle, or hidden problems that matter.
Deep testing requires substantial skill, effort, preparation, time, or tooling, and reliably and comprehensively fulfills its mission.
By contrast, shallow testing does not require much skill, effort, preparation, time, or tooling, and cannot reliably and comprehensively fulfill its mission.
The parallels between Cal’s idea of “deep work” and Michael & James’s “deep testing” are clear. Being mindful of the difference between such deep testing and the more common shallow testing I see in many teams is important, as is the ability to clearly communicate this difference to stakeholders (especially when testing is squeezed under time pressures or being seen as optional in the frantic pace of continuous delivery environments).
I think “Deep Work” is a book worth reading for testers, not just for the parallels with deep testing I’ve tried to outline above but also for the useful tips around reducing distractions and freeing up your capacity for deeper work.
Almost unbelievably, it’s now been a year since I left my long stint at Quest Software. It’s been a very different year for me than any of the previous 25-or-so spent in full-time employment in the IT industry. The continuing impact of COVID-19 on day-to-day life in my part of the world has also made for an unusual 12 months in many ways.
While I haven’t missed working at Quest as much as I expected, I’ve missed the people I had the chance to work with for so long in Melbourne and I’ve also missed my opportunities to spend time with the teams in China that I’d built up such a strong relationship with over the last few years (and who, sadly, have all since departed Quest as well as their operations there were closed down this year).
Starting to work with my first clients in a consulting capacity is an interesting experience with a lot of learning opportunities. I plan to blog on some of my lessons learned from these early engagements later in the year.
Another fun and testing-related project kicked off in May, working with my good friends from the industry, Paul Seaman and Toby Thompson, to start The 3 Amigos of Testing podcast. We’ve always caught up regularly to chat about testing and life in general over a cold one or two, and this new podcast has given us plenty of opportunities to talk testing again, albeit virtually. A new episode of this podcast should drop very soon after this blog post.
On more personal notes, I’ve certainly been finding more time for myself since ending full-time employment. There are some non-negotiables, such as daily one-hour (or more) walks and meditation practice, and I’ve also been prioritizing bike riding and yoga practice. I’ve been reading a lot too – more than a book a week – on a wide variety of different topics. These valuable times away from technology are foundational in helping me to live with much more ease than in the past.
I’ve continued to do volunteer work with The Vegan Society (UK). I started off performing proofreading tasks and have also now joined their web volunteers’ team where I’ve been leading research projects on how to reduce the carbon footprint of the Society’s website and also to improve its accessibility. These web research projects have given me the welcome opportunity to learn about areas that I was not very familiar with before, the “green website” work being particularly interesting and it has inspired me to pursue other opportunities in this area (watch this space!). A massive proofreading task led to the recent publication of the awesome Planting Value in the Food System reports, with some deep research and great ideas for transitioning UK farming away from animal-based agriculture.
Looking to the rest of 2021, the only firm commitment I have in the testing space – outside of consulting work – is an in-person conference talk at Testing Talks 2021 in Melbourne. I’ll be continuing with my considerable volunteering commitment with the Vegan Society and I have a big Status Quo project in the works too! With little to no prospect of long-distance travel in Australia or overseas in this timeframe, we will enjoy short breaks locally between lockdowns and also press on with various renovation projects on our little beach house.
(Given the title of this blog, I can’t waste this opportunity to include a link to one of my favourite Status Quo songs, “A Year” – this powerful ballad morphs into a heavier piece towards the end, providing some light amongst the heaviness of its parent album, “Piledriver”. Enjoy!)
After almost two decades of very regularly attending testing conferences, the combined impacts of COVID-19 and finishing up my career at Quest have curtailed these experiences in more recent times. I’ve missed the in-person interaction with the testing community facilitated by such events, as I know many others have also.
The latter stages of 2020 saw me give three talks; firstly for the DDD Melbourne By Night meetup, then a two-minute talk for the “Community Strikes The Soapbox” part of EuroSTAR 2020 Online, and finally a contribution to the inaugural TestFlix conference. All of these were virtual events and at least gave me some presentation practice.
With the chance to develop a completely new talk, I riffed on a few ideas before settling on what seemed like a timely story for me to tell, namely what I’ve learned from twenty-odd years in the testing industry. I’ve titled the talk “Lessons Learned in Software Testing”, in a deliberate nod to the awesome book of the same name.
I’ve stuck with my usual routine in putting this new talk together, using a mindmap to help me come up with the structure and key messages before starting to cut a slide deck. It remains a challenge for me to focus more on the talk content than refining the slides at this stage, but I’m making a conscious effort to get the messaging down on rough slides before putting finishing touches to them later on.
It’s been interesting to look back over such a long career in the one industry, thinking about the trends that have come and gone, and realizing how much remains the same in terms of being a good tester adding value to projects. I’m looking forward to sharing some of the lessons I’ve learned along the way – some specifically around testing and some more general – in this new talk later in the year.
The following quote in Adam’s article is lifted from this newer book and made me want to dive deeper into the book’s broader content around testing*:
Attempting to assess product quality by asking humans to manually interact with every feature just doesn’t scale. When it comes to testing, there is one clean answer: automation.
Chapter 11 (Testing Overview), p210 (Adam Bender)
I was stunned by this quote from the book. It felt like they were saying that development simply goes too quickly for adequate testing to be performed and also that automation is seen as the silver bullet to moving as fast as they desire while maintaining quality, without those pesky slow humans interacting with the software they’re pushing out.
But, in the interests of fairness, I decided to study the four main chapters of the book devoted to testing to more fully understand how they arrived at the conclusion in this quote – Chapter 11 which offers an overview of the testing approach at Google, chapter 12 devoted to unit testing, chapter 13 on test doubles and chapter 14 on “Larger Testing”. The book is, perhaps unsurprisingly, available to read freely on Google Books.
I didn’t find anything too controversial in chapter 12, rather mostly sensible advice around unit testing. The following quote from this chapter is worth noting, though, as it highlights that “testing” generally means automated checks in their world view:
After preventing bugs, the most important purpose of a test is to improve engineers’ productivity. Compared to broader-scoped tests, unit tests have many properties that make them an excellent way to optimize productivity.
Chapter 13 on test doubles was similarly straightforward, covering the challenges of mocking and giving decent advice around when to opt for faking, stubbing and interaction testing as approaches in this area. Chapter 14 dealt with the challenges of authoring tests of greater scope and I again wasn’t too surprised by what I read there.
It is chapter 11 of this book, Testing Overview (written by Adam Bender), that contains the most interesting content in my opinion and the remainder of this blog post looks in detail at this chapter.
The author says:
since the early 2000s, the software industry’s approach to testing has evolved dramatically to cope with the size and complexity of modern software systems. Central to that evolution has been the practice of developer-driven, automated testing.
I agree that the general industry approach to testing has changed a great deal in the last twenty years. These changes have been driven in part by changes in technology and the ways in which software is delivered to users. They’ve also been driven to some extent by the desire to cut cost and it seems to me that focusing more on automation has been seen (misguidedly) as a way to reduce the overall cost of delivering software solutions. This focus has led to a reduction in the investment in humans to assess what we’re building and I think we all too often experience the results of that reduced level of investment.
Automated testing can prevent bugs from escaping into the wild and affecting your users. The later in the development cycle a bug is caught, the more expensive it is; exponentially so in many cases.
Given the perception of Google as a leader in IT, I was very surprised to see this nonsense about the cost of defects being regurgitated here. This idea is “almost entirely anecdotal” according to Laurent Bossavit in his excellent The Leprechauns of Software Engineering book and he has an entire chapter devoted to this particular mythology. I would imagine that fixing bugs in production for Google is actually inexpensive given the ease with which they can go from code change to delivery into the customer’s hands.
Much ink has been spilled about the subject of testing software, and for good reason: for such an important practice, doing it well still seems to be a mysterious craft to many.
I find the choice of words here particularly interesting, describing testing as “a mysterious craft”. While I think of software testing as a craft, I don’t think it’s mysterious although my experience suggests that it’s very difficult to perform well. I’m not sure whether the wording is a subtle dig at parts of the testing industry in which testing is discussed in terms of it being a craft (e.g. the context-driven testing community) or whether they are genuinely trying to clear up some of the perceived mystery by explaining in some detail how Google approaches testing in this book.
The ability for humans to manually validate every behavior in a system has been unable to keep pace with the explosion of features and platforms in most software. Imagine what it would take to manually test all of the functionality of Google Search, like finding flights, movie times, relevant images, and of course web search results… Even if you can determine how to solve that problem, you then need to multiply that workload by every language, country, and device Google Search must support, and don’t forget to check for things like accessibility and security. Attempting to assess product quality by asking humans to manually interact with every feature just doesn’t scale. When it comes to testing, there is one clear answer: automation
(note: bold emphasis is mine)
We then come to the source of the quote that first piqued my interest. I find it interesting that they seem to be suggesting the need to “test everything” and using that as a justification for saying that using humans to interact with “everything” isn’t scalable. I’d have liked to see some acknowledgement here that the intent is not to attempt to test everything, but rather to make skilled, risk-based judgements about what’s important to test in a particular context for a particular mission (i.e. what are we trying to find out about the system?). The subset of the entire problem space that’s important to us is something we can potentially still ask humans to interact with in valuable ways. The “one clear answer” for testing being “automation” makes little sense to me, given the well-documented shortcomings of automated checks (some of which are acknowledged in this same book) and the different information we should be looking to gather from human interactions with the software compared to that from algorithmic automated checks.
Unlike the QA processes of yore, in which rooms of dedicated software testers pored over new versions of a system, exercising every possible behavior, the engineers who build systems today play an active and integral role in writing and running automated tests for their own code. Even in companies where QA is a prominent organization, developer-written tests are commonplace. At the speed and scale that today’s systems are being developed, the only way to keep up is by sharing the development of tests around the entire engineering staff.
Of course, writing tests is different from writing good tests. It can be quite difficult to train tens of thousands of engineers to write good tests. We will discuss what we have learned about writing good tests in the chapters that follow.
I think it’s great that developers are more involved in testing than they were in the days of yore. Well-written automated checks provide some safety around changing product code and help to prevent a skilled tester from wasting their time on known “broken” builds. But, again, the only discussion that follows in this particular book (as promised in the last sentence above) is about automation and not skilled human testing.
Fast, high-quality releases With a healthy automated test suite, teams can release new versions of their application with confidence. Many projects at Google release a new version to production every day—even large projects with hundreds of engineers and thousands of code changes submitted every day. This would not be possible without automated testing.
The ability to get code changes to production safely and quickly is appealing and having good automated checks in place can certainly help to increase the safety of doing so. “Confidence” is an interesting choice of word to use around this (and is used frequently in this book), though – the Oxford dictionary definition of “confidence” is “a feeling or belief that one can have faith in or rely on someone or something”, so the “healthy automated test suite” referred to here appears to be one that these engineers feel comfortable to rely on enough to say whether new code should go to production or not.
The other interesting point here is about the need to release new versions so frequently. While it makes sense to have deployment pipelines and systems in place that enable releasing to production to be smooth and uneventful, the desire to push out changes to customers very frequently seems like an end in itself these days. For most testers in most organizations, there is probably no need or desire for such frequent production changes so deciding testing strategy on the perceived need for these frequent changes could lead to goal displacement – and potentially take an important aspect of assessing those changes (viz. human testers) out of the picture altogether.
If test flakiness continues to grows you will experience something much worse than lost productivity: a loss of confidence in the tests. It doesn’t take needing to investigate many flakes before a team loses trust in the test suite, After that happens, engineers will stop reacting to test failures, eliminating any value the test suite provided. Our experience suggests that as you approach 1% flakiness, the tests begin to lose value. At Google, our flaky rate hovers around 0.15%, which implies thousands of flakes every day. We fight hard to keep flakes in check, including actively investing engineering hours to fix them.
It’s good to see this acknowledgement of the issues around automated check stability and the propensity for unstable checks to lead to a collapse in trust in the entire suite. I’m interested to know how they go about categorizing failing checks as “flaky” to be included in their overall 0.15% “flaky rate”, no doubt there’s some additional human effort involved there too.
Just as we encourage tests of smaller size, at Google, we also encourage engineers to write tests of narrower scope. As a very rough guideline, we tend to aim to have a mix of around 80% of our tests being narrow-scoped unit tests that validate the majority of our business logic; 15% medium-scoped integration tests that validate the interactions between two or more components; and 5% end-to-end tests that validate the entire system. Figure 11-3 depicts how we can visualize this as a pyramid.
It was inevitable during coverage of automation that some kind of “test pyramid” would make an appearance! In this case, they use the classic Mike Cohn automated test pyramid but I was shocked to see them labelling the three different layers with percentages based on test case count. By their own reasoning, the tests in the different layers are of different scope (that’s why they’re in different layers, right?!) so counting them against each other really makes no sense at all.
Our recommended mix of tests is determined by our two primary goals: engineering productivity and product confidence. Favoring unit tests gives us high confidence quickly, and early in the development process. Larger tests act as sanity checks as the product develops; they should not be viewed as a primary method for catching bugs.
The concept of “confidence” being afforded by particular kinds of checks arises again and it’s also clear that automated checks are viewed as enablers of productivity.
Trying to answer the question “do we have enough tests?” with a single number ignores a lot of context and is unlikely to be useful. Code coverage can provide some insight into untested code, but it is not a substitute for thinking critically about how well your system is tested.
It’s good to see context being mentioned and also the shortcomings of focusing on coverage numbers alone. What I didn’t really find anywhere in what I read in this book was the critical thinking that would lead to an understanding that humans interacting with what’s been built is also a necessary part of assessing whether we’ve got what we wanted. The closest they get to talking about humans experiencing the software in earnest comes from their thoughts around “exploratory testing”:
Exploratory Testing is a fundamentally creative endeavor in which someone treats the application under test as a puzzle to be broken, maybe by executing an unexpected set of steps or by inserting unexpected data. When conducting an exploratory test, the specific problems to be found are unknown at the start. They are gradually uncovered by probing commonly overlooked code paths or unusual responses from the application. As with the detection of security vulnerabilities, as soon as an exploratory test discovers an issue, an automated test should be added to prevent future regressions.
Using automated testing to cover well-understood behaviors enables the expensive and qualitative efforts of human testers to focus on the parts of your products for which they can provide the most value – and avoid boring them to tears in the process.
This description of what exploratory testing is and what it’s best suited to are completely unfamiliar to me, as a practitioner of exploratory testing for fifteen years or so. I don’t treat the software “as a puzzle to be broken” and I’m not even sure what it would mean to do so. It also doesn’t make sense to me to say “the specific problems to be found are unknown at the start”, surely this applies to any type of testing? If we already know what the problems are, we wouldn’t need to test to discover them. My exploratory testing efforts are not focused on “commonly overlooked code paths” either, in fact I’m rarely interested in the code but rather the behaviour of the software experienced by the end user. Given that “exploratory testing” as an approach has been formally defined for such a long time (and refined over that time), it concerns me to see such a different notion being labelled as “exploratory testing” in this book.
TL;DRs Automated testing is foundational to enabling software to change. For tests to scale, they must be automated. A balanced test suite is necessary for maintaining healthy test coverage. “If you liked it, you should have put a test on it.” Changing the testing culture in organizations takes time.
In wrapping up chapter 11 of the book, the focus is again on automated checks with essentially no mention of human testing. The scaling issue is highlighted here also, but thinking solely in terms of scale is missing the point, I think.
The chapters of this book devoted to ‘testing” in some way cover a lot of ground, but the vast majority of that journey is devoted to automated checks of various kinds. Given Google’s reputation and perceived leadership status in IT, I was really surprised to see mention of the “cost of change curve” and the test automation pyramid, but not surprised by the lack of focus on human exploratory testing.
Circling back to that triggering quote I saw in Adam’s blog (“Attempting to assess product quality by asking humans to manually interact with every feature just doesn’t scale”), I didn’t find an explanation of how they do in fact assess product quality – at least in the chapters I read. I was encouraged that they used the term “assess” rather than “measure” when talking about quality (on which James Bach wrote the excellent blog post, Assess Quality, Don’t Measure It), but I only read about their various approaches to using automated checks to build “confidence”, etc. rather than how they actually assess the quality of what they’re building.
I think it’s also important to consider your own context before taking Google’s ideas as a model for your own organization. The vast majority of testers don’t operate in organizations of Google’s scale and so don’t need to copy their solutions to these scaling problems. It seems we’re very fond of taking models, processes, methodologies, etc. from one organization and trying to copy the practices in an entirely different one (the widespread adoption of the so-called “Spotify model” is a perfect example of this problem).
Context is incredibly important and, in this particular case, I’d encourage anyone reading about Google’s approach to testing to be mindful of how different their scale is and not use the argument from the original quote that inspired this post to argue against the need for humans to assess the quality of the software we build.
After leaving Quest back in August 2020, I spent some time working on ideas for a new venture. During this time, I learned some useful lessons from courses by Pat Flynn and got some excellent ideas from Teachable‘s Share What You Know Summit. When I launched my new software testing consultancy, Dr Lee Consulting, I decided to try out one of the ideas I’d heard for generating content around my new brand and so started a blog series, inspired most notably by Terry Rice.
After committing to a ten-part series of posts, I decided to announce my intention publicly (on Twitter and LinkedIn) to keep myself honest, but chose not to commit to a cadence for publishing the parts. I felt that publishing a new blog post once a week was about right and made an internal note to aim for this cadence. Some posts took longer to write than others and the review cycle was more involved for some posts. The series also spread over the Christmas/New Year period, but the entire series took me just on three months to complete so my cadence ended up being close to what I initially thought it would be.
My blogging over the last several years has usually been inspired by something I’ve read or observed or an event I’ve attended such a conference or meetup. These somewhat more spontaneous and sporadic content ideas mean that my posts have been inconsistent in both topic and cadence, not that I see any of this as being an issue.
Committing to a series of posts for which the subject matter was determined for me (in this case by search engine data) meant that I didn’t need to be creative in coming up with ideas for posts, but instead could focus on trying to add something new to the conversation in terms of answering these common questions. I found it difficult to add much nuance in answering some of the questions, but others afforded more lengthy and perhaps controversial responses. Hopefully the series in its entirety is of some value anyway.
My thanks again to Paul Seaman and Ky for reviewing every part of this blog series, as well as to all those who’ve amplified the posts in this series via their blogs, newsletters, lists and social media posts.
The ten parts of my first blog series can be accessed using the links below:
In October 2020, I published my first software testing book, “An Exploration of Testers”. As I mentioned then, one of my intentions with this project was to generate some funds to give back to the testing community (with 100% of all proceeds I receive from book sales being returned to the community).
I’m delighted to announce that I’ve now made my first donation as a result of sales so far, based on royalties for the book in LeanPub to date:
(Note that there is up to a 45-day lag between book sales and my receipt of those funds, so some recent sales are not included in this first donation amount.)
I’ve personally rounded up the royalties paid so far (US$230.93) to form a donation of US$250 (and covered their processing fees) to the Association for Software Testing for use in their excellent Grant Program. I’m sure these funds will help meetup and peer conference organizers greatly in the future.
I will make further donations of royalties received from book sales not covered by this first donation.
“An Exploration of Testers” is available for purchase via LeanPub and a second edition featuring more contributions from great testers around the world should be coming soon. My thanks to all of the contributors so far for making the book a reality and also to those who’ve purchased a copy, without whom this valuable donation to the AST wouldn’t have been possible.