Nov 29

Working With Testing Partners

This article was originally written for the QA on Request blog and was first published here.

Working with the right testing partner is important, but working effectively and efficiently with that testing partner is just as important. It is how you’ll be able to make the most of the service being provided to you.

When working with external testing partners, keep in mind that the really good ones don’t just think of themselves as your “testing partners”; their actions should reflect it as well. They’ll regularly communicate important testing updates and results with you, and work with you to help you get the information you need. But it’s not all just on your testing partners, there are things that you can do as well to get the most value out of testing.

Additionally, when working with your test partners – each test request, information need, client, and situation is different – meaning that what you do and to what degree, to get the most out of testing, will vary.

Communicate your information needs

Clearly communicate what it is that you’re looking for from your testing partner for each of your test requests. What does this mean? Testing is an information providing service that is designed to provide you with quality related information about your product based on your needs. Are you interested in knowing about the bugs in your product so that you can focus on fixing them? Are you interested to know the state of your product so that you can make a good decision about releasing it to market? Do you want to know how your product stacks up to your competition? Do you want to know how your product will behave during daily business usage? It’s these questions that you have – your information needs, that testing will provide you with details about so that you can make good, informed decisions regarding your product. It’s also both possible and perfectly normal that at different times throughout the development of your product, your information needs will be different, so let your testing partners know what your needs from testing are at different times within your product development lifecycle.

Testing priorities

Good testing partners will work with you to prioritize areas of your product that you require information about. Take the time to work with your partners to prioritize features and areas that should be covered. Testing can be an infinite activity but budget isn’t – it’s to everybody’s advantage to focus on the highest priority areas first. Your priorities can change as well throughout the course of a longer test period.

In the case of test requests that last a longer, there may be types of important information and bugs that testing has uncovered that gives you an insight about your product that you didn’t have before. Consequently the focus of what you’d like your testing partners to work on can change as well – let them know in these cases.

High risk areas

A good tester and test team will consider what your product is, what it’s meant to do, who your user base is, and based on the answers to these questions, can begin to define the high risk areas of your application. Nonetheless, external testing partners are often not present in product development and status meetings and may not always have the most up to date business, industry, and market information as quickly as your internal team. Work with your testing partners to review high risk product areas, and to give them this insight so that they consider it in their test design.

Now perhaps you are aware that the development of the latest and newest features of your product, which you’ve asked your test partners to focus on, has likely resulted in some important and previously functional areas of your product to become unstable or nonfunctional. In this case, let your testing partners know about this now high risk area.

Platforms and devices

With the emergence and popularity of mobile devices, and the abundance of software platforms that users will expect your product to work on, and making decisions about which platforms and devices to test on have that much more significance.  Are there particular platforms and devices that you absolutely want covered during testing? Let your testing partner know. Are you interested in learning more about platform and device market share information so that you can make a good decision about which devices to cover during testing? Speak to your testing partner and let them work with you to help provide these statistics.

Features that aren’t ready to be tested

Software product development is a continuous task and a good development methodology will often incorporate testing efforts as part of the development activity. If testing in this scenario is being done by an external testing partner, keep them in the loop about what features are not yet ready to be tested, as the developers may still be working on them. This will save you the time of having to go through bugs that aren’t valid from your perspective, but may be valid from the tester’s perspective if they are not aware of features or dependent features that are not yet ready to be tested.

Specifications documents

Are there specific requirements, specifications, or user flows that are important to your business for which you have documentation? If yes, it will be a good idea to provide these details to your testing partners so that they can account for these scenarios and provide you with information and cases where they may not work as desired.

Do your specifications documents consist of hundreds of pages? Unless for some reason there is value to have your testing partners go through it all, give them the essentials they need to do their job well – which is to provide you with important information about your product so that you can make good decisions about how to proceed with it. After all, you’re paying for actual testing, not having your test partners read tons of pages that will have no value or impact on testing, and will only eat up your testing budget. Keep in mind, each situation is different so consider your needs and what works in each particular situation.

To wrap it up

These are a few tips you can apply to improve the working relationship you have with your testing partners so that you are able to get the most of your testing budget with the information that testing will uncover about your product. Your testing partner is not just there to find bugs in your product, they should be a valuable member and contributor to your team, and help you quickly find bugs and other important things that matter the most to you.

