This interview with Angie Jones is part of the Hexawise “Testing Smarter with…” software testing interview series. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

photo of Angie Jones
Angie Jones

Angie Jones is a Senior Software Engineer in Test at Twitter who has developed automation strategies and frameworks for countless software products. Angie shares her wealth of knowledge by speaking and teaching at software conferences all over the world and leading tech workshops for young girls through Black Girls Code.

Personal Background

Hexawise: Wow! You’re everywhere. Conference presentations around the globe at a break-neck pace. How’d that happen, exactly?

Angie: Ha ha. I’ve been doing test automation for quite some time. In early 2016, I attended a testing conference and didn’t learn much of anything new. It wasn’t a knock on the conference, but it was a wake up call for me.

I also interviewed people for automation roles quite often and found it was extremely hard to find people that were on the same level as my team. I realized that I have something to contribute and should be working to advance the industry in any small way that I can.

Diversity is also something that’s extremely important to me, so I thought being a black female on the stages of white male dominated conferences could also be my way of shaking up the game a little bit.

Actually, seeing a black woman announced as a speaker at a tech conference on Twitter was something that stopped me in my tracks. It wasn’t something I’d seen before. The conference was Write/Speak/Code, an event that empowers women to become thought leaders by writing blogs, speaking at conferences, and contributing to open source software! It was exactly what I needed. I attended and it absolutely changed my life. In less than 6 months after that conference, I’d become an international speaker and was being invited to keynote across the world. It all happened so was crazy!

Hexawise: You have helped Black Girls Code and TechGirlz work to provide girls the opportunity to learn to code. Do those efforts leave you with hope that the future is in good hands?

Angie: You know, I set out to inspire young girls, but every time I work with them I’m the one who leaves totally inspired and renewed. The girls are so smart and innovative! I give them a little push and they end up creating things that totally blow me away. The idea is to plant the seed. I wasn’t exposed to technology much as a young girl and had no idea that computer programming was even a career option. I almost missed my calling because of that. I don’t want our industry to miss out the next Tech Rock Star because she didn’t know about us.

The greatest businesses are ones that observe how their customers are misusing their products/services and adapt accordingly to make it easier for them to do what it is that they want to do, and still gain the benefit of the product/service.

Hexawise: Recently you moved from the Raleigh-Durham area (home to Hexawise, among other technology companies) to San Francisco and took a new role at Twitter. How did that come about? What is your new job?

Angie: Yes, I’m so excited about this new opportunity at Twitter! I told myself that my next role was going to be something fun and cutting edge. Twitter is just that! I love the platform, I love the innovative culture, and I love the possibilities for growth. I’m working on critical automation tasks and helping to drive automation efforts related to ads and live video.

Hexawise: Have you gained a new insight into some aspect of software testing from your work at Twitter that you can share? You haven't been at Twitter long but sometimes in a new environment people are especially alert and gain insights that others may not notice.

Angie: When I have the privilege of choosing the work I'll be doing, I lean towards companies who understand the need for both a Tester and an Automation Engineer. Twitter gets that, which played a big role in my decision to accept this position. I, along with a few other industry leaders, have been preaching for a while now that we don't necessarily need all testers writing automation, but with the complexity of today's applications, testers do need to be technical in order to do a thorough job.

At Twitter, I've now seen just how true that is. I'm working with top notch testers who aren't programmers but they understand the intricate plumbing of our systems and are capable of digging into the guts of the application to ensure all pieces are working as they should. This requires quite a bit of technical acumen yet very little coding. I'll further explore this in my keynotes this Fall at Targeting Quality (Canada), and Agile Testing Days (Germany).

Views on Software Testing

Hexawise: Your article BDD Without the Three Amigos: Maybe Talking To Yourself Isn't So Bad is really thought provoking. In it, you acknowledge that Behavior-Driven Development (BDD) “done right” includes the 3 amigos, but you go on to explore what happens in situations when BA’s and Developers aren’t wiling to “play ball”. You suggest that you have seen testers gain significant value on their own by using BDD. Testers, for example, can create Gherkin feature files with clear “Given / When / Then” instructions that enable rapid creation of executable test scripts.

