Creating A Test Automation Portfolio Episode 2: RPA Testing

  • Languge: VB.Net / UiPath proprietary language
  • IDE: UiPath Studio
  • Source Code Management Tool: Github via Github Desktop
  • Type of Tests: UiPath
  • Website Tested: My Local Gym

In my last blog post, I outlined my goals for a test automation portfolio.

In this post, I’d like to talk about how I’ve been doing with the fifth task – writing a Robotic Process Automation (RPA) test framework using the market leading vendor UiPath.

I’d become familiar with UiPath earlier this year, when I was one of the first to take their newly launched foundation exam, UiRPAv1. So I am officially a certified Associate, but I hadn’t done much with the tool since passing the exam, so this seemed a great opportunity to learn by doing.

I’m actually very happy with how this first part of the portfolio has worked out considering my starting point, but let me be clear that in no way do I want to give anyone the impression that this code was a few minutes in the making. This took days of effort, and one helluva lot of Googling. But we all have to start somewhere, and I’m sure the steep learning curve will mean things will be faster next time. Another bonus is I’ve ended up with a nice template that I can use as a jumping off point in future.

The Project

As a result of Coronavirus restrictions, my local gym introduced a pre-booking policy. Members could book either a gym or a pool session up to 7 days in advance. I thought it would be fun to write a robot to automate this booking process.

So, what does it do?

Here is a video of the booking process. Note I do not confirm a booking (as this could not be undone without a phone call to the gym as they have not implemented an online cancellation feature) but the Robot does the following:-

  • Login using secure credentials (triggering an email if this fails)
  • Navigate to a date – in this case default but could be specified by the user in a pop up box
  • Select a time – again using a default value but user can overwrite this
  • Select an activity of either pool or gym – defaulted to gym, however if the user types a value into the pop up this is then read from a SQL Server Express database (that I created from scratch 🤓) and the corresponding activity number is returned
  • Confirm the booking or alternatively remove the booking
  • Logout and close the browser
  • All key processes contain try/catch blocks for exception handling.
A video of the automated process in action

The code was written in UiPath Studio (a free tool) in its proprietary ui language, and some customised fields were written in Flows and tests are executed either via Studio manually or via a scheduled robot created in UiPath Orchestrator.

For those new to UiPath or Robotic Process Automation in general, an end to end flow is broken down into key workflows/sequences, which utilise customisable drag-and-drop functions to organise the flow. The process can then be embedded into a state machine framework which allows for reliable execution and error handling.

An example block of code inside a workflow

High Level Overview

Here are the key features of the framework:-

A trigger scheduled the automated running of the process in UiPath Orchestrator

The Code

The code is on my GitHub Repo, and I encourage feedback if you have time. Another new tool that I incorporated was GitHub Desktop, which meant I could commit code directly from UiPath into GitHub, add additional files into file explorer instead of using GitHub’s web UI (which I’ve never really gotten on with) so GitHub Desktop will be my default for managing version control in future.

GitHub Desktop made things easy
UiPath integration with Git

There’s a piece of development work alongside the testing element (in fact, the tests were the easiest bit by far). An Excel spreadsheet included as part of the REFramework standardised template allowed each part of the framework to be tested in isolation. This takes seconds.

Lessons learned

Although it was helpful to me to automate a process for a website I actually use in real life (even though I have no intention of using this automation for anything other than a learning exercise really), automating this website was a mistake. The output has meant that as a portfolio entry this has less value than if I’d chosen, say, a practice site mentioned in Angie Jones’ original blog post such as OpenCart or Restful Booker, because someone wanting to see my code running won’t be able to – the login credentials are stored locally in my Windows Credential Manager and for obvious reasons I won’t be sharing them on GitHub. Next time, I will use something generic so that my code will run for anyone.

An update to the above is that I have now frozen my gym membership, so at present even I cannot run the code itself as my account is frozen so I cannot make bookings and improve the code – I’m kicking myself I didn’t use a generic site as this sort of thing wouldn’t happen!

I’m also guilty of over-engineering this solution in the quest to prove to myself that I can write something “proper”. Bloody imposter syndrome. When I looked through Angie’s GitHub repo she had such nice clean simple structure to her code it was much better to do less and keep it simple, especially when this is something I may need to explain in future job interviews.