Aug 16

Interview Basics

During the past few years in some of my respective roles, I have been part of the hiring process. I’ve helped define the the companies needs for test roles, identified skills and experience we’re looking for, reviewed candidates’ profiles, interviewed potential candidates, and have spoken to their references.

I’ve had candidates who’ve come prepared and done well, and on the other end of the spectrum, I’ve had candidates who’ve came to the interview extremely unprepared wasting both my time and theirs. It shouldn’t come as a surprise that they didn’t do well or get the job. There are some basics to an interview that I would’ve thought to be obvious to everybody, but in my experience they aren’t. Below I’ve listed a few basics things that anybody interviewing for a job should come prepared for and with.

Research the company

This is so basic yet I’ve had some candidates who’ve come into the interview not knowing anything about what we do. If you’re answer to the commonly asked question “what do you know about us?” is “not much”, you’ve crossed yourself off the list of potential hires. For me personally, when somebody answers the question in that manner, the interview is over. It would take a lot for the person to catch my attention and interest, and make me want to hire them after answering like that – it hasn’t happened so far. Visit the company website, check out their Twitter account, their LinkedIn profile – find out what they do, what and who their business is, and what their clients are saying about them.

Know what’s on your resume

Numerous times now I’ve asked candidates regarding something specific from their resume, whether it be a tool or technology they’ve listed, an experience with a particular project, or some form of education they’ve listed, and they seem dumbfounded by my question and are unable to answer it. It’s important to be aware of what you’ve written in your resume, people read it and will want to know more.

Bring a portfolio

I’m always puzzled when somebody comes in for an interview completely empty handed as if they just strolled in for a casual chat. I highly suggest you bring a portfolio with the following: a pen, a paper to take notes, a copy of your resume, and anything else that may be relevant for the interview.

Ask questions and take notes

It’s important to come prepared with questions for things that matter to you. When a candidate doesn’t come prepared with any questions and doesn’t think of any during our discussion, it makes me wonder whether they are really interested in working at the company and being a successful part of it, or if the person is just looking for paycheque. You’ll be spending approximately one third of your day at the office with the team, five days a week – don’t you want to know more about the work you’ll be doing, how you’ll be doing it and whom you’ll be doing it with? Some of the questions may get answered at different points of the interview – so prepare more than just a few. Also take notes. There is a lot of information, topics, and details discussed during an interview and chances are you won’t remember them all. You’ll need these notes so that you can review them once the interview is done, and if you’re offered the job, there are things you’ll want to keep in mind and consider.

Dress well

As the saying goes “Dress for the job you want, not the job you have”. You don’t want to come in looking like you were just called into the office for a chat while taking an afternoon stroll. I won’t write much more about this as I feel that it’s a given (not to mention common sense).

Answer questions like a real human

What do I mean by this? There is a lot of information about the type of questions and how to answer them on the internet. There is nothing wrong with reading up on this in an effort to help you prepare. I actually encourage it, but don’t memorize and practice answering questions with “typical” or “standard” answers you read on the internet. I can’t speak for all interviewers, but I like to hear real answers from real humans based on their experiences, their knowledge, and their skills. I like honesty, and originality in responses – it makes for a much more interesting and informative discussion for both parties. Don’t tell the interviewer what you think they want to hear, tell them from your perspective and in your words what your answer to the question is and feel free to explain why.

Practice and learn about interviews

Read up on interviewing well, practice, understand the different types of questions that can be asked during an interview. It takes time and practice to become really good at being interviewed. You may not do great at every single interview as there are a lot of factors at play during an interview, only a handful of which you can control, but that doesn’t mean you won’t learn from each and every one and if the lessons you learn are applied well, it will only make you better. The more you learn and understand about interviews and questions, the better at them you will get. There is a lot of good information out there!


Jul 28

What I’ve Been Up To

It’s been a long while since I’ve posted anything. I’m still here, still doing some great work, and taking pride in what I do. I still love what I do, what I stand for, what I believe in, and of course this skilled craft we call Software Testing. A little bit below about where I’ve been and what I’ve been doing …

