Dec 30

Twenty Seventeen – Year In Review

It’s that time of year again – when I sit down, think back, and write about the year that’s coming to an end and look towards the year that’s about to begin. Twenty Seventeen was an interesting year to say the least, with both good and not so good times like most years, but the good absolutely outshines the not so good. The things I’ve learned, the application of that learning, professional & personal growth, personal health & fitness all continued to improve this year.

New Technology

This year, my team and I started working on and testing the company’s VR projects! It was a fun and exciting time for both the team and the company. To kick off the year, I spent time researching VR – the applications out there, the technology, the development platforms, the capabilities, the equipment, and what people in VR were writing and blogging about.  This, combined with examining each specific project’s context, helped us come up with an effective test approach for our VR projects. For the first retail VR project of the year, we presented our test approach and objectives to the project management and stakeholders, worked very closely with the project manager, our developers, and the UX team. So much of retail VR is visual and performance related, and a lot of it boils down to having a good user experience. We learned a lot working side by side with the UX team and our developers during our pair testing sessions – lessons that we took into account testing other VR applications during the year.

While VR is a different technology compared to the other types of software systems we test – there are aspects, test-wise that remain intact (we are looking for important quality related information about the VR application), there are also differences (how we are going to get that information). That being said, and something most skilled tester’s already know – every software system, and the situation surrounding the project is different, which impacts (or should) the approach to testing it.

We got more familiar with Unity, we were able to check out code and test difference branches as needed. The VR applications we tested were all developed for the HTC Vive, and a few for the Samsung Gear VR.

One of our VR projects ended up winning an award. You can read more about that here.

Building up my team

I hired another software tester to the team. Both myself and the VP of Technology were looking for something specific – a skilled tester with critical thinking skills, good technical skills, with a great attitude (amongst other things). After numerous interviews – we found the person!

We work in a very fast-paced environment, often with very little or no documents outlining specifications and requirements. We often need to go and seek out that information, assess priorities and risks with the PM’s, design effect tests, and carry out our tests. I am working with project management to test early and often, as part of development.

For us to be able to do good work, and good testing in our agency setting, I do different types of trainings with my team. Things ranging from mind map training, exploratory testing, test prioritization, risk assessment, test coverage, bug reporting, test reporting to name a few.

I also like to help each individual on my team improve. Every individual is different in the way they learn, in the way they like feedback to improve, how they improve, and what their goals are. I work with my team to help them improve in the areas that are important for our team to provide great service + area’s that are important to them. I think about and work with the team to help them achieve their goals. It requires creativity, and thought, but it’s fun and I get to learn a lot!

Personal health and fitness

I started biking/cycling again three years ago. This year I took it to a whole new level – I cycled for a total of 623 KMs this year! My longest rides were a 60KM ride and a 50KM ride – plus tons of other shorter distance rides. Many times during the summer, I cycled to and from work. I absolutely love cycling and it’s done wonders for my cardio and overall fitness.

I’ve also continued working out at the gym. My workout’s changed a bit this year, with more focus on cardio as well as core strengthening exercises. There are a lot of difficult and extremely challenging exercises that do not require weights which made me much stronger.

I also picked up swimming this year. I thought my cardio was great with all the cycling I did, but swimming is a entirely different type of cardio. I had a lot of fun with it.

I played badminton this year for the first time since my college days. It was still very fun and yes I am still very competitive (just ask my wife 🙂 )

BBST Bug Advocacy

I successfully completed the BBST Foundations 2.0 course a few years ago and have been looking at taking the BBST Bug Advocacy course for the past two years but with the course only being offered twice a year, the timing never worked out with some personal events and engagements on my end. Well, that’s about to change because I’ve registered for the course in 2018! I am looking forward to this and have been for quite some time now.

Gearing up for Twenty Eighteen

As this year comes to a close, I am looking towards next year. As mentioned, BBST Bug Advocacy is high on my list of things to look forward to in the upcoming year. I’ve started taking a look at Richard Bradshaw’s course on programming, java, and selenium this year and look forward to completing it in Twenty Eighteen.

