Category Archives: Testing

Good News From Afar

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

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

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

Happy to hear things have gone well so far.

MOIIST2014

Two weekends ago the first ever MOIIST (MOntreal Insights Into Software Testing) peer conference & workshop took place in my hometown of Montreal, Canada.  Based on the energy in the room, my observations, and the passionate & positive feedback I received from the participants – I’m happy to say that it was a success!

Rob Sabourin, Stephanie Ripeau, and myself worked together to help organize the workshop, getting together throughout the year to help put the bits and pieces together.  I put in a good amount of time and effort (as did Rob and Stephanie) and we really had an interest in not only seeing the workshop take place, but having the workshop generate interest and attract intelligent, passionate Software Testers – which I’m happy to say it did!

A few of us got together on the eve of the workshop (Friday evening) to chat and have a bite. It was nice to meet some new Tester’s whom I’ve never met before, as well as catch up and chat with the Testers I had met before.

The official workshop took place Saturday and Sunday.  MOIIST2014 was facilitated (as will future iterations ) in the style of LAWST workshops.  We had Scott Barber join us from Florida to help facilitate the workshop. Now if you’ve never seen Scott facilitate, or been in a room with Scott facilitating, I’ll say this – he’s an awesome facilitator!  There were 12 of us in the room who took part in the workshop.  We had participants join us from out of town (Calgary and Portland, plus Scott from Florida) as well as participants from in and around the Montreal area. It was also great to have my team members (from Calgary) Nancy Kelln and Lona Vanberg attend and participate, as well as for their support!

I was the second to present on Saturday.  My story was that of my collaboration with the R&D team (a team that I worked with a few years ago).  Now I have presented before, at lunch & learn sessions, at tutorials, even in school but it was my first presentation at a Software Testing workshop.  It went well, I was confident up there. I knew the theme of the conference, was well aware of the focusing questions and geared my story towards the confines of those focusing questions.  I was happy to have some of the participants approach me after my presentation and tell me that they enjoyed hearing my story and could appreciate all the effort put forth, and how I went about collaborating with my team members on the R&D team. It was great to have that type of feedback from peers, and I really did (and still do) appreciate it. After my presentation, I knew ways I wanted to improve it, and also how I wanted to improve my presentation skills overall. In addition to my self realizations, Rob was kind enough to give me a few additional suggestions over breakfast the following day.

The energy in the room was great both days, with everybody participating, asking questions, creating discussions. We went out to lunch together, a few of us went to dinner together where we continued offline testing discussions. Every collaboration story was different (some had a few similarities but in different contexts), and we each focused on collaboration skills that we got out of each person’s story.  There were a few group exercises where we split up into groups which was fun and at the same time turned out to be a great learning experience. I find that great learning often happens when working with intelligent, thinking Software Testers in the type of group exercises that Rob had us work on.  I’m also happy having had the chance to talk to and hang out with Scott over the course of the 3 days.  I have been following Scott’s work and learning from it for many years now. I met Scott before at CAST2013 where we spoke briefly, but it was awesome to spend more time chatting, joking around, and talking about serious testing topics with Scott this time around.  He was also kind enough to offer me some great insights before we finished up for the day on Sunday evening, which I greatly appreciate.

So what’s next? We had some great feedback at the end of the workshop from all of the participants with a lot of interest in the next one. I’ve had some of the participants offer their help in setting up the next one. I’ve received some other emails on how we can publicize our group more, to a wider audience.  The interest is evident, as is the passion of the Testers who are interested in helping building a community of smart, thinking, skilled, passionate Software Testers.  I’d like to thank everybody that helped out with and participated in the first ever MOIIST workshop!

Stay tuned for more information for MOIIST2015!

 

 

2013 – My Year in Review

