Creating a Test Automation Portfolio Episode 1: Setting a Goal

If you are interested in hearing an audio version of this article, please check out this Racket.

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
  7. BONUS #2: Codeless UI Automation with TestProject

Wish me luck!

Photo by Markus Winkler on Unsplash

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.