Test as Early as Possible: 99 Ways Workshop #9

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.


My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.


Suggestion #9: Test as Early as Possible - Gareth Waterhouse


One of the goals of testing is to help make sure we have the opportunity to find and share information on as many aspects about the product as possible. Often, we tend to think of our testing as starting as soon as we have a build that's been deployed. We can get testing done earlier if we pair with the programmer for a story. There's an even earlier opportunity that is available to us if we really want to "test as early as possible", and that is at the beginning of a story. How this is done and what it is called varies. In my current environment, we call this "story kickoff" and that process begins with "The Three Amigos" meeting.


Workshop #9: Have a "Three Amigos" Meeting to Test The Requirements

There is plenty of writing on the web about Three Amigos Meetings, so if you want to get into the details of what they entail and how they can be used in your organization, just do a Google search on "Three Amigos Meetings" and have at it. To keep things simple, I want to discuss this process as it relates to software testing and how software testers can add a lot of value to these meetings, and actually start testing before a single line of code is written.


A Three Amigos meeting in our organization is synonymous with our story kickoffs. In that kickoff there are three attendees; the product owner/product manager (PM), the software developer/programmer (DEV) and the software tester (QA). The purpose of the story kickoff is to make sure that the story has been scoped, that the requirements are understood by all three attendees, and that questions about the requirements are addressed.


In our model, every story is defined with the acceptance criteria for it to be completed. We use a Kanban system and practice "one piece flow" work for a story, so each story get worked on and inspected many times as it goes through its lifecycle. In this first stage, as we walk through and define the acceptance criteria, each acceptance piece then gets discussed. The PM describes what they want to see happen in the story. QA counters with a variety of questions to make sure that we understand what the criteria needs to be for an acceptable completion. DEV discusses, where relevant, some details about the implementation, including hooks or aspects that will help QA with testing the story. We can also bring up other aspects, such as upgrades, migrations, mobile access, accessibility, localization, etc. Once we are all satisfied that we have covered our bases, we consider the story "kicked off" and ready for development work to begin.


As a tester, think of yourself in this meeting, and think about the questions you would want to ask your PM and DEV counterparts:


- have we considered if this feature will translate to mobile devices?

- do we know if the changes we are implementing will have an effect on performance?

- are we using new libraries for the front end? Will those have an effect on navigation or the perceived performance of the application?

- do we understand, and can we envision test scenarios for the new feature?

- do we understand how we will actually test this new feature?

- do the tools that we have allow us to programmatically access values and states?

- have we identified potential security issues associated with the new features?


Each one of these questions is best handled during the Three Amigos meeting, since the cross section of design, implementation and capability to perform the task are all represented. Misunderstandings can be quickly resolved. If they cannot be resolved in the meeting, the responsible party then knows where they have more work to do before the story can be kicked off.


Will this meeting capture everything? In my experience, no. There are unforeseen issues that pop up all the time. There are missed story tests that we realize after the fact. That's a fact of life, and having no missed story tests rarely happens, unless the story is fairly simple. Over time, though, the missed story tests become fewer the more Three Amigos meetings you participate in, since each time through, you remember some of the situations that led to missed story tests in other stories, and you consider those the next time.

Bottom Line:

Three Amigos works as long as everyone participating does their part. As a tester, your goal in this meting is to make sure that you thoroughly understand the requirements as they have been presented. Your best chance to clear up misconceptions and ensure you are on the right track early enough starts here. Testing the requirements means that you can clarify what should be coded from the outset, and that input can greatly shape the direction of the story, and the need for rework later on. If you are not currently doing this in your organization, have a chat with the Development team and the Product Management team and suggest a pilot run of this approach. Getting an opportunity to discuss the story at its earliest stage helps to make sure that everyone is speaking the same language and understands the terms and goals, or as close as three people can possibly get to that happy state.

Pair with Developers: 99 Ways Workshop #8

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #8: Pair With Developers

The idea of pairing is closely coupled with Extreme Programming and the Agile movement. Some organizations do most, if not all, of their primary development in pairs. The reason? Two people have a conversation. They talk out their ideas and reasons for doing certain things. The pair is accountable to one another, and in the process of that accountability, the work that is done is often of higher quality and the pair is more productive working together than they would be working separately. This is not always the case, of course. Some programmers work better solo, and have a hard time participating in a pair arrangement, but generally speaking, there's a synergistic effect in pair programming situations where the whole is greater than the sum of its parts. Testers often use the same approach when they are looking at software, too. The ability to have two eyes looking at the same story can help by having two perspectives and two different approaches used, and when one person thinks of a test idea, the other tester may follow on with a totally different idea. 

Pair programming? Check. Pair testing? Also check. Pairing a programmer with a tester? See below.

Workshop #8: Practice the Driver/Navigator Method of Pairing

