Testers, Please Speak to the Developers!

This blog post is based on a 99 second talk I gave on 17th July 2019 at the Birmingham #MidsTest meetup.

Developers and testers working together – www.publicdomainpictures.net

Once, a change had to be made to the software. This particular change was something that could not be controlled via the user interface. It was also not possible to observe the change via the user interface.

When we think about the testability, if something cannot be observed or controlled via the User Interface, this would mean that this change was untestable – right?

There are other ways.

Don’t rely on the User Interface

Sometimes a change might be made to the application that isn’t user facing. It might be something that the user should not change or view for safety or confidentiality reasons.

From a usability and user experience point of view, being able to see and interact with the user interface is essential. However, there is much more happening beneath the surface that the user never sees. There is likely to come a time where this needs to be tested.

Understanding Requirements

Contrary to popular belief, developers and testers should not be enemies. They can help each other. A Whole Team Testing approach is being discussed throughout the testing community. Testers can help developers and developers can help testers.

When there is a new work item or change request, encouraging testers and developers to discuss the requirements early on can avoid any misunderstandings later on. A failed test because either the developer or tester did not understand the requirements wastes time.

Making an application testable, making a defect fixable

Communication can also be used so both tester and developer fully understands what is required to complete a work item. A work item should not be complete until it has passed testing by a tester.

If something is not easily testable, then the developer needs to make it testable. To do this, the developer needs to know what the tester needs.

If a defect is found while testing, then the tester needs to provide enough information for the developer to fix the defect. To do this, the tester needs to know what information the developer needs.

Introducing extra logging

When told a change had to be made to the application that could not be controlled or observed via the user interface, I started out by talking with the developer.

We discussed the requirements to make sure we both understood the change and why it was needed.

We then discussed what we needed to fully implement this change. We decided that adding some additional logging would help with testing. We discussed what and when information was required.

Extra logging helps both the developer and the tester. Both can benefit for the information it provides. The tester benefits by having a better understanding of what is happening beneath the user interface. The developer can also use this information to help fix any defects found.

Mutual Understanding

By speaking to the developer before the change was implemented, we were able to reach a mutual understanding. We both agreed on the requirements and what was needed to make the the change testable.

Agreeing on requirements early on can reduce delays later on. Making sure that something is testable improves the quality of the application. Working together improves the efficiency of the entire development process.

Advertisements

Automating BDD Scenarios using SpecFlow (London Tester Gathering Workshop 2019)

On 26th June 2019, I attended the London Tester Gathering workshops. The workshop I’d chosen, Automate Scenarios with SpecFlow. I chose this workshop because I’m hoping to start using SpecFlow on my current test automation project.

The workshop was run by Gáspár Nagy, the creator of SpecFlow, self-proclaimed BDD addict and editor of the BDD monthly newsletter (I’ve already subscribed).

My current project

Testing pyramid. UI testing is only the tip, more testing levels exist. https://martinfowler.com/bliki/TestPyramid.html

I’m not new to test automation. I’ve already developed a series of automated end-to-end UI tests using Ranorex. These tests are designed to provide broad test coverage of the main features in the application. The steps are designed to mimic the process that a typical user is likely to follow. Running these tests allow us to find out if the most commonly used features in the application work as expected.

We also run a series of manual tests that cover individual features more deeply. Ranorex is great for end-to-end testing, but automating more in-depth test cases was inefficient and brought little value to the project. I believe that these tests would be better suited to behaviour driven development, which in turn can be automated using SpecFlow.

By attending the workshop, my main aim was to learn how to use SpecFlow. In addition to this, I hoped to understand how it can be used to improve my current testing strategy. I didn’t want to just include automated end-to-end UI tests. I wanted to dig a little deeper into the test pyramid and cover other testing levels with test automation.

What is BDD?

In order to use SpecFlow, you need to understand what BDD. Therefore it the workshop started with a discussion around what BDD is.

The scenarios are written and agreed on before the development takes place