Angie: Yeah, we often make these hard fast rules and try to force everyone to follow them. Whenever someone “misuses” a practice, all hell breaks loose on the internet. I’ve consulted with a lot of teams and came to realize that these teams are not naive. They realize that they are using the approach differently than it was intended to be used. However, they’ve made it work for them. The greatest businesses are ones that observe how their customers are misusing their products/services and adapt accordingly to make it easier for them to do what it is that they want to do, and still gain the benefit of the product/service. To that point, Matt Wynne, co-founder of Cucumber BDD, actually read this piece and realized that there was more he could do in the industry to push for collaboration from the other amigos.

In a fast-paced software delivery model, automation is definitely needed, but many companies make the mistake of thinking it’s a replacement for testing... Automation should be used as a tool... a technique to enhance testing efforts.

Hexawise: What testing practice(s) do you most wish the software testing community would embrace?

Angie: That’s an easy one...Automation. But there’s definitely some education needed around this, which is why I write and speak on topics in this space. In a fast-paced software delivery model, automation is definitely needed, but many companies make the mistake of thinking it’s a replacement for testing. Anytime I’ve seen companies take this approach, the quality of their product has greatly suffered. Automation should be used as a tool... a technique to enhance testing efforts.

Hexawise: In your presentation at the 2016 SeleniumConf UK conference, you explore "How to Get Automation Included in Your Definition of Done." In that talk you discuss the idea that automation is useful but also that not all tests should be automated. How should a test team go about determining what software tests should be automated?

Angie: Ha ha. That’s a talk in and of itself. Actually, I’m going to give that talk at STPCon in the Fall of 2017. I get asked this question all the time, and it’s such a tricky thing to nail down. That’s because it’s highly contextual to the needs of the business. To do this topic any justice, I plan to explore several case studies in the STPCon talk and demonstrate how context plays such an essential part in answering this question correctly.

Industry Observations / Industry Trends

Hexawise: What trends do you foresee impacting the software testing community in the next 5 to 10 years?

Angie: With the explosion of the Internet of Things (IoT) and artificial intelligence, the systems that we test are going to become a lot more complex. This will require an evolution of testing. Our roles will become even more technical, and yet also require a healthy balance of humanity. The scenarios realized by these smart systems will require thorough testing and solid judgment. Software testing will look a lot different in 10 years, but will be extremely exciting!

Hexawise: Do you see organizations integrating software testers into the software development process (as compared to those instances where the first time software testers are involved is when software is delivered to be tested)? Do you believe more integration of software testers throughout the software development and maintenance process would be useful as software testing evolves?

Angie: I’ve already seen a huge improvement in integrating software testers into the development process with the embracing of agile practices. Quality is no longer solely owned by testers. Developers are testing their features before check-in, and testers are present throughout the entire process, essentially offering insight as early as the requirements phase. This has been essential as teams are adopting continuous integration and deployment processes. Time is of the essence, and the earlier we can avoid/find/correct mistakes, the better!

Hexawise: For those who are not used to involving testers early in the software development process, how would you describe the benefits to the business of involving software testers early in the process?

Angie: By involving testers early in the software development process, the team is able to identify and correct assumptions. This essentially eliminates potential bugs before production even begins. Testers bring in a breadth of knowledge about the application as a whole and how the individual components work together. Testers also serve as a customer advocate, ensuring that their goals are being considered. So, while the team is discussing a potential feature, the tester is advocating for the customer and also calling out how this can affect existing features in the system.

I sat in a design meeting recently and watched the tester poke holes in the proposed design and call out omissions that would cost us millions of dollars. The developers left that meeting with a list of requirements and considerations that they had missed. That's beyond valuable.

Staying Current / Learning

Hexawise: How do you stay current on improvements in software testing practices?

