Friday, June 28, 2013

Reuniting With an Old Friend: Rapid Reporter

A few years ago, I was introduced to a nifty little tool for Exploratory testing and session based test management. That tool was Rapid Reporter, created and curated by Shmuel Gershon. It is a deceptively simple tool, in that it has a very limited interface, a few key features, and a very small footprint. It's what you can do with that little tool, and how quickly you can do it, that is impressive. Alas, it's been a few years since I've worked in an environment where PC's or PC based software was a major component of my work (I've been working on Mac's since January of 2011). Rapid Reporter is an application that requires .NET 3.5 to work, so I basically bid adieu to Rapid Reporter for my regular workday testing.

Fast forward to this week. as I am working with a summer intern, I was considering ways I could talk with him about how to focus on and test various stories. While we have well documented story tests and requirements, sometimes I found that we were losing some key steps in translation from story to actual testing. I also wanted to make it possible to encourage him to take more chances, reach out and explore without my having to be ultra explicit in what he should do. Additionally, we had a number of tests that we were going to need to focus on specific to accessibility, and more specifically, Windows XP and IE7 accessibility (I can hear the groans already ;).

It was while we were setting up for this round of stories that i thought "wait a minute, I know a tool that would be very helpful here". With that, I introduced the intern to Rapid Reporter, and set about to give him a  crash course in how to use it. In the process, I realized what a nice, elegant tool RR really is.

For many of you, Rapid Reporter is old news. You have it, you understand it, you use it, you love it. If you're one of those people, then there's probably not much more I can tell you that you don't already know. if, however, you have not used it before, then I encourage you to do so. It's a small executable, less than 100K. it will run anywhere you place it, and wherever you place it is where it will consider the root directory of all that it does. When you start up Rapid Reporter, you will see a small yellow window on your screen.


Really, that's it. that's the entire app as it appears on your screen. It floats above everything else and it's really unobtrusive. Stick it in a convenient place on the screen, and go about whatever it is you need/want to do.

Rapid Reporter makes for a simple and quick interface to jot down what you are doing. It also allows you to set timers and change where to set your root folder (really helpful if you want to manage/review several testing sessions). to get to those controls, simply click on the right mouse button anywhere that's yellow:


The two buttons on the left side give the user the option to bring up a pop out editor for more detailed comments (including RTF formatting of text if desired). The second button is a quick way to get a full screen capture. 

 Each line gives the option to select a unique label; reporter for the first line, charter for the second line and then a variety of labels for the test session (Setup, Note, Test, Check, Bug, Question, and Next Time). The ability to cycle through these labels quickly makes it easy to categorize what the tester is doing. Small labels above and below the current label help the user quickly see which item they want to dial up for each line entry.

Finally, there's a marching blue gradient that grows across the gray text input field to help the tester know how much time has passed. When the blue gradient has completed across the text input field, the test time expires (you can shut down the clock any time you want to if you finish up early).

When the testing is finished, there are a number of artifacts created. The most important deliverable is a .csv file with all of the data collected (time stamps test steps, comments, notes, and links to screen shots). Additionally , extended notes are stored as RTF files and images are stored as jpegs. All of these together helps to make sure that the tester can go back and review what they did and, if they chose to, see exactly what was happening at the time. 

What makes Rapid Reporter beautiful, in my opinion, is the fact that it does its job by getting out of your way. Shmuel noticed through numerous test sessions with a large number of testers that notes should be quick and easy to make. Notes are most effective if made in the middle of testing, in the thick of the action, and not later or while having to take the eye off the ball. Additionally, these notes are easily able to be put into different formats, condensed, collated and sorted, in any manner the tester or test manager might want. The fact that it's so small and self contained means that RR can be carried anywhere (well, anywhere that .NET 3.5 resides :) ).

Bottom Line: 

This was a great tool in 2010, and it's jut as great, if not better, here in 2013. I had a lot of fun showing our intern how to use this tool (and the fact I could do it over IRC since I was home recovering from surgery) is he real testament to hoe easy and clean this tool really is. Rapid Report does require a Windows environment to run, but if you have one, then by all means, put Rapid Reporter into rotation and see how quickly your focus and testing experience improves. Yes, that's high praise, and yes, Rapid Reporter deserves it.

Weekend Testing Australia/New Zealand: Reloaded

This evening (well, this evening for me, your time most certainly will vary), we will witness the return of Weekend Testing Australia/New Zealand (WTANZ)!

When Marlena Compton made her trek across the Pacific from Sydney to San Francisco, WTANZ went into hibernation. This made me a bit sad, since the WTANZ sessions were the ones I attended as a participant, rather than as a facilitator.

Alessandra Moreira and I have been in discussions over the past couple of months. When I saw that she was willing to get up at 3:00 a.m. Australia time to participate in Weekend Testing Americas sessions, I had a pretty good hunch that I'd found someone crazy enough to be willing to facilitate closer to home. That hunch turned out to be true :).

Thus, today (which is Saturday already in Australia), from 2:00 p.m. to 4:00 p.m. Sydney time (which translates to 9:00 p.m. to 11:00 p.m. Pacific time), WTANZ will be hosting a session dedicated to test oracles, using the mail.com web client as the product under test.

The Mission:
Using an alternative web email client: mail.com, the focus will be on finding bugs and observing how Oracles play a part in deciding if something we see is a bug or not.

From the Weekend Testing site:

Oracles are principles or mechanisms by which we recognise a problem. Below are links with more information on Oracles in Software Testing:

http://www.developsense.com/blog/2012/07/few-hiccupps/
http://www.developsense.com/blog/category/oracles/
http://www.associationforsoftwaretesting.org/2012/06/12/observation-inference-oracle/#comments


