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.
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?
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.
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.
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
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 🙂
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!
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.”
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
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:-
Start catch-ups with ice-breaker or comments funny/interesting events happening currently to make the mood/setting relaxed and comfortable
Leave the stage open for the person to tell you how things are going for them in a personal and work context.
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)
remove or put away distractions like smartphones etc during the catch-up
try to let them tell their full story , do not interrupt unnecessarily
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
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.
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.
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”
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
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.
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 outthis 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 ofvisibility 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.
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
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?
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.
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.
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.
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 https://toyerm.wordpress.com/2017/04/05/get-out-there-share-your-story/ and Lisi’s blog site https://www.lisihocke.com/2018/12/2018-a-crazy-year-in-retrospect.html 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
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.
Early insights- do you know yourself?
My learnings started with a bang! Fairly early on I was introduced to the concept of Enneagrams- https://www.integrative9.com/enneagram/introduction/ – 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.
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
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.
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!
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!
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.
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 E2EUI 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?
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!
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 🙂
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!
It has been quite a while since my last blog post and most of my blog followers have probably been wondering what I have been up to. From day to day work across multiple projects, mentoring workshops, podcast recordings and webinars, things have been really hectic over the past few weeks. Hopefully I will be sharing much more of those details real soon.
I recently presented an internal presentation at my company regarding practical examples and benefits of Mind-Mapping in Testing to increase Test coverage. I then followed that up very recently with a Webinar on the Biggerplate platform. Biggerplate is quite passionate about getting the concept of mind-mapping to take off across the world in multiple industries from Education to Finance & Medical to Information systems.
They have very kindly allowed me to share the video on this blog. Thank you Biggerplate. I hope you enjoy the video and drop a comment if you have a question 🙂
Check out this link for the video :
This webinar was recorded for the BiggerplatePRO Members. Save $10 on Annual membership ($29) using the code TOYER10 today! To find out more, visit https://www.biggerplate.com/PRO
So the idea for this next blog post came after questions from one of my colleagues was posed to me during the last lunch @ work before the month of Ramadan commenced. Some quick background for those who don’t know, Ramadan is the Holy month in the Islamic calendar where fasting is observed for an entire month, from sunrise to sunset-daily.
So back to my colleagues questions, he posed a few questions to me regarding why fasting is observed? what benefits do we attain? why are we encouraged to give charity during this month? This then sparked many discussions but it also helped me understand many attributes or lessons I have learnt over the years from fasting that helped me apply to my testing career. I am sure the month of Ramadan and fasting in particular has many individual benefits to each person in many different ways, I have applied many of its benefits and virtues to other areas of my life, but below I highlight some key factors that fasting taught me which I used to shape my testing career.
Dedication, discipline, focus and persistence
Fasting requires a lot of dedication and discipline. It requires abstaining from food and water (from sunrise to sunset), it also encourages one to restrain from bad or sinful speech amongst many other things. This highlights the focus one has to have and also the persistence to get through the day and then the entire month.
These qualities have been applied to my testing career as well, more so the last aspect of persistence which is a key factor in the Software testing world. I recall over my 15 years of my testing experience, I was given many opportunities to change my career path- from the possibility of becoming a Business Analyst, a Developer or even a Scrum Master. However I turned these roles down to focus on Testing, I did try out being a Scrum Master for +-6months at some point but the lure, passion and my dedication to Software Testing just brought me back to the field. Check out Wait how did I get here? Time for reflection (part 1). , in that post I highlight these points. Stick to what you believe and you will be fine
Persistence is a nice quality to have as a tester, pushing hard to get a bug resolved or pushing the levels of quality to software is a key element in this field.
Fasting teaches one to be patient, I re-call growing up as a kid and a teen constantly watching that clock ever so frequently, waiting for the time to sunset before one can enjoy the delicacies prepared that evening. It teaches one to have the will-power to get through the day, the endurance of the night prayer after a long day of fasting and the entire month.
Looking back over my testing career thus far that’s exactly how I approached it, I also advise junior testers to take this patient approach. One can be overwhelmed with all the insane amount of different technologies available nowadays – there are tons of programming languages, tons of tools, tons of approaches, frameworks etc. There are so many different industries one can work in, each having its own challenges, do you focus on business, people or tech objectives? I’m sure you will agree that can be overwhelming indeed. If you take it step by step and set yourself regular objectives you can achieve key aspects in manageable chunks. Set yourself a daily goal, a weekly goals, monthly and yearly goals! Doing it all at once can confuse you and mess up what you are trying to achieve.
My current company encourages annual objectives setting, I recall over the years that I have been employed with them – some of my main objectives included: 1 year I would have a business focus in that I would try to learn as much as possible from business users, then there were other years like the current one where I change my focus to everything Tech. Researching and playing around with Docker, Kubernetes, AI and everything new in the Tech world. A tester and more so a ‘modern tester’ needs an armoury of different skills to succeed in this ever changing landscape. Be patient and take it step-by-step!
Another lesson I learnt from fasting is how it had got me on track by following a specific routine and being punctual. We have to get up at a certain time to eat (before sunrise), eating a minute after sunrise and this could nullify your fast, performing prayers at a specific time, then breaking your fast at a specific time. Everything had order and an allocated time.
Well in testing and in almost every career being punctual is key, managing your time and what you do in your job is key. Over my career I try to never be late for a meeting, I always try to schedule things well in advance too. With regards to testing, this can help you prioritise and schedule your testing. If you are doing different things as your tester job function for example running performance tests and functional automation, then set aside time to schedule when you do these. It helps clear the noise when panic and pandemonium sets in which i’m sure you all can relate to. Test Co-ordination and test scheduling is something that comes to mind here. Add order to your day by being punctual and managing what you do, when !
During Ramadan one is encouraged to give more charity than usual, give back to the less fortunate or just sharing a meal with someone when you break your fast for the day.
Over the past 2 years or so, I have realised that I have reached a point in my career where I can give back some of what I have learnt and know in the testing industry. Which is why I decided to have more knowledge sharing sessions, present at conferences, webinars and even blogging more. All this to give back to the testing community, to junior testers and even to people in rural communities who might not have had exposure to the Software or testing field. Ultimately knowledge is wealth and giving/sharing this knowledge is a pure form of charity. Even helping out new starters or junior testers at your work place would fall under this banner 3 different mentoring experiences in a short space of time!
Below is 2 recent examples that spring to mind where I could give back something.
Throughout ones life we are encouraged to seek knowledge, knowledge of the world and knowledge of the religion. This is more relevant during the fasting month too. One increases in prayer and supplication plus reads/researches more regarding religious matters.
In one of my more recent blog posts Observations of the testing universe- where are we? And where are we heading? I mention “The testing world as we know it is changing dramatically right in front of us, its scary yet exciting. The best way to make it more exciting than scary is to learn, learn and learn more. Social media and pairing up with others is key to keep in-touch and at pace, google is also your friend and should be used extensively.” this has been at the forefront of my testing career from day 1 and I always kept an eye out for what is happening in the testing world around me. Seek knowledge in this ever changing IT and tech world to prevent you from being left behind. There is so much of change around us and with the evolution of Automation Testing and where its headed this is something we need to keep in touch with. AI + Machine learning is here and will spread at a rapid rate, just knowing 1 form of Automation would not cut it in the future.
Spread your wings and seek out that knowledge as much as possible!
Recently I have had quite a few ideas for my next blog post, all aiming at different aspects of testing however time has been a major issue for me due to work commitments. I do promise to get those ideas onto this blog eventually. So watch this space.
An idea which I was pretty excited about sharing, was the idea of bringing your test scenarios close to your Automation code. In fact I worked on a case where it can actually reside on the same repo or code base as your automation scripts. I received a lot of interest on the topic when I tweeted about it a few weeks back.
Ok, ok let me explain by first starting on the problem case or dilemma most testers face with when thinking of converting manual test cases/scenarios to automation scripts and how it would fit into the bigger automation picture.
The case for mind maps
Lets start all the way at Sprint level and your daily standup. For a proper illustration I created a simple example Project Jira board and code project for a dummy e-commerce application to explain my thinking around this concept.
Its Day 1 of your Sprint and your Dev has started working on an API story, in this instance he/she is working on the Items API story and the get Items API task to be precise. You proceed to define you test scenarios/cases while he/she is busy developing.
Previously I would have written my test cases in ‘traditional format’ – in a test management tool or document. But after being introduced to mind maps and how it can be used effectively in defining test scenarios/cases, I have found the many benefits of it that facilitate better efficiencies within the Agile process. Some of the advantages of mind map test cases that I have found are the following:-
-greater test coverage
-greater team collaboration
-faster test scenario/case creation
-easier reading/understanding due to visual representation
-more time to focus on exploratory testing, automation and non-functional testing
The above points have been quite evident on my project but as a word of caution there were also some points of caution I had to address to convince my team that mind maps was the best approach for us. Some of the concerns and questions included the following –I have added my answers in italics :-
–what about traceability back to the story/task? Answer: Adding the mind map as an attachment to task (on Jira) worked for us, also a link to a shared drive or address to where it is stored would work.
–only the person who creates the mind map would understand their thinking vs step by step detail of test case. Answer: Fair point however it depends on how the map is created. The easier solution is to have a quick 5 minute pow-wow with your team to give them a brief overview of your thinking. Agile is about collaboration after all, everyone is working on the same product, if they are not on the same page regarding functionality then there are bigger issues. Rather a quick catch-up session with everyone compared to the pain of writing step by step detail which might not even get looked at post sprint.
–what about newbies joining the project at a later stage? how would they understand the test cases?Answer: multiple points come to mind here, 1- you can take the newbie through your mind map collaboratively, they have to learn your system anyway so that initial time to get them on the same wavelength will be worthwhile. 2- why shy away from working on a more efficient way of test scenario definition by worrying about when a newbie starts. How often does that happen? if it does then we deal with it by tackling it with point 1 (above).
-would this totally replace conventional test cases? Answer: It depends, you can if you want to. The whole aim of mind mapping test cases for me is to quickly define or extract test requirements for your system or application which can aid exploratory testing and give you way more coverage than normal. You could if you want highlight the main regression or critical scenarios on the mind map and only do detailed traditional test cases for those scenarios. This way you still defined better test coverage and still keep your normal detailed cases and stats. Your mind map then becomes a tool for you to better create test cases.
Take your mind maps to your automation
Now that I have got the case for using mind-maps out the way lets get back to our e-commerce app example. To keep my example simple I have mapped out a few test scenarios for the get Items API using xMind
I have now been in testing and Automation for 15 years, the big problem I have seen over the years and today is the blank look you get from the testers (including myself) when they have to create Automation scripts. I can imagine the thoughts going through the minds…what do we automate? how does this automation tie back to the story/task? my test cases sit in this system but my automation sits in that repo? This disconnect from Test cases/scenarios to Automation scripts is a problem, consider also a few months or years down the line when your Automation scripts grow massively to a point where nobody even knows what they are covering, unless you go through the lines of code on the script. Well with this concept of bringing ‘Mind maps closer to your Automation Code’ I am hoping to bridge this gap and bring the visual aspect to Automation coverage along with fast and efficient test case creation.
Back to our e-commerce app, the developer has now moved the task over to you for testing and has also thanked you for adding the mind map to the task as this also helped him to create some detailed unit tests covering areas which he would have not generally thought about. Good job he says! You now either execute you test scenarios quickly with the mind map as your reference or you proceed straight to creating your automation api test scripts. Lets assume you do the latter.
I recently (together with the help of my wife 😉 an ex-Tester and now ScrumMaster) found a cool mind-map plug-in for intelliJ. https://plugins.jetbrains.com/plugin/8045-idea-mind-map . How cool, with this plug-in one can create a mind-map directly in intelliJ (hopefully you use intelliJ IDE to create you automation scripts) or you can import a mind-map created from other popular mind-map software like FreeMind and xMind (which is what we use). This is where my concept comes in with the ‘Testing’ context.
Here is how that works.
Under the relevant folder where you would create your automation test script, create new or import the test case mind-map (see screenshot below where I import the xMind mind-map that I created during my test case/scenario definition in-Sprint.)
In-order to now use your mind-map as a template for your automation script, right click and choose to export the mind-map as a plain-text file
I now save my file with the name of my intended Automation test script and change the format to a .js file
I now right click on my folder structure and ‘Synchronize’ the folder to pull in the file created above.
7. And voila, you now have your template to create your automation script in, with all the test scenarios you defined showing up. You now have a 1 to 1 mapping
8. Now you can proceed to create your automation script, which should look something like this (you can comment out the text pulled in from the mind-map)
Points to note and summary:
This concept shows how one can use mind-maps to generate test scenarios from story task level, then import this into your Automation code base repo so that your test scenarios now live side by side with your automation code providing one with an easy transition from manual test definition to automation script. There is now also enhanced documentation of your actual test automation coverage by having these scenarios as a reference living in the same repository.
Happy mapping! Your Automation scripts should not feel alone! 🙂