Finally, I know full well that if an experienced RPA tester/developer were to review my code they would inevitably find space to improve it (and if anyone is up to the task, I’d genuinely be very grateful). I know, for example, that nested if statements aren’t cute. But I honestly could not think of a better solution. I think this is perhaps where pair programming/code review with an experienced person comes into its own. Two heads are definitely better than one.

That said, I’m still in a celebratory mood having completed the first of my five automation porfolio tasks. Time for a short break, then on to the next one!

Creating a Test Automation Portfolio Episode 1: Setting a Goal

Not for the first time, I’d like to give my thanks to Angie Jones for her post “10 portfolio projects for aspiring test automation engineers“. Reading it made perfect sense to me, so much so that I wondered why I hadn’t thought about creating a portfolio before.

If someone were to come to an interview for a testing related position armed with their own GitHub repository containing samples of their work I can only think this would be a positive thing, for the following reasons:-

  • Even if it isn’t perfect, it gives conversations about automation a jumping off point – “can you tell me why you did X” and “what would you like to do to improve Y“, “when wouldn’t you use automation for Z” etc.
  • It demonstrates an enthusiasm and passion for testing
  • It allows a nervous interviewee an opportunity to show their skills without just speaking about them
  • If they don’t yet have commercial experience in that area, it is a great way to demonstrate what they could do if given the right opportunity
  • There may be some useful code which (assuming it is the property of the person who wrote it and not copied and pasted from someone else’s repo) may be applicable to the work-related project and the ideas can be quickly lifted and shifted to add value.

Now, lets be clear, I have only been working in automation for a few years, so I am still learning and would still class myself as a beginner/intermediate level in lots of areas. But I’m also keen to take advantage of the free online courses and resources aimed at people just like me, so I’m setting myself a long term goal with this activity.

Goal – in 1 years time I will attempt to have the following on GitHub:-

  1. C#/Java solution for web browser automation for Opencart using Selenium WebDriver
    buy an item (interact with multiple pages) – ideally atomically by API calls
    Use POM and clean code
  2. JavaScript solution for web browser automation for Opencart using Cypress
  3. API testing for Restful Booker using Postman
    Newman calls
    use GET, POST, DELETE methods
    Use parameters, environment configs, request bodies and tests – learn about mocking and try using that
  4. CI integration testing using TAIKO to read programatically from an external data source
  5. UIpath to do RPA testing preferably reading from a sql server express database to populate values to somewhere in the test
  6. BONUS: NUnit Testing of Restful Booker

Wish me luck!

Risk is… in the eye of the beholder

Millions and millions of years ago, back when I was studying for my Law degree, I was surprised to learn that far from the truth being objective and fixed, it was a malleable thing.

Mooting societies, where aspiring lawyers could pick a side to debate about a particular case, or topic, were popular. And they were popular because either side, with the right amount of well constructed arguments and material, could win.

definition of risk from

Fast forward to my current life as a software tester, and this subjective fluidity also applies to risk. There are many different ways to prioritise bugs, issues or features – including whether to raise them at all if you think they won’t get fixed.

The one thing that seems to consistently hold true is:- most people assume everyone thinks the same about risk as they do.

The confirmation bias is strong in this one.

I’ve often been shocked, even when an agreed categorisation table is in place for both priority and severity, triaging bugs that I would deem super critical, only for the Product Owner or wider team to prioritise something I would consider far more trivial instead – sometimes I understand why, other times the rationale seems flawed. As a tester, I see risk everywhere, which can be a good thing, but needs to be kept in check. Sometimes a pragmatic way forward needs to be accepted by everyone, where not all bugs can be fixed, and we “fail-forward”. UPDATE: An interesting approach that I’d like to investigate more on bug raising was outlined at a recent Lean Coffee morning I attended. Stuart Day, Principal QA and Agile Coach at Dunelm, advocates not raising bugs at all (or hardly ever) – as most bugs take more time to create, triage, prioritise and fix than they do just to have a chat with the developer and get them sorted there and then (or even fix them yourself if you can). Whilst I’ve informally done this from time to time, I’ve never seen it be openly advocated from a senior manager in this way, and it definitely peaked my interest. I guess you can be the judge of whether that approach is more or less risky.

Of course, the risk appetite is greater or weaker depending on other factors too, such as:-