For those who want to participate, the session will be held over Skype, as usual. No video or voice required, just chat. To join this session add "WeekendTestingANZ" to your Skype contact list, and then be on Skype 15 minutes prior to the start of the session. From there, you will be added to the discussion. 

To keep in touch with WTANZ and upcoming events, follow @WTANZ_ on Twitter.

It's great to see this old friend back and active. Looking forward to coming out to play with you all tonight!

Thursday, June 27, 2013

Aedificamus: The Defining Point

For some of my readers, this post may seem all over the map. There is a very good reason for it.

Last Thursday, I went in for what I hope will be one of the last chapters of what has proven to be a rather long ordeal. I had surgery on Thursday, June 20, 2013, to remove the steel plate and pins/screws that were in my right tibia. These were remnants of an injury I suffered on August 29, 2011, when I broke clean through both bones in my lower right leg.

The past two years have been times of incredible highs and smashing lows. From the excitement of having my first full talk accepted for a major conference, to having to send my regrets to that conference because I would be flat on my back for the next month and physically unsuited to attending.  That month was one of the longest I ever went through, but it was also cathartic. It was the month I worked through several books. It was the month I spent doing all I could to make "Mordor", a smoke testing framework written in Cucumber, RSpec and Capybara (with a lot of help from Sidereel developers) something that was actually effective and reliable. It was a period where I realized that the world didn't stop turning because I wasn't running 100 miles an hour to do everything I needed/wanted/had to do. I had to rely on others, and trust they would do what had to get done. In most cases, they got done.

Sometimes, we don't know what we miss until we can't do it any longer. I came to the conclusion that I missed running. Note, I wasn't much of a "runner" before, but I took for granted that, if I wanted to go for a run, or play a game of Frisbee or touch football with some friends, I could. Then this accident happened, and even after I healed, my ability to run was greatly compromised. The orthopedic surgeon was impressed with my range of motion, was glad that I could walk for long distances, and looked to him otherwise vigorous and strong. Still, I couldn't run. I could jog at a slow clip, but if I tried to do a full out run, I looked like a drunk man staggering. I lost 25 pounds after the accident, but since I was inactive, much that weight loss came from losing muscle. Sadly, when I gained 35 pounds back, the majority of it wasn't muscle, either. I'm now, like it or not, the heaviest I've ever been (256 pounds). Granted, when you're almost 6'3", that may not seem like much, but for a guy that was used to being a vigorous, active, and fairly solid 225 pounds for the bulk of his adult life, this has been frustrating.

Thursday, June 20, 2013, was a defining and pivotal point in my life. The stainless steel is now gone. The "zipper", i.e the long scar and staples in my leg, has made a return engagement, and I have to do all I can to keep it covered, clean, and elevated. My lymphatic system is still recovering, and my circulatory system, by association, still has a way to go. Also, my tibia now has about 14 holes of various lengths extending from just above my ankle to about 40% up the length of the bone. As a friend pointed out, those holes make my leg, for now, just like the perforations on a saltine cracker. Overall, the bone is solid, but if I hit it just the right way, until those holes fill in with new bone, I run a risk of breakage and going back to square one. The good news? That should take, maybe, six or eight weeks, and then my bone should be "good as new". No more plate, no more irritation and threats of infection, no more torsion modulus if I happen to mis-step or flex my leg quickly. In short, with the exception of a big scar, two remodeling bones, and some nerve damage that may never recover, I have a choice to rehab and get back into my preferred "fighting shape".

I've decided I'm going to share that journey with everyone, or at least those who want to follow along. You will notice a tab that is, for now, mostly empty. That tab says Aedificamus. Much like my "Practicum" is where I practice my craft of testing in various ways, Aedificamus is where I will test and refine the theories needed to rebuild the most important project I have... ME :).

I want to rebuild. I want to get stronger. Most important, I want to run again, and I want to do this in a way that is meaningful to me. This could become the "boldest boast" of my career, maybe even my life. It could work out splendidly. It could go down in flames.

There's only one way to find out ;).

Wednesday, June 26, 2013

Reframing the Discussion Often Changes the Results

Over the past several months, my older daughter has wanted to learn more about fitness and keeping her self healthy and in good shape. I have a sneaking suspicion a lot of this has to do with the fact that she's starting high school in a couple of months. I'm willing to squarely say there's a "vanity" quotient here, but whatever prompted it, I'm happy to see her embrace it and focus on it.

Lately, she's been asking a lot about food and understanding how food plays into the broader range of fitness, weight, health, etc. and how it measures up to things like exercise, metabolism, genetics, etc. Having had a stronger than passing interest in bodybuilding as a youth and in my twenties (no great shakes, but I was pretty solid for a good stretch of years back then :) ), I knew a fair amount about how to discuss some of these topics with her.