Between Pair Programming and Pair Testing is a middle ground that I like to call the "Driver and Navigator" space. With this model, both the programmer and the tester take turns as both the driver and the navigator. While the programmer is writing the code, the tester asks questions and gets clarification as to what is being implemented. While the tester tests, and articulates what they are testing, the programmer often gets new insights, and can go back and modify the code based on the areas being tested. Why is this effective?

First, it's effective because the programmer, while writing the code, explains what they are doing conceptually to the tester. Think of it as the driver explaining to the passenger in a car what they are going to see while they travel along their destination. The passenger could just sit there and take in the scenery, but often, the passenger might choose to be proactive, and say "you know, there's this cool area on this side road that might be fun to travel down, and it might save us some time, since we know the section of freeway ahead is prone to traffic". With that, the driver can opt to switch course, or consider another route altogether.

Second, the tester, by virtue of getting a play by play of the developer writing the code, can ask questions and get clarification ("I noticed that you have set up the page with his set of IDs. are you planning on providing alt tags for each of them? That will help with accessibility.") By doing this, the tester actually starts testing the code as it is being written, and the developer, receiving the feedback, has the ability to "fix bugs" in real time. 

Third, even a non programming tester, if they are following along as a programmer writes the code, might notice inconsistencies within the code and comment on them. "Oh, so you're calling this procedure at this point, and you're calling this other procedure over here. Do the two procedures need to interact with one another?" That comment might help a developer notice that "Oh yes, you're right, if I don't scope the variables, they will not be handled correctly when passed to each other.

Bottom Line:

Programs in their finished state can seem very impenetrable and hard to understand. While they are being written, and with a guide to explain what they are doing, programmers can illustrate small sections of code even to those who have little knowledge of programming. Likewise, in the process of this design and build-up, testers have a great opportunity to ask questions and help guide the programmers to ensure that they are really doing what they think they are doing. 

The real value of this interaction is the conversation, the give and take of both parties as the code is being written. This will not work for every story, but it will work a great deal of the time. If you have a programmer that's willing to work with you in this capacity, try it out. Sitting side by side is the best approach, but if that's not possible, sharing a screen session and using a chat client can be very effective as well (in some ways, even more effective, since you have a transcript of what was discussed). Using the driver/navigator method, over time, you may also find that you become more comfortable with the coding aspects as well, and then you may find yourself gravitating towards more more of a peer programming model. Frankly, that wouldn't be a bad outcome at all :).

Have the Courage to Share Your Findings With Whoever is in Charge as Well as Fight for Key Changes: 99 Ways Workshop #7

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.


My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #7: …and have the courage to share your findings with whoever is in charge as well as fight for key changes - Erick Brickarp

This dovetails perfectly in to what I was talking about with the last suggestion. In some ways, I could just say "look at Workshop #6", but that would be a cop out. The fact is, looking at work differently is one thing. Developing the ability to stand up and fight for change might not be something you feel comfortable doing, or feel you actually can do. Sometimes you have to up the ante, and to up the ante, you may have to expose hypocrisy, greed, ego, politics, or all four. Might sound impossible, but I have found a very interesting method to be able to do exactly that, and it really is remarkably effective.


Workshop #7: Ask One Stupid Question Every Day (At Minimum)

I have told my team and my company that I reserve the right to as "a stupid question every day", and that stupid question is very often related to things I find when I test. This approach has proven to be effective in two ways. First, it shows that I'm not presenting myself as a know it all or someone who "has to be right". It also has the added effect that it means those who have issues with what I've found or am presenting need to respond in a way that will explain or resolve my "ignorance".


I am not saying "play dumb", I am not saying "be coy or play political games". I am saying be aware enough to know when addressing certain issues may prove to be a political or emotional minefield. By asking the other side to explain why they are doing what they are doing, for whatever reason, very often it diffuses what could be a negative situation. It also allows me to practice what I and others call "active listening", where I can really make sure I understand, completely, what is being said and explained. It also opens an avenue for me to explain why I think that another course of action would be better. Often, it's possible to diffuse situations that are uncomfortable or awkward just by doing this.


In a way, this is a Socratic Method approach to dealing with issues and getting to genuine resolutions. Honestly, I find that when I approach situations where I may not understand all of the ramifications or decisions that have gone on before, it leaves openings for others to consider taking alternative actions, where before distrust and frustration may have prevented that from happening. One thing that's critical if you use this approach. You cannot come from a place of "feeling". You cannot say "I feel that we are going the wrong direction". My own experience has shown me that "feelings" don't persuade. Facts and hard data does. If you have a gut feeling, that a decision is the wrong one, do all you can to have data that can help back up why you feel the way you do.


Bottom Line:

We all have it in us to be courageous, and we all have it in us to stand up for what is the right course of action, but rather than doing so from a position of "I'm right, so you better listen to me", I've found it more effective to say "Help me understand what you are seeing. Fill me in on what may be missing from my understanding. Let me explain back what I am hearing, and tell me if I understand this correctly."