So here we are a few days away from 2014.  Like most busy days and busy weeks, the year has gone by quick! It’s been a great year for me in terms of my life as a Software Tester (but then again I’m an optimist who truly believes that for it to be a great year, you have to make it a great year).  Everyday I pride myself on being a better Tester than I was the day before. At the end of the year now, I can see (and feel) the accumulation of all of those individual efforts I put forth each day throughout the year.

I started blogging late last year in December and have continued to do so throughout this year, posting at least once or twice a month.  Most if not all of my posts are based on my first person experiences.  I enjoy writing and believe I do my best writing when I’m in “the zone”.

Throughout the year (especially during the first half of the year) Michael Bolton was actually kind enough to take some of his time to help me tackle a few challenges I was having regarding testing and more specifically the challenges and battles I was going through as a context-driven tester in a traditional factory testing environment.  Somewhere throughout those conversations, Michael “introduced” me to a great Software Engineering and Testing mind in my hometown – Rob Sabourin.

I always enjoy speaking with Rob, I feel like I get something valuable out of our conversations each time. Early in the year we spoke about and then began organizing a Software Testing Peer Conference right here in our hometown of Montreal. We’ve been working together throughout the year (along with Stephanie R.) organizing the workshop which will be held in January 2014.  We have some good Testers speaking about some interesting topics on collaboration in Software Testing and I’ll also be presenting at the conference!

I worked with Matt Heuseur early in the year as a volunteer and test judge to help out with the first (to my knowledge) Online Test Competition.  It was fun collaborating with Matt and the rest of the team, seeing how they would organize what we wanted to get done and how, and then go about getting it done. I had a blast judging the teams.  The competition was held on Friday April 19th and the performance testing portion was held over that weekend where each team had a time slot reserved to do their testing. There were some awesome teams who did some really great work. I spend hours upon hours reviewing test reports, grading, and re-reviewing them and got some great ideas to improve my own work from a few of the teams.

In August I went to my first CAST! I registered to attend early in the year and it was something I looked forward to for months!  CAST2013 was awesome! I met so many interesting testers – some whom I knew and had many talks with over Twitter. With some of the testers I met it was like “hey we finally get to meet in person!”  One of the highlights for me was Paul Holland’s End to End agile Testing tutorial.  It was a fun, highly participatory tutorial that I learned a lot from. As soon as I came home from CAST I reviewed what I learned from the tutorial and started using the things I learned in my daily work. I had spoken to Paul on twitter and by email before meeting him at CAST2013, but being able to meet him, learn from him, and talk to him in his tutorial and also speak with him during the 3 days (including joking around with him) Paul is a great teacher and also one of the funniest people I’ve met!  Another highlight for me from CAST2013 is Rob introducing me to Jon Bach. The three of us had a nice chat over a meal and when Rob had to go prepare for his tutorial Jon and I continued to chat.  I enjoyed chatting with Jon, and he helped me answer a question I had regarding something I was trying to do better – but like many highly intelligent people he didn’t directly answer my question, instead he helped me think about it in a different way and helped me work my way to the answer myself.  I enjoyed every single talk I attended. I could write an entire blog post about the talks I attended, there were some great talks that I enjoyed.  I made sure so sit in the front for all of them!

Two weeks after I got back from CAST2013 I began my BBST Foundations course. Wow what a course and what an experience! I knew that I had better be prepared to spend time on the course and be 100% focused for the entire 4 weeks.  I went into the course very well mentally prepared – I was ready to sacrifice my life for those 4 weeks and made sure I learned a ton from the course (which I did) and successfully complete it (which I also did).  It was a tough, fast paced and intensive course – but it was also a challenging (which is what I wanted), fun, and rewarding course.  I met a coupe of good testers in the course who I keep in contact with via Twitter, Skype, and LinkedIn.  Erik Davis and I had been talking about taking the course together and I believe after some juggling on his side we were able too. I also appreciate the instructors and what I was able to learn from them, and also kept in touch with a few. Two weeks after the course I went on a long awaited and well deserved vacation 🙂