One of the things I made sure she understood immediately was that many of the images in magazines were a very brief snapshot in time. I also told her about (and showed her) some pictures of bodybuilders, figure competitors and athletes during the "off season". Why? Too often, kids see the images made at the very tail end of a competitive cycle. That cycle may include anabolic steroids, growth hormone and other things, not to mention tanning spray, lots of professional lighting, and potentially a healthy dose of Photoshop on top of it. My point was to get her out of the mindset of "oh, I could never live up to that" (news flash: in many cases, they can't live up to that either). Instead, I wanted to have her understand what was clearly under her control and what she could do and expect coming from a genetically typical place.

Once we were able to establish the ground rules and the reality of the playing field, we could have more in-depth discussions. One of the key things I suggested she do was that she create a few spreadsheets (or use a spiral notebook if she prefers) and for the next month, I wanted to have her record, in its entirety, everything she did to train, and everything she ate during the day. In the process, I created a simple spreadsheet for her that allowed her to do a few things:

- Create an ingredient list of typical meals she makes
- write down the serving size, and the number of servings she actually consumes
- record the protein, carbohydrate and fat grams for each item (I'll have to show her how to navigate the USDA Foods index to estimate the calories from fresh fruits and vegetables, etc.)
- from there, the sheet calculates the total number of calories from each, and then breaks it into a percentage.

I've encouraged her to make a goal of total calorie consumption that leans towards maintenance levels. For her height and weight, that's a rough estimate of 2,000 calories. In that, I suggested she aim for about 40% total intake coming from proteins, 30% coming from carbs, and 30% coming from fats. She can play with the sources of those. I recommended that she also aim for at least a gram of protein per pound of lean bodyweight per day.

From there, I have now stepped back, and I am curious to see what she comes up with and how she chooses to meet those goals.

This example, as I explain to her, is a way of getting data and learning about habits while creating basic constraints. As she chooses to navigate this, she knows she has a total (2000kCal per day), she knows a rough breakdown, and she knows one component she needs to focus on as a priority (that being protein consumption). Now, she can play with the foods she eats, actually learn what is nutrient dense and what is nutrient lacking, but most of all, she now has real data to compare and consider.

In testing, we often do the same things, we have a product that we test, and we may often do good testing, but we get complacent, and therefore we just do whatever it is we do. It's not bad, but it's not optimal, and very often, it's not as informed as it could be. By framing our challenges (charters, missions, etc.) and creating constraints and prioritizing areas we really care about, we can often come up with very different testing scenarios, even if it's within a narrow area. Just as I told my daughter that I don't expect her to become formulaic with what she chooses to eat (it would be simplest to say "eat this, don't eat that", but where's the discovery in that?), we shouldn't be too prescriptive with our tests and what we do. We can be as prescriptive as we want to be with the framing, but the actual steps, leave some leeway there, as much as is reasonable. Don't be surprised if you discover that you learn a lot more than you would if it was painted in black and white.

Tuesday, June 25, 2013

Five Questions with... Me :)

This one is short and sweet today. I wanted to say thank you to Nicola Owen in Auckland, New Zealand, for reaching out and interviewing me for her blog.

In it, we talk a bit about rock and roll, how being a musician helped prep me for testing, my thoughts on the changes happening in the testing world and the way that testers approach what they do, and she asked me what I felt my biggest accomplishment was.

I'll not tip the scales too much (go to Nicola's site and read the interview there ;) ), but I'll paraphrase one answer and say what I think the biggest accomplishment is... it's right here. Everything that has happened (one way or another) in the past three years and a few months, has stemmed from this blog, and the people that have read it, commented on it, challenged me on it, and given me suggestions as to where I should go.

Without TESTHEAD, there would likely be no Miagi-do for me. It's likely that my connection with AST would not exist, and thus my involvement with BBST and SummerQAmp wouldn't have happened. Without TESTHEAD, I would have probably had no reason to get onto Twitter (I set up my Twitter account specifically to announce my blog posts, though it grew into lots more). I would likely not have met the several hundred passionate testers and developers that I converse with regularly. In short, life would be rather different today had I never started doing this.

To that end, once again, may I say "thank you" to each and every one of you who takes the time to read this blog. You give me an opportunity to give something back to the testing community, and at the same time, help me figure out if I'm crazy, abnormal, or just haven't thought some things through. You also let me know that I can, every once in  awhile, figure some interesting things out. Thanks for being there for me, and thanks for making this fun :).

Monday, June 24, 2013

A Long Time "Face Value"

As testers, we like to believe that we don't take things at their "face value". We pride ourselves in the fact that we investigate things, we are skeptics, we research and we check things out, and we are sure that the things that we do have passed this so called test. Yet, very often, we carry around things that we've always thought were true, or have thought something was true for so long we never thought to investigate. This is a story of one of those instances, and the "face value" issue has, effectively, spanned my entire professional life.

When I first started working at Cisco Systems in 1991, I joined a variety of USENET newsgroups. In that process, I saw a lot of people posting intelligent commentary on a variety of topics, many people having considerably more experience and understanding than I had at the time. Additionally, this was the era when everyone had some kind of interesting or pithy .sig file, and typically they had quotes. Some were well known, others a little more obscure, and one just stuck out and appealed to me so much I decided to adopt it as part of my own .sig. That quote?

"Not one shred of evidence supports the notion that life is serious." - Friedrich Nietzsche

This quote has followed along with me, in some way, shape or form for twenty-two years. It's been part of .sig files, profiles, and favorite quotation lists. The thing is, I never remembered reading the quote in anything that Nietzsche wrote. Granted, I will not profess to having read all things Nietzsche, but it was something I'd seen so many places, posted by so many people, and I'd used myself for over two decades. No one ever said anything about it. It wasn't until I started using a service called Goodreads, and where I started to plug in favorite quotes, that I realized something was odd. Various quotes I'd been able to plug in, and they came back with slightly different versions, but with generally the attributed speaker, and the actual text quote. The quote above, when I ran it with Nietzshe's name, came back with nothing.

Huh?

The site must be broken... or maybe no one had entered it in before. Still, I started to get a nagging feeling... had I been wrong all this time? Was the quote something that someone else said? Thus, I decided to see if I'd been wrong... and apparently, I and many others had been wrong. There's a reason there's no reference to Nietzsche being listed as the quote source... he never said it. If he did, it was never written down.

As I was searching, though, I came across this interesting page at Quote Investigator, and it looks like this quote is much more recent, but in many ways, has the feeling of Nietzche, and thus could be seen why it might be attributed to him. From quote investigator:

