Refining Your Test Automation Approach in a Microservice Architecture World

As the software development industry moves forward, one thing that never stops is the ever-evolving introduction of new concepts and/or buzzwords. Some are literally just buzzwords wrapped around something that previously existed in the industry in some form or the other. However other concepts go beyond just buzzwords, and need to be taken seriously as it potentially becomes a key factor in influencing how software is and will be built going forward.

Failing to keep up with the concept or trend could mean that previous tried and tested approaches might not be as effective and even worse, might put major question marks against an individual’s relevance and marketability in a thriving, fast paced industry. One such concept is that of “Microservices” or a “Microservice Architecture.” With this concept/approach in mind even more questions come to mind regarding Development, DevOps and other areas, however what does it mean for previous quality engineering, testing and test automation approaches?

I wrote this article on “Refining Your Test Automation Approach in a Microservice Architecture World” for the Applitools blog platform. – – As the Software world evolves, so too should your Test Automation approach follow a similar path. Have you or your company evolved your test automation approach?

Transitioning into QA Leadership: Take the leap

I recently had the pleasure of being offered the opportunity to share some blog posts for the Applitools blog platform at

My recent article on making the transition to QA leadership has just been published.

A quick intro into what my content addresses on this post:

I have seen QA Engineers go through what I call ‘mid-career crisis’. It’s not directly synonymous with a mid-life crisis, however there are some glaring symptoms which pop up across those who face it. Some of those include questions or thoughts like:

  • Is there a future for me in the QA space?
  • I’m just using QA and Testing as a stepping stone to something else within the tech world
  • Testing is great, but where to from here?
  • I will never be a VP of Engineering or even move to a CTO or C-Level
  • Is growth in a test automation path enough to move me to a lead or manager role?

Whether you have asked yourself these questions or have had similar thoughts, you have come to the right place… read the blog post further below and make sure to subscribe for more content on anything Testing and Test Automation related.

Go ahead, make the transition.

Follow the link below to read the full post:

Shift left testing-The Right Way (video)

I recently did a talk at the Ministry of Testing Abu Dhabi Meetup on an area of Testing that I am really passionate about. Some of the points covered in this talk include:

-What are the current challenges in Software development and testing

-What is shift left testing?

– What are the key enablers for shift left testing to be effective.

-What are the key benefits when once chooses to shift left.

-Tools that companies/people can use in order to facilitate the move to shift left.

– Practical examples that can be used to enable more effective shift left test approach.

Here is the video link below. Please share your views.

A reflection, not a goodbye: Tracing the path to job longevity

It has been a tremendously busy period with many major developments and changes happening on the work, personal and test community front. I will share another blog post shortly regarding the work on the test community side.

This post is slightly different from my normal posts as I reflect on the end of a rather rewarding and a proud journey personally.

This post is as much a personal “Thank you” message as it is a reflection (in my view) on what could make a workplace increase employee loyalty and job longevity.

This is a message highlighting the end of a rewarding job, a goodbye to a valued workplace and a ‘until we meet again’ to my work friends who are now more like family. I am hoping that what you and workplaces in general can take out of this post is a path to creating a happy, engaged and challenged workforce, who thrive on giving of their best daily to make personal, team and company wide impact, by increasing job tenure. Something that as a Test Leader or general leader you can try to enforce within your company culture.

A reflection rather than a goodbye


As I near the end of my almost 12 year journey at my current company, to now take up a position internationally at a multi-national company, I reflect back on what has made me so loyal, engaged and dedicated to my employer. Tenure and job longevity is something that is considered very, very rare in today’s rapid changing, competitive world, so naturally the topic of staff retention or employee job satisfaction is something that most companies share a vested interest in.

*For a more detailed account leading up to my career moves over the years check out my two posts on and *

So after being considered a job hopper walking into my current employer was not an easy task, but after a solid tenure I reflect back on what is it that has kept me here for so long? Is this something that you as a leader can look to adopt as part of your company or team culture?