In November 2015 I had the opportunity to attend TestBash NY and had a chance to catch up with Matt Heusser. Now we didn’t just talk software and testing, but we had a nice chat about some of the most important things in our personal lives including family, our significant others, the gift of time time, and celebrations. I’ll never forget that chat and the advice Matt gave to me that day. One of the things he told me was that it was okay to step away from the testing world to focus on personal stuff and then balance it all out and to never forget or take for granted the people and things that are most important to us.

Now I’ve still been reading, staying up to date on the happenings in the testing and software world on twitter, and still doing some great testing at work. Matter of fact, I just finished up working on a project with a great software development team working alongside a fellow skilled and talented tester, and a strong team of individuals that filled out the different roles on our team. Great news is that I’ll be staying alongside many of the team members to work on our next project!

Throughout the past 10 months I’ve continued to experience a lot, learn a lot, and observe a lot of different things – I have a ton I’m going to be talking about in my upcoming posts.



Nov 30

TestBashNY – Part 1


TestBash NY

TestBash NY @ Gramercy Theatre

A few weeks ago I had a chance to attend a great two day Software Testing conference in New York City called TestBashNY! Why was it great? Well I got to learn tons, I gained more knowledge & skills to help me become an even better Software Test professional, I got to actively converse with some very smart, intellectual testing people, and I gained insights into a lot of content, and teachings to bring back to my team here in Montreal, as well for for myself. And if that wasn’t enough – I also got to  catch up with some old friends and make a few new ones!

Now before I continue, I would like to thank Richard Bradshaw for holding a contest to allow contestants a chance at a free ticket to the TestBashNY conference session. You see, I entered and was one the five winners. The contest was a classy act by Richard and offered a great chance to those interested to attend.

I would also like to thank my colleague and founder of the company where I currently work, Simon Papineau for investing in me to take the trip to New York, and giving me the opportunity to attend the tutorials as well as the conference session. I’ve bought back a great deal of information for our team here in Montreal.

The first day of the conference was the tutorial sessions. I registered for the Mobile Test Design tutorial instructed by JeanAnn Harrison which I attended in the morning, and in the afternoon I attended the Swimming with Sharks tutorial instructed by Martin Hynie and Anna Royzman.

Mobile Test Design

I registered for this tutorial as testing on mobile platforms is within the realm of testing that I do, and I always focus on and work at getting better at what I do, in addition to learning new and better ways to do what I do.

We spoke about how testing mobile applications is so much more than just the GUI, and how there are a lot more things going on in a mobile application that can be considered in test design, depending on what the application is, the type of application it is, and what it does.

We discussed a lot of great content in this tutorial, the questions and tips from the attendees gave me ideas to think about in the context of my own mobile tests. JeanAnn spoke about the different types of mobile applications out there including native apps, hybrid apps, mobile web apps, and mobile websites. Questions from the attendees helped us further break down how we can figure out within which category the applications we test fall under, and the types of applications that typically fall under certain categories. Determining and knowing the type of mobile application you are testing can really help you design effective tests, and prioritize them to help you gather important information for your stakeholders.

We actively discussed and brainstormed performance tests on native applications, hybrid applications and mobile web applications.

Towards the end of the tutorial, JeanAnn spoke about User Experience Tests and tips for designing these types of tests. There was a lot of content covered – so much that I’ve asked JeanAnn if she would be willing to share her slides from the tutorial (which she did), so that I can take some of the content introduced and learn more about it and build on it during my own time – which I look forward to doing!

Swimming with Sharks … Communication Tools for Testers

I registered for this tutorial as I am an advocate for effective collaboration and communication to help add value to your team. I’ve previously written and spoke on the subject, but the content I learned about in this tutorial will help me take my knowledge and collaboration skills even further as I take time to breakdown and study the tutorial, the exercises we did, their outcomes, and the lessons learned.

Martin and Anna used the Trading Zones metaphor to help create a visual communication framework for the group to consider and work within as part of our exercises. We worked in small groups of 3-4 people and using the framework shown to us, placed some of our real-life workplace relationships with people we work with at some level, within the framework in one of the four trading zones (Interlanguage, Fractionated, Enforced, Subversive). We discussed why the relationship was in the trading zone that we had put it in and sometimes discussing it with group members gave different perspectives of where that relationship really might be and ways to improve it, which in turn is a step in improving the collaboration level and communication within the team and/or workplace setting.