A few days from now, on January 4th I’ve enrolled in a webinar by Cem Kaner: An Introduction to Domain Testing. I find myself curious to learn more about the course and domain testing.

I look forward to continuing to build up our test team at work, with new people, new trainings, new projects, and doing even more exceptional work. We have some new thing’s we’ll be implementing this upcoming year which I will be blogging about.

I really enjoy reading books and although I did read a few this year,  I’d like to get in more books in the upcoming year. There are a lot of books on my list on both the software front and the self improvement front that I will be reading.

I will be continuing having fun cycling, swimming, working out, and some badminton.

Last but not least, I look forward to continuing my journey exploring & travelling, enjoying great conversation & delicious food with the wife, great friends and family, and spending time enjoying life!

Dec 12

Our VR project won an award

I had the opportunity to work on a very fun, and engaging retail VR project at Valtech Canada this year, the retail VR software application for Decathlon. The version we worked on this year is the second version of the application.

The Decathlon VR application recently won an award at the 2017 Boomerang show held in Montreal, Quebec, Canada – The Grand Prix for Interactive Retail Environment for our Decathlon Virtual Reality “Camp de Base”.

You can find more information about the show here, and the article about the award we won over here.

It was a proud moment for our team, to be recognized for our great work on this application.

As the test lead on this project, I worked on the application from the very start, understanding the context and then building a test approach suitable for this type of application and with the client’s objectives for this solution in mind. My responsibility also extended to hands-on test design and testing with the team.  The timeline for delivery was extremely aggressive, but we had a great team in place, from my test team, the developers, the UX team, the project manager, and every single person that worked with us to help deliver this application.

The Decathlon VR application allows users to gear up with the technology of the HTC Vive to view and interact in a 3D world and compare tents, prices, items in three different camping environments and different weather conditions. It’s currently deployed in 14 stores, 3 countries, and 6 languages.

Nov 08

Adding good testers is a start but there’s a lot more

There are many factors that go into the quality of what you end up delivering to your customers. Good testing (and making informed decisions from it) is just one of them. The members on the team, the commitment to do great work, the environment for people to do top notch work, the architecture the system is built on, the development, the project management, the decision making, communication, collaboration, system testability, the situation you put your team in to succeed (or not succeed) – the list can go on and on.

Adding good software test people to your team is a great start if you’re looking to improve the testing on your team, within your company, and are interested in having your software development teams deliver great work. However, it does not automatically improve your quality or testing situation.

Good testers, just like the other people on your team and in your company, need to be put in situations where they can do great work and succeed. One of the many things a good tester will do and understands, is that time and budget is always limited, but the amount of things to testing isn’t. They will focus on doing the best testing, the most important testing possible in the time available, in the current situation, and present their stakeholders with a report about their testing which will include problems, risk factors, and about the test coverage (among other things) so that the decision makers can make informed business decisions.

But when you find yourself constantly saying “we don’t have the time to test much” or “we don’t have the budget to go that deep into testing”, what you’re really saying is “we don’t have the time or budget to properly evaluate our product” which is a quote I got from Michael Bolton. When you ask your testers to just quickly check that something is working, just to confirm that a function works as it’s supposed to and go no further – it’s important to understand that there isn’t much value to that – and most good testers will tell you that.

Having good software test people on your team is a great start, but it’s not automatically going to improve the testing being done. You need to put them in a situation where they can do great work and help the team deliver great products, and not restrict them in ways that impact the value of what they’re actually delivering to you in terms of information about the quality of the product under test. Don’t falsely convince yourself that just because there was some testing done, it was enough, or that it was good, or that it automatically increased the quality of what you’re going to deliver.

“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” – Steve Jobs


Oct 04

Document complex test setup information

Testing systems which require complex and time consuming setup on the backend, initializing parameters, setting system conditions and flags, and using test tools can be challenging and fun, but often as testers we usually have a lot to cover and want to spend the majority of our time testing – which is what we should be doing.

Often in the chaos, we’re learning how and where to set up variables, conditions, flags, tools etc. to enable us to test our conditions and scenarios and observe what’s happening with the software we’re testing, while recording the results of our tests. During all of this, we often forgot to document and take note of the specific and complex setup required to test.

