2016 on Heather Reid's Blog

Dynamic Tables in Automation

Fri, 14 Oct 2016 21:15:28 +0000

This blog was originally posted on Medium.

I’m pretty new to automation. I’m a self taught lone tester who started out in automation basically trying anything. I previously worked as a developer, using Matlab, so code wasn’t new to me. Our team knew that we needed to get automation up and running to help with the regression efforts. I am only one person after all.

It was decided that the automation code would be written in Java as the developers would be able to read it and possibly help me if I ran into difficulty. I tinkered around a bit, understanding page objects and locators but not really getting to where I thought I should be. My company contracted in someone for a few days to help me get a proper automation suite up and running. Everything was looking rosy. Things were popping up on the screen, getting filled in, we had identified some page load problems and I had something to show my boss.

The contractor left and a short time later things were not looking so rosy. I was stuck. I had something that didn’t appear to be scalable. The contractor had assured me that this was the best process for our application but I soon discovered that it wasn’t. Maybe I didn’t explain our product well enough to them, maybe they always write their code like this or had never experienced this before. I keep retrospecting on this and I can’t come up with the answer. All I can say is that this was a fantastic learning curve for me and my team have been very patient as I tried to refactor all of the code.

A bit of a background on our application: it is a clinical trial simulation tool. You can read more about it here. To anyone reading this with a dev/tester background it basically means a LOT of dynamic tables. When I say a lot I mean a table on 90% of the pages for the 17 page objects I have declared so far. A thing of beauty for the user, a thing of horror for the newbie automator.

I felt like I couldn’t go back to the contractor. Let’s be honest, for a small company, the feeling is that they cost a lot and it can be hard to find a “good” one. I asked the developers to explain what the tables were and how they were created. They said our application created dynamic tables using AngularJS. Extensive googling of this didn’t net me any results (I probably used the wrong combination of search words). I asked for help in Ministry of Testing slack channel “Does anyone have any experience automating for dynamic tables?”. Andrew Morton and Richard Bradshaw replied. They had, success!

Andrew sent me code snippets which turned into functions which turned into lengthy discussions about how best to organise my automation. Andrews thinking was if you have something, like tables, that appear frequently in your application they should fall into a utility page object. That is to say that functions to search tables, locate cells of tables, etc. should have their own page object that would have a title “tableUtility” or similar. The table utility functions would then be called from the page objects rather than repeating code over and over in page objects to interact with tables.

Richard sent me a link to a blog post and some code on Github. This started a long slack thread with Richard and, at times, Andrew (mostly about lambda functions because it took me a long time to get the hang of them). I have to thank them both for their patience with me. I would have been lost without them. I think one of my favourite pieces of advice from Richard was: “Think about how you would search a table for information in every day life. You would know that you are looking for a customer so you would find the header for that and search the column for the customer you want. You can search a table in other ways so think about that before you try to understand the code.” At the time I was frustrated because I had this mental block of “I’ve done it all wrong and I’m costing my company money trying to fix it”. You even have the fear of “Will they sack me because this is a pretty big screw up”. I was learning (I still am-you never really stop) and I was too hard on myself, my company knew I was learning too and I could give valid justification for why the refactor needed to happen. With the patience of Andrew and Richard (and a lot of yoga) I managed to get something working. Now, not only do I have it working but I have expanded on the functionality from Richards code and I have it working well in Java.

I learned that my XPaths were actually the problem, not my lambda functions. Always start with the basics or you’ll spend ages searching the complex things and getting increasingly frustrated. You’ll then kick yourself if you discover it was a very simple thing that caused the problem.

So a simpler view of what I’ve been dealing with over the past few months. I’ve added some HTML below with an image of the table that it generates. This is a pretty simplified version of our tables!

Using w3schools with the above, I generated a table like this:

A much simpler version of the tables I’ve encountered!

So what was the problem? Why was our code not scalable? In some cases, the number of columns/rows on one page depended on the user selection on a previous page. Our previous locators looked like this:

I mean there isn’t anything wrong with this. It did work for one user journey through the system. The problem was that it wasn’t scalable because if there were more (or less) user entries on the previous page, then the XPaths changed. I learned this quite quickly. I was going to have to add a new locator and new method to use that locator for each combination I wanted to check. It did work but I thought there had to be an easier way.

This is where the code from Richard came in. To start with, I now just use the ID of the table in the page object and perform cell/row/column locations in the table utility. The below code calls a function in the table utility to find the table headers and return them as a list.

That is one of the easier examples but isn’t it tidy? It’s scalable too. If the number of headers on the table changes I don’t have to update the function or the XPaths. All I would have to update in that case would be the expected results for my automated check.

I have more examples of how to use each of the functions on my own Git repository if you want the java version of Richards code. I have added some code to mine to locate buttons in a cell. Our tables have different sets of actions, not all tables have the same actions buttons, so I’ve had to add some different functions for those. An example:

Note the buttons in the far right cell.

XPaths for those buttons from left to right:

.//*[@id=’someTable']/tbody/tr/td[4]/div/a
.//*[@id=’someTable']/tbody/tr/td[4]/div/button[1]
.//*[@id=’someTable']/tbody/tr/td[4]/div/button[2]
.//*[@id=’someTable']/tbody/tr/td[4]/div/button[3]

To click the buttons you can use the code below in your page object. The headerToSearch would be “Actions”-you are looking in the Actions column for the buttons. The variables knownLabel and knownColumnHeader would be “Label” and “Use2Find” or “Description” and “Another column of known information you can use to find buttons”.

Some closing comments: watch your HTML tags, in particular tbody vs thead. Depending on how the HTML is written will dictate how you declare/handle the variables tableHeaders and tableBody. For example, in our application our header row, first column would have an XPath like this:

.//*[@id=’someTable’]/thead/tr/th[1]

The second row of the table, the one that appears under the header row, would have an XPath like this:

.//*[@id=’someTable’]/tbody/tr[1]/td[1]

I have encountered other tables whose XPath for the header was:

.//*[@id=’someTable’]/tbody/tr/th[1]

I missed this when I first examined the table and spent far too long trying to get to the root of the problem. I spoke to the developers about it and it’s something we’re all aware of going forward, so we will always have the format of the first XPath example.

If in doubt, always go back to basics.

Whose Fault Is It Anyway?

Wed, 20 Jul 2016 20:55:25 +0000

This blog was originally posted on Medium.

The day started like any other sprint close day would, bugs frantically moving across the sprint board and the “Has this not been tested yet?” questions. This happens in every agile environment that I’ve heard of. If it doesn’t happen in yours, congratulations.

I had written or contributed to the bulk of the user stories in the sprint that was due to come next (i.e. The next day). I had asked for feedback on these stories, not much had come back. I was testing the bugs that had a deadline to be signed off by that afternoon when a substantial amount of emails popped up in my inbox (thank you Jira). They were, I felt, criticising the way I had written the user stories, ripping apart the hours and days of work I had put in to them. Normally if we have questions about each other’s stories we pop a Slack message to one another or, you know talk to each other across the desk like humans. This time was different, this time I felt like I had put in the bulk of the work and not got much feedback until this very moment. And why was the feedback coming in emails and added comments on Jira? When did we stop talking to one another in favour of a good paper trail of our criticisms and feedback?

I won’t go in to the whole details of how I eventually snapped but I did and I decided “Well if you can add a paper trail to Jira so can I”. I responded with “Suit yourself. You’re going to regardless so perhaps you would prefer to take up writing all of the user stories in future”. I said that.

I was discussing it on the testersio (Testing Community) Slack channel at the time. This felt like my work was being torn apart, what should I do and was I overreacting. I was honest and told them how I had responded. I got some very good advice from Nicola Sedgwick, Richard Bradshaw and Neill Boyd to name the main contributors.

