Five Questions With Selena Delesie

Selena Delesie is a photographer and ballroom dancer who enjoys camping around Canada. She's also the Software QA Manager for Intelligent Mechatronic Systems and President of the Kitchener Waterloo Software Quality Association. She accidentally discovered testing back in high school as she debugged her way through programming class. College brought her more testing experience in the form of helping her classmates determine why their programs weren't doing what they were supposed to. After college she continued both the testing and the mentoring for a variety of employers, including a stint at Research In Motion playing withtesting their wireless devices and services.

Here is what Selena has to say:

DDJ: What was your first introduction to testing? What did that leave you thinking about the act and/or concept of testing?
SD: High school programming class was my first introduction. We were not taught about testing our programs, though of course they had to work. I remember doing iterations of ‘testing’ on my code to get it running correctly. Though I was proud of my creations when completed, I found debugging them to be much more satisfying. Hunting for and identifying problems in software became an enjoyable activity for me the remainder of my computer classes in high school and university. I was often helping classmates debug their software in addition to my own, even through late nights in the computer lab, and really loving it. I imagined myself a software detective, though I didn’t realize I could turn it into a career.

My real introduction occurred when I fell, quite literally, into a software testing job after university. I had applied to everything under the sun to find a job. Somehow my resume ended up in the wrong pile and someone noticed. That someone read my resume and decided to bring me in for an interview on a whim. I got the job, and I was suddenly a software tester. I was excited to discover that I could get paid to do something I enjoyed doing so much. I soon realized that testing could be an art and a craft. The more I tested, the more intrigued I was to find better ways to do it. I was hooked.

DDJ: What has most surprised you as you have learned about testing/in your experiences with testing?
SD: It astonishes me that not a single class I had in school taught me how to test the software I was creating. From what I have observed this hasn’t changed very much over the years. Our society relies so much on software, yet hasn’t promoted many of the activities that will help ensure quality software is released. While companies want to release quality products, there are still a lot of misconceptions about what it takes to do so. Software today is extremely complex, so flexibility and a variety of test techniques is key... the 'old school' approaches to software development and testing are not as effective on their own as they once were.

So there is an ongoing need to educate other people about what testing is and is not, and why it is important. Many people (executives, management, development, and even testers) have no idea what testing is about, how much work it is to test software, why it is a valuable activity, and why it is not just an end-of-lifecycle activity. Teaching others about this craft can be frustrating, and it sometimes feels like a lost cause. I continue to do so just to experience those moments when I see the glimmer in someone’s eye that shows me they 'get it'. It’s great to find a network of people who are doing the same all over the world.

DDJ: How would you describe your testing philosophy?
SD: First, systematic yet varied. I have tried a variety of techniques and approaches in my experiences, and I have discovered that they all work in one situation or another. I prefer to plan and organize work for a project as early as I can, and determine which approaches would be most appropriate for it. I have found it important to be flexible as the plan is executed though, as new information and experiences on the project will revise what an appropriate plan of action is. For me it's about understanding when different approaches are most effective, and not being afraid to utilize them.

Second, learn, learn, and learn some more. When I began my career in testing, I knew very little about it. I actively sought opportunities to learn and expand my knowledge on the job and in formal training. While I now make time to read a variety of books, articles, and blogs, my most valuable learning experiences have come on the job and in conversations with people who make me think. I am constantly learning new things and evolving my methods and approaches in testing, which helps keep me engaged and successful in my work. I try to share my love for learning with those I work with in the hopes that they will catch the learning bug too.

DDJ: What do you think is the most important thing for a tester to know? To do? For developers to know and do about testing?
SD: Important things for testers to know and do:

• How to look at something from different perspectives. Using the same perspective (or no perspective) will limit the number of solutions to a problem, as well as the number and type of defects that are discovered. As testers, we need to wear different hats and play different roles. Try pretending to be different stakeholders or users of the software. For example, a tester could pretend to be: a product super-user, an elderly person who is uncomfortable with new technology, the VP of your organization, the IT specialist who will support use of the product, someone who speaks a foreign language, or someone who is deaf. Each stakeholder will care about different aspects of the product. An ability to look at the product from the perspective of different stakeholders will help uncover different problems.


• There is no 'right' way to test. There are many approaches and recommendations for software testing, but not any one is the 'right' way in every situation. It is valuable to understand and know how to use as many of these as possible, so when it is time to solve a problem or select a test approach for a particular piece of software, a tester can dive into their 'toolkit' and use the most suitable one. A mechanic would not diagnose all car problems with a single approach. Similarly, a tester should not attempt to find all software defects with a single approach.
  
  Testing with positive and negative functional tests alone is typically insufficient for most software created in this day and age, yet many organizations still believe the contrary. Consider: risk-based testing, orthogonal array theory, persona testing, flow testing, end-to-end system testing, and creating visual test models. These are a small handful of approaches that can be extremely valuable in different situations and will find different types of software defects that standard functional tests would be unlikely to uncover.


• Learning never ends. Learn as much as possible about anything and everything. If interested in software testing, read about it or take courses. Venture into topics such as critical thinking, problem solving, working with other people, detective work, and even the art of magic tricks. These areas, and so many others, will improve ones' abilities as a tester. I personally aim to learn at least one new thing every day. It keeps me fresh and alert, and helps ensure I don’t get stuck in a rut doing the same things.

• Unit testing is important! I know many developers who feel the crunch to get software developed and delivered, and in that crunch unit testing gets skipped. The result though is that the software test team ends up spending much of their test cycle finding bugs that could have been found during unit test, and less time finding other types of (often more critical) bugs.


• Testers are your friend. The last thing a developer wants is to see bad bugs be released in software they wrote. Testers will help uncover some of these bugs on their own, but can do so much more if developers and testers work together. Teach a fellow tester about the software you developed, talk to them about the software design, and even involve them in code reviews. I have worked on projects where developers and testers rarely interacted, and those where they worked closely with one another. The latter experiences were much more satisfying and led to open communication, testers helping find bugs during the design phase (when they are much cheaper to fix), and a more solid product being released.

[See my Table Of Contents post for more details about this interview series.]

Posted by The Braidy Tester at 07:30 AM  Permalink