Angie: I read a ton. I’m subscribed to several blogs, and I use Twitter to find new ones all the time. People are always creating new tools or approaches to solve interesting problems and I try to absorb as much of it as I can.

I don’t limit myself to testing blogs. I also read development blogs and tech news sites to stay up to date with trends in the software industry as a whole. This helps me think past my current role and prepare myself for the future as well.

I’ve already seen a huge improvement in integrating software testers into the development process with the embracing of agile practices. Quality is no longer owned by testers. Developers are testing their features before check-in, and testers are present throughout the entire process, essentially offering insight as early as the requirements phases.

Hexawise: You have presented at and attended many technology conferences. What advice do you have for people attending software conferences so that they can get more out of the experience?

Angie: It’s so funny how people tend to flock towards topics they are familiar with. They end up sitting there nodding in agreement with everything the speaker says, sharing their own experiences during Q&A, and leaving thinking that was such a great talk. However, did they learn anything new?

I try to attend talks that will address an unsolved problem that I have, or is in an area that I know very little about. These are the talks where I gain the most insight and can bring something of value back to my job.

Also, be sure to network! You won’t remember everything that people said during their talks, but leaving with a catalog of names and contact information of not just the speakers, but attendees as well, is gold! I often hit problems and I recall meeting someone a year ago at a conference who talked about this very problem during the cocktail hour. Because I networked with them, I feel comfortable reaching out and asking for help.

Hexawise: What blogs would you recommend should be included in a software tester's RSS feed reader?

Angie: Fortunately, Ministry of Testing has an aggregated feed that I use all the time. It consists of more than 500 testing blogs! It’s my morning newspaper.


Angie Jones is a Senior Software Engineer in Test at Twitter who has developed automation strategies and frameworks for countless software products. As a Master Inventor, she is known for her innovative and out-of-the-box thinking style which has resulted in more than 20 patented inventions in the US and China.

Angie shares her wealth of knowledge by speaking and teaching at software conferences all over the world and leading tech workshops for young girls through Black Girls Code.


Blog: Angie Jones

Twitter: @techgirl1908

Read previous Testing Smarter with... interviews: Testing Smarter with Alan Page - Testing Smarter with Dorothy Graham - Testing Smarter with Mike Bland

Subscribe to the RSS feed for the Hexawise software testing blog.

By: John Hunter and Justin Hunter on Jun 14, 2017

Categories: Interview, Interesting People , Software Testing, Testing Smarter with...

This interview with James Bach is the first our series of “Testing Smarter with…” interviews. Our goal with these interviews is to highlight insights and experiences as told by many of the software testing field’s leading thinkers.

James Bach, one of the most well-known and controversial leaders in the software testing community, challenges himself and others to continually develop their software testing approaches. James believes that excellent testing is a craft that requires many skills and ongoing practice and focus to develop and maintain those skills. The skills of testing include general systems analysis and critical thinking, but also social skills. In some sense, any child can test. But children and other amateurs cannot test systematically, nor can they provide professional self-assessment and reporting on the testing they do.

photo of James Bach
James Bach, Founder and CEO of Satisfice Inc

Personal Background

Hexawise: What one or two software testing-related experiences have you found to be most personally satisfying in your career?

James Bach: In 2002, Microsoft complained to a federal judge that I hadn’t given it a power cord. Yes, an ordinary power cord of the kind you can pull out of the back of any standard desktop computer. Yes, to a federal judge. No, I am not making this up. Yes, I also thought it was bizarre-- bizarre but kind of satisfying.

This happened during the Microsoft Remedies Trial, wherein nine American states were suing Microsoft and the government because they wanted a tougher punishment for Microsoft after it lost its big antitrust case. The states hired me as an expert witness to find out if Microsoft was telling the truth when it claimed it was “technically infeasible” to remove IE and the Windows Media Player. I gathered a team and went to work. I soon discovered that it was possible to remove these things-- using only public information and Microsoft’s own helpful tech support people to set up my testing to prove it. (The tech support people did not realize the purpose of my questions, and cheerily gave me all that I needed to know.)