The people

Apart from amazing offices in one of the trendiest places in Cape Town, South Africa, the people of the company is something I value the most. To be surrounded daily by talented, knowledgeable and innovative colleagues makes one give of their ultimate best every step of the way. The relationships one gains from people and colleagues over time can have an impact not only on what one does but also what resides in their hearts as well. This was 1 of the major key factors for me. Celebrate achievements and have time to bond as a team every now and then.

Each conversation, interaction and relationship is what I take with me as a building block to what the future throws at me regarding challenges and interactions.

Taking time as a team

Space to do what you love

As an automation tester coming in to the company, I was given the opportunity to do exactly what I love doing, I was given the space and responsibility to drive solutions relating to particular problems. Playing to my strengths and knowing what made me tick were master strokes in giving the best for the company at the same time, giving whats best for me, the individual. Leaving a lasting legacy on test automation and performance testing is something that prides me as I move forward to take on a new adventure abroad.

As my role evolved, with it changed my needs and what I loved best at a given time. The evolving hunger was met by the opportunity to contribute to a space that I was passionate about, for example growing my leadership skills when I felt I was ready. More on this below.

Growth on multiple levels

I am and will be ever so grateful for the multiple growth opportunities, from a personal growth perspective and a career growth perspective.

I have so much to be thankful for to the company where I spent over 1/4 of my life at. Over the years I was fortunate enough to be sent on many courses, development programs and conferences.

Courses ranging from ISTQB and Certified Agile Tester from a career and testing perspective

Then development programs including Leadership development which not just helped to grow leadership skills but focused on helping me shape myself personally. A blog post will not be enough to count and state the many ways here.


Conference participation: the opportunity to attend both local and international conferences was another aspect that I am grateful for, obviously this is something that one earns based on performance- but also the push to earn it yourself, I could try to attend subsequent conferences if I had the courage to get up there on stage and represent. Something which I grabbed with both hands.

Presenting on the international stage with fellow colleagues

Empowering others

One thing that I personally valued was empowering others, this for me goes both ways. The ability to be taught and the ability to teach.

There is a great feeling of accomplishment when one shares knowledge for the greater good of other individuals and for a company. A culture that embraces this is a space is bound to prosper. Encourage this!

Also look at allowing the space to challenge and have the confidence to speak up if needed. Creating a safe space is what its all about

Screenshot 2019-10-14 at 22.37.24


Exposure to multiple systems and tech

Over the years I have been exposed to so many systems and technologies that there was no room not to be challenged. There was also encouragement to rotate and try out other systems or domains within the IT space if there was ever a feeling of ‘oops I’m heading to comfort zone level‘ , this meant there was so much of opportunity to keep building on knowledge gained. At the same time sharing knowledge of other systems to your new space. The sphere of knowledge rotation between teams and systems was another factor that constantly sparked my interest. Never a dull moment as they say 🙂

Listen to this podcast for more on this.

Culture: Values, empathy and a sense of belonging

Finally another key aspect for me is the foundation of the culture, something that is ingrained into a workforce is very hard not to take note of. Aspects that stand out for me is the array of values and principles on show in almost every individual at the company. You know you are dealing with sheer professionalism at all times.

Caring for another individual is also right up there, there were some ups and downs over my time at the company, to have others genuinely show compassion, empathy or even share in an excitement gives me comfort in knowing that the working world can be a happy place.

A sense of belonging is something that I can never take for granted. Whether its the combination of all of the above points or just an intuition or gut feeling, I always felt part of the cause, a place where it was more than just work, a place where the heart and mind said yes, we are aligned!


End of a chapter

So can you or your company trace some of the ingredients in increasing employee tenure and longevity?