Towards the end of this year and most recently I started a new job – but not just any job, I am working with some great, fun, and smart context-driven Software Testers.  I look forward to working with all my new team members on our upcoming projects!

So what’s in store for 2014? Well first and foremost my new job. I will be presenting at MOIIST2014 in about 2 weeks.  I plan to register for the BBST Bug Advocacy course in 2014.  I also plan to attend CAST again this year and may even submit a proposal!  I will continue to write, read, discuss Software Testing and continue on working towards being an even better Software Tester every single day.

Before I end this post, I’d like to take an idea I got from a post Erik Davis wrote last year, to mention and thank the testers who have in some way inspired me this past year either through a talk, discussion, reading or listening to their work, working with them, training, re-tweeting my tweets & posts and even a combination of these to be a better tester.  Michael Bolton – thanks for everything, Rob Sabourin – awesome working with organizing MOIIST, Paul Holland – thanks and looking forward to talking to you again, Nancy Kelln – who has taught me a great deal during the past few weeks, and happy to say is also my new manager! Jon Bach – thanks for the chat at CAST, James Bach – who’s work I continue to learn a lot from to become a better Tester, Scott Barber – who I finally got to meet at CAST after following his work for so long, Cem KanerGerald Weinberg,  Lona Vanberg – my new teammate, Julie Hurst  – who I met at CAST and also my new teammate, Erik Davis – who I finally met at CAST, Eric Brickarp – who’s inspiring talk I attended at CAST, Keith Klain – the Skilled Testing Revolution is under way, Matt Heusser – who it was a pleasure working with, Michael D KellyMartin Hynie – who I met at CAST and had some nice conversations with, Mike Lyles, Claire Moss, Tim Voet – who continues to help me get better every year, Troy Benohanian – who I was finally able to meet up with after many years and talk testing, Benjamin Yaroch, Dawn Hayes – gave a great inspiring talk at CAST, Pete Walen, Simon Schrijver, Richard Robinson, Ben Kelly – big fan of his The Testing Dead series, Andy Glover – big fan of his cartoons, Pradeep Soundararajan, Phil Kirkham – who has the wittiest comments on twitter, Alan Page – always enjoy reading his posts, Joep Schuurkes – who inspired me to write Fighting the Good Fight), Teri Charles – thanks for the encouragement and rooting me on, JeanAnn Harrison, Anne-Marie Charrett – with whom I had a great conversation with at the airport on the way home from CAST, Markus Gartner, Geir GulbrandsenRichard Bradshaw, Stephen Blower, Michael Corum, and Griffin Jones – who introduced me to a lot of great testers at CAST.  Despite my precaution not to forget anybody, I may have forgotten a few individuals in which case I apologize but my thanks to you as well!

Montreal Insights Into Software Testing

I’ve been working with Rob Sabourin (whom I consider a friend, mentor, and a great mind in Software Engineering) and Stephanie R. to organize a Software Testing peer conference and workshop called MOIIST (which stands for MOntreal Insights Into Software Testing) in Montreal, Canada.  We’ve been working together and collaborating since early this year – in person over lunches, via phone, and Skype. This will be the first MOIIST peer conference & workshop and this year’s them is Collaboration.  More information can be found on the MOIIST website.

There will be presenters from Montreal as well as presenters from out of town.  I’ve seen the accepted submissions and the collaboration topics look interesting. I’m looking forward to all of the presentations especially those that caught my attention because I am interested in learning more about those specific topics and the presenter’s experience report about it.

I am looking forward to the presentations, the questions, the learning, all the testing discussions & conversations, meeting passionate like-minded software testing professionals and everything else that comes with a conference with passionate, intelligent software testers!  MOIIST will be held in January – it will likely be cold, there will likely be snow, there will likely be a windchill factor making it even more cold. Good thing we’ll have the option of plenty of great food choices to keep us warm!  Oh yes – I will be presenting as well.

Stay tuned for more.

Fighting the Good Fight