When I revealed my results, Microsoft demanded that I turn over all the materials necessary to reproduce my results. So I gave them one of my test systems. At the last moment, I pulled out the power cord, thinking that I was causing some low-level techie 30 seconds of annoyance. But the next day Microsoft was in court acting like I had withheld the Golden Power Cord of Truth.

It was satisfying because Microsoft never even attempted to proved me wrong on the facts. They used lawyer tricks to stop my truth bombs, instead. Way to go, Bill Gates.

Another satisfying moment was watching my son find a catastrophic bug in a life-critical piece of medical equipment. He didn’t ask for a spec or a test case specification. He used video-gamer techniques to confuse the system until it overrode its own safety features and melted itself inside the simulated patient. Yeah. Melted. That was a $3000 piece of equipment he ruined. I’ve rarely been prouder of myself for having such foresight as to create a son like him: he is such a good test tool.

people who don’t “embrace exploratory testing” are, to me, not even testers. They are fact checkers, maybe. I think that’s not good enough.

Hexawise: Failures can often lead to interesting lessons learned. Do you have any noteworthy failure stories that you’d be willing to share?

James: How about the time I tried to set up my corporate server. I got it all working. Then I moved it from the conference room to the server room. I couldn’t get it to come online after that. For 12 hours I worked on it, all through the night. At long last I relented to my brother’s suggestion-- that we move it back to the conference room. I had refused to do that because it didn’t make any sense. The conference room simply connected to the server room. How would adding an extraneous variable like that change anything. But, zoom, we were back online.

After a moment of “wha??” the solution flashed into my mind: we must have two feeds to the Internet instead of one. It turned out that the conference room was patched into the open net, but the other port I had been using in the server room was routed through a firewall which in turn connected to the net. Nobody told me this during the buildout of my office space. It was a completely missing possibility in my mind.

So what did I learn? I learned about the importance of de-focusing, which includes trying apparently silly things to solve problems. I’m more open to that now.

Here is another interesting failure. I recently wrote a report involving the calculation of percentages. A non-technical person (a lawyer I worked with) checked my math and found it to be wrong. In fact, every one of her calculations was wrong. But in the process of refuting her claims, I discovered a different error in one of my own numbers. So, isn’t that interesting? Even if a critique of your work is incorrect, it could still be a useful stimulant to help you find your own problems.

Hexawise: What kinds of activities do you enjoy when you’re not at work?

James: I run a business, so I feel like I’m always at work. But I guess I do take little bits of time off each day. What do I do? I daydream. I read science news. I solve math and logic puzzles. I try to walk each day. And I watch videos with my wife. We binge on English television series, mostly.

Hexawise: Describe a testing experience you are especially proud of. What discovery did you make while testing and how did you share this information so improvements could be made to the software?

James: Well, many of those things I now use as testing exercises for my students, so I don’t want to spoil them. But, hmm, here’s one. I was given one day to break into an invoicing system for a large pharmaceutical company. I found three ways to do it. One of the methods I used was to get one of the sales engineers to sit with me while I tested. I asked him to demo the system to me and then he hung around while I tried to break-in. The first time I broke in (using a traversal attack if you follow such things) I didn’t even know I had done it until the sales engineer said “hey you aren’t supposed to see that data.” Good thing he was there, huh? So part of testing can be charming people into helping you, and you never know what that help will bring.

Views on Software Testing

Hexawise: Some of the thought-provoking ideas you and Michael Bolton have come up with, like the important distinction between Testing vs. Checking have received a great deal of attention within the community. Other intellectual contributions to the community you have made are not as well known but are arguably equally important and insightful. One such contribution that comes to mind which really resonates with us at Hexawise is the exploratory-scripted (or formality) continuum you and your brother Jon described.

image of software testing formality continuum

Do you have one or two intellectual contributions to the community that you wish were more widely known?

James: I wish that more people understood the folly, the sheer silliness, of counting test cases and calculating pass rates.