Richard told me “Be congruent with yourself. Did you behave correctly? Are you happy with the way you responded/acted? The answers to those questions will potentially lead to some actions.” Firstly, no I was not happy with the way I responded or acted. It was out of character for me, it was impulsive and I more than likely hurt the feelings of the person who had created the paper trail. Did I behave correctly? No, absolutely not! I took a deep breath (thank you Neill for the advice on this one) and I thought about what to do next. I really thought about it, no use diving in because look where that got me already.

I apologised to the other team member “Sorry for snapping. Feeling like I’m under a lot of pressure”. I took Nicolas advice on this one “retrospect on yourself” and I thought that if I was the team member who was only getting to review the user stories now, how would I be feeling? I’d probably send me a similar message to the one I had sent them. There was surely a reason that they were only getting to it now. It was time for a long walk on lunch to think about it all.

I started to think “It’s my fault for not writing user stories good enough”, “It’s the devs fault for not dedicating time before now to review the stories”, “It’s the product managers fault for not telling us what they want”. As I got further on my walk I began to wonder why did it have to be someone’s fault? In my limited experience with agile it’s all about traceability, who did the most user stories, who had the most bugs, who wrote the story that had the most bugs. This brought me back to a video I watched during the week by Selena Delesie and my thoughts about that and my current situation.

The problem wasn’t agile. The problem wasn’t one particular person’s fault. Yes, the feedback from both sides could have been better, I could have not responded like I did. The main cause of the whole problem, the fault in the whole thing was our communication. We stopped doing what we normally do when we communicate with each other. Instead there was this focus on a paper trail and the way things should be done. It wasn’t any one person’s fault but once I apologised and explained where my head was at, I learned that the devs were feeling the same way even the product manager was.

When we sat down to do a retrospective on the sprint we were finishing, a lot of things came into the spotlight. So where do we go from here? We go back to the way we were using to communicate before. I take a deep breath before I reply and I reflect on it and myself to know where I could improve for the future. If we had all stopped focusing on whose fault it was anyway maybe we never would have gotten here.

TestBash Is It Just for Testers?

Tue, 10 May 2016 20:56:01 +0000

This blog was originally posted on Medium.

There have been a lot of blog posts about TestBash Brighton 2016. I’ve brought back a lot from the conference that has helped not just me, the sole tester for my company. I’m going to focus primarily on the social aspect of the conference because I think that part could be applied anywhere.

In the run up to TestBash there was a lot of talk about it on Twitter and Slack. I was familiar with Slack, but Twitter seemed to be too out there for me, too much information on the internet, but after much deliberation I made the leap and joined it.. Best.Career.Move.Ever.

This was my first conference so I was nervous. From talking to people in work it was all going to be very formal. I should be arranging meetings and bringing stacks of business cards, not sharing my twitter handle. In the weeks leading up to the conference there was a huge hype on twitter, Slack and meetup.com. People arranging to meet for tea, lunch, dinner, drinks and games. Most importantly everyone was welcome. These weren’t small groups of people arranging meetings among themselves and only for themselves, there were 50+ people attending these events and tweeting for others to do the same. Thank you especially to Rosie Sherry and Dan Billing on this front. Rosie for personally emailing me a reply for help to convince my company to go and Dan for replying to a comment I made on a meetup event. The comment was simple, something along the lines of looking forward to meeting you. I didn’t know these people and already I felt like they were my friends.

On my first day I attended a workshop run by Noah Sussman and Jess Ingrassellino. I happened to sit beside Graham Sherry who gave me a piece of advice that has stuck with me. “Make keeping up with technology and industry changes part of your job”. It will be hard at first but then it will become natural. It was definitely a difficult start because I was clicking on every blog post I saw. With time I learned to filter what I read and it is now a natural habit. Twitter really helped with this.

This workshop was attended by people from various areas of software development. There were testers, developers and managers. It was amazing because it got a really interesting dialog going. This was the start of my thinking “our whole dev team should come to this”.