Quote Investigator: Brendan Gill wrote for The New Yorker magazine for six decades. In 1975, near the four decade mark, he published a memoir titled “Here at The New Yorker” that included the following passage: 1
In fact, not a shred of evidence exists in favor of the argument that life is serious, though it is often hard and even terrible. And saying that, I am prompted to add what follows out of it: that since everything ends badly for us, in the inescapable catastrophe of death, it seems obvious that the first rule of life is to have a good time; and that the second rule of life is to hurt as few people as possible in the course of doing so. There is no third rule.

Why am i bringing this up now? If you do a search on my name and various email addresses I've had over the years, as well as various web sites I've hosted, I've clearly used the Nietzche reference. For two decades and some change, I and many others blissfully ignored the fact that the quote I posted was mis-attributed. Had I not become more curious, it might have stayed that way. Alas, I did something that gave me an unexpected result, and it started a line of thinking. Why didn't I get back the result I expected?  My first response was not "do I have a mis-attributed quote". Instead it was "what's wrong with this service?" Yes, I very quickly jumped to that latter answer. Still, I felt uneasy. For a service that posts and shares quotes, it seemed odd that such a big name and such an oft bandied quote didn't line up. Perhaps the service isn't wrong. Perhaps it's me that's wrong. That led down a number of searches and this recent discovery, where I now have to admit that a favorite quote deserves to be attributed, and reworded, so that Brenden Gill gets proper credit.

What do you take at face value today? Are there things you've long understood or believed to be one way, that upon further investigation, turned out to be not so? Did a quote, a statement, or a thought that you held onto or a long time actually belong to someone else? Did time and no challenge from anyone else just cement the fact that "it must be so" in your mind? I'm guessing that for many of us the answer is "yes". As professional skeptics, it's nice to think that we believe we "think differently". It's also amusing, and frustrating, to realize that we may have been taken in by something for years. The happy ending isn't that I was taken in, or that I was foolish to think the way I did, but that a moment of serendipity led me to other facts, and now I have a clearer view of something today that I didn't have a few weeks ago. That's pretty cool, if you ask me :).

Wednesday, June 19, 2013

Lessons in Entrepreneurship, Courtesy of My Daughter

Some of you may recall that my daughter embarked on an ambitious fundraising project so that she could go to Japan on a school trip (we participate in a Sister City exchange program between San Bruno, CA, USA and Narita, Japan). We hosted two girls from Japan in March when the Japanese contingent came to visit us. In a little over ten days, my daughter will be leaving for her leg of the program. Yes, I’m not just a little bit jealous.


This post, however, isn’t about my jealousy. Instead, it’s about how my daughter used a talent that she loves (her ability to draw) and turned it into a way to raise money for her trip. I encouraged her to embark on this initiative, and told her I’d be happy to help her. In a way, I was her “business manager” as she considered commissions and how to charge and schedule her work. I was interested in seeing what her reaction would be, and how she would approach what she did, when there was more of a “business” aspect to what she was doing. The results were rather telling.


Even Doing Something You Love Takes a Hit When It Becomes A Job


One of the things I found interesting was the fact that my daughter had varying levels of interest, focus and desire on a variety of the projects that she took on. Sometimes she was really into it, but other times, she was a bit less enthusiastic. Some she was able to do very quickly and with a flurry of activity. Others took a lot longer to complete. This probably shouldn’t come as much of a surprise to long-time testers. Even when we love what we do, some projects just tax us in different ways. Unlike our volunteer or personal projects, which we can put down and get back to whenever we feel like it, we can’t do that when we’ve made an agreement with someone to complete a job, and especially not when they are paying for it. She told me that she felt a different level of personal pressure to do the work and complete it, and that sometimes, while she was having fun doing it, at times the fun was mitigated by the fact that she had to produce even when she “wasn’t feeling it”.


We often think that, if we really love what we do for a living, that that will carry us through all the downers and negatives. The truth is, that’s just not the case. Back when I took a job at a video game company, I was excited, because, hey, I got to test video games! That level of excitement wore off after about a week, and then it was just another job. Don’t get me wrong, I still like games, and I still enjoy playing, but when you don’t get to chose what you are testing, and what aspects need to be done, even that huge love only goes so far. My daughter discovered that a love of art can be tempered by the fact that she’d need to produce, and do so on time and on budget, even if it was not 100% what she wanted to do at that given point in time.

It’s Vital to Have an External Outlet

Sometimes I’d come upstairs and see Karina working on something, and I’d ask “hey, what’s that for?” She’d stammer and say it was something she wanted to work on. When I quizzically (and with a smile, I might add) asked her if what she was working on was a commission, a lot of the time the answer was “No”. “No? Why are you working on that?” She would often make some reason, but invariably, each time it could be summed up as “yes, this is something I’m doing for free, but I need to do this, as it’s what balances my commissions and keeps me interested.” Note: this is not me being critical, this is me nodding my head in total agreement. I explained to her that this is, in a large part, the reason I’m involved in activities like Weekend Testing, BBST classes, podcasting and SummerQAmp. Each of these allows me a place that I can recharge, find inspiration, consider different things, and do them just for the fun of it. She felt the same way, and she really depended on these diversions to keep her focused and energized.

Money Really Wasn’t The Object


Some of the commissions she was offered were quite lucrative. Hour for hour, on some of these projects, she was earning more than I do :). Still, I found it very interesting that the jobs she did for her friends (who could not afford to pay her a lot) were ones she was excited about. Others, where she was being offered a lot more money, she was willing to do, and did very well, but she sometimes found herself struggling to complete them. I wondered if a big dollar amount would be a big enticement, but it really wasn’t. She said in many of the cases that, while she was motivated to do a good job, she felt she was much more engaged when she had an emotional connection with the subject. She was certainly grateful to those who contributed and offered her large paying commissions, and she gave it her all to complete them, but it was interesting to see which projects she genuinely smiled while she worked on them, and which ones she did out of a sense of obligation for the goal.


