Maybe they should have thought about that.

Recently I was working in the USA with some of our teams, during this time I unfortunately ended up having to visit a medical centre due to getting a chest infection.  This article is my experience of this visit from a testing perspective.

Some background context, I am a resident of the United Kingdom; my permanent address is in the UK format of:

Line 1 – the addressee's name
Line 2 – building number and street name
Line 3 – locality name, if required
Line 4 – POST TOWN, please print in capitals
Line 5 – POSTCODE, please print in capitals, in full and on a separate line

Courtesy of http://www.royalmail.com/personal/help-and-support/How-do-I-address-my-mail-correctly

I arrived at the medical centre, approached the receptionist and explained my need to see a doctor.  The receptionist asked if I had visited the medical centre before.  I replied that this was my first visit and the receptionist stated that I would need to fill out some registration details.  They handed me an Ipad which has some medical registration software installed.  I sat down and proceeded to enter the details the software was asking.  Standard information was asked for such as name, DOB (in the American format of mm/dd/yy), previous conditions.  After about ten minutes of filling in personal information the system then asked for my home address, with each line being a separate screen.  I entered the details for my home address in the UK, including country and then I came across a problem.  (Surprise surprise) It asked me to enter a ZIPCODE.  I proceeded to enter my POSTCODE and the system reported this was not a valid ZIPCODE and would not let me proceed.  There was no option to bypass this and the system did not seem to be able to deal with international visitors. So after wasting fifteen minutes entering my details on a system the receptionist gave me a pen and a printed form.  This form did not have anything for stating if you were an international visitor; it still only had an option for a ZIPCODE. I completed the form and handed it back.

I eventually saw a doctor, got the required medicine and went to pay for the treatment.  This is where the fun started!  I needed an invoice to be able to claim back the costs via my medical insurance.  The receptionist could not enter my details on to the billing system without a valid US ZIPCODE!  After an hour of attempting many ways to get around this I gave them my office address and was able to get a copy of the invoice.  So in total what should be have been an hour visit to the medical center ended up being a three hour visit.

We are living in a global world where it is more and more common for people to be working away from their normal residency it would make sense for software to be able to deal with international visitors.  Maybe whoever tested this system should have thought about this and tested that people from outside the USA can register on the system. 

So the next time you are testing a system in which address details are being requested maybe think about what are the chances that someone who is not from that country, in which the system is being used, may need to register.  If there is a possibility that this could happen then test for that possibility.  

Using Exploratory Testing to Drive Automation

Traditionally automation and exploratory testing have been seen as independent tasks that work in different ways and normally do not appear to be ideal partners. This article suggests that there is value in utilizing the work done when automating to add some exploratory testing effort.

In most cases there is some form of documentation or communication which indicates what the system being designed will do. This can be in the form of requirements, design specification, email, design meetings and so forth. An assumption has been made here that testers are involved in the design phase, if they are not for your project then they should be.

Within the context in which I work these documents/communications are analyzed for automated cucumber scenarios and exploratory charters. For the automation scenarios these are created using the Gherkin format:

Feature: Password management
Scenario: Forgot password
Given a user with email "someuser@example.com" exists
When I ask for a password reset
Then an email with a password reset link should be sent

Exploratory charters are created in the Exploratory Charter format as described by Elisabeth Hendrickson in the book Explore It!:

Explore (target)
With (resources)
To discover (information)

Where:

·                  Target: Where are you exploring

·                  Resources: What resources will you bring with you

·                  Information: What kind of information are you hoping to find?

Once the exploratory testing charters and cucumber scenarios have been initially defined the Test Engineer manually steps through the cucumber scenario to determine the pre-requite components needed to complete the scenario from an automation perspective, at the same time adding details to the Gherkin feature file. This may involve building the environment and integrating the components. It is at this point that some level of exploratory testing can be performed to gain more value from this manual effort. This manual effort can be recorded on a wiki or some other similar tool. The suggestion for using a wiki is the ease of access and use for cross regional teams. It is not mandated for teams to us a wiki but from experience it appears to be the best way to share information.

This will require a mindset shift for the test engineer instead of only focusing on the automation scenario they should be looking for future opportunities to test either automated or manually and these should be fed back to the team and added as backlog items. One other benefit is that as you explore the automation scenario you may uncover issues or defects earlier which are always a good benefit for the project.

Once the step definitions have been coded and implemented for the automation scenario they should feed into whatever automation reporting system you have selected. This should report scenarios pass or fail. It is expected that defects should not be found at this stage and if scenarios fails it is indication that your expectations of what the system does has changed and should be investigated before any possible defects are raised. This is a simple approach to close the link between test automation and exploratory testing and leverage the skills of the test engineers to their full value.

It should be noted that there will still need to be more effort to ensure that the exploratory charters are run manually and recording using the current approaches for your projects.  This then become a continuous cycle as more scenarios are discovered for automation then more exploratory testing can be done and more information about the system can be uncovered.  This approach makes exploratory testing and automation partners rather than as independent entities.  It hopefully reduces the checking vs testing debate and focuses on utilizing the skills of testers to deliver a product that customers will enjoy using.

The diagram below is a simple visually representation of this concept.