I learned about interactional expertise and how it applies to me as a Software Tester. I also learned about the Scarf Model, and how to think about it and begin to use it to better collaborate with others. These are two very interesting topics that were introduced to me that I’ve slowly started to learn more about and learning to better apply it in my own communication with others in my own communication and working relationship with others.

Roundup of the tutorials

There are so much more details, synergies, discussions, and hands on learning that took place in these tutorials, in addition to the actual content that was discussed, and taught – my post touches on the main topics of the tutorials, and some of the details around them . Both tutorials have taught me enough to take what I’ve learned and do the research to build on my knowledge and skill to apply my learning in my own situations.

Stay tuned for Part 2, where I’ll write about the second day – the talks!

Oct 27

Being a Good Teammate

As Software Testers we work with many different people in many different roles. Some of the roles the people we work with occupy can include other software testers, developers, software architects, product owners, project managers, database analysts, clients and many more depending on the context of the project and makeup of the project team. These individuals are often our teammates.

Throughout the years I’ve had teammates ranging from terrible to bad to good to truly great. It’s the truly great teammates that I remember and would like to work with again. The terrible and bad teammates exhibited behaviours and actions that I will never exhibit towards anybody (you can learn a lot from negative behaviours).

In my experience, a lot of the qualities of being a good teammate also apply to being a good professional. A lot of it is not doing and exhibiting certain types of behaviour, and not treating others in ways we wouldn’t want to be treated – which leads us into three short areas I’ll cover below.

Don’t bark commands

Regardless of your role and position within the team, nobody enjoys having commands barked to them. I’ve seen this in different companies, and people in general don’t enjoy being spoken to and treated in that manner. Most people don’t enjoy working with people who bark orders. Speak to teammates with respect, it doesn’t hurt to respectfully ask as opposed to barking orders. Being a leader and a good teammate doesn’t mean you have to bark orders to have an impact on your team – unless it’s negative impact you’re trying to achieve.


Listening just might be one of the least used communication skills in today’s society and within the workplace. I often see individuals prepared and ready to speak before the individual speaking has finished talking. It’s important for teammates to be able to express themselves and say what they are trying to say and for the audience to listen, hear, and consider what is being said. Listening and considering what our teammates are saying can also lead to better replies, discussions, and solutions which are beneficial to the entire team and project.

Work together and learn from each other

A big reason I remember the truly great teammates I’ve worked with is because of how we worked together, and learned from each other to deliver great work on the projects we contributed to. Working together on a project is not some type of internal competition (or shouldn’t be), it’s about working and collaborating with our teammates to help deliver great work together, using everybody’s skills, expertise, and contributions to help deliver a successful project. Learning from each other is not the same as quickly telling somebody how something works without considering whether they fully understood or not – it’s clearly explaining concepts that are important to the testing being done in the context of the project that end up benefiting the team as well as the stakeholders of the project. Working together and learning from each other involves the exchange of good ideas, building on these ideas, using the energy that comes from the collaboration, and incorporating in into our own specific tasks so that we can do them better.

There is a lot more to being a great teammate than the areas I’ve covered above. Different situations will enable us to be good and great teammates in different ways and exhibit different qualities .

Being a good teammate (and especially a great one) is one of the things that will leave a positive impression on those you work with and help them remember you as such. It’s also one of the things that can help you build a good reputation for yourself and be somebody that other’s will want to work with.


Feb 20

My Love for Computers and Software – Part 1

How it all started – Part 1

My love for computers and software began when I was 10 year old kid in elementary school.  At that time, the only students who had access to the computer lab were selected (and very intelligent) students in grade 6. I was a student in grade 4 at the time but I had a good friend who was in grade 6 and recognized as one of the smartest and intelligent students in the school – and of course he had access to the computer lab, even during lunch hour!

Finally after months of hearing how awesome computers were and what you could do with the software on them, my friend asked the teachers in charge of the computer lab if he could bring me to see the lab one day during lunch hour. I was a very well behaved student and so there wasn’t much hesitation from the teachers to allow me to come into the lab during a lunch hour one day, under one condition – I could see but not touch.  So the day finally came, I got to enter the computer lab and see 10-12 computers – I was told they were MacIntosh computers (I noticed an apple on each of the machines).  So I sat and watched my friend type things onto the keyboard and the computer execute the commands my friend was requesting. This was all so mind blowing to me!

