Exploratory Testing is not the antithesis of structured testing

I am getting tired of fellow software testers telling, stating, writing that exploratory testers do not like structured testing, or that exploratory testing is the opposite of structured testing, or that exploratory testing can only be done based on experience or domain knowledge, and on and on….

Exploratory testing is, like ‘traditional testing’, not also based on risk analysis, requirements, quality attributes and test design techniques. It does not ignore or oppose these approaches. Exploratory testing just also reaches beyond that and is also based on modeling, using oracles, using heuristics, time management, providing stakeholder relevant information, and much more.

Exploratory testing doesn’t spent unnecessary time on writing specific stepwise test cases in advance. It rather works with test ideas which it critically investigates while keeping an open mind on what is observed during execution. Exploratory testing then uses the information to create new and additional test ideas, change direction or raise bugs. But it always aims to use the results to provide relevant information to stakeholders that enables them to take decisions or meet their targets. And that can be a verbal account or a brief note but is more likely to be stakeholder specific test execution accounts, showing test results related to achieving the stakeholders acceptance criteria, (business) goals and mission It accounts how much is done, could not be done and how much still should/needs to be done both in terms of progress and coverage.

Exploratory testing is no free pass to click around in the software. Exploratory testing is both highly structured and flexible and it is flexible enough to change along the way so it can provide the most value information possible to the stakeholders.

So…

Exploratory Testing is not the antithesis of structured testing

To do exploratory testing well you have to work structured, disciplined and flexible at the same time. That’s what makes exploratory testing hard to do but lots of fun at the same time.

You don’t just have to take my word for it. Many have written about it before, see some examples below, but the best way to get convinced is to learn and experience it. So I challenge you to go out and do it seriously and with engagement. If you don’t know how many colleagues or myself are more than happy to show you.

Further reading

http://www.satisfice.com/articles/what_is_et.shtml
http://www.kaner.com/pdfs/QAIExploring.pdf
http://university.utest.com/exploratory-testing-the-basics/
http://www.developsense.com/blog/category/exploratory-testing/?submit=Search
http://www.slideshare.net/codecentric/exploratory-testing-inagileoverviewmeettheexpertselisabethhendrickson
http://lets-test.com/?p=2335

Best book:
https://pragprog.com/book/ehxta/explore-it

And just to prevent wrong ideas.
Test ideas can, depending on context, be more or less detailed and almost look like scripts even while their execution is not.
Also testers that prefer exploratory testing can use checklists or scripts if that better serves the need for information for the stakeholders. Although I think information transfer is better served by putting relevant detail in the reports and not in the test cases.

 

Why is software development (not) like building a house?

While this blog mostly addresses software testing that is not the only thing I do.
I am also Scrum Master and provide agile coaching. This post is about a topic I have run across particularly in agile environments but is also used in discussions about other development practices.

Why isn’t software development like building a house!?

Building a house starts at the foundation not at the roof!

Houses, bridges and building in general is predictable, why isn’t software building?!

These remarks and similar ones express the discontent some have with software development in general and agile software development in particular. A discontent that I believe arises as a side effect of two agile development basic elements: “transparency” and “prioritization”. Transparency has the effect that a lot of things that usually take place behind the scenes or that are handled implicitly become visible to a wider audience. Prioritization in agile regularly breaks with the seeming simplicity and logical sequentially of traditional software development as it focusses on delivering valuable but partial solutions first rather than complete solutions later. And it does so visibly.

The simplicity of building…

So is building a house really that simple?
Populistic concepts edict that building follows these, or similar, steps:

  • Pouring a foundation
  • Erecting the walls
  • Flooring
  • Adding a roof
  • Closing up with windows and doorsBuilding-Construction

Occasionally an architect, electricity and plumbing is added but not much more. In any case building is considered fairly simple and straightforward and essentially the question is raised why software development isn’t?

The answer to that question is actually simple.
If software development were only compiling the final build and deploying that to production it would be as simple. But software development is not only creating a build an deploying it and neither is building a house if you look further.

A more realistic view on building a house

Building a house doesn’t start with pouring a foundation, it doesn’t even start with the blueprint the architect makes. It started earlier with the design and production of all the materials the architect and the builder chose for construction of the house. Concrete, bricks, wooden beams, pipes, cables, lighting, etc. did not appear out of thin air and ready for use. All of these materials have undergone their own designing, prototyping, testing, and fabrication process before they could be picked by an architect and used by a builder on site. Let’s take a closer look at bricks to illustrate this.

In the Netherlands and Belgium alone there are over 45 different sizes of bricks, there are many mixtures of ingredients (clay, sand, minerals, water,etc.), colors, and textures. While some of the differences are merely decorative many of them are functional. And that is just the brick itself. Consider also all the possible ways of stacking them and all the kinds of cement that can be used to keep them together that took years and years of practical (live) tests.Wall_bonds

So before any first brick is laid not only the architect and builder have chosen which brick to use and how to use it. The manufacturer of the brick has also implemented design specifications, chose a mixture of ingredients, chose a way to manufacture it and had it tested for durability, fire proofing, insulation and structural integrity.

This is so for for most if not all materials used in building. Some of them may be more or less generic but all of them eventually have a specific usage in building a specific house.

Comparing building a house to software development

So how does building house then compare to software development. Well building a house basically can be seen as the sum of all individual material developments integrated into constructing a house. When looking at it in that way it is not very unlike software development of an application. In software development the individual components of the application are developed and eventually integrated into a full application.

Yet in practice building a house is not conceived as similar to software development. And that is not surprising. While in software development components are often developed as part of the same project in which the application is delivered. While in building the individual materials are most likely developed and manufactured separated both in place and time from the actual construction of the building.

Another similarity between building a house and developing software is that, contrary to the simplistic view, both are hardly ever right first time. In fact errors are so common in building that professions and consumer societies exist that are largely based on its shortcomings. Like software development, where there are software testers, auditors etc., building also has its inspectors, overseers etc..

A difference between software development and building a house is the visible duration. While building (and deploying) software can take a few minutes to up to a few days. Building a house takes a few days up to several weeks. On the other of side of the medal preparation of building a house is largely unseen. Which is quite the opposite to developing software. Getting up to a deployable build can last a few days to several months and sometimes up to several years.

Conclusion

I think the continued use of technical references and terminology in software testing spurs the comparison between software development and building. It seems to me that the remarks with which the post started find their basis in a incomplete vision. A vision that is based on contextual experiences. Working in an IT environment lets you see what a struggle software development is. And when your vision of house building comes from an owners perspective you are likely only to take the final construction as reference with all its supposed simplicity.

Even when the development processes leading up to construction is taken into account there still are significant differences in time, space and execution that outweigh the similarities.