Giving Her All, Even When Challenging, is What Separates a Tradesperson From an Artist


At my daughter’s age, she’s likely to see the end product of what she does as the “Art” that she delivers. In truth, that’s missing the point. Yes, the finished product, with what it represents, is art, but the uniqueness of it, the creative scenarios, the giving of one’s time, talent and energies to make something special, even when they themselves are removed from the subject matter... that is the Art that she brings to these finished pieces. It’s also the art that we all bring to our work, whatever it is.


My daughter will be the first to say that she loves to draw, and that she loves art and being an artist, but this is her first experience with really being “on” with what she does. For many of us, our passions are often kept outside of our livelihoods because we want to keep them something we are passionate about. Once we put commerce into the equation, the dynamic changes. I think a lot of it stems from the control that we have. When we volunteer, we are ultimately the ones responsible for the output. If it delights our customer, then that’s awesome. If it doesn’t, well, hey, we were volunteering our time anyway. Once actual payment enters into the equation, we are now subject to another person’s interpretation of what is good and what works for them. If we don’t live up to the hype, then there’s some anxiety, because we feel as though we may have failed to meet an expectation.


This process has been very eye opening, I think. Not just for my daughter, but for me as well, as it’s helped me to see through my daughter’s eyes the way that I approach my own work, and confirmed, at least for me, some things I’ve long suspected. Additionally, It’s also given my daughter a chance to really appreciate this upcoming trip a lot more than it would have if we just paid her way. In addition to getting a gauge on what her skill set is worth at this current point in time, she’s also learned what it takes to please a customer, adjust to a customer’s wants, and deliver on that promise. More than anything else, though, she will appreciate the fact that that plane ticket, suitcase, and per diem going with her are all things she worked very hard for. Some say that people don’t know the value of a dollar. I think right now, my daughter knows intimately well the value of the dollars that are paying for this trip :).

Tuesday, June 18, 2013

TESTHEAD Gives Props to Tea Time

This may seem an odd title, but I assure you, it's appropriate, and well deserved.

A few weeks ago, Lalit Bhamare, the editor-in-chief of Tea Time With Testers, an online magazine that I have contributed to, asked me if I'd be willing to offer some commentary for a video clip that they wanted to produce, I said "Sure!"

Below is the result:


Bernice Niel Ruhland, Jay Philips, Keith Klain, Rajesh Mathur and I contributed audio interviews to the clip.

Bottom line, I'm happy to see this voice for the software testing world getting more press and notice, and I am happy to lend my voice to their efforts. Here's wishing Tea Time With Testers many more years of success and much greater market and mind-share penetration.

Monday, June 17, 2013

Guru99: Aiming to be the NetTuts of Software Testing?





One of the more interesting aspects of working on this site over the past few years is the fact that people reach out to me to ask them to take a look at what they are doing and to comment on it. I’m honored to get these requests, but lament the fact that I don’t have enough time to really get in and do sites like this justice. I decided to change that and take a look at a site recommended to me called Guru99.




Guru99 bills itself as a site that aims to help testers learn concepts and tools by actually practicing what they learn. They create tutorials for a variety of topics, some of which have video clips that the user can watch and review.


The topics that are covered range from commercial tools such as QTP, Quality Center, Load Runner, etc, but also covers topics that are open source such as Selenium, MySQL, and also looks to cover software testing as a general discipline. In addition to its own hosted video links and comments/commentary, there are also links to other tools and sites to be able to learn the details needed. For those familiar with NetTuts, I think Guru99 is trying to be a software testing analog.


Some of the material is definitely geared towards those who are aiming to cover the certification space. Many of the tutorials are worded and geared towards what has become standardized in the industry over the last few years. I bristled at some of the phraseology (software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is defect free), and while I might reword the text and presentation a bit (there’s no such thing as a defect free product, and software testing does not make a product defect free; it does give us the opportunity to determine which issues are the most critical and that deserve the most focus), the overall message is still valid.


Each of the videos provided range from two to ten minutes, so they are following the Khan Academy model of short, focused discussions, where the user can play them multiple times and review them as they consider the details. This is much preferred compared to trying to go through longer videos, etc. It works much better with my own shorter attention span ;).


If I had to offer a direct criticism, it would be that a number of the videos use a digitized speaking voice to cover the more general topics, while more specific topics and sections are covered by actual presenters. For me, personally, the computerized voice is a distraction. While it’s meant to add clarity and detail, the problem is that much of it comes across as flat and challenging to listen to. I much prefer individual presentations, even if the presenter has an accent. No matter how well tuned the digital voices are, it’s much more engaging to have an individual attached to the topic be the one presenting the material. This way, the vocal nuance can be heard and followed. there’s also no way to insert passion into a computer generated voice (well, there is, but that would go well beyond what the tools and tutorials are meant to do).


Some may look at the materials and say “this is so old school”. This is traditional software testing. They would be right. This site covers several of the traditional tool products of software testing, and they would also be right. The material seems to be geared towards those looking to get certified. Again, true. There is some coverage of new ideas and open source materials, and again, yes, you would be right. The material isn’t cutting edge en masse, but it is a good representation of testing as it currently exists. For those who want to get into software testing, and are looking to work at a Fortune 500 company or at larger corporations, much of the material presented is very much on point. Long time testers may feel that the site is missing some key details, but as an overview, I think it covers the primary topics adequately.