Not too long ago I was describing the role of the test group at a company I have worked for to a group of Software Testers outside of the company. Now before I go any further I will say this – I’m not “bashing” any individual or group of individuals at the company.  The majority of people I’ve met in the test group are actually great individuals.  I am referring to the behaviours and attitudes towards testing.  I had mentioned the role of testing in the company and how it contradicted with what I did (including what I did at this company) and what I believed in as a proud and passionate software tester.  I described how there was a lot of checking going on that was labelled as testing – checking that applications and features would work as per requirements – and calling that testing.  I have a chart posted at my desk showing the difference between testing and checking as I learned from Michael Bolton’s work.

I also went on to describe some of the key responsibilities of the test group – which I explicitly stated were not things that I necessarily did. Responsibilities such as signing off (my post on testers signing off here), extensive standardized documentation in the form of mindless test plan and strategy templates, and mindless heavily scripted test cases pre-written before any testing was even done. (I have included more details to the responsibilities here than I did when I described them to the group of software testers).

I made sure I stated that I did not take part in all of these activities, because I spent (and still do) a lot of time and effort arguing my case, my reasoning, explaining what software testing really is, its value and that it involves skill, and thought, and isn’t just some mindless task just anybody could do.  I won’t lie, because I dealt with it every single day, at times it’s difficult and can even be draining to have to fight and disagree and have to prove and mention my reasoning over and over to different people in different positions within the company.  Sure, after some gruelling days I have even asked myself “is it even worth fighting for testing at this place?”.  Those next days, I still did stand my ground and fought for myself as a skilled tester who was there to provide testing with some type of value and not engage in mindless activities.  I had presented this to management a few times but unfortunately the situation and reorganization at the company prevented anybody with the power to actually do anything about it.

I received some nice and encouraging feedback from some of the software testers in the group I was describing this too, and one that got me thinking came from Joep Schuurkes who told me to “keep up the good fight”.  Now up until that point I considered myself fighting against incompetence in testing, against template junkies (I got that term from Rob Sabourin), and against testing zombies (I got that term from Ben Kelly), and stated it as such.

I was fighting against all of these things and I still do, every single day – but another good way to put it as I now do – I am fighting the good fight, and will do so as long as I am a Software Tester!

 

CAST2013 Tutorial

After spending almost the entire year looking forward to it, I finally attended not only my first conference but my first CAST! The first day consisted of four full-day tutorials. Attendees were given the choice to attend any one of four full-day tutorials, they all looked intriguing but the one I choose to register for was End to End agile Testing with Paul Holland – and I was not disappointed.  What I learned and got out of the tutorial is actually one of my highlights for this year’s CAST.  Now I’ve spoken to Paul before via twitter and email, and he had also informed me early on about a public RST class (completing RST is one of my goals) he was teaching in Ottawa earlier this year, which unfortunately I was not able to attend due to timing issues – but this is the first time I’ve actually met Paul in person.  I will say this – Paul is an awesome teacher!  Aside from the tutorial I also got a chance to speak with him about some of my goals as a tester, how I can go about to accomplish them and he was able to give me some great insights.  I also got a chance to joke around with him for a bit – he is one funny individual!

Getting back to the tutorial – there’s one term that I feel has been engraved into my head, and that is PCO which stands for Product Coverage Outline.  I work on many different projects at my company, and usually asked to create & document a test strategy.  I have to create a test strategy that will be looked at by many different people (Product Owners, Project Managers, Developers, Architects, Systems Development Manager, Test Managers) with different technical knowledge & understanding, and different understanding of what software testing is or what I (the tester) actually do.  This can be even more amplified at a big company such as where I work right now where the application might interact with many other components and due to the number of levels and teams who have worked on the different components, many people have a different understanding of where and what the risks are.  I don’t create 50 page documents explaining my test strategy (despite some in the company who may believe that is what needs to be written), instead I have been creating test strategies consisting of a short document divided into a few sections, and a diagram depicting the application and related components (which went over well) – but the challenge still remained, how can I do this better in a way different people with different understanding will better comprehend?