Sure we may remember how to set things up tomorrow, or the day after, but chances are, with the amount of things we’re testing, and the different types of test’s we’re doing, we wont remember them for long.

It may seem like there’s just not enough time to document complex test setup information, but taking some time to do so in whichever medium your project, team, or company uses, will save you and others on your team a lot of time and effort when it’s time to revisit the features. Take those fifteen minutes, you’ll be glad you did.

Jan 31

Team Workshops

During the past few years, I’ve organized, held, and participated in quite a few test team workshops to help build and evolve test skills and practices with the different teams I’ve been a part of.

When putting together a workshop, I like to consider my audience, their familiarity is on the topic, how I’ll present the topic, how I’ll engage the participants, how it can help them, and what I’d like the team to take away from the workshop. Taking the aforementioned into consideration, I’ll start putting the workshop together.

I am an advocate of highly participatory workshops where everybody is actively involved and where we all learn from each other. I believe it’s people’s interest, curiously, and their own test and project situations that often brings forth the most intriguing questions, thoughts, and comments – all which fuel the energy in the room.


I believe there’s a lot of learning that can be had listening to presentations and talks from some people. Some of these people deliver information so well, you’re often at the edge of your seat. The things you can learn from listening to a talk can go a long way.

I also believe that a great way to learn test skills in a workshop setting is by actually applying and practicing the skill as part of the workshop, with the rest of the team and participating. It’s a great way to learn, to brainstorm with others, to practice, to put your ideas into your work and then build on them while learning from others. In short, we’re learning by actually doing.


I also enjoy having everybody, or every team share the results of their respective tasks during the workshop. It gives everybody a chance to show what they’ve done, how, what thought process they used and for them to explain it and allow their peers to ask questions. It enables their peers to learn alternative ways, or additional ways a task could have been approached, and build on what they’ve put together.


What’s the point of taking time away during a busy work day to attend a team workshop if you’re not going to learn and enjoy it? I find workshops are usually as great as the participants make it – especially in an open, active environment where everybody participates and learns together. Generally speaking, when people are invited to workshops and they get to actively learn, get involved, present, brainstorm and work on tasks together – they enjoy the experience, use some of the skills from the workshop in the context of their own projects, and want to attend more workshops!

Dec 31

2016 – Year in Review

Another year gone by and I’m glad to say that it’s been another great year of learning, overcoming challenges, achieving many goals, and doing some great, challenging, purposeful work. Sure just like every year, there were tough days, but even those days offer things to learn from. It’s been a very rewarding year on the testing side of things. I continue to work hard, and be the honest, transparent, ethical professional I take great pride in being. I continue to read, write, engage in productive conversations with some very smart and awesome people. On the blog front, I didn’t write as much as I would’ve liked to, but that wasn’t due to less learning happening, but rather me celebrating and being occupied by things on the personal end of things.

Technical side of things

This year I started worked with XCode, and different SDK’s to help test and deliver mobile applications for iOS and Android platforms. I also started working again with the command line after not using it much for the past few years. I got to see more C++ code, see and understand some Python code, understand Git a little better, fetch code commits to build iOS and Android applications locally. I also learned different ways to build applications pointing to mock servers running on my machine and how to mock different data that the application uses to allow me to test different scenarios and situations. I made better use of different tools such as Charles, Wireshark, iOS Console, DDMS, and others to help me test the integration of the different components and services that our applications use. I had the opportunity to test analytics, which enhanced my knowledge of analytics as I got to work with and test different services including Google, Adobe, and Apteligent. I continued to work on some very technical things that required me to do some research and learn more about the technology that I was testing. I continued to figure stuff out – and had fun while doing so.

Testing and leadership side of things

I am a very hands on Test Lead, and I work very closely with developers as part of an Agile team – it’s something I enjoy and look for in a workplace. I’m very glad I have it. I also lead, coach, and mentor a small group of software testers. This year I’ve done more workshops for my teams than any other year. My workshops this year covered many topics including mind maps, different ways a mind maps can be put together, test coverage, test reporting, exploratory testing, and testing missions. My workshop style is very engaging, and highly participatory for the attendees. I like everybody to be involved, to participate, and contribute – the goal is for active learning to take place. I always considered my audience when giving any workshop or training, and I’ve learned that different people have different learning styles and will learn at different paces – that is okay.