Several years ago, I would tell you that there's no way that I'd be able to sway people's thinking just by actively listening, but today, I not only believe it's possible, I've witnessed it first hand. I'm not going to pretend it always works; there are braggarts, egotists, and bullies everywhere, and those aspects often get in the way of doing what's best and what's right. I will say, though, that actively listening and getting to the root issues, when possible, can make for the best path to getting even reluctant or antagonistic people and organizations to do what should be done.

Question the Way You Work Everyday: 99 Ways Workshop #6

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.


My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #6: Question the Way You Work Everyday - Kinofrost

Sometimes, it's easy for us to think that things are set in stone, that we cannot really change things We don't have a voice or the authority to change up what we do. Generally speaking, unless you are an inmate in a penitentiary, that is not true. You can do things to change the way that you work and the way that you are perceived in your workspace. What is usually the case is that you (and me), like many others, are waiting to be given permission to make a change. Stop it! You don't have to ask permission. Asking permission is anathema to being a tester ;).

Workshop #6: Add Some Disorder To Your Day

Pick a project you are working on. Consider its protocols, its "essential elements", its mandated deliverables, whatever process exists to do what you need to do to complete the job as it's defined. Got that? Cool. Now, for one day, look at every single protocol and rule, and try to subvert it. I don't mean break the law, I mean try to see if you can either change up the way you do things, or, if you believe you can be effective in chucking something entirely, do so… but make notes of what you do in their stead.

For many years, I had a spreadsheet, and that spreadsheet was an ironclad "do this, do this, observe this, mark yes or no". It was a totally by the numbers thing. I had to turn this sheet in every day, and it was reviewed and commented on by the lead tester. It was efficient. It was accurate. It was also soulless and joyless. One day, I decided to simply call a personal mutiny. I decided to drop the spreadsheet for a day and see if, by ranging into different places and ignoring the set script, I could discover something interesting. Often, I did, and often, the things I discovered actually were game changers. I would then go through and look at the "canned script" and see what areas I covered and give the yes or no, and sure enough, what I found was often not part of the specified test cases, and would not have been found by the set test cases. 

Occasionally, I'd be told "that's out of scope, do it by the book", but over time, as I found other interesting oddities, and continued to do so, I was able to demonstrate that some "exploration" was more valuable than following the mandatory checks (note: at this point in my career, I don't think that the term "exploratory testing" was known by many, but that's definitely what I was doing).  

Think about the way that you write bug reports. If you walked in blind, would you be able to tell what's happening? Could you recreate the issue described? If not, how could you change what you write to be more effective?

Have you ever thought to yourself "This would be a cool tool to use to (fill in the blank), but our infrastructure is so different, I don't see a good way to integrate that into our environment"?

Interestingly, the last one was something I was discussing with our development team today. I was telling them that I was exploring some open source tools for doing security testing and load/performance testing. The problem was that the tools used different languages than we were using. I was afraid that any tests I created would exist on their own little islands, so maybe they weren't worth the time to dig deeper. I just figured that that was the case, so it didn't make much sense for me to talk about it further. I did bring it up with my Director, though, and mentioned that I thought they might be novel things to look at. 

During our group meeting, said Director brought up the tools I was talking about, and my perceived "shortcomings" as far as them working in our environment. One of our developers said "Hmmm… that might not be so hard to implement after all. Since we use Jenkins to do a lot of our CI and functional tests, Jenkins can scaffold just about anything. Let's take a lot later and see if we could work those tools in". After I showed him what I was considering, he said "Oh yeah, that's no so out there. We could definitely explore this!"

Bottom Line:

As testers, we are trained to ask tough questions of the products we interact with, and the methods and tools we use. We should be just as willing to ask the tough questions when we "test" our own organizations. If something seems odd, out of place, wasteful, or less than helpful, we should be willing to experiment and see if we can do better with something else. Perhaps it really is the best way, but I'm willing to bet, a lot of the time, thinking differently and approaching situations with a different point of view will prove to be very enlightening, both to you and the organization. There is, of course  a danger if there is politics or status associated with some decisions and policies (and a sense of losing face for an individual if your changes are implemented), but even then, it's possible to start changing hearts and minds a little at a time. Be willing to "think different", but be prepared to show how your different thinking is better than what's already in place. It's possible you won't be able to… then again, maybe you will ;).

Learn When to Automate and When Not To: 99 Ways Workshop #5

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

 
Suggestion #5: Learn When to Automate and When Not To -- Christopher George

Automation… I figured we'd get to this topic soon enough.

I'm going to say it, and if this frustrates anyone, I apologize. If you want to become good at software test automation, you will have to become good at software programming. That's it. Where you do that programming is largely left up to need, purpose and application, but there's no way around it. Good automation requires good programming skills, and consistent use of them. Abstraction frameworks help some, and may ease the way in for some testers to help in the automation process, but those frameworks will only carry you so far. If they break, need service, or otherwise don't meet the actual need, then what will you do? The likelihood is that you will have to grab a programmer and have them help you fill in the blanks. There is nothing wrong with that, but it's a reality too few people understand, and too few tool vendors ever mention.