Would I like to see more about context-driven testing, or other topics that are not currently represented? Sure. The cool thing is that they encourage others to help them do that. As of right now, there are three posted externally developed articles/tutorials available on the site, and I suspect they would publish more if people were to be willing to post them (hint hint ;) ).


Bottom Line: For experienced testers, there may be some interesting nuggets here, and some things that you might find yourself saying “hmmm, i didn’t know that!” For first time testers, there is a lot of information here, and a lot of it is quite good and direct, especially for working in traditional environments. For those looking for specific tool knowledge of the listed tools, there’s a lot of good information on these tools presented in a way that might be very helpful to those in that context. For those looking to add information about the state of testing, have it be readily available, and get into the hands of those who might most benefit from it, this looks like a good place to go.

Friday, June 7, 2013

Let's Stop Faking It: Everything's an Analog

Before I was a software tester, I was a musician. Everyone who has heard me talk about my career knows that I transitioned into testing after making a go as a professional musician. I talked about a lot of the things I learned in the process of being a musician, and how a lot of what I learned really had more to do with entrepreneurship than it did with making music. A band is a start up in its most literal sense. The music, the image, the story, the stage show... that is our product. Thus, it probably doesn't come as much of a surprise that music and musical metaphors get repeated often in my work and in my vocabulary.

Today, I'm going to share a conversation I recently had with a friend of mine (names have been changed, but for the sake of this post, we'll call him "Will").

---

Will: So I've heard you talk a lot about becoming a musician over the years, and I know you played in several bands, primarily as a singer. I've also heard you say that you played several instruments, but you yourself said you didn't play any of them particularly well. How did you ultimately become a musician then?

Me: Well, it was something that actually happened over time. I started taking piano lessons about the time I was in fourth grade, and I did that for about a year or two, not really being all that thrilled with it. In fifth grade, I went to a public school for the first time, and they had a "band" class. I looked at the options available, and for some reason, I thought the flute sounded interesting, so I said "I'd like to learn how to play the flute."

Will: Interesting, so how hard was it to learn how to play the flute?

Me: It wasn't too difficult to learn the basics. I guess I was lucky because I knew a bit about reading music. Unlike the piano, where I had to interpret chords and finger placing for ten different fingers to sound out simultaneous notes, a flute was easier. The flute can only play one note at a time, so a melody line for a flute was a lot easier to read. Figuring out the finger placements and the breath control to get the right note, the right octave, etc. was the harder part.

Will: So where did the guitar enter into this?

Me: In seventh grade. I bought a cheap electric guitar from the BEST catalog store (A Global Les Paul copy) and started to learn on it. My mother's Godfather, Jimmy Feodi, was an accomplished jazz guitarist and played the various mountain clubs up between Santa Cruz and Boulder Creek a lot. He saw that I wanted to learn guitar, and for my 13th birthday, he gave me a Fender Jazzmaster from the early 70s, a beautiful (and very heavy) guitar. This made me really excited to want to practice and play, so I tried my best to learn what I could about playing the guitar, including taking lessons locally and playing in my school's Jazz band. Understand, playing might be a slight exaggeration. I did try, but I was not nearly good enough to do it justice. A lot of the time, I would turn the guitar way down on more difficult passages, so it wouldn't be so obvious where I wasn't as good.

Will: So was playing guitar that different than playing the piano or flute?

Me: Fingering the strings was odd, and plucking and strumming took getting used to. The chord shapes were, at first, very strange, but I noticed many of them could be used in different positions on the neck, and that helped a lot. Learning that heavy metal often used two finger to play "Power chords" was kind of cool, but this was the time of Eddie Van Halen, Randy Rhodes and, later Yngwie Malmsteen and others, and the solo was king. I just wasn't that fast or articulate, so I kind of gave up at that point.

Will: But you still became a musician later, so something must have clicked. What happened?

Me: Sometime in my senior year of high school, just for fun, I decided I wanted to start playing again. I saw that some of my friends were putting bands together, and I thought it would be fun to play along. I didn't think my skills as a piano player, flute player or guitar player would get me very far, but what seemed like an "easy" instrument to learn was electric bass. Yes, I know, hubris, but work with me here. A bass just needs one note to be played at a time (yeah, again, work with me here, this is my 16 year old mind we're talking about here). They also just have to play a steady "bump-bump-bump-bump"... heck, I can do *that*! Of course, as soon as I started playing bass, I started to notice bass lines in songs sticking out more prominently, and suddenly, I realized that the bass, depending on the band, was a lot more involved instrument than I ever gave it credit for. Sure, I knew about Geddy Lee of Rush, Steve Harris of Iron Maiden,  and Chris Squire of Yes, but it wasn't until I started playing myself that I realized the skill level of players like John Taylor of Duran Duran, Verdine White of Earth, Wind and Fire, or John Entwistle of the Who. The most surprising one, to me, was Gene Simmons of KISS. Some how, I just never realized that he was actually really good! Anyway, I quickly realized that I was not going to have as easy a time getting "good" at playing bass. Sure, I could keep time, and I could anchor a band, but if I wanted to do more than that, it was going to take time. The nice things was that the four string bass (and yes, to the players of today, there was once a time when five and six string basses were extremely rare; if you played a bass, you played an E Bass with 4 strings) fit very nicely with what I learned about playing a guitar, The strings were thicker, the neck was longer, but much was the same.

Will: So I've seen the pictures of your bands... you don't play any instruments. You were the singer. Why did you make that choice?