As Iron man so famously said in a recent Marvel Avengers movie- “Part of the journey is the end”  – while I am excited to tackle my new job and the new role and challenge that lies ahead of me, I am thankful and grateful for all the opportunities received and the lasting connections made. So thank you to all of you who was part of the DNA composition of this magical journey.

Ralph Waldo Emerson Quotes

“What lies behind you and what lies in front of you, pales in comparison to what lies inside of you.”



Bolstering your Leadership Armoury-Part 2- Leadership series

One of my previous posts kicked off the Test Leadership series on my blog, if you missed it, please catch-up here :THE TEST LEADERSHIP LEAP! AN INTRO (PART1-LEADERSHIP SERIES), at the end of that post I did mention that there were layers and layers of aspects behind leadership- so in this post I would like to dive into a few more aspects that could help shape your leadership skills. Today I will touch on these important points:-

-The art of listening in leadership

-Receiving feedback

I will try to focus on the above points firstly in generic terms and then try to bring it back specifically to the testing world and how this could be implemented practically.

The art of listening

Has your partner ever told you “But you never listen to me?” – sometimes this statement can have serious repercussions to a relationship and sometimes its just a frustration. However in a professional context especially when you are told this as a leader, it could potentially have a negative impact , possibly even lead to mistrust between individuals, leading to the resignations of individuals. Ultimately leaders (and managers) who listen effectively create much more trustworthy and open relationships. This also builds your image as being a more empathetic or compassionate leader. Finding the perfect balance between tech, testing and people is not always the easiest but it goes a long way in building a team of people who follow a common vision.

So how can we apply this concept to the testing field. Firstly all testers are people (sorry automation tools :-)) and no testing leader or manager will be dealing with people who are immune to personal issues. Whether it be to due personal relationship matters, health issues, financial matters or anything else of a personal nature, the leader has to rise up to factor this when delegating or assigning any task/project or deliverable. Whether that deliverable be a short term sprint level goal or even a company wide goal one has to take into account what impact external influences have on achieving a task before evaluating when a task has not been met.

One aspect I recently changed after starting my leadership journey in the recent months was to tackle this element of ‘active listening’ by setting up recurring one on ones (or catch-ups) with those I am leading. Not only doing that but changing my approach on how I go about tackling these one on one sessions by starting of conversations to have a personal touch rather than going into robot, work mode. I will elaborate on the frequency and approach change below.

setup time and space to listen:

Being in a tech space I found myself constantly working across multiple technologies and looking to implement new tools, type of tests etc. This made time to catch-up with my reportees and mentees much less and very unfair to them. If they had certain expectations in a team and broader context which were not being achieved, by me not knowing the circumstances around these non-achievements is not a fault on them but rather on me as a leader.

Managing expectations based on real-world circumstances around individuals is so key to maintaining effective output in a workplace. Unrealistic expectations usually leads to frustration, disengagement and a feeling of going with the flow. Never let this happen to those you ‘lead’. By increasing the frequency of catch-ups from monthly to bi-monthly and also open the door to impromptu private chats (when needed) has made a massive difference in my relationship with those that I lead. Its amazing what you get to hear from others if you just set aside time and space for them to share what experiences, challenges ,celebrations and impediments they are facing – both in a private and work context.

Some initial concepts around my approach to enhance listening included the following:-

  1. Start catch-ups with ice-breaker or comments funny/interesting events happening currently to make the mood/setting relaxed and comfortable
  2. Leave the stage open for the person to tell you how things are going for them in a personal and work context.
  3. As a leader its important to maintain proper body language and show genuine level of caring in what they are sharing (put yourself in their shoes)
  4. remove or put away distractions like smartphones etc during the catch-up
  5. try to let them tell their full story , do not interrupt unnecessarily
  6. give suggestions if a problem or issue has been highlighted. A suggestion based on practical implementation is valued way more than something blue-skies or unreasonable.