As part of my coaching duties, I also see that different members of my team learn in different ways, and that as a coach, its important for me to tailor my techniques to help different members for my team learn and improve how they’re doing things. I’m doing a lot of teaching, but I’m also getting to learn a lot while doing it. And most importantly, I am enjoying it – working with a small team of testers willing and able to learn is a big responsibility but a rewarding one as well. My job in leading the team is to help each member of my team learn, reach their goals, and become a better tester, and work together to help the team become better, more skilled, and better suited to add more value in different ways as a well-oiled test team.

2017 …

So with 2017 right around the corner, I want to continue doing great work, enhancing my technical knowledge both on the mobile and automation front, being an even better leader for the team and helping them reach new heights. I will try to blog more than I did last year – I have so much to write about! I also plan on getting more involved on the VR side of things, and may tweet and write some stuff about testing VR. I would like to attend CAST2017, so I’ll work on making that happen. I may finally enrol in the BBST Bug Advocacy course. With the course being offered twice during the year, my schedule the past few years hasn’t allowed me to do so yet. And most importantly, I’ll continue to have fun doing what I love to do.


Dec 07

How We Deliver Information Matters

I work in the software business – a lot of you reading this probably do as well. I help test, develop, and deliver software applications – and a whole lot of stuff in between. As I always tell my team, other teams, and stakeholders at my company – my team of Software Testers (me included) are information service providers.

To quote Michael Bolton – we provide quality related information to our stakeholders.

I deliver information in numerous ways – in test reports, bugs reports, emails, meetings, stand ups, slack, video calls – you name it.  Note: Now keep in mind, I deliver different types of information via different means – for example I don’t report bugs in Slack.

Many years ago I realized that how I deliver testing related information really does matter! It matters in terms of how it’s received, by whom, and what types of action is taken on it. How I write something, the wording I use, and the language I use matters. How I say something, the tone I use, and the body language I show matters.

Now imagine you’re looking to buy something that you’ll use in your home, you do your research, and finally come to a decision about the item you’ll spend your hard earned money to purchase. You’ve done your homework and are convinced that this item is absolutely amazing. You place an order and a few days later your item is delivered – but the box that arrives is wet, torn, dented and in terrible shape. You open the box and find a set of instructions about your item – but the instructions are poorly written, making it incredibly difficult to understand. Furthermore your item is wrapped in plastic that is hard to remove and after all that unwrapping, you find the item has some scratches on it. Sure the item itself may still be the amazing product you had ordered a few days earlier but lets face it – you’d probably be extremely disappointed considering it’s condition and how it was delivered.

How you report bugs – what you write, the information it contains, how you write it matters. The same goes for test reports, crash logs, information logs and how you deliver this information.

If you’re the person paying for something, whether it be a product or service – how it’s delivered will matter to you and will play a big factor in determining whether you’ll want to continue paying for it. If it’s delivered and looks sloppy, rushed, and inconsistent, chances are you won’t continue using and paying for it. On the other hand, if its clean, consistent, and you can see that time and effort was taken to deliver a quality service or product to you – you’ll likely be happy and will continue your using it.

It’s something to consider when determining good practices on how you expect yourself and your team to write bug reports, test reports, provide updates at stand ups, and other status meetings.

That being said, write and advocate for bugs well, put in time and effort into how you’re presenting your test reports, status, findings, and quality related information to your audience – because it matters and can go a long way. Eventually it will become a habit – a good habit!



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.

Oct 26

Shifting to a team of Developers

This article was originally written for Testing Circus magazine and was first published on page 29 in the September 2014 edition and can also be found here.