The PCO

I got my answer and learned how during the tutorial – Product Coverage Outline.  We were split into teams based on where we were sitting (I have more on this below). Paul explained to us (and then had us practice it in our teams during the tutorial) how a PCO can be created and used (in different ways) for different purposes – to explain testing, to guide testing, to divide testing amongst the team (if that’s your aim), to show test progress (along with visual tracking using a whiteboard), to show test coverage and how it can also be used as part of the final test report.  We started off creating our own PCO, although during this stage my team and many other had starting finding bugs and logging them into the shared bug list. This PCO would then help us focus our testing based on risks and features. Before lunch each team presented and explained their PCO in a timespan for 3 minutes.

Testing the application and filing bugs

After lunch Paul explained Test Reports and what was expected from them, and then we started (well officially started) to test the application and log bugs.  We had about 2.5 hours (which went extremely quick) to discuss the test strategy with our respective teams, test, file bugs and create our test report which each team would then present. One challenge here was to do all these things in the time allocated – a testing challenge we all face in the real world.  Another was to find and file bugs, in that we had to ensure another team had not already filed the bug, this eliminated duplicate entries and furthermore the team that filed the bug first would receive credit for it.

 Presenting the Test Report

The final part of the tutorial was each team presenting their Test Reports.  My team and I were nowhere near ready as I had just finished up writing the Test Report when we were called on as the first team to present. I presented the 5 minute test report for my team.  Now this was nowhere near my best presentation – not even close, but I know I can do better because I have done better.  More importantly though is that Paul gave me some insight on how I can do better in area’s I had not been aware of – how I can better deliver my test report verbally explaining the test report based on a story about the status of the product, how we tested it and how good that testing was.

Tough lesson learned

This being my first conference and my first tutorial of this type, I did learn a tough lesson on this first day.  It has nothing to do with Paul or the content or the tutorial itself.  I will say this to anybody new to a conference and tutorial of this type – try to sit in the front with people who seem excited and passionate about being there (which can be difficult to do as you’ve never seen or met these people before).  I feel I made a mistake by for some reason sitting towards the back – now this is solely my opinion based on my experience, doesn’t necessary hold true for everybody or every time.  There are different types of people who come to conferences for different reasons and different levels of passion for testing, different goals or types of things they want to get out of something like this – which is fine I guess.  But for me I want these types of sessions to require me to really think, learn how to think, I like them to challenge my thinking and my way of doing things. In team exercises I like working with passionate people with different ideas who want to share, learn, and push their thinking just like me – unfortunately this wasn’t the case (teammates not on the same page goal-wise) for me during the tutorial.  Despite this tough lesson, I was still able to learn, apply what I learned, got feedback on how to improve it and looking forward to using it on my projects at work and getting better at it by practicing it.

For the remainder of the conference, every session and talk I attended, I sat in the one of the first three rows – learned a ton, asked the speaker questions and had a blast! 🙂

Going to CAST2013

So it’s now official – I’m going to CAST2013.  Earlier this week I finalized my travel arrangements to and from CAST which is being held in Madison, Wisconsin this year. I had booked my hotel about a month and a half ago and registered for the conference itself early this year shortly after the registration had opened – before any type of schedule or sessions had been posted. This will be my first time attending CAST.  Prior personal commitments prevented me from attending CAST2012 in San Jose, California last year.  I’m not sure what to expect in certain regards at the conference but I do have a better idea now thanks to a blog post Erik Davis wrote about some of the things to expect for first-timers attending CAST.