This then equips the leader with a mental map of how to tread when dealing with a specific individual. From Test Automation task to General test tasks I now know better the boundaries or barriers regarding achievement of these tasks by each one of the people I lead, also ‘hopefully’ 🙂 gaining their trust in having a genuine interest in their lives



Receiving feedback

If you are doing feedback as a leader which is one directional (leader>lead) you might want to revisit or open yourself to feedback the other way too (lead>leader). With any relationship, open and honest two way communication is critical to the success of that relationship.


(image source:

Usually to most people let alone leaders eliciting and requesting feedback can seem like a daunting task. But in my view this is imperative for one to have sight of their ‘blind-spots’ and help them grow as a leader.

Even when a leader musters the courage to request frequent feedback, how one goes about requesting it, usually requires a measured approach.

  1. Be specific. For example in your catchup or emails to those whom your lead, don’t just state “do you have any feedback for me?”. Usually the person you lead will feel scared or uncomfortable to speak his or her mind. Ask questions like “right now do you feel as if there is anything more I can do on the UI automation side to make automation easier for you?” or “do you feel like you received enough support from me when that Dev challenged you on that bug that you logged”
  2. Don’t become defensive if you hear negative feedback. Rather gather your thoughts and try to think it through, then let the other person know that its a potential action point which they can hold you accountable to try rectify or action in future
  3. find peers or people on your leadership/management level to give you feedback on how you can be more effective or areas where they feel you need to improve on.

The ultimate goal for yourself is to look at negative feedback as something constructive and help find out where it fits in helping you to become a better leader.

More layers to come…

As I keep writing these posts I realize there are many avenues one can go down in this leadership journey, most overlap so its extremely tricky to put these down as a step-by-step guide to leadership. In reality leadership is a mash-up of various ingredients which only gives the best flavor when mixed and applied correctly.

Bolster your leadership armoury!

Approaching your automation – with measured awareness!

The following is a blog post personally written originally for PractiTest

Just as money makes the world go round, automation makes the testing world go round.

Automation has gone beyond just a buzz word and has now become a critical part of most organisations backbone to software releases. But the question remains, is Test Automation being done the right way? or an even bigger question should be, is there a right way to do Test Automation? The answer is usually it depends…it depends on so many different factors that come in to play regarding the application under the test, an environment, data, architecture and tons of other factors.

With any major project or task one does need a plan or a sort of strategy to get going with Automation. Many people use Quadrants, pyramids and other models to use as references to get the wheels in motion when deciding on an Automation approach for example for some awesome detail around some great models (including an Automation triangle model by myself). check out this link.

In my 16 years+ experience in the Test Automation world, my observations and experiences has led me down a path of putting down some of the key elements that goes into consideration when developing a Test Automation Strategy. I will discuss a few of these below.

1. The case of the test case – Test management tools or similar

Lets take it all the way back to the start. Whether you are using a specific Test Management tool or checklists/mind-maps etc in an Exploratory Testing world, there is an underlying aim. The aim to bring some sort of planning aspect or structure to how you tackle a testing task. At this stage believe it or not, is the first place where Test Automation ideas and thoughts should come to mind. You should identify typical automation candidates during the defining of your test cases/scenarios.

The other aspect around a Test management tool or similar is the key element of visibility and transparency that it provides to all. Test Automation should not happen in isolation and the better a tools ability to provide full on transparency, traceability and visibility to the team, the more relevant it will be to your test automation effort. Never under-estimate the power this element brings, especially to a developing Agile universe- where team play is critical to the success of any organisation. Everyone should be on the same page regarding your teams automation effort. Visibility seen in the terms of test coverage, test results, test trends and all sorts of fancy automation stats comes to mind here.

A further point which can be related to a test management tool in some cases or possibly an external tool like CI/CD supported tools like Jenkins or Gitlab is the ability to executethese automation tests/scripts in batches or in a pipeline, scheduled or on-demand. This is a far step forward from the good old days of scripts residing on a specific machine and executed rather tediously sequentially by opening each test before execution

2. Where to automate- Show me where!

Another key element regarding an automation strategy is ‘Where’ and ‘What’ to automate. Well in a way the ‘What’ to automate is tackled above, the ‘Where’ to automate in this context is not referring to a specific test environment but rather speaking to the layer of the application to automate. Are we talking automation of Front-end or Back-end, are we talking API or UI or possibly even DB. And then the question of E2E testing comes in to play and even further to that Multiple cross- system E2E tests. As you can see automation involves a lot of thinking before doing. So typically inter-Team and tester discussions are vital to get right before deciding on ‘Where’ to focus your automation efforts

3. Tool selection- choose wisely

It doesn’t get any easier you know

Now that we have an idea of ‘What and Where’ to automate the even tougher task of choosing the right automation tool for the job becomes key. In some instances a tool is already purchased at a company and automation has to now abide by this pre-selected tool, that scenario provides its own challenges which I wont get into in this post. If destiny was in the testers own hands a then the choice of a tool should span multiple areas. Some quick points that come to mind regarding tool selection are as follows:-

a.) Tool to technology —> can the tool automate our web application? can the tool automate our desktop application? Does it support API automation? How about mobile platforms?

