Category Archives: Testing

Oct 26

Shifting to a team of Developers

Posted on by

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

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!

 

Jan 31

TestBashNY – 99 Second Talks

Posted on by

I had the opportunity to attend TestBashNY in early November 2015. I learned a lot, had a chance to catch up with old testing friends, and made some new ones. I also gave a 99 second talk!

Presenting in front of an audience is nothing new as I’ve regularly present, hold trainings and workshops at work, and present at MOIIST workshops, but this is the first time I’ve spoken in front of this many people at the Gramercy Theatre in New York.

I knew that one of the challenges in giving a 99 second talk was making sure I clearly delivered my message. When you’re prepared and have a message to deliver – those 99 seconds go quick! I took some time to prepare my points and to figure out how I was going to deliver my message that morning. I tweaked certain points of my talk throughout the day and then gave my 99 second talk.

Mark Tomlinson was awesome throughout the entire process, with the support, encouragement, and making sure was able to catch my flight back home by having me be the second presenter (I didn’t want to go first). I had to leave right after I gave my talk to make sure I was able to catch my flight back home.

You can see my talk and all the others below – I am the second presenter.

99 Second Talks at TestBashNY

 

Nov 30

TestBashNY – Part 1

Posted on by

 

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

Posted on by

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.

 

Mar 23

I Don’t Need Explicit Written Requirements to Test

Posted on by

I’ve been in Software Testing and Quality for almost 10 years now, and a disturbing trend I tend to hear every now and then, are individuals on the test team complaining and whining that they are unable to test because there aren’t any written requirements available.  I’ve seen these same individuals refuse to begin any testing effort (not even willing to launch the system) without having the written requirements in front of them, and waiting for somebody to produce these requirements before even launching the system, not realizing the valuable time they’ve just wasted, time that could have been used to test.  Of course, I believe a big part of this approach and expectation could be due to their uninformed belief of what software testing (and their job) really is – but more on that later.

Even before I practiced and got better at approaching situations where I was asked to test and told there were no written requirements, I believed in getting the information I needed in order to test.  In the last few years I’ve began referring to it as “information hunting”.  This information could be anything relevant to the situation at hand, from the manner in which to access the system under test, to who the end users of the system will be.

If I find myself in a situation where there are no written requirements, I am going to go “information hunting” to find out more about the project and testing situation I am in.  If I find myself in a situation where there are written requirements, I’ll be sure to read & analyze them and I will also go “information hunting”.  You see, there is SO MUCH more to software testing than just the requirements. I’ve seen many systems in the past, with tons of written requirements and numerous test cases mapped to each of the requirements, yet when I actually used the system myself and tested it – it was less than positive experience using the system and there were many problems present, despite of all those test cases that had been mapped to each of the requirements and “passed” by whomever was assigned to run the tests.

Now going back to what and how some people on test teams view their role and job – some people just don’t see software testing as anything more than validating the requirements – but that’s not software testing.  Software testing is about providing important information about the quality of the system under test.  One of the many things I’ve learned from Michael Bolton is that you don’t need explicit written requirements in order to launch a system and begin to question it, observe its behavior and learn about it – so that you’re to provide important information about the quality of the system you are testing.  This is such a huge part of Software Testing that I believe is missing on many software test teams – the understanding and appreciation of the skills required to be a valuable software tester, the use of the brain, and actually thinking while interacting with the system under test.

When I go “information hunting” I want to learn and get more information about the current test situation (every test situation is different) that I find myself in.  I carefully put together and analyze all of the information I am able to gather about the testing needs and the system, so that I can create and share my test approach with my managers and project stakeholders – and carry out good testing.

I like to find out the reasoning justifying the cost behind the development effort.  What are the information needs of my stakeholders for this specific test effort at this specific time?  What is the purpose of the system and what are the goals that the system is setting out to accomplish?  Who will be the end users of the system?  How will the users use the system?  Why will they use the system?  What will they use the system for?  When will they use it?   Who are the developers with whom I will be collaborating with and can/will they answer my questions about technical changes and possible impacts to consider in my test approach?  Who can I work with to discuss the risks?  Who can I work with to discuss security and performance expectations?  Which other systems and components will be impacted?  There is more information I may look to seek out depending on the specific situation and circumstances surrounding the system under test (for example test environments, remote team members, third-party involvement).