A few years into my career as a Professional Software Tester, I had been working at a company with some great people in a nice, outgoing, dynamic environment as a software tester on the test team – a team of about 6 people. I enjoyed what I did and even back then, I was a tester who was always looking to learn new things and make myself a better, more skilled tester. One day, my manager at the time approached me about an opportunity he had recommended me for – it was an opportunity to be a part of the Research & Development team at the company as the software tester. I had built a good reputation on the team I had started on and amongst some of the other teams and individuals at the company. He also believed that I needed a new challenge at the company, and I believed that as well. As it turned out, it was an excellent challenge for me. He mentioned that I would be learning a lot, things that would really enhance my technical knowledge as a software tester and that it would only help my career, an assessment I agreed with as well. I took a few days to think it over, after which I made the decision to accept the opportunity to join the R&D team. At the time I knew it was a decision that would eventually be great for my career and towards my goal be being a better, more technical, and a more skilled tester. Little did I know then what I know now, that my decision to join the team would have a tremendous positive impact on my career as a professional software tester. I was under a lot of pressure (most of it from myself), and the learning curve I faced was steep. Things didn’t go smoothly right off the bat, it was actually quite rough in the beginning, but as I continuously put in the work and effort, things got smoother and from there, things went great.

Joining a team of Developers

They were now my team & I was a part of theirs. Now for the first time in my career, I was a member of a team with no other software testers on it. Instead, the members of my team were primarily composed of developers, a scrum master, and a product owner (we worked within an Agile Scrum software development framework). This was a big adjustment for me. I had never worked on a team surrounded by people who weren’t software testers. I no longer had a test manager (or a test coordinator) presenting my test results and findings to stakeholders, I was doing it myself. On the same account, if a development manager or lead wasn’t in favour of information I had found, I no longer had a test manager to “shield” me in this type of situation. The “safety net” of being around and on a team full of testers, was gone. This was one of the best things to happen, it allowed me to grow as a tester and as a professional. There was a lot more responsibility on my plate now, but I saw it as a lot more opportunity.

I wanted to show & prove to them that I was there to make them look good. The developers I was now working with, my new team members, had never directly worked with me before. It seemed that they weren’t yet sure if I was going to be an obstacle for them or if I was going to contribute to the team. I wasn’t there to cause chaos for the developers, nor to waste their time having them read through tons of bug reports I had logged into the bug tracking tool. I wasn’t there to point out and glorify bugs I discovered due to coding. I wasn’t there to slow things down or get in the way of deadlines. I was there to make them look good – but it wasn’t enough for me to just say that to myself, or even say it to them. I had to show them and prove it to them. Over the course of a few months (and tons of work and effort) I did, but it took a lot time and a lot of learning.

Worked with them, and took the time to learn

I showed them that not only was I willing to work with them, but that I genuinely wanted to work with them and that I wanted to learn. I had a lot of energy and was really up to that task and I wanted them to see that. I spoke to the technical lead on the team and got his feedback about how I could approach the different developers and how I could become a valuable and contributing member of the team. He offered his insights, after which I thought about his recommendations and how I was going to go about putting my plan into action.

I wanted to learn more about the different components that made up the system that the team built from the ground up and continued to do development & testing work on. I asked the developers questions about the different components and how they were all integrated together, the data and information flows, and in which ways they were independent from and dependent on each other. When the developers took time to explain these things to me, I always made sure to take notes. I informed them that I would be taking notes so that I could review them later to better understand and so that I wouldn’t need to ask them the same questions again. I made it a point to review the notes towards the end of the day, or even on my way home which sometimes prompted me to ask further clarifying questions. One thing I found extremely useful when they explained things to me using the whiteboard, was to draw out the diagrams of components, flows, and business logic, and other important information. I always made sure to re-draw the contents of the whiteboard or even take a picture of it. This was one of the most useful techniques that helped me the most when I first joined the team, to be able to understand the technicalities and interactions between the different system components. It enabled me to ask better questions about the implications and risks of the development work being done. I was able to think of potential problems or things nobody had yet thought of within the system when discussing the development & testing efforts of new features. I was able to design my tests better, and do more effective testing because of the knowledge I obtained regarding the components, and the information and data flows between them. As a result, I was able to focus my testing and coverage, which enabled me to provide more valuable information from the testing I was doing, in the available time I had to test.