Me: Well, originally, I hadn't planned to be a singer, at least not a dedicated one. When I first started putting Monikker together with a few friends, we thought we'd do something like the Beatles, or Kiss, or Queen, where there were multiple singers and each would take a turn at various songs. When we set up the group originally, we actually had a lineup similar to the Beatles or Kiss. I played bass, we had two guitar players (one would switch to keys if the song needed it) and a drummer. The problem was that, as we started trying to do things that were not so basic, I had trouble paying the bass and singing lead at the same time. Harmonies, not a problem, but singing lead while doing more than a pedal tone, ugh, I just couldn't do it. Over time, the other band members commented that I had the strongest voice of any of them. One day, our second guitar player at the time asked me if he could borrow my bass for that rehearsal session. I said sure, gave it to him, and he said "OK, sing lead... on all of the songs!" I was startled at first, but said "OK", and that rehearsal, we went through our entire set list with me singing the lead and him playing the bass. At the end of that rehearsal, he told everyone that he felt it would be in the best interest of the band if he took over playing bass, and if I would sing lead from then on.

Will: So was it some "innate" talent that you had, or had learning all of those other instruments over several years helped you when you decided to sing?

Me: Ha! I see what you did there :)!!! Well, I realized that I carried a lot of small bits of musical education from each of the instruments I learned. I wasn't great shakes at any of them individually, but by the time I got to the skill I had some aptitude for (singing) I was actually very well prepared to not just sing notes, but to read music, to write melody lines, and to sit down with other instruments and, albeit slowly, work out a bunch of musical ideas. The piano helped me with note recognition and music reading, the flute helped me with breath control, melody, and controlling my volume and note placement. Guitar taught me rhythm and popular songs, bass taught me rhythm of a more percussive nature and how to keep time in different signatures. All of this, when it came to singing, meant that I had a lot of stuff I could draw from to help me learn something that many might think is automatic, but really isn't at all. Singing is a lot harder than people realize, especially if you are pushing a P.A. system in a club for hours a night. Surprisingly, my stamina for singing came from what I learned playing flute :).

Will: I remember seeing someplace that you played drums. When did that happen?

Me: Actually, that was a few years after I stopped playing "professionally". I wanted to set up a music studio in my garage so I could keep writing, and MIDI allowed me a way to record ideas quickly. I started out with a drum machine, but found I was getting bored with the basic rhythm construction, so I bough a drum module that accepted trigger inputs. I started with one trigger, then two, then three, then bought a kick drum trigger, and over time, I built a makeshift electronic drum set. As I started playing along with my songs I was writing, I started to vary the rhythm and, over time, I learned how to play a number of drum beats. Don't get me wrong, I'm not about to step on stage for a band or anything, but I can sit down and show another drummer the beat that I have in my head, and I can play those beats for several measures solidly (fills and flourishes are where I start to fall apart ;) ). But yes, it seems everything I'd learned up to that point helped me considerably with picking up other instruments.

---

Hmmm, so what was the point of all of this? Yesterday, I mentioned that many of us copy and master "forms" to learn something, we learn the rules, and then we learn where we can break them, and ultimately, we learn that there are no rules, we are one with the rules, and we don't follow the rules, we just do. The nature of that approach is referred to as "Shu Ha Ri" in martial arts. It's great for when we have a well established tradition to draw upon, but what if there isn't a well established tradition? What if we are looking for or are interested in "the new hotness"? What do we do then?

Will's point is that we draw on what we have already done, and we look for the analog. When it comes to computers, music, philosophy, education, art, etc., at this stage of the game there really isn't anything "new" under the sun. Tools change, techniques change, and mediums change, but the general skills are still the same. A drum is very different from a flute, but a note is a note. Just because the note is considered a "beat" doesn't really change the fact that it is still a noise that happens at a predetermined time. Though my vocal chords are different than breathing through a small aperture and holding down stoppers, a "C" is still a "C". An Am (minor) chord, whether played on a piano, a guitar, or a bass, still contains the same notes. The rhythm structures that we learn strumming or fingerpicking a guitar; fingering, picking or slaping a bass; or pounding out chords or bass accompaniment on a piano translates to a drum. The medium has changed, but the fundamental skills are still the same. What we have to do is abstract what we are doing, so that we can use the skills in multiple places.

Programming languages differ in syntax, and they differ in where they are used, but most languages in use today (I'll keep assembly or other low level languages out of this discussion for now) all do similar things. They all store variables, they all store strings, they all store larger pieces of data that we construct. Some use functions, others use objects and methods, all of them use flow control, all of them use conditions, and all of them encourage creating libraries for reuse of things that have been built before. In short, everything is an analog, and what you have learned at some point will inform what you do going forward. Had I realized this when I was younger, I might have been able to not only save myself a lot of frustration, but I could have become a lot better at the instruments I had learned how to play (which I've proven to myself over the past few years as I've gone back to try to play piano, flute, guitar, bass, and drums).

I recall going to a PowWow in 2008 and one of the vendors was showing six hole flutes. He encouraged me to try it out. I did, and after a couple of minutes playing around, I was playing songs I remembered hearing when I was younger. There was a group that surrounded me to listen, and the owner of the booth asked me how long I had been playing. When I told him I'd never picked one up before, he was astonished, and he said "wow, you're a natural!" Looking back, no, I wasn't. I was, however, someone who had thirty years of various musical experiences that I could call on, inductively, to help me figure out how to play this, to me, totally foreign instrument. The point is, ultimately, that a good foundation in a discipline can help you pick up something new, but you need to have some experience to start with. Once you have that experience, leverage the analogs to learn new things.

Wednesday, June 5, 2013

Let's Stop Faking It: Three Books on Craft and Shu Ha Ri

As mentioned at the end of last month, I will be speaking at Oredev in November, and one of my talks is about how we need to stop faking it and really get to know the things that we do. I like to use analogies from my everyday life, and the things that I do as a tester parallel other things that I do as well.

For those who follow this blog, you know that I have an eclectic mix of things I find interesting and get involved in. One of those areas is my involvement with Native American Pow Wow Traditions (basically Native American singing, drumming, music and dance styles). For years, I have been buying, finding, and learning about how to make dance outfits for both myself and my kids. To make these outfits there are dozens of techniques that an individual needs to master... well, dozens if you actually want to be the one to make them. If you are content to buy them all, then fine, you pay to let someone else have the expertise. Still, there's a certain amount of satisfaction that comes from learning a craft and taking the (sometimes frustrating) time to "master" it.

I'm going through three books at the moment to learn about techniques so that I can get out of the cycle of "buying my outfits" and so that I and my kids can make our own. The areas I am exploring currently are beadwork, featherwork and ribbonwork. Each of these has their own unique challenges, and all of them require stamina, determination, and, most of all, patience. They also require a willingness to go and find information about the techniques that are of interest. For the three above, I recently purchased and started reading the following:

Beadwork Techniques of the Native Americans by Scott Sutton

One of the cool things about this particular book is that I know the author :). Scott Sutton has been active in CIHA and the Native American/Pow Wow community for decades, and he is passionate about Native American beadwork. That passion shines through as he talks about the methods he uses, materials to create the items, and ways in which even novices can get striking results. He also shows a number of variations of projects and pieces for a fuller picture of the process. He shows four approaches (loom, gourd stitching, lane stitching and two needle applique) and where and when to use each.