A great example of how we all asses risk differently is with Coronavirus (I realise this post is weirdly Covid-19 heavy, but bear with me!). I have lots of conversations with friends and family who consider “bending” the rules absolutely fine, whilst others stick rigidly to the government guidelines. Everyone feels their approach to risk is the right one. Often people, are quick to criticise others for exposing themselves to “unnecessary” risk which they themselves justify taking “I just don’t understand how these big crowds are going out and mixing together. I had a party in my back garden yesterday, but that was OK because it was just my neighbours and some family”. etc. etc. Risk is in the eye of the beholder.

I think in general the ubiquity of software means that most people have a reasonably high risk appetite when it comes to, say, an app, or even an early release of any software product. They accept that if they are “early adopters” or “beta testers” the development team are still working through issues. The important thing IMHO is to find the time and the space to fix the “cosmetic” or “usability” issues, often found in user testing or by testers themselves, which negatively impact their experience of the software. Workarounds shouldn’t have to be used forever, and companies who continue to treat their users in this second rate way may pay a heavy price. Perhaps this is where Stuart Day’s approach to fast bug fixing would pay off?

Thank you to the Bloggers Club at the Ministry of Testing for inspiring me to write this. You are awesome.

Testing is like… an amazing secret

Something you can’t believe not everyone knows because its so. bloody. fantastic. It is the key that opens the door to financial independence, opportunity to work with like-minded people from all over the globe and a chance to be a part of delivering things which can affect millions of people. And we should cherish it.

Let me tell you something about me. I grew up on the East Marsh area of Grimsby, in the county of North East Lincolnshire, UK. At the time I was growing up, it was in the top 25 most deprived wards in the country. Twenty-fifth, out of 32,844.

So knowledgeable was it of the fact that the East Marsh was such a rubbish area to live, the English Indicies of Deprivation Index was kind enough to embed an advert for a burglar alarm installer onto the above page on its report, which gave the scores for the East Marsh itself. The % scores of deprivation read like binary code – better than 0% of areas in England for Education, employment, income deprivation etc, etc. – statistically speaking, there was nowhere worse in England for me to have grown up.

When I was 18 someone told me I was more likely to have had a child by my age than make it to university. It stung (the truth always does I guess), but it also lit a fire under my bum.

I was obsessed with getting out. My only ambition was making it to University. Fortunately, I was blessed with a hard working professional for a mother, as well as determined and capable matriarchs as grandmothers, so I never doubted it was an option, and indeed my hard work got me to the University of Sheffield, where I studied Law. But I used to smile at the people I met at Uni for whom attending was a given, something that was nailed on. For me it was (and still is, when I come to think about it) my best ever achievement.

But what does this have to do with testing you ask?

Well I guess those early experiences of growing up in such a deprived area, as well as working in a bunch of other tremendously overworked and underpaid “menial” jobs, taught me two things. I don’t ever want to go back, and appreciate the good things. My mantra in my early twenties was follow the money – I sought work on a single criteria – wherever paid the best for my skillset, so determined was I to not be resigned to my statistical fate.

When, like most testers, I fell into testing by saying yes to an opportunity without really knowing what I was getting in to, I could not have known how much amazing goodness would be coming my way over the coming decade.

When I hear people in our industry complaining about working conditions, or not having enough free coffee, or only getting a 2K payrise, I only have to think of the life I left behind me to realise how lucky folks are to have what many would consider such paltry concerns. I feel like crying when people from back home get in touch to tell me there are no jobs and (despite being perfectly capable) the geography of where they live has limited their chances. They’ve never heard of software testing either, but I wish they had.

I feel incredibly lucky to work in an industry that is such an unbelievably amazing sector, at such a great time in history for tech – its exciting, challenging, interesting and, yes, for what you are doing, very lucrative indeed. You don’t need to talk to verbally abusive strangers, you don’t need to clean toilets or ashtrays, or pack boxes with frozen fish for hours on end (and yes, I talk from experience on all these matters). Generally speaking, you work with well educated and like-minded people and you get to be a small part of delivering some brilliant, game changing stuff.

If you work as a tester in 2020, you’ve lucked out my friend.

Thank you to the Bloggers Club at the Ministry of Testing for inspiring me to write this, my first ever WordPress blog.