Now, having gotten that little downer out of the way... what I really want to do is reset the discussion at this stage. For our purposes, let's drop the phrase "automation" because it's too broad a description and it covers way too much to be a practical term for this workshop. Instead, let's bend the vocabulary a bit and use a different term… computer aided testing. Every time we do anything with a computer system, we are using computer aided testing. Any time we determine there's a pattern that we can repeat and, by bundling the steps together and running them in sequence, we can either save time or prevent human error, at its most elementary level, that is automation, and that is something anyone can start doing.

Workshop #5: Focusing on Patterns of Repetition

If you are working with a Linux/UNIX based system, this is something that you are probably already somewhat familiar with. The whole point of the UNIX paradigm is that utilities take work from one process and direct them to another process. This pipelining, redirecting, copying, sorting and trimming is at the core of most one-off shell scripts that are written. I've written one-off scripts for many years, but didn't stop to really consider what I was doing until relatively recently. Many software testers have similar steps that need to be performed. We start environments, we get them to a particular state, we pose questions that we hope will yield certain answers and if we see what we expect to see, we break down the environment or just exit the shell.

Chances are, many of the steps that are performed to do this are the same every time that you do them. If you can identify those steps, and the sequence those steps are performed, then you have identified a critical area where "computer aided testing" can be of benefit to you. Likewise, if at the end of a test run, you have a large amount of data that you need to go through, parse and cut out key areas to look at more closely, that is also another area where "computer aided testing" can be exceptionally helpful.

These areas are not glamorous. They are not what we traditionally consider to be "automation". They certainly aren't what we normally look at as being "automated testing". Still,  everyone has to start somewhere, and if you need to automate anything, I would strongly suggest automating those steps that you know will always, or at least a great percentage of the time, act the same way.

Another area that frequently comes into play is checking input fields. Much of the time, we know in advance what values we want to use, or a representation of what values we want to use. Filling in those fields manually is murder, but there are small tools that you can use that can ease this process considerably. On Mac, I use a tool called aText. On PC, a longtime standby for this purpose is Texter. Both work in similar ways; they allow you to create shortcut keys so that you can input text in predictable order. Both tools support tabbing, so that you can fill in forms directly. Again, this isn't classic hands off automation, but they streamline and simplify many time intensive steps, and that's often a very good thing.

Many people want automate their browser interactions, and for that purpose, using direct tools like Selenium IDE is a "gateway drug" to test automation. While I think Selenium IDE has a limited benefit, it can be helpful to do certain things, and it's a good way to get started with repeatable testing at the UI level. The disadvantages are also many, and there are plenty of blog posts out there that explain exactly why.

Most important, though, is taking the time to stop and think about what the actual problem is. As I wrote on the SmartBear Software Quality Matters blog, when we focus too much attention on a tool (or a need to automate) we often miss the obvious point, which is "what is the problem that we want to solve?" A tester might want to create a data driven test that walks through and adds 100 users to a system using the front end form. If the point of the test is making sure that the form handles a variety of input parameters effectively, then yes, a front end, data driven test might make sense. If the goal is to populate the database with 100 entries, then a much more effective approach (and likely less error prone) would be to create a shell script that inserts records to your test machine's SQL database (or the appropriate nomenclature for your system of choice).

Bottom Line:

For anyone looking to take their first steps into automation, start small, but start with what will give you the biggest immediate benefit. Make it a habit to become "more lazy". Find the tools that will allow you to repeat the repeatable, fill the fillable, and click the clickable. Once you get a taste of how to do that, then you may find you have an appetite to get deeper into more traditional automation frameworks and approaches. As you make that transition, you will need to boost your programming chops to meet the skill needs, but as you do that, you will also be getting better at recognizing real duplication patterns, and the more familiar you are with what those patterns are, the more effective you will be at making automation tests that will serve your needs.

Recognize That You Will Never Know Everything: 99 Ways Workshop #4

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #4: ...and Recognize That You Will Never Know Everything - Amy Phillips


Malcolm Gladwell and his book Outliers has made famous the idea of "10,000 Hours". For those not familiar with this idea, Gladwell states that, for many world class performers in a variety of disciplines (sports, academics, arts, etc.) the standout difference between those who have natural talent and those who can exploit that talent to maximum advantage come down to those who spent an enormous amount of time focusing on something and practicing their craft. Anyone can get passably good at something with a little time and effort. To get truly great at something, though, requires tremendous time and attention, to the point that to be world class at something, for most of us, we have to pick and choose what very few things we will genuinely be world class performers in.

Too often, we get overwhelmed by the sheer enormity of some goals. For many people, too big of a goal is just as demoralizing as having no direction at all. When things get to be to big, or we feel inadequate or feel that there's just too much to learn, paring back and forcing yourself to deal with smaller chunks can be incredibly helpful.

Workshop #4: Practice The Rule of Three

