Three takeaways from my application support days…

When I graduated from university and started working in my new job, my first role was to work in application support. Most of my friends were working in application enhancement development or new application development and I was a little envious at first, but as time went by I came to appreciate the application support role.

The defence line of your organisation”

I worked in application support for one year and during that one year, I learnt a lot that helped shape my tester career:

  • Priority Management

Working in application support, you needed to learn how to manage priorities to ensure we were always working on the most important issues. If you weren’t managing priorities accordingly, then the users would become unhappy as their issues weren’t being attended to on a timely basis.

  • Stress levels

Working in application support can be very stressful but you needed to realise very quickly that you cannot be running around like a headless chicken. You needed to be methodical and calm headed to ensure you resolving the users’ issues quickly and effectively.

  • Domain knowledge

In that one year, I gained a lot of domain knowledge about the inner workings of the application that we were supporting so that when I moved off the support team to the enhancement development team, I had acquired sufficient knowledge of the applications that I was going to be testing.

Looking back at that first year in application support there were many highs and lows, however the experience was invaluable and help partly shape the tester that I am today.

Some thoughts on presentations…

I recently read a blog post by Rebecca Murphey titled Speaker Notes. It is one of the better articles I have read on the topic of speaking at a public conference or speaking at a presentation. There are many awesome tips, advice and techniques in the article. It’s well worth the time investment to read the article.


“That sinking feeling”

I have found preparing for an important presentation or training session as one of the more stressful responsibilities especially when you are presenting to your peers. To deal with this, I have found the following technique to help me better prepare for presentations:

  1. Practise the presentation out aloud

No matter how many times you have practised the presentation in your head, I have found that its important to practise the presentation out aloud. I get in front of mirror with my presentation notes and then deliver the presentation. Doing this I am able to notice:

  • Whether my main ideas for the presentation come across well
  • Whether the flow of the presentation works

By hearing myself speak I am able to make any necessary adjustments to the presentation or the associated notes for the presentation topic. Once I have made the necessary adjustments, I then practise the presentation a few more times until I am comfortable to deliver the presentation without relying on my notes.

This technique is not ground breaking, but it took a while for me to learn and adapt it as part of my presentation process. The nerves however never go away but that isn’t a bad thing, as it keeps me on my toes.

Actionable next steps…

Managing your time, can be somewhat challenging especially when you are juggling many different priorities at a time. Its becomes increasingly more difficult when to know which items are more important as priorities rapidly change.



There are so many great time management articles and systems available (see above image for a nice summary) on the internet, but specifically for myself I have found one technique that helps me.

Actionable next steps

One thing that has helped me better switch focus is to write down what is the next actionable step(s) for the item I’m busy working on. Example:

  • If I am requiring to pause testing on application X, as I need to switch focus to application Y, I will write down my next actionable step (e.g. investigate functionality A for performance using perfmon) for application X so that when I pick up application X again, I can get into the zone more quickly by looking at my next actionable step(s).

I have found this technique beneficial and allows me to pick up where I left off. At the end of the day, its important to find out what works for you but I have found a lot of benefit in using this technique.

Some thoughts on coordinating a team…

For the past few months, I have been working on coordinating an internal team at my work. I’m not a project manager or anything like that but have been responsible for the coordination of the team. The team consists of myself and 2 developers. I serve as a project coordinator, business analyst and tester on the team.

This post, I’d like to focus on the some of the tools and principles we use in the team to manage our work.


Simple but very effective tool that we use on a daily basis to determine; what we are working on, who’s working on what and what has been completed. Our board has a simple layout and consists of the following lists: Prioritised Backlog, In Analysis, In Development, In Testing and Done.

  • MS Project Plan

A high-level project plan that looks at the macro picture for the team. We don’t use it as extensive as some of the other project teams, but it serves its purpose for the long term view.


  • 3 Wins

As a team we try to identify 3 major wins that we will try to accomplish for the week. We have taken the concepts of 3 wins from J.D Meier’s Getting Results the Agile Way. We don’t use all the aspects of the system, but apply what’s necessary to the team.

  • Honest Communication

It’s fundamental and key to be open and honest with each other to ensure we are pulling in the right direction.

  • Limit WIP

We limit our work in progress (WIP) items to a maximum of 3 items per person as this helps each team member, remain focused on completing what’s important for the week. If our priorities are not clear, then its very easy to become distracted and work on things that are not as important.

  • Having fun

If we are not having fun, then what’s the point really? Humour and maintaining a positive attitude is important as it contributes to a fun atmosphere that people want to work in.

Most of the aforementioned items are not new but they are simple and effective ways, I have found to help coordinate a team.

Most important thing about a conference proposal…