BDD stands for behaviour driven development. It encourages collaboration between the testers, developers and other stakeholders. All requirements should be fully understood and agreed on before any development takes place. Allowing for an earlier feedback loop, where any questions or confusion is cleared up before the scenarios are formalised. This ensures that all parties fully understand what work needs to be done.

The advantage of BDD is that its tests are designed to show how the expected behaviour aligns with the product. The development of a feature is designed to focus on the user expectations.

The scenarios are written in a common language that allow anyone in the team to write tests, making it easier to document and verify the tests. It also ensures that there is a shared understanding of the requirements across the entire team, not just those who understand code.

How is BDD used in SpecFlow?

SpecFlow uses Gherkin language in its scenarios which are designed to show the features expected behaviour. Gherkin breaks down the scenario into Given, When,Then steps. This language ensures that the scenarios can be understood by anyone.

The format used in SpecFlow will look something like this:

Example of a scenario in SpecFlow. Taken from one of the exercises used in the workshop.

Then, for each statement in the scenario, some code is written that will run the steps required for that statement.

Automation

After covering the basics of BDD and scenarios, we then went through a series of exercises designed to encourage us to use SpecFlow and understand how it works. Each exercise had its own visual studio solution, containing all the resources needed to complete the exercise. The application being tested, a pizza website called GeekPizza.

We first created a basic test that checked the number of pizzas displayed on the menu. There was an additional bonus exercise to try out at home. We were also encouraged to think about how we would test that the automation worked correctly.

The second exercise looked at introducing a data table containing a list of items which need to be checked while the test is being run. The third exercise was designed to show how to split up files and step definition classes.

The next set of exercises showed us how to use SpecFlow for web automation. We only had time to work on the first exercise, but we have enough information to help us with the remaining exercises.

Final thought…

This workshop provided an excellent introduction to Behaviour Driven Development, which is essential for SpecFlow. All the exercises, even the ones we’d already done, included bonus tasks so there is plenty to work on at home. The workshop provided everything we needed to really practice and understand SpecFlow.

Gáspár is definitely the person to go to if you need help with writing BDD scenarios or automating them using SpecFlow. I strongly recommend going to one of his talks, workshops or courses if you need to learn more.

Main image taken from http://www.publicdomainpictures.net

Collaborate Bristol Part 4 – Talks by Catalina Butnaru and Eriol Fox

What stands in the way of Ethical AI?
Catalina Butnaru

Who do we design for? It is probably not who you think (or want). We want to design for the end-user, but we are often promoting the views of the business stakeholders. If they don’t approve of something, then it can’t be delivered.

There are several false beliefs with AI:

• AI created super human intelligence
• AI can be ethical

These are both false and any attempts to achieve this will product ethical zombies – something that cannot think for itself.

Designers need to account for the ethical design of AI applications. To achieve this, several ethical principles need to be established:

• Privacy
  The ability to be switched off at the request of the user
• Well being
  Deploying the application doesn’t harm a human (physically or mentally)
• Accountability
  The user is able to report on unfair outcomes
• Transparency
  It must be clear to the user that the application uses AI. It must also be clear how the AI makes its decisions
• Awareness of Misuse
  It should be clear that the system can be misused, how it can be misused and the user should be able to report this when it has happened

Only when these principles have been implemented can a MEP be achieved – Minimum Ethical Product.

Diverse representations in design and awkward conversations with colleagues
Eriol Fox

There is no such thing as a completed neutral tool. Everyone is guilty of unconscious bias which can have an effect on the design of products. Lack of representation of certain demographics can also lead to misunderstandings. To avoid this, we need to start having these awkward conversations so that there is a more accurate representation. Reach out to users, include them so that there is a better understanding of what they want and need.

Stock photos that don’t represent real people, forms that only allow official names or male/female genders, proving the option for doctor male and doctor female instead of just doctor (why?). The list goes on.

These have become known as edge cases, or people we don’t care about or don’t represent the main users. They are excuses we make when we don’t want to discuss certain people. Instead, we should use the term ‘stress cases’ – cases that need more attention.