This concept comes from the book Getting Results The Agile Way, written by J.D. Meier and a previous TESTHEAD book review. The key pint from my review, and I think the key point to this workshop approach:

For each of your goals, try to think of every thing you would like to accomplish, and break them out into four distinct regions; the day, the week, the month and the year. Now for each of those, think of the three things you most want to accomplish in each. If you want to just sample this idea, start with one day. What three things would you be really happy about if you were to complete them today? List them, visualize the outcome you want, and then time box and focus specifically on those areas to get them completed. If you do all three and still have energy, bite off a fourth thing, or more if you have it in you. Stretch this idea out to a week (what three things do you really want to accomplish this week), then to a month (what three things) and then to a year (again, what three things). The day level is, of course, an immediate view. The week level is a 500 foot view, the month is 15,000 feet, and the year, well, let's picture that guy jumping out of a balloon at the edge of our atmosphere, shall we :)?

What makes this technique effective is that it forces the user to make constraints. Any goal that you want to achieve can only be addressed in groups of three. Of course, if you have energy to take on a fourth or fifth item, that's awesome, but do not commit to anything until you have met the completion criteria contained in the "rule of three". The cool thing about this constraint is that it allows individuals to breathe. It forces the individual to prioritize and focus on the things that matter the most. It also allows individuals to create parallel paths. If you have it in you to do six things, then focus on two different areas and do three things for both of them.

This also helps in the sense that it gives the participant a chance to actually leverage areas that they are strong, identify areas where they are weak, and seek to balance them for a more general level of knowledge. Additionally, if a participant wants to maximize a strength, then they can specialize in a given area and learn  that much more for it.

By making a game plan that has deliverables that need to be covered every day (and a limited number at that) accountability is easier and more tangible. It's also easier to see how well you are progressing as the data points to examine are fewer, but more regular.

The trickiest part is making the split on goals, and making sure that the goals you set are those that can be accomplished as sets of three each day. This means, often, that initial goals are set low and may take only a few minutes during the course of the day. For some, this may feel unnatural. Why limit yourself when you are raring to go and have a lot of enthusiasm? The reason is that you want to do what you can to keep that enthusiasm going for the long haul. Some goals might me three tasks and your done, but most are probably much longer and more involved. I tend to think of the math books I had to lug around in grade school, junior high, and high school. Often, I'd think I had plenty of understanding of the problems in the book, or I'd just sit down and plow through a section until I did everything, often at one sitting. The problem with that is that we don't give ourselves enough time to process what we re doing. That, or we feel we learn enough to regurgitate answers onto a test, and once we're done, we breathe a sigh of relief, and then we move on or just stop. We end up forgetting much of what we learn when we do things in too large (or not large enough) chunks. Over time, we will learn how to balance our "rules of three" so that we have a good balance between enough work to carry over each day and enough of a challenge so that we actually learn something new, and make it stick.

I recall telling a friend of mine that, if I spent one hour a day, every day, on learning Japanese, that by the time I completed my 10,000 hours, 27 years would have passed. If I spent two hours a day, it would take me 13 1/2 years. Four hours a day, roughly seven years, and if I spent 8 hours a day, then I could become a world class speaker of Japanese in about three and a half years. What's the problem? The reality is, I really have closer to the one hour a day opportunity level than I do the eight, so I have to adjust t my expectations accordingly. Likewise, the broader and more varied the topics I want to learn, the longer it will take to develop any level of mastery at them. In short, I can't and I will not learn everything. Even in a discipline that is theoretically bounded like software testing, there are so many disciplines that inform it that, even there, I cannot learn or know everything. I can come close to knowing everything in small slivers. If that's my ultimate goal, then it makes sense to specialize and go deep on those topics. If I want to be as flexible as possible, then I will want to learn a lot about a variety of different areas, but be content with the fact I will be a master of none of those areas. Ultimately, we have a limited amount of time to learn the things we want to learn. Make a game plan to make the best use of that time, and then attack it with a plan that will go the distance.

Never Stop Learning: 99 Ways Workshop #3

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions.

Suggestion #3: Never Stop Learning - Chris George

All right, this one is the epitome of "general and vague", so creating a true "workshop" around this one would go way beyond an actual blog post. Still, it's a very good piece of advice, so I'm going to put some personal spin on this, and make some suggestions for what has worked for me in this regard.

Workshop #3: Create Your Own "Perpetual Learning Program"

Software testing is a broad and varied discipline. Context reigns supreme, and each endeavor that deploys software (which covers just about every interest imaginable) requires testing and understanding of the customer domain and technical domain to be effective. That means that, if you want to learn everything there is to know about software testing... it's a never ending process. You actually can learn forever because every product and project is different. 

I like to think of software testing to fit into three different areas, and when I talk about software testing, I tend to think of these three areas:

- universal software testing skills

- context specific domains

- customer specific domains

I'm deliberately simplifying this because we could easily write books on each of these aspects.

