Category Archives: Short Posts

Jul 22

Stand Behind Your Products And Services

Posted on by

I’ve been in the software business for 15 years. One of the things I’m most proud of is that I’ve always given every single project I’ve worked on my absolute best, most focused effort. I’m proud that I’m able to stand behind the work I do.

The best organizations I’ve worked at stand behind their products and services. The best people I’ve worked with, stand behind the quality of the work they put forth. People who care about their craft, like myself, always want to put forth the best work they can given the situation.

In software, we want our clients to be happy, and beyond satisfied with the solutions we deliver to them. I find that in the software world, this is more important than ever. There are so many products, services, and competitors out there, it’s that much more important for organizations to put forth their best work, and deliver the best solutions they can for their clients, and then stand behind those solutions.

As a consumer, I purchase things like most people do. I highly respect the shops that stand behind their products, the people and companies that stand behind the services they offer. These are the shops, people, and companies that I remember, like, and will purchase from again. I’ll recommend to friends, family, and neighbours and write great reviews for.

Making a sale is just the beginning, delivering a top notch quality product and/or service and being proud of it, and standing behind it – thats the win.

Dec 20

Be The Driving Force

Posted on by

It’s been two years since I’ve last written. That’s a long time! Time flies as they say. Things are good, both on the personal end of things and the professional end of things too. I’ve been busy producing great work, living, exploring, learning, enjoying time with the family. Spending time the way it should be spent.

The lack of posts definitely doesn’t mean I don’t have lots of share and write about – because I do. I’ve been keeping notes about topics I want to write about, so I will post about those topics sometime. Maybe even sometime soon.

In the beautiful world of software, I see a lot of people be placed in charge of huge projects and initiatives and I see so many of them not have the impact they should have had. They lack the fuel, the passion, the fire. The person heading up the initiative just doesn’t have the driving force to produce the fuel, the passion, the fire that these initiatives deeply need. They’re in it, but they’re not. You may recognize what I mean by this. They’re in it, but they don’t want to get their hands too dirty – maybe just a little bit. They kind of want to get things started and rolling, but then might expect other people tasked to help on the initiative to get their hands dirty, while their’s are clean. People are smart (not everybody, but we should give credit where it’s due). They pick up on these things.

Initiatives work and have powerful impact when the person heading up the initiative is not just willing, but is actually getting their hands dirty. Is out there getting things rolling, being involved, and getting things done well. People can sense that. They see it. They feel it. It serves as a great motivator for everybody tasked on the initiative. It sets an example. It sets the tone.

If you want an initiative that you’re in charge of to be great, to have a real impact, to have life and soul, and make a difference, first and foremost you have to be the driving force behind it. I’ve seen these things fail many times. I’ve seen them realize great success other times. There are many reasons behind the end result. One of them is how much of a driving force the person in charge of the initiative is. Obviously there are many facets around being a productive and influential driving force – but that’s not what I’m covering in this post.

There are often huge budgets set out for these initiatives. They’re needed business-wise for many different reasons. If you find yourself put in charge of something like this, bring your A game. You’ll be remembered for it. Do something great and leave your footprint behind. Be the driving force.

Dec 12

Our VR project won an award

Posted on by

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

Posted on by

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 doesn’t 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 test 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 information about the test coverage (among other things) so that the decision makers can make well informed 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 testers in a situation where they can do great work and help the team deliver great products. Avoid restricting 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

Posted on by

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

Posted on by

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.

Learning

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.

Sharing

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.

Enjoying

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 07

How We Deliver Information Matters

Posted on by

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!

 

 

Aug 16

Interview Basics

Posted on by

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

Posted on by

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.