I don’t care if you have 80 test cases or 8 million of them. That number tells me nothing about you or your testing. It tells me nothing by itself, and it tells me nothing in conjuction with other information (except in rare cases not worth talking about). It’s like telling me that you have broken your day into 27 tasks, of 1353 tasks, or whatever. Just stop. Instead of fake science smoke rings, tell me what you actually did. Here’s a simple suggestion: instead of giving me a number, give me a list: a list of test ideas, test cases, test activities, bugs, features, people… I can do something with a list. But if you give me a number I just have to say “show me the things you are counting.”

Hexawise: Can you describe a view or opinion about software testing that you have changed your mind about in the last few years? What caused you to change your mind?

James: I used to think it was useful to talk about exploratory testing. But now I think it’s more helpful to say that all testing is exploratory. To say “exploratory testing” is the same as saying “testing.” Instead, I speak of how testing can be more or less formal, but it is always informal to some degree or else it ceases to be testing.

Also, in the last few years I have concluded that term “test automation” is toxic and should be avoided. It deposits a little poison in the mind whenever it is uttered. An angel loses its wings every time someone calls himself an “automated tester.” I changed my mind on both things as the result of ongoing attempts to teach students and hearing their questions and seeing where they get confused. That, and deep conversations with Michael Bolton.

Hexawise: How do/would you test very complex systems such as genetic algorithm systems and evolutionary systems? How do you test systems when we don't understand how they work? It seems kind of like medical differential diagnosis: poke, observe, learn, hypothesize, poke again. Or is there a better way?

James: I test them using social science methods. That, after all, is how scientists attempt to test their theories about social life. That means an emphasis on qualitative analysis, but bringing in statistical methods whenever applicable.

I agree that the medical world is a good example of where statistical methods and heuristic approaches are also needed. In testing complex things, some of what you need to do includes:

  • You must use time to your advantage-- observing systems over time the way primatologists observe chimps in the wild.
  • You must use Grounded Theory, beginning with immersion and observation, until patterns begin to reveal themselves.
  • You must focus on testability. To create an environment where you can control and observe more of what is there.
  • You must pay attention to clues. Many, many clues. Stop looking for simplistic “test cases” that will “prove” that the software works.
  • You must become expert at data wrangling, since these systems usually involve huge amounts of data.
  • Let other people help you.
  • Forge partnerships with users.

If it’s a training gig then my objective is to show them what testing can be, show them a path to get there, and encourage them to walk that path. A lot of that is about removing the obstacles to moving along.

Hexawise: It is clear from your writings and frequent presentations, that you feel passionately that the software testing community would greatly benefit if far more testers embraced Exploratory Testing. It’s a deeply held conviction. What particular testing practice(s) do you most wish the software testing community would embrace?

James: Testing is exploratory. So, people who don’t “embrace exploratory testing” are, to me, not even testers. They are fact checkers, maybe. I think that’s not good enough.

I wish more testers were mathematically inclined. You must see this, too, at Hexawise-- the widespread math-phobia in our field. I want to talk about Karnaugh maps and the value of de Bruijn sequences. But I have to keep that stuff out of my classes or I will freak most people out. It’s not that I am a mathematics expert. I’m just an enthusiast who wants to be held to a higher standard. But even my dalliances in Bayesian belief nets sound like high elf incantations to most testers. Mathematical disabilities, in general, make our craft prey to quackery and fraud of all kinds.

At the same time, I want to be inclusive. Mathophobes have a lot of offer and I don’t want them to think I don’t welcome them. But must they necessarily be the majority of testers? I guess I’m saying I want a cure for mathophobia, please.

Hexawise: What do you wish more developers, business analysts, and project managers understood about software testing?

James: I wish they understood that it benefits from specialization. When software people get heart disease they don’t limit themselves to a GP, do they? If they need surgery they don’t insist on being operated on by a rotating team of generic medical people who took a three day class in “Agile medicine” do they?