On the Wednesday night there was a games evening. Thank you John Stevenson for bringing the games and writing a blog post afterwards so I could get them all. Let me start by saying the next morning I ordered two of the games on Amazon to be delivered to the office. We have since played Dixit in the office and it was a huge success. It got us all talking about how differently the whole office thinks. Our office is not just software developers and a tester, we have statisticians and mathematicians too. We aimed to play this at least once a month but it has been pulled out a few times now already. Who would have thought a games evening at a conference could get people talking so much. You have a room full of people who may or may not know each other playing board games. Yes we were mostly testers but this got you knowing each other on a social level which helped the professional discussions to continue more smoothly.

On Thursday I attended Ash Winter’s workshop for System Architecture. I have brought the exercises from this back to the office and everyone is trying to use them. Ash had us explain architecture in everyday terms e.g. a kitchen in a restaurant, how orders get to the kitchen, etc. This brought back memories from my statistics lecturer “You better be able to explain it to me as if I was your gran and I better be able to understand it”. So taking the theory from the workshop, could we apply it to the statistics side of the business? We all know our jobs very well so we should be able to. Yes this workshop was useful for me as a tester, and I wish it had been longer, but the theory from it could be applied to many areas within our company.

The Thursday afternoon workshop with Alexandra Casapu was examining your testing skills. I was initially frustrated at this workshop if I’m honest. Why couldn’t I figure out the pattern in the black box? What were my skills? Do I even have any useful skills? I’m very self-critical so it did take me a while to realise the full benefit of this workshop. That evening I thought “oh, I do that and it’s a skill” Wooo! If you took testing out of the title of this workshop it really could be applied to anywhere in the company. We regularly have to fill in information for contracts our company hopes to get through. They regularly ask what skills are in the company. We regularly scratch our heads. We know we can do the work no problem but to actually describe what skills we use to do the work is always a thinker.

Lean Coffee http://leancoffee.org/ do it. This opened the conference on the Friday and it was excellent. I made friends that I am still talking to today. We have done this in work with amazing results. We did one lean coffee which resulted in us learning what people don’t like to eat, planning an office trip out for lunch and saying events we would love to do as a group from the office. Shortly after this, the board of directors decided there should be a social budget set aside for things like this. We can plan events, buy games for the office, have payday pizza and the remainder can go towards our Christmas party. You really never know what you could achieve with Lean coffee so don’t hold back.

A BIG theme from the whole conference was Pairing. It was mentioned in a lot of talks, it was done in a lot of workshops, pairing was everywhere. We took that idea in our company and went a bit further. We plan to start with inter department pairing. Myself and the Devs will pair up and swap about, the statisticians will pair with each other on projects and swap about. We thought, why stop there though? Any of us could be asked what does our company do or even within the company asking for an ear to sound out some ideas. So we thought let’s add in cross department pairing when we finish the first leg. The Sales and Marketing team are very excited about this. It’s not always easy for us to explain what we do so showing how we do it and getting a different perspective on that will be amazing.

From the conference I have also done Tiny Habits http://tinyhabits.com/. You pick three tiny things you would like to make habits. Tiny is the key word here. You dedicate about 30 seconds each day to the habit for a week. You celebrate when you have achieved your tiny habit, for each habit. By the end of the week each of the habits become natural to you. This is also not just for testers. Three tiny things have helped make me more organised in my everyday life and achieve what Graham advised me on the Tuesday. I’ve also started learning Italian and sign language along with some programming skills. The trick is to celebrate when you achieve what you set out to do even if it is just a small celebration.

Finally, for everyone-you can be awesome. Don’t be afraid to put yourself out there. I am normally a very shy individual, especially confronted with a room full of people I don’t know. Thanks to TestBash (and Kristine, Matt and Vernon) I got up in front of a room of a couple of hundred people and gave a 99 second talk. This thought was terrifying to me at the start of the week but by the end I thought anything was possible, all of these people were friendly and keen to help each other.

Everyone can learn something from TestBash.