A lot of times when I was providing information about the behaviours I was seeing during my testing, the developers would access the linux server to check system and error logs to get more information on what was happening. I took a lot interest in this as I was curious and wanted to see how they were further investigating what I was telling them from my testing. One day, one of the developers asked me if I had an SSH client on my machine and the accesses to log into the server myself. I was able to install an SSH client and get information on the accesses and permissions I would need to log into the server. Once I had what I needed, the developer took some time and explained the directory structures to me, and where some of the logs and files were located. They showed me commands I could use and how to use specific search commands to follow, and apply filters on for specific keywords I was looking for within the log files. I wrote down the directory structures, and the different linux commands they were using. It took me some time to get more comfortable navigating the different directories and using the different commands, but as I used them more regularly, and was able to find the information I was looking for, logging into the server to further investigate during testing, become one of my favourite skills to use from my arsenal. I was able to quickly and better investigate the causes of some of the behaviours I was seeing, and provide this detailed level of information back to the developers, who in turn were able to use the detailed information and quickly correct pieces of the code, or components where the problems originated from. The understanding of the linux server logs, in the context of our system allowed me to further investigate during testing and allowed the developers to focus on their development and less time investigating causes of some bugs and troubleshooting abnormal behaviours.

Pair Testing

My team and I worked in an open space concept, and in an open communication style atmosphere. As the developers and I got to know each other better, and got to know each others working styles better, they occasionally asked me to log into their local machines so that we could do some testing on new development items or bug fixes before they would commit their code and deploy to our development and test environments. I enjoyed this activity, it allowed for quick feedback and also saved us time instead of having to deploy, test, fix, re-deploy and test again later.

Other times, while testing and continuously providing quick, regular feedback (this was how we worked) the developers would come over to my desk, and we would test new features, existing features, and potentially impacted features together. This allowed us to look at the application or features we were testing from different perspectives and helped us identify and find bugs or the particular types of information we were looking for depending on our testing focus at the time. It was also fun and productive as one persons thought process often led to great test ideas from the other.

There was one developer in particular whom I tested with, at his machine without the use of any UI or tool, but rather by looking at his code. This was actually one of his ideas (an awesome idea), and it allowed me to contribute to the development efforts in an entirely new way. We would chat about what the code was meant to do and for which feature we were developing and testing, and we would go through the different code statements, conditions and branches and work together to think about which logic was covered, where and which cases were accounted for in the code, and work together to brainstorm and identify cases which possibly were not covered. This was an entirely new way for me (at the time) to be able to use my testing mindset and perspective to work together with a developer.

How I said things

Early on in my career, I often saw some (a small number) software testers approaching and informing developers that they had found some bugs in the application, in a tone and with a facial expression reminiscent of a smirk, as if they were bragging and shoving the fact that they found bugs due to coding, in the face of developers. I never quite understood this, nor grasped the concept. Furthermore, I remember seeing the faces and reactions of the developers and understood the animosity between developers and testers in some companies on some teams. I knew just from witnessing this, that I never wanted to be one of these testers (and for the record, the vast majority of the testers IĘĽve worked with did not do this). I paid extra attention to the words I used, how I used them, and the tone in which I used them.

I never walked up to any of the developers with a smirk on my face and said something along the lines of “Hey IĘĽve found some bugs in the application and broke your code”. I respected software and developers way too much. I considered the working and communication style on our team (open communication with a focus on quick and regular feedback) so that when I found bugs or something not working “correctly” I would always try to find as much information I could supporting the behaviour I was seeing regarding the bug and its extent. I made it a point to always tell the developers I was working with, in an informal way, and offering for them to come take a look at my observations at my machine. Depending on what the behaviour was that I was observing, and in which component it was likely taking place in, I often asked the developers if they had committed and deployed the code for that specific component or feature yet. I also learned the check in, check out and deployment process and system we used, therefore I would also go check myself at times. The point was, I was always communicating in an open manner and in a non-threatening tone. I focused on communicating in a helpful manner, for example, “Hey can we look into this a little further because something doesn’t seem right”.