I get to be a specialist tester mainly because I do it on my own time. My clients are paying me, usually, for training, not for doing testing. So I usually test in my “free time” to sharpen my skills. I recently did have a wonderful and lucrative testing-related gig (because this particular project knew that it needed the best tester and analyst it could possibly get and became convinced I was the Chosen One), but those gigs are few and far between for someone like me.

Hexawise: When individual companies hire you for consulting engagements, how would you describe what it is that you usually seek to provide to them?

James: If it’s a training gig then my objective is to show them what testing can be, show them a path to get there, and encourage them to walk that path. A lot of that is about removing the obstacles to moving along. Chief among those obstacles is lack of confidence. So I do a lot of pep talking. Another obstacle is the very primitive, mechanical way that people think about testing. I have to replace that with systems thinking.

If it’s a testing gig then my objective is usually to provide deep, exemplary testing, that is transparent to my client. I want them to feel that they see their product in a beautiful focus. The danger I am always in when I test is that I will get too deep (and therefore be too slow and expensive). But for me, deep testing is the most fun, so it’s a constant struggle to hold myself back from using my most penetrating methods and tools.

Industry Observations / Industry Trends

Hexawise: As Artificial Intelligence increases in capability (for example the strides made by Watson) do you foresee an increase in the capabilities of computer checking? I am thinking, not of an elimination of the difference between human lead testing and what can be done without people but to what extent you see the possibility for AI to do a progressively much better job of checking.

James: I foresee a collapse of critical thinking about these complex systems, followed by some sort of disaster, followed by a new realization of the risks of surrendering human judgment to a machine. I foresee that this will be an ongoing cycle. This collapse of critical thinking will lead to more shallow testing and perfunctory checking, presented as if it were deep. For an example of what I mean, see this old computer commercial:

Pay attention starting at 2:05. Oh look, the computer is assuring us that it has no errors. Everyone relax! It’s “electronic brain” can be trusted!

Hexawise: Do you have any predictions about how large an impact Artificial Intelligence and Machine Learning will have on software testing in the next 5-10 years?

James: I don’t think it will have any impact on testing as such, except inasmuch as many people (not skeptical testers, but people who might otherwise hire testers) will trust black boxes when they should be challenging them.

I suppose as machine learning become more available to the masses, someone might try to train one to recognize bad output of some kind. That’s a sort of test tool. But it would only apply to well-established kinds of badness.

If you think about it, anti-spam systems are a sort of test system. Machine learning is used in spam filters. So, I guess testing is already using machine learning in that sense. But I don’t see the average tester applying machine learning methods to testing. I don’t see a developer doing that, either. It’s too involved and complicated; too narrow in application.

I hear that people at Google are going to “put coders out of business” with a system that writes code based on people just talking. You know what that’s called? A compiler. They are inventing a high level compiler. Now the people who talk will be called developers and will have to learn to talk properly, because it will emerge that normal people can’t say what they actually want.

Hexawise: Have you seen a particularly effective process where the software testing team was integrated into the feedback from a deployed software application (getting feedback from users on problems, exploring issues the software noted as possible bugs...)? What was so effective about that instance?

James: Not really. What I see is developers ignoring feedback. It’s too overwhelming. I suspect there are people who are really good at doing that. But I haven’t run across any.

One of the things that has happened with DevOps is a de-emphasis on testing and more of an emphasis on overall risk management. That’s a valid strategy, of course, but it has interesting blind spots. Whenever I hear a developer speak about wanting feedback from users I immediately think about how abusive and incompetent most users are about reporting problems. No, my developer friends, you really don’t want to read all those Internet comments on your software. You will be demoralized. But testers? We love reading that stuff. It’s our wheelhouse. We get clues and then we can reproduce the problems and make them sensible for the devs.

My brother, at eBay, with his testing mentality, loves going over the user feedback and bringing it to the teams there. But he will tell you it’s a constant struggle to get the attention of the dev teams.