I do expect to learn – a lot! That’s one of the main reasons I am going – to learn, to challenge myself, to listen to other software testers and learn from their experiences and to get ideas and modify those ideas if need be to apply them to my own testing projects with their own context,  to learn and get better from the tutorial I’ve enrolled for, from the speakers, the talks and the keynotes.  I’m looking forward to meeting a lot of the other testers with whom I’ve had some great discussions with via twitter, direct messages, and emails.  Looking forward to meeting some smart & skilled testers who have taken their own personal time to help me out with feedback and advice on how to deal with and approach different test related scenarios (from speaking about testing to management to approaching testing under different circumstances). Looking forward to meeting some of the testers I’ve worked with this year for the Test Competition.  I am also looking forward to meeting, learning from, and exchanges ideas with testers whom I’ve never had a chance to interact with yet.

Needless to say I am looking forward to the conference and what it offers, and expect to have a few blog posts covering different topics once I return.

Test Competition

On April 19th at 10am Eastern Time, the day and time had finally arrived for the NRG Global Test Competition.  Matt Heusser posted the competition rules and off we went.  A few weeks later, after a good amount of time and effort spent judging, comparing reports, discussion and chat, the results of the competition were posted (you can read them here).  This was the first time I was working with Matt as well as the other volunteers including Jason Coutu, Smita Mishra, and Lalit Bhamare among others.  I spent a good amount of time being involved with the test competition and every minute of it was worth it. First and foremost because I had fun and furthermore, I learned a great deal working with the other volunteers in setting up the test competition and from the test competition itself.

Matt first started floating the idea of organizing a test competition on twitter in early January.  We had our first meeting via Google Hangouts in mid January.  Some of our meetings were held in the evening (Eastern Time) which worked out well for me as my mind was more than warmed up and flowing with ideas and thoughts after a day at the office.  Other times our meetings were held in the mornings (7am Eastern Time) as some of our teammates are in India Standard Time – it was much more challenging to get the mind warmed up and flowing with ideas before that morning coffee 🙂

It was a great learning experience being involved as a volunteer & test judge for the competition. We discussed what we wanted to do – and then potential solutions (the how to part). For example how we would communicate with the participants during the competition to answer questions? Where would participants log bugs? What did we want to consider when grading and how would we use our grading scale.  Working with the team in determining all of this was great, I learned a lot from it and have a good range of knowledge to perhaps organize a similar event at the office – and have the team as external test judges (which would be awesome).  I also had an opportunity to use and familiarize myself with Telerik TeamPulse in the weeks leading up to the the test competition – this was the tool used by the participants to log bug reports.

For the competition itself, we had 17 teams registered from four different continents. Teams varied in terms of number of team members and the location of members within the teams. Teams were given 3 hours for the functional portion of the competition and had scheduled time-slots over the course of the weekend for the performance portion of the competition.  Teams had 4 different websites to choose from to test. Some teams choose to execute tests on all 4 websites while other teams chose to perform testing on a select 1, 2, or 3 of the 4 choices.  Now the challenge here wasn’t just to read the rules, ask questions, select websites to test, coordinate with team members, implement test strategy, do the actual testing, log bug reports, write test reports – it was doing all of this (and possibly even more for some teams) in 3 hours!  This is an actual and real challenge we as software testers face every day – we don’t have all the time in the world (and often very little time) to test so we have to choose what we test and how, wisely.

I reviewed every bug report and test report that was submitted at least twice, comparing the bug reports  logged and the content in those reports to our grading scale, and to bug reports logged by other teams.  I reviewed how well and clearly the test reports were written, and how valuable the information in the test reports were for me viewing as a stakeholder.  I went into the websites and tried to reproduce a lot of the bugs that were logged according to the repro steps provided.  I was very impressed with some of the bug reports and test reports we received and that those teams were able to produce and submit this information in a timeframe of 3 hours. I even got a few ideas from one or two test reports that I may be able to apply to certain applications I write test reports for.

Having fun and learning – for me being involved in the test competition as a volunteer & test judge,  these two factors went hand in hand.  As Matt mentions in the Test Competition Results post, it’s rest and regroup stage for the time being, but I am looking forward to what comes next!

Congrats to all the winners – well done!