Over the past month, my attentions have been focused on writing a proposal for attending a conference. There are many benefits that can be gained from attending a conference and this picture sums it up perfectly:


But exactly what benefit will the organisation or company gain from the employee attending the conference?

Output of value gained.

Demonstrate the output of value gained to the organisation or company from attending the conference. Example:

  • x number of training sessions based on the knowledge gained from attending the conference.
  • Improvement in the process of software development based on the knowledge gained from attending the conference.
  • Exposure to new tools.
  • etc.

At the end of the day, whoever is paying for the employee to attend the conference, they would like to see what tangible value can be brought back into the organisation. Demonstrate this value and make them realise the tangible benefits gained.

Pro-rating Testing Challenge

Markus Gärtner recently posted a testing challenge on his blog. It is an interesting challenge and I tried to solve it to a certain extent.

Before I start any form of testing, I always like to mindmap my thoughts and ideas while working through the problem. For my mindmap, I used the new free cloud based mindmapping tool called MindMup.

Pro-rating Testing Challenge MindMup

In the mindmap, I tried to understand the context of the problem and jotted down my ideas for possible scenarios that I would test for problems in.

The key part of the challenge is to find interesting variables that may cause problems. For the purpose of the challenge, I decided to try combinatorial testing (pairwise) technique in order to determine different interesting variables. I used Microsoft’s pairwise testing tool called PICT. I declared the following variables and values for the challenge:

  • Months
    • Values: January, February (Non-Leap Year), February (Leap Year), March, April, May, June, July, August, September, October, November, December

The user can sign up for the different months of the year.

  • Days in Month:
    • Values: 28, 29, 30, 31

Each month has different unique number of days in the month.

  • Subscription Start
    • Values: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31

The different start days that a user can sign up for the subscription.

  • Subscription End
    • Values: 1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31

The different end days that a user can cancel their subscription.

I had also declared the following conditions for the challenge to help create better pairs and not pair invalid variables and values :

IF [Months] IN {“January”, “March”, “May”, “July”, “August”, “October”, “December”} THEN [Days in Month] = 31;

IF [Months] = “February (Non-Leap Year)” THEN [Days in Month] = 28;

IF [Months] = “February (Leap Year)” THEN [Days in Month] = 29;

IF [Months] IN {“April”, “June”, “September”, “November”} THEN [Days in Month] = 30;

Once this was configured, I execute the PICT tool and it generated 987 different combinations using the variables and values. However, after looking at the data I realised there were still more invalid pairs. I proceeded to copy the data into a Google spreadsheet and removed the subsequent invalid pairs by using an IF OR statement which resulted in 456 different combinations.

I then proceeded to calculate what the pro-rated value would be for the 456 different combinations using the following formula:

(Subscription End – Subscription Start)/Days in Month

I applied this formula and then realised a lot of the different combinations produced the same pro-rated value. Taking this into account, I then removed all the duplicate values and was left with 100 distinct pro-rated calculation values. I have made the spreadsheet available for anyone to view.

Overall, a very interesting testing challenge and I wonder how many other ways will other testers try to solve the challenge.

Habits revisited…

A few months ago I wrote a blog post titled forming habits. In it, I declared some habits that I wanted to incorporate into my routine and I thought it would be a good to revisit these again. The following habits I declared to incorporate into my routine:

  • To read daily

I have always enjoyed reading and its great to be doing it on a frequent basis. I read all sorts from batman comics to post-apocalyptic novels to how Google tests software. I try to read for 30 minutes before I go to sleep.

  • To write on a weekly basis

I’m surprised that this habit has managed to stick (so far). I have never been good at writing or profess to be good at it, but since I have started this blog I haven’t missed a week without posting a blog. This is something I want to continue and maybe one day I’ll take up Zenhabit’s challenge of writing daily.

  • To code on a weekly basis

The least successful of the habits which I have tried to slot into my routine. It started really well with me getting through ATDD by Example: A Practical Guide to Acceptance Test-Driven Development and Specification by Example: How Successful Teams Deliver the Right Software but since then I haven’t managed to do anything of substance. I’m not a very technical tester and therefore found getting into code quite challenging. Also, I found if you not actively coding on daily basis, its even more tougher. However, I have read some blog posts recently that are serving as inspiration for me to kickstart this again.

So as you can see, these new habits have been so-so successful. Some things I have learned during the past months while trying to form new habits:

  • The most challenging aspect about building new habits is that your willpower gets tested often. Zenhabits wrote a good post about when the path ahead gets tough we often choose the easy path and this couldn’t be more truer. On many occasions throughout the past few months, the obstacles ahead have caused me to take the easy route.
  • Maintaining a habit journal has helped to keep track of my habits. It doesn’t matter what format you use (I use a Google spreadsheet to keep track of my habits on a daily and weekly basis) but the mere fact, that you keep track of yourself does help to make yourself more accountable.
  • Forming habits requires dedication and hard work. Simple as that.