attend a conference. Don’t bother to go to the talks, though. Most of the talks are full of fluff. Instead, find people and talk to them. Compare notes, make friends. Go to the testing lab.

Hexawise: Often one of the major roadblocks to software testers is their own management. Do you think this is a fair statement? Do you have suggestions for how testers can attempt to improve the situation. My background is strongly influenced by W. Edwards Deming so I have a tendency to look at the organization as a system and see room to improve the management system. It seems to me often the biggest gains are not possible if we keep departments separate (software development, software testing, marketing, customer service...). We can make improvements in software testing even if it is largely seen as separate from the organization but in doing so we miss much greater potential improvement.

James: The collapse of the test management industry is a terrible problem. It’s getting harder to find any kind of test manager out there. Do they even exist in Silicon Valley any more or have they all been hunted down by parasitic wasps who lay “scrum master” eggs in their living carcasses?

People who seem to know little about management or testing tell me that test managers are not needed. Okay, that means a whole lot of things that test managers do will not get done. This includes: providing a protected place for testers to work, free of harassment; negotiating for testability; negotiating for resources; assuring that schedules are reasonable; assuring that testing gets the respect it requires in order to attract and keep talented people; assuring that deadlines are met; explaining testing to management; assuring that testers are properly trained. When those things aren’t happening, testers tend to become more zombie-like and reactive (I’m not speaking of those fast zombies); or they become cheerleaders for the devs, instead of critical thinkers.

Staying Current / Learning

Hexawise: How do you stay current on improvements in software testing practices?

James: I’m not convinced there are improvements in testing practices in the absence of improvements in the thinking and social systems that drive practices-- and those things don’t improve much, as I’m sure you’ve noticed. Seems to me that the current nonsense in our craft is very similar to the old nonsense. Maybe some of the buzzwords have changed, but not much else.

The landscape of testing has definitely changed. Agile and Lean have aggressively colonized a lot of the testing space. Since most testers are young people (and test management has been eviscerated) they are easy pickings for the Agile Universalists (the people who think that we don’t need testers because we can just all test whenever we feel like it).

What this means is that testing remains rather primitive wherever I go (with a few interesting exceptions, driven inevitably by a single enlightened Elrond-like or Galadriel-like manager, who always seems to disappear off into the Grey Havens within a couple of years of me meeting him or her).

How I become aware of new and interesting ideas is through my community. For instance, a student told me about Karnaugh maps the other day and now I am trying to find a use for them.

Hexawise: How would you suggest testers stay current?

James: I don’t think currency is a thing in testing, except with respect to learning about certain emerging technologies and buzzwords.

The bigger thing in testing is to push us forward, which not enough testers are trying to do. Don’t worry about currency, worry about whether you truly understand testing, and keep working on that study.

Read widely about science. Get ideas from that. And play with the ideas. For instance, I read on Hacker News about 350,000 free images being released by the Metropolitan Museum of Art. I decided to experiment with turning that into a practical resource for test data. This led to playing with data wrangling and image analysis tools.

Also, attend a conference. Don’t bother to go to the talks, though. Most of the talks are full of fluff. Instead, find people and talk to them. Compare notes, make friends. Go to the testing lab. Or host a little conference. Invite testers to a small gathering where you can share experience reports.

Hexawise: What software testing-related books would you recommend should be on a tester’s bookshelf?



James Bach has authored two books and consulted and presented on software testing worldwide. It is difficult to put into words how unique and insightful James is. In order to get a feel, we suggest listening to his presentations yourself and reading his excellent blog.

Some Career Highlights


By: John Hunter and Justin Hunter on Mar 2, 2017

Categories: Interesting People , Software Testing, Testing Strategies, Interview, Testing Smarter with...

We have mentioned George Box before. He was an amazing person, scientist and statistician. One of the traditions George started in Madison, Wisconsin was the Monday Night Beer Sessions.

An excerpt of Mac Berthouex’s introduction to An Accidental Statistician: The Life and Memories of George E. P. Box:

I met George Box in 1968 at the long-running hit show that he called “The Monday Night Beer Session,” an informal discussion group that met in the basement of his house. I was taking Bill Hunter’s course in nonlinear model building. Bill suggested that I should go and talk about some research we were doing. The idea of discussing a modeling problem with the renowned Professor Box was unsettling. Bill said it would be good because George liked engineers.

Bill and several of the Monday Nighters were chemical engineers, and George’s early partnership with Olaf Hougen, then Chair of Chemical Engineering at Wisconsin, was a creative force in the early days of the newly formed Statistics Department. I tightened my belt and dropped in one night, sitting in the back and wondering whether I dared take a beer (Fauerbach brand, an appropriate choice for doing statistics because no two cases were alike).

I attended a great many sessions over almost 30 years, during which hundreds of Monday Nighters got to watch George execute an exquisite interplay of questions, quick tutorials, practical suggestions, and encouragement for anyone who had a problem and wanted to use statistics. No problem was too small, and no problem was too difficult. The output from George was always helpful and friendly advice, never discouragement. Week after week we observed the cycle of discovery and iterative experimentation.

Justin, at a meet up with a few testers in Nottingham, out of a desire to do something nice for some testers in the community found himself buying beers for a few testers. The organizer asked Justin to put a couple slides together, then he posted them on Twitter and thanked us.


Justin made a similar offer to attendees at StarEast. And as luck would have it, the first guy to respond was Alan Page who was giving the keynote speech at the conference. Alan sent out tweets with showing testers getting and sharing a few beers.


And CAST2014 didn't miss a beat.

Hexawise buys the beers cast 2014 twitter

Hexawise buys the beers cast 2014 twitter conversation

Now #HexawiseBuysTheBeers has become a way to encourage comradery among software testers at conferences and another small way the legacy of George Box lives on.

By: John Hunter and Justin Hunter on Sep 1, 2014

Categories: Hexawise, Interesting People

A friend passed me this set of recent tweets from Wil Shipley, a Mac developer with 11,743 followers on Twitter as of today. Wil recently encountered the familiar problem of what to do when you've got more software tests to run than you can realistically execute.



I love that. Who can't relate?

Now if only there were a good, quick way to reduce the number of tests from over a billion to a smaller, much more manageable set of tests that were "Altoid-like" in their curious strength. :) I rarely use this blog for shameless plugs of our test case generating tool, but I can't help myself here. The opening is just too inviting. So here goes:



There's an app for that... See for Hexawise, a "pairwise software test case generating tool on steroids." It eats problems like the one you encountered for breakfast. Hexawise winnows bazillions of possible test cases down in the blink of an eye to small, manageable sets of test cases that are carefully constructed to maximize coverage in the smallest amount of tests, with flexibility to adjust the solutions based upon the execution time you have available. In addition to generating pairwise testing solutions, Hexawise also generates more thorough applied statistics-based "combinatorial software testing" solutions that include tests for, say, all possible 6-way combinations of test inputs.

Where your Mac cops an attitude and tells you "Bitch, I ain't even allocating 1 billion integers to hold your results" and showers you with taunting derisive sneers, head-waggling and snaps all carefully choreographed to let you know where you stand, Hexawise, in contrast, would helpfully tell you: "Only 1 billion total possibilities to select tests from? Pfft! Child's play. Want to start testing the 100 or so most powerful tests? Want to execute an extremely thorough set of 10,000 tests? Want to select a thoroughness setting in the middle? Your wish is my command, sir. You tell me approximately how many tests you want to run and the test inputs you want to include, and I'll calculate the most powerful set of tests you can execute (based on proven applied statistics-based Design of Experiments methods) before you can say "I'm Wil Shipley and I like my TED Conference swag."

More info at:
free trials at:

By: Justin Hunter on Jun 23, 2010

Categories: Combinatorial Software Testing, Combinatorial Testing, Interesting People , Pairwise Software Testing, Pairwise Testing, Recommended Tool, Software Testing