b.) Tool support —> is there support to aid with assistance regarding problems, crashes or tool maintenance. How often are newer versions of the tool released?

c.) Language support —> what coding language does the selected tool support? Does it support multiple languages like Java and/or Javascript. This question also becomes relevant when doing recruitment and hiring.

There could be many other points to consider in your eco-system that would be relevant regarding tool selection but the above points are some of the first things to keep in mind.

4. Environment Stability- keep it tidy

This is one area which is often over-looked yet negligence or instability in this area could almost nullify all you test automation efforts. Think about this, imagine having the flashiest, beautifully crafted new age Yacht! But you take it to the most rockiest waters to sail on. What an epic fail that would be!

This is exactly how it feels or would feel if there is environment in-stability. Questions around environment up-time, dependency availability (whether local or external) needs to be address here. An example that comes to mind here is something like a google API dependency to test log-in feature of an application. If there is interrupted connection to external services and your tests depends on it, then how reliable or trustworthy is your automation.

Finding ways to weed out problems in your environment and coming up with ways to make your environment more stable as you grow your automation efforts becomes critical.

5. Data, data and more data

Data is another concept which is so key to an automation approach. Data is complicated and can bring many challenges, this is mostly down to the numerous permutations that could exist per any given scenario. Hard coding automation test inputs and variations are almost frowned upon and rightly so in many instances as the power of your scripts reach to find defects is greatly enhanced by feeding it random data per execution. You chances of finding defects per unique data scenario greatly increases with this approach. In a way this can be seen as a form of automation exploratory testing which is a win-win situation.

So focus on finding ways to randomly generate or obtain different combination of data inputs to strengthen your automation efforts, whether this be in the form of sourcing data from tables, files or api’s, it is definitely worth investigating. Some thing to keep at the back of your mind here is the speed aspect. Would sourcing this data slow down your scripts? By how much will it slow them down? These are calls you would need to make as a team when considering how to approach the data vs coverage topic.

In closing

To summarise, It all starts with with how you start. For a well thought out automation approach one has to keep in mind that automation does not just happen. Early automation candidate identification, visibility, team interaction and general planning is imperative to have a solid foundation. Once this is established the other key factors like tool selection, level of automation, data and environment issues need to be addressed to make your automation a success in your world.

The Test Leadership Leap! an intro (part1-Leadership series)

In my last blog post I mentioned that I have had a change of focus this year regarding a key focus area which I am concentrating towards building on.

