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 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.

Listen

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.