Focus on Feathers: A Complete Guide to American Indian Feather Craft by Andrew Forsythe

For those who are familiar with dance outfits used in Pow Wows, the use of feathers is commonplace, to single adornments on some outfits, to dozens or even hundreds used in the making of bustles and headdresses. Since Eagles and raptors are protected, collecting these feathers is becoming more difficult (and if you are not Native American, actually illegal). This book goes into great detail about how to work with commercially available feathers (typically made available from poultry farms, and usually coming from turkeys) and painting/shaping them to resemble (sometimes frighteningly so) the feathers of raptors such as hawks, falcons and eagles. The book is beautifully illustrated and includes examples of traditional items, some dating back hundreds of years.

Scarlet Ribbons: American Indian Technique for Today's Quilters bu Helen Kelley

This may seem on the surface to be an odd fit, but it's actually an excellent guide to understanding the techniques needed to create what is called "ribbon-work" or, more appropriately, ribbon applique stitching. Several regional styles are reflected, from the southern and northern plains areas (Osage, Ponca, etc.), to the Eastern woodlands (Cherokee, Pottawatomie, etc.) and the variations that make each different and unique. This ribbon work is commonly seen in dance shawls, on traditional southern dresses and shirts, and as embellishment on aprons, trailers, leggings and dance trailers for Southern Straight dancers (it's for this purpose that I'm scouring this book. I want to update my Straight dance outfit, and this time, I want to make a unifying ribbon-work scheme. The techniques are well illustrated, and there are many projects that allow the creator the opportunity to try out a variety of techniques and projects. It does emphasize modern fabric and production techniques over traditional approaches, so some may feel a bit disappointed in that, but consider that if it matters to you.


So why am I bringing up these three books in this post? They go the the heart of an idea that is familiar to many martial artists called "Shu Ha Ri". The idea actually holds for many of the things that we do, not just for martial arts. Shu represents the phase where we copy what others do, learn the techniques required to mimic what we are seeing, and to effectively duplicate them. Once we "know the rules", we can experiment with them and do things that don't necessarily follow exactly the types and models we have been given (Ha). We put ourselves into the process. Finally, we get to the point where the rules are automatic, they just become part of us, and we rarely even consider the "rules"; they are just part of what we do, and they inform, but do not direct. In the above examples, I'm fortunate that I'm looking at crafts that are not just long standing, but ancient, spanning centuries and even millennia. Thus, the techniques, traditions and cultures are well established, yet even they are not static. There is a lot of innovation and new ideas being experimented with. The benefit here is that there is a lot of data that has already been mined, curated, considered, applied, critiqued and discarded, to the point that books that are "comprehensive" can be created. From there, we can look at what is current, and adjust our approaches accordingly (or even create our own "forms").

OK, so Shu Ha Ri works great for stuff that's been around for awhile... what about for something that is just starting to get traction? What about the "new hotness"? What if those "forms" haven't been codified yet? That's the topic of my next post (to be continued... ;) ).

Tuesday, June 4, 2013

My SmartBear Blog Post and the Future of "Lesson Zero"

First, I want to say thanks to SmertBear Software Quality Matters Blog for publishing a question I've long wanted to see addressed. Yesterday, my blog post about what I think needs to be taught to every software tester went live yesterday. In it, I make the case that, before we talk any testing techniques, before we talk any foundational knowledge whatsoever, there needs to be a "Lesson Zero" for all aspiring testers. So what is Lesson Zero? In my mind, Lesson Zero needs to be "What is the Scientific Method?".

I won't rewrite the article here, but suffice it to say that may people come to software testing with little or no knowledge of the scientific method, and I feel it is to their detriment. Thus, I think it would be great to help make a module (I'm thinking SummerQAmp, but by no means limited there), that would help teach what the scientific method is, how to apply it, and how to experiment with it. I've started an initiative over at the AST EdSIG forum to start putting this together. To that end, I would love suggestions as to how to make this engaging, interesting, and easy to understand, without being patronizing or trivial. It's a simple concept on the surface, but as I have seen many times, simple does not mean easy.

In short, if you would like to help shape this, I'd love to talk to you :).