Universal Software Testing Skills

If I had to make a suggestion for everyone, at the bare minimum, I think every tester should spend some time learning how to program the shell of their preferred/required system. Make that goal one.

For most of us, there are three systems that are in general everyday use. If you have a laptop computer, chances are it's a variation of three flavors: Windows, MacOS, or Linux. MacOS and Linux have very similar plumbing, and the shell they use (with variations for the particular flavor) all utilize a shell that interacts with system resources in a similar way. Windows uses Power Shell, which, while using a different syntax, does many of the same things. Thus, if I had to suggest any "universal testing skill" it would be to learn how to program, even at a rudimentary level, the shell of your operating system.

Programming knowledge can be very readily compared to the scripts created in the shell, and many languages use similar constructs. The reason I would suggest learning how to program the shell first, is that users can more readily, and more quickly, see how systems interact with one another. It's also helpful in the sense that managing data and the ability to transform data can give a tremendous boost when it comes to helping testers analyze and consider the data they generate with their tests.

Outside of shell programming, when we consider a skill that's universal, to me that means a skill that anyone can use and apply to any testing problem. Here's a small list:

- understanding the scientific method and how it applies to software testing

- asking questions and determining what we know and don't know

- testing assumptions with observable results

- understanding oracles and how they can help guide us to decisions 

- direct communication and effective bug reporting and triage

- test case design and how to express testing ideas to others

- monitoring for performance

- understanding the basics of user experience

- configuration and modification of system parameters

Each environment will have different ways that these things are implemented, and making a universal "you need to learn this to be effective" is tricky. The overview of each of these is, I feel, universal, so spend some energy learning the basics of all of these.

Context Specific Domains

If the application that you are working on has to deal with a particular subject domain, then it is a good idea to make part of your "continuing education" to learn about the actual focus of your business. If you want to be an effective tester at your business, one of the best recommendations I can make is "learn your business". 

- If you work on networking equipment, the more you know about routing and switching protocols, the more effective you will be.

- If you work on medical equipment, understanding the processes and the methods used for medical care will help you better test.

- If you are creating software that helps attorney's manage the legal process, then learn about those cases and sections of law that are relevant to your product. 

Note: software testers do not have to be experts in these subjects, and there's a lot of testing that can be done with just a little knowledge, but the more expertise you possess, the better you as a tester can address interesting issues that others may not be able to find.

Customer Specific Domains

This brings us back to suggestion #1, which is "Get to Know Your Customers". Products are used differently by different people, so learn what it is that they do and how they do it. Understand the contexts and different ways that a product can be used, and what issues matter to different audiences and how to address those issues and audiences. 

Bottom Line:

There's so much to learn, so much to focus on, and so many different avenues to explore, that the general statement "never stop learning" is easy to achieve. Read blogs. Watch courses on NetTutsPlus, Coursera and Khan Academy. Dig into SlideShare and other testers presentations over the years. Review the BBST materials available at testingeducation.org/BBST. Read about topics like philosophy, epistemology, systems thinking, User interface design, customer service, and other avenues that are not necessarily obvious. There's plenty to learn about software testing to keep us busy, but let's not forget that there are many other areas and disciplines that, if we learn more about them, will have a tremendous knock off effect on the way that we look at and practice our testing.

Work First Line Support For Awhile: 99 Ways Workshop #2

The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really simple, general and vague. Some of them are remarkably specific.

My goal for the next few weeks is to take the "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each of the suggestions. 

Suggestion #2 - Work First Line Support For Awhile - Chris George

As a tester who has actually done this a fair bit during his career, and has actually been a Customer Support Engineer on the phone with customers, I have to say I agree 100% with this approach. there re skills that you learn when dealing with customers in a one on one situation that can really sharpen your overall testing skill set. There are many reasons for this:

- Support calls are closely monitored and tickets are watched and evaluated frequently. This means that the goal of a support organization is to get questions answered, problems solved and customers happy as fast as possible. Therefore, front line support people need to be able to think fast.

- Customers on the phone with a problem are not always the most patient people. The front line support person needs to be able to calmly and deliberately work with the customer and get to the root of their issues.

- Customer support may not have an immediate fix, but they are often able to, and encouraged, to come up with workarounds for situations if at all possible. The ability to consider workarounds and alternative ways to accomplish goals often leads to great insights regarding application design and alternative approaches to testing.

- Since front line customers often have access to screen share tools or remote desktop control applications, it's possible to get status and see what is actually happening on customer's machines.

That's just a quick and dirty run down of benefits and abilities that a customer support engineer needs to be aware of, and it barely scratches the surface of what they actually do. Each environment is different. Some may be primarily phone based, dome nay work mostly with email or chat. Some may set up special meetings so that they can share their workspace and watch in real time what you are experiencing.

Workshop: Becoming a Virtual Customer Support Engineer