Using the information I hunt down, I am able to think about the system and how I am going to approach my assignment of testing it.  The answers to my “information hunting” questions have a direct impact of what I test and how.  I am always thinking when I test, while I observe my interactions with the system, and the behaviours I observe within it.

Within the past few years I have also studied and learned different test skills, the use of judgement, oracles, and heuristics and to incorporate them into my testing, in order to help me find and report important quality related information.

I don’t need explicit written requirements to start testing, nor do I heavily rely on them in order to do my job well and to be a valuable contributor to the team.

Jan 08

2014 – My Year in Review

Posted on by

2014…

So here we are, a few days into the new year – eight days to be exact.  I haven’t written in a while, it’s been almost six months!  I have been reading though, reading a lot, and that re-energizes my mind and puts me in the zone to write.  After the amazing, unreal, AWESOME year I had in 2013, I went into 2014 pumped and full of energy.  The first ever Montreal Insights Into Software Testing workshop & peer conference – MOIIST2014 was just around the corner, I had started a new job a few weeks earlier, and I had plans to continue my testing accomplishments and learning from where I left off.

In January, we held the first ever Montreal Insights Into Software Testing (MOIIST2014) workshop & peer conference.  I had put in a great deal of effort in the months leading up to the workshop to help organize it and it was well worth it.  The workshop was great – I did my first presentation at a Software Testing event and met some awesome Testers, both from Montreal and Testers who attended from out of town, not to mention the chance to hang out and chat with Rob and Scott.

Plans can and do sometimes change

I had a lot of other plans for 2014 – to continue on that great road of Software Testing awesomeness from 2013, and the MOIIST2014 workshop – but in life things happen and plans sometimes get postponed due to circumstances and priorities.  The first half of the year was exceptionally tough, but I was able to stay optimistic, make decisions I needed to make (which turned out to be great decisions) and I’m happy to say that the second half of the year was great!  But before things could change and get better, they got tough (and negative) and I ended up learning quite a bit from the experience.

What I learned

In one sentence – it’s never too early to leave a job if you’re unhappy.  I was hired by a Test Manager with whom I wanted to work and a great team of fellow Test Lead’s and Testers (in western Canada).  I was hired to work at the office just outside of Montreal. I never thought the distance and not being in the same office would present the types of issues and challenges that it did – none of us did.  When the individuals (especially the leadership group) at the local office where you’re hired to work do not want you there – no matter how great of a professional, tester, and person you are, no matter the things you do to make things work and change their perception – it won’t make a difference, you’re not wanted – period (that held true in my situation).  It’s 2014 and the world is as connected and collaborative as ever, but in some toxic environments (like the office environment and location I was in) you can’t stop negative, backwards thinking.  I don’t regret taking the opportunity, I learned a ton working with my fellow Testers out in western Canada but I do regret staying in such a hostile, discriminative environment for the duration I did stay (I stayed a few months but should have left in a few weeks).

Now even though the aforementioned experience was a negative one – I always look for lessons learned and I took away some really positive and important lessons that have made me more aware and knowledgeable.  I learned more about myself as a person and as a professional and experienced first-hand what I had always known, what I stood for, and what I believed in – that my self respect and dignity was more important than a paycheque (especially one coming from a toxic environment).

I learned that sometimes it’s worth taking that bold risk and leaving a negative situation without that safety net to fall into – which is what I did. I also learned that when interviewing for a job where your manager and/or team will be in another location, its extremely important to meet (in person) the individuals with whom you will work with locally in the same office, including the leadership group. It’s especially important to speak with those in the leadership group to get a feel for how they work, the environment and atmosphere they promote, how they view testing & their goals regarding development & testing and collaborating with the team(s) located in different offices/cities.  I would take the time to ask about their philosophy and if they are actually in-tune with the testing approach being taught and encouraged from the leadership group (the ones hiring you) in another location.  There’s a lot that can be learned by taking the time to do that, and may also help you make a good decision by listening to your gut feeling.