I think the most important thing I have realised is that until these habits become part of my daily/weekly routine, I’ll continue to work on them.

My thoughts on Test Plans…

I’m busy working through Google’s Software Testing book, How Google Tests Software, and got inspired when I read about the 10 minute test plan in the book. I had read this blog post a few years ago but only recently has it made an impression on me. I’m all for the main gist of the blog post to not create waste and to focus your planning efforts. If you do a google search for test plan templates and peruse some of them, some of these promote waste creation that frankly will never read by most of your team members.

Before I get to the main point of my blog post, lets unpack what a test plan is:

A test plan is a document detailing a systematic approach to testing a system such as a machine or software


sum or intersection of strategy and logistics


A test plan should serve as a living document of your planning efforts on how you are going to test. This document should be the blueprint that dictates how testing will be performed for the application/project.

A test plan shouldn’t be about filling out a template because if that’s what your definition of a test plan then you are being inefficient with your use of time. A test plan should be specific, contextual and discuss the following:

  • Why

Why are we testing on this project?  Do we understand why the customer wants this enhancement or new application?

  • What

What problem are we trying to solve? What areas of the application are being affected?

  • How

How are we going to test the application e.g. heuristics, oracles, scenarios?

  • When

When are we planning to test e.g. testing estimates?

  • Where

Where will these changes be tested e.g. environment?

At the end of the day, you should not need to document more information than the aforementioned points because then you are just taking precious time away from the most important responsibility of a tester i.e. to test!

If you would like to do some more reading on how to create more context specific test plans, I’d highly recommend reading through the following resources:

Good luck with your future planning efforts!

Position Heuristic

This post I want to focus on the position heuristic, which I have found useful when it comes to testing. To clarify what a heuristic is:

A heuristic is a fallible method for solving a problem or making a decision


Heuristics are strategies using readily accessible, though loosely applicable, information to control problem solving in human beings and machines


I found out about the position heuristic via Elisabeth Hendrickson Test Heuristics Cheat Sheet. The position heuristic focuses on testing data (or whatever you need to apply it to) by focusing on:

  • Beginning
  • Middle
  • End

How to apply this heuristic to your testing? For example, you have an application that generates a report of employee information :

  • First name
  • Last name
  • ID
  • Cellphone

When you generate this report (hypothetically), a 1000  employee records are displayed. You can manually verify and validate each of the 1000 records and whether the information displayed are correct but that would take too long. If you apply the position heuristic (with a slight modification), you can verify and validate the report as follows (this is assuming you have written a SQL query that produces the report data for your own verification/validation purposes):

  • Compare the top 20 records in the report to the top 20 records in the SQL query
  • Compare the middle 20 records in the report to the middle 20 records in the SQL query
  • Compare the bottom 20 records in the report to the bottom 20 records in the SQL query
  • Randomly compare records between the top and middle data sets
  • Randomly compare records between the middle and bottom data sets

Applying this heuristic, you will achieve good test coverage. Also, as a final test you can check whether the SQL query total (i.e. 1000 records) matches the total output from the report.

There are probably other ways to test the report with the use of tools (e.g. scraping the data from the report and the database and using excel or win merge to find any differences between the datasets) however I have found this heuristic very helpful when it comes to this testing reports.

Lessons learnt in mentoring testers…

I have been mentoring testers now for 5 years (still a novice in this domain) at my company. Predominately I focus on graduates however I do get the occasional experienced tester to train and mentor. I have 4 short lessons on detailing my experiences while mentoring testers.

  • Have mentoring programme or structure in place

I have found that it’s important to have a training programme in place, but this programme should be flexible enough so that you can adapt it to the relevant tester. This programme should try to serve as a baseline of guidance for their role as a tester.

  • Patience and support

As the saying goes, patience is a virtue and this couldn’t be truer when you are a mentor to someone. Mentoring requires patience! There are going to be times, when you are frustrated with them but try to not let this show. Rather work with them in building their confidence and trust and this will help them in the long run.

  • Critical thinking

Very important point to drive home when working with the testers. “Think outside the box”, see things from different perspectives and always ask question. Introduce them to blogs, books and other resources that will help expand their knowledge on testing and quality assurance. Doing this from the beginning will greatly assist in building a smart tester!

  • Work closely with them on their projects

I like to work closely with the tester on their project. This allows me to better understand how they test. I am then able to probe and ask questions about their thought process and approach to testing on the specific project. These answers that the tester provides, gives me insights into where there are gaps in the training and what to focus on next, which will assist them.

Mentoring is a constant challenge but a very rewarding challenge at the end of the day.