Wednesday, October 17, 2018

Testing Tour Stop #23: Pair Automating with Marianne

When Marianne Duijst scheduled a pair testing session with me, I was super excited. The last time we met each other in real life was at CAST, and it was a real pleasure. Just as this testing tour stop!

Preparation Phase

Both Marianne and I love to explore, however, for our learning session we chose to practice automation together so we both can improve in this area. We wanted to have a basic setup to start from so we both looked for projects that suited our needs. We considered especially the following options.
Before our session, I had a closer look on each of those options. I got all running and checked whether I could extend them without too much hassle in an easy way. Getting back to Marianne with my results, we decided to give the BDD Trader application a try, as testing against an API was something that appealed to both of us. Marianne found that all the courses and workshops usually work on UI level, not on API. As she is coming from data warehouse testing she felt this would be fun and educational to do.

Combining Technical Skills and Domain Knowledge for the Win

At the beginning of our session I introduced Marianne to what I already knew about the BDD Trader application. Our starting point was the project's readme which included explanations about the application domain. In a nutshell, the product allowed users to buy and sell shares using real market data.

As we had agreed in advance, we paired the strong-style way, using my usual suspect of a mob timer. We started the application and verified it was running. We decided to follow the provided exercises, allowing us to get to know the application and already existing tests.

The first part of our session was mainly taking instructions, copying and pasting code. This task was not challenging, however, it gave us time to familiarize ourselves with a few things.
  • We got an overview of the application and a first set of its capabilities.
  • We gained a shared understanding of the diverse knowledge and experience we bring in to the pair as persons. I could introduce Marianne to some technical and tooling topics like IntelliJ as IDE or Cucumber. Marianne, on the other hand, had worked in the financial sector for banks and could introduce me to the domain of trading stocks I knew so little about.
  • We found how to setup our working environment to level our playing field. Marianne shared that she was color-blind, so the IDE coloring problems like missing class imports in red font was not helpful. Therefore we adjusted IntelliJ's colors for red-green color vision deficiency which at least improved the situation. It's easy to forget we don't all share the same access to technology while it's super important to make it as easy as possible for all of us.
  • We learned how the scenarios had been put together, how to make them pass and how to make them fail as well, which was just as crucial as getting them running.
While following the exercises, we found two issues with the provided documentation.
  1. One code snippet contained numbers like "(1)" that were used as references to explain what was happening at each step further on in the documentation. However, these should have been commented out to allow easier copying and pasting.
  2. Two other code snippets included a method expecting a parameter of type Long, but when the method was called an Integer was passed.
Both issues easy to fix, however, they made us realize we had fallen into the copy and paste trap. We had not given one thought whether we should automate the provided scenarios at all, where the risks of the product really were, and so on; things that you would normally start with. While noting this, we accepted it for the sake of our learning purpose for this session.

When we tackled the task of implementing variations on our current scenarios, it got really interesting on a completely different level. Now our thinking skills were in high demand. By adding our own scenarios and adapting their parameters we explored not only how the tests were implemented, but also how the product behaved. For example, we found that we were not allowed to spend more than we had in our account; and kept in mind that we would add a test for this.

One scenario caused us quite some headaches. We wanted to verify the product behavior when a registered user made losses on multiple shares. At first we questioned what was really meant by profit here. We tried different parameter values, and the test failed. We noticed we had forgotten to adapt further parameters and changed those as well. However, the scenario kept failing. We commented out all other scenarios of the feature just to be sure there was no dependency. This way our focus fell on the background for all scenarios, providing us details about the test data setup we had missed before. We struggled with identifying the correct data in the data table we used, so we provided the expected values from the error message output, without understanding why - and the test passed. Only then we finally saw which pieces of the jigsaw puzzle we had missed and realized why they were - of course - needed!

Ending Happy

We decided to stop here in a green state and reflect. I felt this whole setup mimicked the case that you join a new team and look at an already existing product with already existing test automation. We were trying to figure out what we saw. We were sharing knowledge about the tooling used. We were aiming to get on common ground regarding the domain knowledge required. And in the end we knew why! Alone we would have sat a lot longer, asking ourselves this question again and again, from different angles. Combining our knowledge was the key here.

Marianne shared it was great to experiment in this way. She felt she was still at a position where coping with all new things at once would have been too overwhelming for her: the IDE, the provided code, the libraries, etc. But she really liked thinking about the logical problem. We made a perfect match here, as from time to time I felt so dumb, having a hard time understanding financial domain topics although I felt I should easily grasp those concepts. Marianne caught me here before I got too frustrated with my own lacking. Where Marianne was happy to get navigated through technical details and tools and having someone else generating ideas from this perspective, I was super happy to have someone being able to make informed assumptions about the domain and the related product behavior that we could verify.

Sometimes people having expertise in certain areas, be it technical or domain oriented or anything else, are tempted to rush ahead and inevitably lose pairing partners that "don't get it"(yet). This is where strong-style pairing can make such a difference. Using this approach we have to express our thoughts and ideas, we navigate each other through parts we don't know yet, and we have to explain concepts otherwise the other one would not be able to navigate next. Doing it together, we both got farther than we would have on our own and learned from each other at the same time. To say it with Marianne's words: "This was so cool."

We ended happy, and I'm even happier to meet Marianne again in person at Agile Testing Days in just a few weeks. Her awesome "Sketchnoting Adventures" workshop is definitely on my list of favorites, and I heard there's still a chance to get yourself one step out of your own comfort zone and give an agile unicorn talk!

No comments:

Post a Comment