Applications should be make for anyone to use, not just those who we see as ‘normal’.

Several books were recommended. I’m currently reading ‘Technically Wrong’. A lot of the examples used in the talk are mentioned in this book, I strongly recommend reading it. I’ve already ordered ‘The Politics of Design’ on Amazon.

Final Thoughts…

Positive user experience and collaboration are essential when software testing. With all the software testing events that I take part in, it is good to step back and think things through a little differently. Collaborate Bristol 2019 gave me an opportunity to do just that. I now have new avenues of research to explore, which will help expand my knowledge and experience in software testing.

Thankyou Simon Norris and the other organisers at Collaborate Bristol for an enjoyable and informative day.

Collaborate Bristol Part 3 – Talks by Gavin Strange and Hilary Brownlie

Don’t make it perfect, make it now
Gavin Strange

Never before have I seen such an energetic talk as the one that was given by Gavin Strange.

It was full of messages that centred around the idea of being creative and trying out new ideas. Generate new ideas, develop them, try them out, experiment. It doesn’t matter how you do it. Some prefer to take a more targeted approach with an end-goal in mind. Others like to take a more exploratory approach. Doesn’t matter which, try out these ideas.

Seek creative satisfaction wherever you can get it. How do you find time? Use a time circle to map out the amount of time you have in the day. There are 24 hours in total, how much of this time do you spend on eating, sleeping and working. How much time do you have left over? How do you spend this time? Allocate some time for side-projects. Your career can flourish from these side projects, and from sharing them.

The most important thing is that you share your ideas and creations. Even if they don’t work out, even if its ugly, the very fact it exists make it important. It should be shared with the world.

“If we don’t tell our stories no one else will” – Mira Nair

Flying the plane while changing the engine
Hilary Brownlie

Who are we designing products for? The customer of course. What happens when we start designing ‘with’ the customer instead of ‘for’ the customer? A drastic culture change that encourages collaboration and benefits both the user and the organisation.

In this talk, Hilary Brownlie walks us through how this culture change occurred. Instead of starting with a brief, the question ‘what could we improve?’ was asked. This led to the Scottish Approach to Service Design (SAtSD), an approach where services are designed with the customers, rather than for the customers. The ideas that developed from this approach led to the company culture changing that had more empathy and encouraged designers to listen to the users. Overall, there was a much stronger focus on the user.

Collaborate Bristol Part 2 – Talks by Jon Fisher and Georgia Rakusen

Falling between the cracks
Jon Fisher

Could a product have the capability of killing someone?

Three real life examples were given:

1. Chernobyl
   A mixture of poor design and human behaviour led to the core in one of the nuclear reactors exploding. This was caused by an optimising violation where someone attempts to break the rules with the intent of achieving someone good. In this example, the engineers wanted the safety test to pass so they broke crucial safety rules to do so. In total 31 people died (if you believe the official statistics).
2. Railway Safety
   Unfortunately, I did not write enough down to fully remember or understand this particular scenario but it involved someone working at a computer where they had to perform repetitive tasks. A chain of events led to the person at the computer making a mistake due to the repetitiveness of his work. The railway line became fully electrified while an engineer was doing maintenance work. Fortunately, no one died. Unfortunately, the engineer had to have both his hands amputated.
3. Ethiopian Airlines Flight 302
   The cause of this plane crash is still under investigation, however it is generally believed to have been caused by a sensor recording the wrong flight angle. The computer decided to dip the plan to correct this angle. The pilot noticed this and attempted to stop the plane from dipping. The pilot and the computer were fighting each other – the computer won the fight and 157 people died.

The Swiss cheese model was mentioned as a way to show that there will always be several holes in the design. Accidents can happen when those holes are perfectly aligned.

When designing a product, the desired outcome is to deliver value to the customer. Is there an obsession with value? Are we even aware of the potential risks and pains involved when delivering that value?