After that lunch hour, it was 2 years later that I was a student in grade 6 and allowed back into the computer lab!  By that time computer class had become a part of the school curriculum. Finally I had the opportunity to be the pilot behind the keyboard, and type commands onto the keyboard and see a green turtle on screen execute the commands (I was using Apple’s logowriter programming language) I was typing. It was cool to watch it all happen 2 years before, and even cooler to be the individual behind the keyboard.

I was 12 years old at the time, and I had no idea how powerful and common computers & software would become in the years to follow and how much my interests (and life) would be tied to computers and software …

Jul 07

We Don’t Break Things – They’re Already Broken

Fellow Software Tester and President of the Association for Software Testing, Ben Yaroch posted a tweet earlier today (which I later re-tweeted) that highlighted something I’ve encountered a few times in my career – you can view his tweet here.

The content of the tweet and the picture that goes with it say it all.  This misconception, this misbelief, this misunderstanding – illustrated in the photo,  is something I’ve seen many professionals, some of whom are highly respected within the scope of the project requiring testing support, unknowingly fall victim too.

The Software Testing group (or QA group as it’s called in many companies) are not breaking the software we’re asked to test – us skilled testers (and I can’t speak for all of us) are discovering things in the software that we are assigned to test (often using specific skills relevant to testing such as heuristics) to help discover and identify problems in the software.

Now what happens, and what we Software Testers do once we’ve discovered things about the software – information about the quality of the software, can vary depending on the company, and even different projects within the same company.  What I mean by this is that at certain companies or projects, the Software Testers may have to spend a great deal of time and effort advocating for what we’ve discovered.  At other companies & projects the Software Testers may need to identify whom the “correct” stakeholders are, before these important pieces of information can eve be presented to them. Now the last statement can veer into at least two different posts, but for this post I’d like to remain on topic and to remind, or bring to the attention of stakeholders & active members of a given project (and those looking to learn more about me) that the goal, purpose and mission (yes this is a broad mission/statement) of testing is to find & provide information about the software – including things that are already broken that we discover while testing. Despite what people may believe, or have been led to believe … No, we don’t break things – they’re already broken.



May 31

My Recent Visit to a SQDG event in Calgary

I was recently in Calgary for a work related kick-off project.  Each day was filled with work related activities and each evening I found myself exploring the city with a great team member (also a Software Tester) of mine.  During my final evening in Calgary, I was able to attend the SQDG’s event on May 14.

I met one or two Software Testers whom I had previously met and was able to catch up and chat with them. I also met a lot of new, interested, and passionate Testers from Calgary. It was great being around these types of testers, great conversations, and awesome energy filled the location we gathered at.  From what I understand, the format for this particular event, titled Speed Geeking was slightly different than the format of most SQDG events.

We spent the first 30 minutes or so chatting amongst ourselves in an open, non-formal manner. I was introduced to many new faces, had some great conversations about testing and met some great individuals from PQA.  We then split into different groups (randomly assembled) and brainstormed our ideas and answers to a series of questions. We were free to move from one group to another for different questions which bought forth different views and perspectives and helped kick-off different types of discussions, different answers and people’s reasoning for them, often based on their own personal experiences.

I found it to be a good, fun, and engaging atmosphere to talk testing with Software Testers and those involved with the craft in some form.  If I am ever in Calgary at the same time as an another SQDG event, I’ll be sure to attend again.

Mar 27

Good News From Afar

A few weeks ago I received an email from a Business Analyst with whom I worked with on a project at a former workplace (which I left to pursue another opportunity).  He informed me that he and a few other BA’s at the company had been recounting some of the best Testers that had worked at the company and that my name had come up (it’s always nice to be mentioned in good company).

He went on to inform me that a portion of a particular project on which I worked (I was the Software Tester for that portion), along with him and a few other individuals was one that turned out to be very successful – the application (as well as the portion of it that I tested) was running smoothly in the production environment and the application users were very happy with it.

I kindly thanked him for sharing the good news, and told him that everybody’s contribution to the project is what made it successful and that it was important to keep that in mind, as quality is everybody’s responsibility.  My job, and responsibility as the Software Tester, was to test application as I did, and find good, valuable information about the quality of the application just as I did, so that the business stakeholders were able to use the information that I discovered and use it to make good business decisions about the application.

Happy to hear things have gone well so far.