Getting back on track

Once I made the bold decision to leave with no safety net to fall into – everything (professionally and personally) started to change – I was happy, full of energy and things started getting back on track!  While I had a plan, I didn’t have another job lined up (and that can be a scary thing considering bills, house etc.) – but I had/have confidence, optimism, and my testing skill-set that I am always working on expanding. It was a bold risk I took and I’m happy I took it. Things fell quickly back into place and I enjoyed the second half of the year much more at my “new” job and was having fun outside of work, and was also able to focus my energy on learning more about software testing once again and doing the things I enjoyed doing.

Wait – what about those plans?

There were a few plans and goals I had for 2014 that I wasn’t able “execute” in my roller coaster of a year. After CAST2013 (after which I was so pumped up to attend the next CAST), I wasn’t able to attend CAST2014 as I had planned too.  I can’t get that back but I will be at CAST2015!  After successfully completing the BBST Foundations course in 2013 I had planned to take the BBST Bug Advocacy course but with everything going on and the course schedule, it just didn’t pan out.  On the plus side, I am going to take the course this year and I’m looking forward to the learning experience and challenge!

Ending off the year

I ended off the year happy, relaxed and reading a book on the beautiful beaches of Varadero, Cuba.  I feel refreshed, energized, and extremely focused (professionally and personally) starting off this new year.  While I still progressed as a Software Tester in 2014, it wasn’t the type of progress and “jump” I experienced in 2013 – which is okay.  I learned a lot of valuable lessons as a professional and as a human being from the negative situation I found myself in.  I learned to turn things around and that only I had the power to do so.  While I try not to live with regrets, if I could go back and do things a bit differently I would – but knowing that now, is a part of what learning is about.

KMF – 2015 here I come!

Jul 07

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

Posted on by

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

Posted on by

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.

Apr 29

Asking Questions – Almost 9 years later

Posted on by

I remember when I first started my career (and my life) as a Professional Software Tester almost 9 years ago now, and even back then I was a bit different from some of the other “new” Software Testers. Different in that I would ask questions about what I was being asked to test, to gain some sort of insight into the application I was being asked to test, and not just test aimlessly or without a purpose.

So now, almost 9 years later, I’m still asking questions, that hasn’t changed. What has changed are the types of questions I ask. The people I ask them to.  The confidence with which I ask them.  How I am able to ask better questions to learn more about the situation I am in.  Asking questions based on some of the answers I receive from my initial questions.  Not settling for answers that don’t give me the information I was looking for by asking the question.  I’ve also changed as a person, a professional, and as a software tester – I am more skilled, more confident, have tested a lot more complex systems, have questioned (and continue to) so much about testing, learned from some highly skilled testing professionals & leaders, taught myself by reading & listening, received training for software testing.  Many of these things I continue to do on a daily basis, because I am eager to become even better and because I am truly passionate about the craft & science of Software Testing.

Now I remember a few instances 9 years ago when I was in a room full of people and I would ask questions and other people in the room, smart people (developers, project managers, architects who were well known for their skill & knowledge in their respective areas) would make jokes about me asking all these questions, mock me for asking questions, tell me to stop asking questions, and just outright downplay testing.  At the time I had just started my career in Software Testing, I was a kid. I was intimidated, it distracted me when this happened, it bothered me and prevented me from having the courage to ask further questions about Testing.  I hadn’t yet built up my testing skill set and confidence.

I had completely forgotten about those specific situations until not too long ago I was in a room full of smart people discussing the development and testing for a project and it happened again. But this time it was a whole different situation.  Sure the comments and actions from some of the other people in the room were quite similar, but I wasn’t. It didn’t intimidate me one bit, nor distract me. It didn’t bother me and it didn’t prevent me from continuing to ask the questions I needed to ask in order to get the information that I believed to be relevant to testing.  I was able to effectively filter out and ignore the comments downplaying testing, and carry on to get the information I was looking for and listening for more information.

I’ve had a lot of fun putting in the work and effort into becoming a better, more skilled tester, and the manner in which I’ve evolved myself as a Software Tester sure did help – in a lot of different ways!