I hear what you are saying... OK, that's all great, but we already have a support team. I can't just ask to go and sit in for support. That may be true, but that doesn't mean you can't still practice these ideas and learn from them. here's some thoughts as to how you could role-play "Front Line Support" for your product or for others.

1. Does your product have an active support forum? If so, go in and select 10 issues at random. Why at random? Because real life support engineers may not get the luxury of deciding which issue they deal with right then and there. If they get a call, they have to cover it. By picking at random, you don't get to chose if you will wait to deal with it. It's on your plate right now.

2. Give yourself a time box to work in. depending on the issue, you may want to spend five or ten minutes dealing with each issue. Why so short? Because that's a real pressure front line customer support engineers have to deal with. Time is money, and every minute spent working through an issue is a minute you are not helping another customer with their issue. Plus, working quickly with the issues helps to get you focused on examining the issues and risks and making assessments quickly.

3. If you can determine a solution for a problem, write it out in as concise an direct a manner as you can. If you cannot solve the problem, devise a workaround for the issue and write out the workaround in the same manner. If you can neither solve the problem or devise a workaround, write a bug report for the issue (again, make it as clear and concise as possible. What's the issue, how can you get to it, what are you seeing, and what you would expect to see).

4. If you can recruit another tester, member or your organization, or a friend to help you with this next step, set up a time (perhaps an hour block) where that friend will call you with "issues' regarding your chosen representative product. Get the second partner in this experiment to try to find a genuine issue, or construct a scenario that you can help troubleshoot, and suggest a solution, a workaround or confirm a bug. See how long it takes you to come to the resolution. Try to do this for ten issues, if possible.

Some key takeaways from doing this:

- Ask about machine specifications, applications installed, and other details that could interfere with programs running smoothly

- Consider the way that customers use a product, and try to see what areas are causing them the most pain.

- Look to see what common misconceptions are, and if there are trends and patterns you are noticing.

- For each issue that you troubleshot and resolve, review and see if new testing insights are revealed, and if you can use some of those insights in future testing efforts.

Granted, there's no better way to learn about front line support than actually having the opportunity to do front line support. If you have a customer support engineer or two, ask them if you would be able to sit in for an hour here and there. Yes, actually take calls and answer email or forum questions, if the support team feels you are up to it. If they don't have that comfort level, then do it virtually or as a support role to the actual front line customer support team. If your experience is anything like mine, you will likely discover many avenues you would never consider without experience in this paradigm.

Get to Know Your Customers: 99 Ways Workshop #1

I'd be a hypocrite if I didn't at least try to practice what I preached.  Therefore, I'm taking a draught of my own medicine and following up on my advice from earlier today. How's that for mixed metaphor malapropism (not to mention partial alliteration ;) )?

Suggestion #1 - Get to know your customers - Chris George

Seems a little, I don't know... obvious. Right? I mean seriously, if you work for a company that makes a product, you probably know who buys it. I think there's a good reason that this is listed first, though, and it's not just to make a "blinding flash of the obvious" introduction. The idea of a "customer" is not always cut and dry. It's not like we can just simply say "this person/group/entity uses this product for X" and have it be true in all cases. For extremely simple things, possibly, but for most applications, you may be surprised how they are being used, and quite possibly in ways you never really imagined.

Workshop: Define a Customer for a Product (The Art of Personas)

Consider an application that's fairly simple and direct. For my purposes, I'm going to suggest a simple image editing application called IrfanView. Why IrfanView? Because it's the first app I looked at in my PC's launch bar ;).

Now let's stop and think... who would use this tool, and why? I know why I use it, and the reason it's helpful to me, but could I think of other uses of the product? More to the point, are there other contexts where a product might be used "differently"?

Off the top of my head, I could use IrfanView to...

- trim a bunch of images and make thumbnails (front end developer)
- size multiple images for a brochure (desktop publisher)
- create cover images for mp3's uploaded to iTunes (podcaster, musician)
- capture and annotate screenshots for testing reports (software tester, tech writer)
- modify red eye for pictures to be posted to social media sites (just about anyone)

There, off the cuff, are profiles of five different uses of the same product. Should I expect that each of them will want to use the product in the same way? To accomplish the same goals? What is common for all of them is that they manipulate images. If that were all I were to focus on, then I might be able to help deliver a tool that middle of the road handles the basics for all of them, but misses key aspects for those who has specialized and focused needs.

So how do I get to know who the customer is? There's a few ways.

• Go out on the net and look at an application's support forum. Some places use services like GetSatisfaction. If they do, that's a golden opportunity to learn a lot about what is valuable to the customers of that product. What's more, you will also likely find dozens of examples of uses of a product that you might never have considered.
• Product reviews are also great ways to see how people are using a product, and frequently, they provide plenty of information about what it is that they do to give excellent insights as to what's important to them, and where a product meets expectations (or doesn't).
• Sometimes general purpose forums are good sources as well, if for no other reason, you can see who is suggesting a particular application based on the context of a thread.
• If you can get the opportunity to go to a trade show or other public event where people come up and ask about your product, as a tester, see if you can make a case for doing booth duty for a day or two. Physically press the flesh and talk to people who want to know more about your product and what it does, and listen for key aspects of what they are saying? Are they current customers? Are they curious about your product? Are they wary of it? Are they undecided? If they are undecided, why is that?