I also learned when to bring things up. We worked in an Agile Scrum development framework, therefore I made sure I was always explicit (yet respectful) in my updates. If there was an issue I had discovered that would require some additional time (more time than usual) for the developer to come to my machine so that I could show them my findings, along with supporting information from my investigation, I would mention it in the morning stand up and ask a timeframe in the day that we (together) could look into it further. I think this showed the team that I wasn’t just finding bugs, reporting them and cleaning my hands of them – but that I wanted take the time to show them, and work with them to resolve them. If there was a discussion I had with a developer the previous day, and I was still unsure of the outcome of the discussion because it still somewhat contradicted my understanding, I would bring it up at the morning stand up (so that it could be brought to the attention of the correct people to be taken offline). I would explain my initial understanding and where the contradiction still remained based on what was discussed. This helped with transparency and for the whole team to chime in, and open up the discussion to determine if we were indeed all on the same page with the same understanding. In some cases we discovered that understanding on some things weren’t completely unanimous. Most importantly, it didn’t attempt to put anybody on blast. The approach I used in my communication with the team helped me become a welcome member of the team, and be recognized as contributing member and team player.

Got to know them

Just as I was extremely passionate about Software Testing and was always looking to enhance my skills, the developers on my team were equally passionate about Development. Over time, the understanding of being truly passionate about oneĘĽs craft allowed us to have an even better understanding and respect for what the other did.

What they believed in and practiced as Developers

Some of the things I spoke about to the developers on my team were their backgrounds as developers, where their interest in software and development stemmed from, how they got started and what they believed in and practiced as professional developers. It was interesting to hear the types of systems that they had helped develop before they had started working at the company we worked at, what types of industries they had worked in, what coding related work they did on their own time, and how they were increasing their knowledge and skill level. I had numerous discussions with them about their thoughts on information technology and software, this made for great and very insightful conversations. What made the conversations even more interesting was the fact that my discussions with each of the developers was different with each individual given the fact that their interests, backgrounds, coding they did outside of work were unique. Over time this led to a friendship between myself and each of the developers, unique friendships (that exist to this day even though we donĘĽt work together anymore).

Going out for lunches

From time to time I also went out to lunch with the developers on my team, often on a one to one basis. This allowed us to informally chat about the projects, the user stories and features we were working on, different partners we were working with and how that was going, as well as technical implications and decisions. This gave us a chance to brainstorm about the aforementioned topics and get into deep discussions about them. If the lunch was with the technical leads on the team, they always made sure to ask about my feedback for testing matters, and again that led to great informal discussions regarding testing matters in the context of our team. Over time working with the team, and the manner in which I did, focusing on integrating myself as a valuable and contributing member of the team and taking the time to get to know the developers, helped me build credibility (within the team) and build a great trust level amongst the members of the team – all of which helped us run like a well oiled machine and at the same time, having fun learning from each other and working together.

Final Thoughts

As I mentioned at the beginning of this article, I knew this would be a great opportunity for me to accept, but little did I know how great the opportunity would actually turn out to be, considering the amazing impact it ended up having for me as a professional and as a software tester. The things I learned, both on the technical and software side, as well engaging with and working on a team with individuals who were not just software testers, was superb. The experience was invaluable – to this day one of the greatest work experiences of my career so far.

I have worked at different companies, and on different projects with different teams and different developers under different conditions. At my current place of employment, I work very closely on projects with both software testers and developers, and have a great working rapport with both my fellow software testers and with the developers. I use many of the things I learned and applied in my experiences, on a daily basis, and encourage other testers on my team to do the same (I try to tell different testers in different ways as everybody has their own style). At my current place of employment the efforts have led to a cooperative, productive, and fun working environment. My efforts have also been recognized by others. IĘĽve been told by my managers that the developers on the projects I work on enjoy working with me, given my testing skill, and how I engage them throughout the projects we work on together.

Working well with talented teams composed of individuals in different roles, focused on different activities is extremely important as companies are slowly starting to realize that testing isnĘĽt something that should be done alone, or after development is complete, but rather that testing is actually an important and valuable activity that goes hand in hand with development. As this becomes more common, it will be important for software testers to evolve and learn to enhance their skills and how they work with other members of the team – and I donĘĽt mean just other software testers.

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!