Just some quick background regarding the so-called ‘Pact’ tradition that Elisabeth Hocke and myself have found ourselves doing since the end of 2016. It has become an annual thing where we hold ourselves accountable on reaching certain medium term goals: for a recap checkout some of my earlier posts specifically and Lisi’s blog site for some detail on the full story regarding holding each other accountable on challenging goals and the actual pacts.  As you will read on Lisi’s 2019 challenge, she has pitched forward the idea of her becoming ‘Code confident’ – a rather amazing challenge! On my side I decided to take ‘The Test Leadership Leap”. So my goal and pact for 2019 is to focus on building all areas of becoming a better leader. This ties in with multiple areas of my career, I have recently been given the role to manage several testers at my company, this to add to my current role of a QA Tech Lead. So the balancing act of People vs Tech is a rather interesting aspect to get into. The other area is on Test community matters, where the itch to learn and share knowledge has automatically made me more visible in the test and software community, both locally and internationally. The prospect of inspiring and motivating others really excites me, so learning key areas of leading is rather important to me at this point. More about this further on in this post


          (image source:

The opportunity

At the end of 2018 I was given the opportunity by the company that I work for, to attend an internally run Leadership course which spans 3 years. The first 2 years of which includes being on 4 day block weeks for about 4 times a year and the final year which includes a leadership focused project that cohorts need to work and submit on. This was something which fitted directly into my short and medium term goals, an opportunity which I was willing to grab with both hands and a grateful heart!

The reason why I specifically waited a few months to blog about this pact was to gain some early insights into the first 2 block weeks of the Leadership programme to gather thoughts and application of the leadership concept and overlay that against the background of the Testers world. This will be an ongoing Leadership series of things I have learnt and how I see the possible practical implementation of some of these concepts.

Screenshot 2019-04-19 at 01.16.24

Early insights- do you know yourself?

My learnings started with a bang! Fairly early on I was introduced to the concept of Enneagrams- – a quick definition from that site is “The Enneagram refers to the nine different types or styles, with each representing a worldview and archetype that resonates with the way people think, feel and act in relation to the world, others and themselves”

After doing an assessment to determine my Enneagram type, many things fell into place regarding my thinking, feeling and acting areas of my life. I will not share my enneagram type on this blog post due to a personal choice 🙂 but I must say I definitely knew which type I resonated with the most before doing the actual assessment.

1 thing I picked up that defines the way I move forward in this Leadership journey, is that you firstly have to know your own positive traits along with your areas of development and blindspots to be an effective leader. The power of influence is driven by how you convey the ideas you are looking to implement or to get buy-in for. You have to know yourself and you have to know the person/s on the other side. Knowing your audience and their needs is key to make the topic of influence a little easier.

Find your “Why”!

As with any individual including someone who also chooses to lead you have to know why you are there.

As mentioned in my intro, one aspect which has always drawn me to leadership and influence was my passion for people, also to add to that – the satisfaction I gain in helping others learn and push them to reach as far as they can.


                                                             (Image source: “”)

I asked myself am I really living this as someone in the Testing Field. I then gained much comfort in 2 very recent testing related examples and experiences.

  • firstly as a leader, last year our testers were given a new challenge to upskill quickly to this new super technical angle that our company was heading towards. Quite a few of the testers that we had at the company had moved in from business areas of the company or did not have previous experience with coding or even the aesthetics around tool specifics. I decided to drive forward and host a 5 part bi-monthly sessions to give them intros and some practical demos on:-
    • version control software like git, the check in and merge process etc
    • API basics like what is an API, what does it do, how do we test API’s and much more
    • automation tools used at our company, and what level of the application they cover
    • Javascript and some of its basics, standards etc
    • other technical tools like Monitoring tools
    • High level system architecture -so that one knew the flows intra and inter system in order  to test better
  • secondly as a test community member, Lisi and myself decided to do a few things to inspire others:-
    • share our story of pairing at conference and via blogs, social media, webinars, articles and podcasts–all this to get others to push themselves to reach new heights to benefit self and company.
    • form an extended “PowerLearningGroup” – which is an international skype group which meets every 3 weeks or so. This group includes 10 like-minded, passionate testers and leaders from across the world (9 countries) who meet regularly to share ideas and concepts that can benefit our day to day tester lives. The other benefit is to spur each other on to work on latest and greatest initiatives to better the testing world practically.



(image source:


Doing is believing

So I looked to bring this back to testing. As a Test Leader and manager I had to take steps of doing massive introspections and also getting to know my peers, mentees and fellow colleagues even more. I am making concerted efforts to setup time with those who report into me to better understand them from a personal and work point of view. To find out what makes them tick, what drives them and what would they like from me as a leader. I also looked at using my technical knowledge to leverage more respect by doing , helping and working together to attain a common goal. For example a recent practical example was to improve the presence of Performance testing across multiple areas. I decided to setup an initial session with a broader group to highlight the reason why Performance testing is vital in our environment , how it was done and what needed to be focused on to get it going themselves. I have now proceeded to have more focused team specific sessions where I would physically help in implementation of these tests. In my view a better leader (especially in the IT development world) does as much as he speaks, don’t just talk the talk, but walk the walk too. Lead as YOU want to be led!

in Ending

This leads (see what i did there) me to the end of part 1, as I wrote this I realised that there are layers and layers to this Leadership area and it might take me a good few hours to keep going on this post. It is a journey indeed! There is so much more to share on this early stage of my Leadership journey but I will save it for the next part of the series 🙂 So welcome on this journey with me!


(image source:

DevTestOps: It’s alive, but what can testers do to make it alive AND kicking into overdrive! (My External community guest blog post)

It’s me again 🙂

It’s been a rather crazy beginning to 2019 with so much happening. This year I have a key focus area that I will be sharing in a detailed blog post real soon.

Hopefully that key focus area will be a kick-off to a series of blog posts related to that particular topic

For now, please check out my recent blog post feature on the Testing in DevOps community site.

Enjoy 🙂

Lower level Automation and testing? Be more precise! The Automation triangle revisited…again!

A blog post has been well overdue for me- but hey better late than never.

In this post I want to bring together a mixture of current experience, some theory and a word of caution when tackling low-level automation and testing. An observation and point of note to anyone who finds themselves in a similar situation now or in the future. I recently found myself in a very interesting space on one of my projects which got me thinking about a potential point of caution when one is looking to automate or even test across the different levels of your system.

Recently there has been this great ‘Shift Left’ concept which was mostly spearheaded by the famous ‘Automation Pyramid/Triangle’– yeah that famous pyramid again. I am not putting that pic up as I think that pyramid is tired of making so many appearances 🙂 Instead I will use this pic of a real life pyramid for effect. If you need to check-out all about the automation pyramid, then I suggest you do some reading on it. Check out these 2 links for a start : and


Setting the scene

So where am I getting to? I must highlight 1 point before I go any further the following dilemma I mention below would not be evident on all types of systems that one faces but it would be the reality in most modern systems/applications including Low-code type systems and systems where there is a some sort of manipulation or translation from the UI to your middle layer or even API’s . Regardless the question begs to be asked on every project that you tackle just to reassure that the Automation and testing approach that you follow gives you a peaceful night’s sleep.

Well consider the following scenario on your project, you have a shiny new application with some cool front end tech coupled with some sleek back-end engineering. You wonderfully decide to follow this magical Automation pyramid, you think you are going to totally smash that Automation pyramid/triangle model by working real close with your devs to create superb unit tests, you want to add in a dash of component tests to further strengthen what you covered in your unit tests. You don’t stop there you decide want to throw in some fancy Integration tests. 1 last topping on this amazing triangle- you ponder a hint of E2E UI tests to top it all off. Not too much just the right amount. How awesome you think, this defence I have planned to build up is surely watertight!

What they don’t tell you!

Based on the famous triangle or pyramid this is usually how people want to tackle their Automation. But remember, it’s not magic! its not plug and play, you have to keep asking the questions. What am I testing? Am I automating just for the sake of it? am I automating or testing here just to fit in to the Automation pyramid?

download.jpeg . image from:

When you get back to your desk to start on this cool testing task, you pause and think- hang on something is amiss! something is just not adding up here. Create unit, component and integration testing–but where? Well I found out the hard way and also found out where the major shortfall was on my project- that I will explain afterwards.

The simple answer is the Automation triangle needs to be expanded in practice. One needs to break it up even further when you tackle the actual effort on your project. This effort then explodes- as I said its not magic and one has to prepare for this personally and let it be known to the team and relevant interested parties- as this effort ultimately affects the sprint and in-turn estimation which then impacts actual time to delivery.

My attempt at breaking up the Automation triangle according to my experience is depicted below. I will then give a brief explanation below. The reality looks like this!


The reality

So now that I have broken the triangle up a bit more to put theory into practice by aiding actual day to day activity or project contribution. Lets unpack it a little more.

A testers full testing effort is usually not limited to just an API or one part of the UI. A testers effectiveness is evident when he/she has the full picture in his/her mind, testing the entire application as seen by the user and beyond! Front end, back-end, logging etc. With this in mind if the true sense of ‘Shift left’ is to materialise one needs to cover testing and automation at every possible level. UI and API (and whatever other backend magic that exists)

That then means that triangle now needs to be less vague and more specific to include both UI and API/Backend tests across the different levels for it to make practical sense to the actual testers who need to carry out the detailed tasks at hand.

UI Unit– usually done by the devs to cover unit level of a UI validation, field, text etc

UI Component –usually written by testers to see how that component/area of the UI behaves usually by mocking out its dependent calls or API’s

UI Integration (within the application itself)- usually written by testers to test how that new component behaves when integrated within the application at large. For example does a new field/element that is recently added to the application conflict with an already existing field or element- or just finding any weird general issue when this is merged to the greater individual application under test

UI Integration (to APIs/Backend)- usually written by testers to test one of the most important aspects-bringing the Front end and back-end together. Passing on variables and composing a payload or xml to be sent to the API or Backend/webservices etc.

API Unit-usually written by devs, where testers atleast have some visibility into coverage. Covering unit/s of an individual API composition

API Component-usually written by testers with dev assistance and input. Consisting of mocking of dependencies, run independent of environmental related data.

API Integration (to backend and/or other API’s)-usually written by testers. Consisting of actually calls to dependent APIs and/or downstream systems/dbs

E2E UI- usually written by testers- light coverage to bring all of the above together and just provide re-assurance that all is in order- Run in a fully integrated non-mocked working environment

Hope that makes sense 🙂

The diagnosis

As mentioned earlier on the project I worked on I found this out the hard way. I actually had multiple tests and some great detailed coverage across all areas of the triangle accept for 1 area.

Any guesses where?

Well that area proved to be the UI integration to API. I had covered tons of different API scenarios and I figured I was safe when it came to hooking up the UI. But that wasn’t the case at all. The manipulation of variables and parameters from the UI as they passed through various different workflows that composed the payload, which then passed on to the actual API’s proved to be the big problem area. Individually everything worked great, but when integrated it didnt play nicely.

This was quickly identified and a solution suggested to hook into this UI workflow integration to API level and bolster coverage at that level to prevent any gaps in coverage.

So basically the lesson learnt from this is to understand your application and its inner workings when approaching your testing efforts. Following a model or blueprint blindly without asking the relevant questions can be catastrophic. The key is that a model is just a guide and should be used that way, for maximum effectiveness you need something that suits your situation. It can be tweaked to suit you unique situation or system.

Keep challenging your own thinking and the system will be a better place.

Finally you can sleep peacefully, knowing you have your bases covered!

lion sleeping beside rock
Photo by Aldo Picaso on