The human will try and do things the tech team believed they shouldn’t and won’t do. Humans are unpredictable – they they probably do the unexpected. No matter how many levels of defence, there will always exist that perfect chain of events that can result in catastrophe.

I have one observation with the examples mentioned above. We have 2 situations where a human was trying to fight the system. In one case, the human won resulting in Chernobyl. In another, the system won resulting in the Ethiopia plane crash. Do we design to allow a human to take over when required when the computer has gotten it wrong? Or, do we design to prevent a human taking over so they don’t do something stupid?

Web 3.0: How blockchain will change the way we interact with one another
Georgia Rakusen

Thew world is full centralised systems who control everything we do. What is the problem with centralisation? Everything is controlled by a central organisation who have all the power. All information is controlled by the central power, which can create questionable integrity.

Centralized vs decentralized vs distributed processing

Blockchains allow information to be stored across a network of computers. Because the information is not stored at a central location, it is not owned by a single person or company. Multiple people are encouraged to cooperate to verify the information and transactions are valid. Since the information is stored and checked by multiple sources, the overall system has better integrity.

A few examples were given where such a system has been beneficial.

CIvil – The journalism industry is reliant on ad revenue which influences content. As a result, we have no idea what information is correct or not. A decentralised system of co-ownership and participation can help build a more integral industry. Members have to follow a code of conduct and can be voted out if that code is broken.

Openlaw – Normally, legal contracts are controlled by a lawyer. This can make any legal process slow and cumbersome. Instead, legal agreements are created and signed on a block chain. Without any central lawyer, it is easier to raise disputes. Ultimately, all parties involved have to agree.

UPort – an open identity system where personal information can be easily transferred to new platforms. The user has better control over what information they want to share, and what information they want to hide.

I found this great video explains what blockchain is better than I do.

I hope you enjoy reading my summaries. I find its a great way to review my notes and record my own interpretation of the talk. Next post will be about the talks by Gavin Strange and Hilary Brownlie.

Collaborate Bristol Part 1 – Talks by Onkardeep Singh MBE and Juliana Martinhago

On Friday 21st July 2019, I attended Collaborate Bristol – A UX and design conference. This is the second time I’ve attended this conference and, like last year, I learnt a great deal from it. I am normally so focused on software testing, it is easy to forget the importance of the user experience. I definitely encourage others to research alternative subject areas that may offer a different outlook to your main interests.

I was pleasantly surprised to find myself on the front cover of the program – in a photo taken of the audience last year, you can just see me on the second row.

In total there were 8 talks on varying topics. In this blog post, I am going to start by writing what I learnt from the first 2 talks – by Onkardeep Singh and Juliana Martinhago

Being passionate, not precious, about your work
Onkardeep Singh MBE

Passion – intense desire or enthusiasm for something
Precious – something that is of great value that must not be wasted.

This first talk explored the workings of the mind. As someone who has always struggled to understand the basic concepts of psychology, I fear this talk may have gone a little over my head. However, it was still an interesting talk and I’m going to do my best to provide my own interpretation.

During this talk, Onkardeep asked the audience a couple of questions:

• Thoughts and feelings com before an action – true or false
• Humans are unique because we are in control of our thoughts and actions – true or false

The responses to these questions were mixed. The truth is there is no concrete answer. It is quite common for someone to consciously think before they act, however there often comes a time where that same person might run on autopilot. Sometimes we have control over our actions, but not always – mistakes can happen.

Our actions may be better explained by what is most important to us. If we detach ourselves then our actions aren’t affected as much by our thoughts. When we see something as precious, we see it as being of great value. If we see something as valuable, then we are more likely to have strong thoughts and feelings about it. These thoughts and feelings can affect the way we act. By distancing ourselves from something, not seeing it as precious, we are less likely to have that strong reaction.

We need to be passionate about our work, and have that intense desire for things to go well. But we should avoid being precious about it, so that we don’t react too negatively when things go wrong.

Building great products and successful teams
Juliana Martinhago