Each one of these approaches will yield a lot of information. How can we put that information to work? Create "Personas". A Persona is a representation of a customer, but more than just a representation, it's meant to be a look into who they are and what they are hoping to accomplish.

Persona's could be general: an advertising specialist wants to size pictures for a banner ad.

Personas could be very specific: Kimberly is an advertising and copy specialist with a firm that produces banner ads. As such, she needs to quickly create dozens of advertising images each work day.

For me, the more specific and detailed the persona is, the more likely I can get into their head and consider test cases that will answer the needs of that customer. In the example above, one of the most important aspects is speed of use and turnaround time for images. With that as a goal, I can look at what a workflow needs for it to be fast, effective and turn around a lot of images.  These goals will help inform both the way I utilize the product as well as the ideas I formulate to test it.

Moving Forward:

Pick a software product. Any product. Any platform.

Who do you think the customer of such an application would be?
How many different customers could you identify?
Do they have unique or different needs?
Does the product in question make for a better "fit" for some customers?
Are there key elements that could be improved based on your understanding of the customer?
Does trying on different personas help you think differently about the product?
Does trying on different personal help you generate different test ideas?

Can you think of anything that we could add to this hypothetical workshop to make it better?

Just Do Something, Already!!!

Provocative title? It's meant to be. Let's face it, we live in an age of streaming information coming at us in all directions, 24/7. Never in the history of mankind has so much knowledge been available to so many people so inexpensively, and that knowledge is only going to increase as time marches on. We are in a golden age of opportunity, possibilities, and avenues for exploration.

The problem is, most of us read something, we retweet it or hit share on Facebook, we thump our chest at our cool smugness of knowing something neat... and that's as far as it goes. My Favorites pane in Twitter is embarrassingly long. I don't know how most people use the Favorite feature in Twitter, but for me, Favorite means "this is something I want to take a look at later, so hold onto it so I can more carefully review it." I just checked my Favorites list... it's hundreds of entries long! The earliest item dates back to two years ago. Where would I be today if I had gone back to every one of those Favorited items and not just read them, but actually worked through each one of them; trying out a particular tool, writing code, asking questions, submitting tests, challenging the premises, or actually integrating the ideas or processes into my everyday work? I'll bet I'd be a lot more proficient in certain areas than I actually am.

Today's danger is not about lack of choices or options, it's that there are so many choices and options that we can drive ourselves to distraction. Me personally, I feel that I read a lot, but superficially dismiss a lot of it with a wave of the hand and an "Oh, I'm already doing that." Really? Am I? I may be "doing that", but am I actually doing as good a job as I could be doing?


The Software Testing Club recently put out an eBook called "99 Things You Can Do to Become a Better Tester". Some of them are really simple, general and vague. Some of them are remarkably specific. In either case, many of them are things that I already think I'm doing. I could read it and say "Yeah, those are good ideas..." and that would be the end of it. What if, instead, each and every day, I chose one of those items, and actually did something very specific related to it? What if, instead of a quick and cursory "oh, that's an interesting idea" I said "Hey, what if I really focused on this idea today. Could I add to it? Could I make a specific example? How far could I take this idea?" This takes us out of the passive mode. Now we're not just giving ourselves a pat on the back for how neat and awesome we are because we're smart and can do stuff.  Now we're taking each line item and making a personal workshop for ourselves. In short, we are "actively doing", and active doing is way more valuable than just passively reading something and thinking "yeah, neat, whatever".

Many of us look at the examples in programming books, and we often dismiss them because we can do the exercise in our heads. We think "yeah yeah, I got it". The problem is, we are robbing ourselves of the opportunity to make broader jumps because we stop ourselves from doing that "basic training". When we get to a more challenging area, we often find ourselves stumped. I firmly believe it's because we don't give ourselves time to play with those very basic ideas early on as part of our daily training. Think of them as warm up sets before doing some heavy lifting. Another example, one that I'll borrow from The Secret Ninja Cucumber Scrolls. In it, every example has three implementations (Ruby, Java and .NET). I think this is really cool, not just because it shows different implementations, but if we were to structure what we do so that we had to look at it from three different perspectives, and implementations, I'm willing to bet we could way better connect the dots with concepts than if we just figure out what works "for us" and is expedient at that given point in time.

My goal for the next few weeks is to take this "99 Things" book and see if I can put my own personal spin on each of them, and make a personal workshop out of each one of them. An item may take a couple of minutes, or it may take several days or weeks. The key, though, is to act on them, or any other area that's been hanging around. Open up your bookmarks list and commit to making a workshop for yourself in every relevant link you've saved. What you do, or how you do it, is not important... just do something, already :).