Juliana is a product designer at Monzo – a banking app which I’ve never used and knew very little about until this talk.

Monzo was presented being a bank that aims to make banking easier, removing the normal frustration associated with traditional banks. This is achieved by having a strong focus on improving the user experience.

Spotify Model

At Monzo, the teams are made up of ‘squads’ – small teams with a shared goal. They are formed around outcomes instead of features. This seems like a good idea as the feature may fail to achieve the desired outcome. Focusing on a outcome means that alternative ideas can be explored.

I can’t remember if the Spotify model was mentioned or if its used at Monzo, however I do know that this also uses ‘squads’.

They start each stand-up by asking the question: What is the most impactful thing we can do today to achieve X? This allows a backlog of ideas to be developed that could be used to achieve what ever X is (the outcome).

One feature available in Monzo is the ‘labs’. This is used to test new features. The user is able to switch on or off specific features which are still in development. Customers are aware that there the feature is still a working progress, but are given the opportunity to test it out early and provide early feedback.

The entire model used at Monzo is aimed at providing something meaningful for the customer, which provides a banking app with a vastly improved user experience.

I will continue publishing my write ups of the Collaborate Conference talks over the next couple of weeks. Next up will be ‘Falling between the cracks’ by Jon Fisher and ‘Web 3.0’ by Georgia Rakusen.

A Stitch In Time Reduces Critical Bugs

On 19th July 2019, I attended the #MidsTest meetup in Coventry where I gave my second 99 second talk. This time, I brought a prop – a block from a quilt I’m currently making. This blog post is based on the talk I gave.

Tweet about my 99 second talk, including a photo of me giving the talk

One of my hobbies includes sewing. At the moment I’m working on a patchwork quilt which will be a wedding gift for my sister-in-law who is getting married in August.

A patchwork quilt is made up of hundreds of small pieces of fabric, sewn together to create blocks. These are then sewn together to make the completed quilt. The main image for this post is one of several blocks which will be included in the final quilt.

You’re probably wondering where I’m doing with this!

Unit and Integration Testing

Those small pieces of fabric that make up the quilt – rectangles, squares and triangles – have to be unit tested before being used to make the quilt. Any that have not bee cut to the correct shape and size could result in a major bug finding its way to the completed quite.

Once the ‘units’ of fabric have been tested, they are sewn together into smaller blocks. Before sewing the blocks together, they have to be integration tested. Incorrect seam widths or wrong side of the fabric being used are common bugs that can affect the overall design of the quilt.

Saving time by finding defects earlier

These smaller blocks get stitched together to make bigger blocks, which are sewn together to make even bigger blocks. Eventually, all the blocks are sewn together to complete the entire quilt. Each block was integration tested before being used to make a bigger block.

All the testing that takes place early in the quilts development helps reduce the risk of more critical defects being introduced later on. Additionally, bugs found in the smaller blocks are a lot easier to fix than ones found in the bigger ones. The stitches have to be unpicked and the pieces of fabric sewn back together. Defects on smaller blocks are quicker to fix because there are fewer stitches that need unpicking – there are fewer dependencies.

All that testing, why are there still bugs?

Unfortunately, no amount of testing will completely eliminate all bugs. It helps drastically reduce the number of defects that find their way into the final product – but doesn’t eliminate them altogether.

No matter how careful I am, the quilts I make all have minor flaws in them. However, these are minor issues that don’t significantly affect the design. Any major defects that could have affected the quilts design were eliminated early on. If they had been found later, once the quilt was complete, they would be a lot harder to fix.

Why don’t I fix every defect? If I stopped to fix every defect then there is a risk that the quilt won’t get completed in time for my sister-in-laws wedding. In software development, the risks are normally a lot greater than that. Delaying the release costs the business money, sometimes more than if a defect was released to the live environment.

It is not always feasible to fix every single defect – especially if they are minor ones. A little more effort on unit and integration testing can reduce the number of bugs that need to be fixed later.