Testy Testy

Software Updates=Bad User Experience

Testy Redhead — Mon, 24 Nov 2008 12:12:42 GMT

A few days ago I had the following experience.

1. Open Windows XP SP3 based laptop.
2. Machine failed to sleep when I closed the lid, so it promptly sleeps when I'm trying to use it.
3. I wait for the machine to wake up again.
4. Upon waking, Outlook crashes.
5. Outlook will not die, even with end process tree. It is following the philosophy of "Never give up, Never surrender."
6. I force the machine to restart anyhow.
7. Five minutes later, the Windows restarts.
8. Upon restart, Office would like to update, wants to know if I'd like to report it crashing, and needs to do a full inbox scan.
9. While awaiting Office, all of my other software, including BOTH of my beloved Creative Suites and Windows itself would like to update.
10. Firefox and IE would like to update.

In short, it took me well over 35 minutes before I could get my work email even though I declined all other updates.

My computer using friends, we have a major problem. My software creating friends? We have SHOT ourselves in the foot. No WONDER people aren't updating and taking our security patches. We have done a TERRIBLE job of creating a decent experience! It's shameful. Really. One of the most annoying things about software.

Here are my suggestions:
1. Update on start or launch is a TERRIBLE idea. Let's explore the alternatives. This could be an ok option for some people, but is a horrid default. Think about the user. They are trying to do something with the software and we are interrupting them and delaying them. I realize this is the default because it is easy and there is a WRONG assumption out there that a user wants to know "as soon as possible" about every update that exists for every little thing. No, they do not.

2. Outlook needs to improve immediately at it's utter fear of death. When I say DIE, I mean DIE NOW and give me my resources back. I have no patience for Dumpprep when it's the same issue over and over. Dump THIS. End means end. It means give up right now. Internet applications and Windows are both guilty of this "never say die" attitude. Stop being selfish and greedy. The problem with the design is that it's so arrogant. "My application is the only thing that matters." That is the attitude that went into the over inflated sense of importance of refusing to die. If someone is ending task, it must be in error. They must WANT to tell us about it, because our software is more important than what the user is doing. This sort of thinking needs to be discouraged in companies. Your software is NOT more important than the user. They get priority, not you. Server/Client relations of many kinds fail at usability in this department. I think this issue is more technically difficult to solve, but we need to be more responsive to the user desire to be done.

3. Contradicting point 2, I'd like to suggest an option to update on program exit as a good default. This way you aren't waiting. This default should be to "Update and auto exit", not to update and make the user exit again.

4. Why? Why does it take so long to quit applications? Why is there no goal for us to speed this up and give the user their resources back? This is also a performance issue. I know many of us test for startup time, time to complete processing a certain task. Quit time matters too. So does time to cancel. I'm tired of the nonworking cancel button. Cancel means cut it out now. I feel unheard by my software often when I want to quit. As a person it makes me feel disrespected (seriously) and angry. These usability problems can really impact the overall experience someone has.

5. If we really care about security, we need to increase the likely hood of users taking an update. I wish someone would do a study of reduction in costs of security bugs and support costs by making the update experience better. So, I know how important it is and I STILL am not up to date on my home computer. I think that says a great deal. It doesn't make me a bad user, it makes me a mad user.

Dirty Testing Jobs

Testy Redhead — Thu, 13 Nov 2008 18:31:01 GMT

I am told that if you buy a Johnson and Johnson rectal thermometer and take out the literature from the box and read it carefully there is a notice that in small print says:

"Every Rectal Thermometer made by Johnson &Johnson is personally tested and then sanitized ."

Whatever you are testing today, be pleased and repeat, "It's only software."

Creative Suite 4 Unofficial Highlights

Testy Redhead — Mon, 10 Nov 2008 20:29:19 GMT

It is sort of tradition for me to geek out and share what I like about the new Creative Suite with my designer friends when it first comes out, only this time I'm sharing it with you in case you are interested. I use these products (all of them in the Suites with limited exposure to the Video products, so this is NOT about Production Premium). There are an insane amount of features, so let me tell you only what blows me away and I like most. Of course, there is an official overview and demo if you want the real overview and not opinion from me. This is my honest opinion no hype version, but I am by no means a neutral party. I am a flat out fan of Adobe design products and always have been. I'm elbow deep in the technology and solidly in love with Vectors.

Lanette's List of Wow Cool

Photoshop GPU enhancements
UI Integration with Tabbed document interface
Share my Screen
Content Aware Scaling
Illustrator Gradients
Product Improvement Program

Why is it cool?
Stuff in the Products
This overview on Photoshop CS4 by Martin Evening is a good one. I agree with him.
Photoshop GPU enhancements- Because performance matters hugely in Photoshop. To get the no hype, no marketing version of what you actually get, check out the knowledge base article. It is cool because it speeds up what you need to get done and we all hate waiting. Faster is good. Ok, while still in the Photoshop topic, let's talk about the coolest thing (note: Not most useful to you, but COOLEST) in all of CS4.

Content Aware Scaling-Because it is wickedly innovative. When I imagine that this is just the second feature based on this concept, I get excited for the future of Photoshop and digital imaging in general. Ok, we bought this technology from a school, but it RULES. It is some good koolaid to drink. Photoshop knows what is important in your pictures (sort of). I thought that Auto Align Layers was the best thing in CS3, and this is just variation on a theme taken much much further.

Illustrator Gradients-This you just HAVE to try. Download the trial version and check it out. It's the coolest thing since gradient mesh. Now you can have transparency in your gradients and they are so much easier to edit. Everyone is going to be so into the Multiple Artboards that they won't give the gradients the proper WOW they deserve. Check this out.

I'd also like to state for Ellen that NO, this version of Illustrator doesn't suck as much as some of the past ones in terms of stability. You know that when you say some of our versions of AI suck I shake my head sadly in agreement, but I know you are just disappointed as a fellow vector lover. Check out the trial and I think you'll see many of the crashing issues now resolved in CS4. AI CS4!=suck How is that for marketing?

Stuff in the Suite
Integrated Interface-Our new look is a subtle goth appearance. This brings me back. Finally, Suite apps look and act much more the same! Less jarring. Easier to transition between applications. The tabbed documents on the top are very easy to switch between. I put this in the cool category because it isn't just useful, it does look nice as well.

Share My Screen- Ugh, I hesitate to put a link here because it's SO much better if I just show you. Email me and ask me to share my CS4 screen and show you something cool. I'm testing a patch help update the next 2 days and TRUST ME, I've got time to share my screen. Hit me up if you want to see this. It is the thing I was most excited about and just try it. Don't watch the tutorial. The best thing about it is you don't need a tutorial. Usability is beautiful. Go to acrobat.com, sign up for a free account, and share your screen.

This is free. Yes, free. It is AWESOME. Just try it. It is so simple. I am so addicted to this that I've stopped having in person meetings in some cases. This is a snoopy person's dream. Don't tell me about it, show me what you've got! It's very fast and useful (except for video, don't bother sharing that through your meeting room). Rather than allowing another person control of your computer, or controlling their computer, there is an isolated room created for you. You can make changes real time while collaborating. There are just too many good tools in there for me to go over them here, but it is worth making a free account to do this. This is the service I'm most excited about. All you need is a browser with Flash installed. You get a URL to share you can just IM or email to someone. Directions are pointless. If you just pick Share my screen, anyone can do this. You do need a buddy to share with though. Perhaps you want to show me your pretty artwork?

Product Improvement Program-This isn't cool for you yet, but if you opt in, it will be. It's going to give me some generic information about what platform, and how long you had each application launched for. This will focus testing on more real data and I plan to use it for workflow testing. Nothing is tracked unless you opt in, but please DO opt in? I will use the info to test where it makes the biggest difference. Those who test online products often have more information than those testing desktop products, but if people are willing to let us use this component to track what applications they use most, we can adjust accordingly when it comes to testing what exists and predicting how new features will fit in to existing workflows. Say what you will about Adobe, but for a for profit software company, Adobe is a good, sincere, trustworthy company. If we have a few main areas for growth, one is openness, which I'm part of the push to change here, by showing my plain opinion. By having courage to take a risk and tell you my thoughts, consequences be d@mn3d. Now, the other area is in that of humility, which I'm also working on, so please, trust us with your info to help us test even better. We'll give back our ideas to help you in your testing too. I'm working on a little something for you guys to help you in testing. Should be ready at EOB tomorrow in my blog. I got off track today due to a "retest" firedrill, but I won't forget to share something special with you that can be used at any software company, commercial or otherwise, that has multiple languages.

Testing for the User Experience-First Scientific Paper

Testy Redhead — Mon, 03 Nov 2008 09:03:37 GMT

I am proud to share with you the published version (in pnsqc 2008 conference proceedings) of my first technical paper, Testing for the User Experience!

Once the video presentation is ready, I'll post that too! The presentation is "based on" the paper but very much not the same as the paper. I wrote the paper this summer before I could talk about Creative Suites 4. The examples in the presentation are all more current than in this paper.

Greetings from my Cyborgtoe

Testy Redhead — Sun, 02 Nov 2008 10:53:13 GMT

I just wanted to report that I survived toe surgery and am recovering nicely. Once they got in to my toe the ligament was entirely missing from my toe rather than mostly gone, so I ended up with a pin through my toe as well as a metal brace screwed into the toe bone to fuse it. The pin will come out after 2 weeks (Umm, I'm scared for that?), so it is covered in a bizarre plastic cover at the end of the pin which looks like a gumball. I will have "the boot" on for 4 weeks and it will swell from 3-4 months. I will be unable to wear heels for 4 months, so no fancy holiday parties for me. It will be worth it to have my toe not hurting and the ability to walk without swelling back. They expect I'll be able to do everything I normally do including dancing once the fusing is completely healed. The only limitation is I will not be a prima ballerina. Alas, let's hope this software thing works out instead.

If you tried to chat with me last week, please forgive me if I fell asleep or didn't make much sense. I had very strong anethesia and medication to make sure that my muscles didn't cause my toe to go out of alignment for healing. I'm afraid I wasn't not great for conversation or anything intellectual. Please try again in a week or so when I'm more recovered and have my memory working fully again. I was supposed to be back at work tomorrow, but it depends on my ability to walk and drive if I'll be going or not.

I am terrible at lying low and recovering. I get easily bored. I decided instead of resting to begin writing a Science Fiction novel. It is much harder than I thought and I'm only up to 800 words. I may be less naturally talented at writing novels than I'd hoped, but I always make an effort on my life's To Do list. If you have fantastic test material for me to read, please send me links.

The thing I'm most happy about right now is that I have tickets to travel to Placencia, Belize in Feb for a vacation with my Mother. The main idea is to travel to snorkel, go down The Monkey River to see the wildlife, and spend time on the beach. It's been such a rough year for me in terms of health that the break will be very welcome. We travel very well together as we both enjoy a most rustic and cultural experience to a fancy resort lifestyle. We love to meet real people and see the natural landscape. I'm looking forward to trying the seaweed milkshakes and exotic fruits I've never heard of. It will be my first visit to Central America.

Research in Progress-Model Based Test Planning and UML

Testy Redhead — Sat, 25 Oct 2008 08:29:24 GMT

I am working on learning UML right now. I naturally speak in models in my head and have even devised a "roadmap" way to express how I envision the functionality layout in my head. The issue I find is other people can't understand it. For that reason, I am working on gaining a deeper understanding of UML so that I can experiment in model based test planning. I mean applying workflow testing and exploratory testing based on models. I am less interested in the uses for creating automation based on the models. I see my role in creatively coming up with a better way to plan and communicate using models, a better way to reduce existing test cases and create new ones and communicate risk and coverage using the overall picture in models rather than words and statistics. I've done some research to see what exists, but it seems to me that this area is largely unexplored in terms of large scale software projects like the Creative Suite.

How do you currently use models for planning testing? Do you use them to plan when things are testable? How about just to organize your thoughts on risk and importance and communicate with other people?

Can a set of models be used with any sort of consistent results as an overall map to organize collaborative testing? I'd like to try.

I think my team must at this point roll their eyes every single time I want to try another cooky idea to improve our collaborative testing documentation. I have really only a few traits that make me a good tester. Above average curiosity, above average enthusiasm, and a passion for ranting and seeing things improve. Basically, I'm meddlesome and problematic. I think that my drive to always improve is what makes me useful in quality, but can be an absolute pain in terms of romance.

The New Reality-Altered and Enhanced

Testy Redhead — Fri, 24 Oct 2008 07:32:04 GMT

Consider if you will, the Great Onion Nebula. In reading about it today it cracked me up that the professional astronomer described this as "Hot young stars" in keywords. Well, my scientific friend, that's one way to increase number of hits. Since I was a child I've had interest in the night sky. Upon seeing these beautiful images and those from the hubble telescope (in my opinion THE best use of money in all of space exploration in my entire lifetime), I began to imagine if I were able to float around in space that the colorful beauty of nature would surround me and exceed even the beauty available on earth. Then the truth. OUCH the truth. It's like finding out that Santa Claus isn't real. How bored I was with my first telescope. It represented a shattering of one of my fondest dreams. I'd been tricked! These photos aren't real! Real or not, they are a beautiful creation, we just need to explain what they are. They are art. They are enhanced reality based on science. Partly real, partly art. Like every magazine photo you see. However, we need to explain that only parts of it are real. We also need to show the unenhanced reality to people so that they do not feel tricked. Do not blame Photoshop for the human desire to see beauty and art. Do not doubt the integrity of the artists who create these. Realize this is their craft and appreciate the talent it takes. They do not create the demand for art and beauty. Even Reality TV is enhanced reality. No one wants real reality. Have you seen the "depression channel"? It's all footage of people starving, death and dismay. Commercials just flash up, "You are slowly dying. No one will get out of this alive." No, we can't stand that emotionally in large doses. I don't think that cable channel is likely to exists soon. Even the horror films that get popular are almost never situations very close to reality. People who love to be afraid enjoy the excitement, but if it's too close to home they no longer have the sense of relief that it isn't them. What does this have to do with testing? I've noticed two main schools of thought in testing. We have those who believe in giving managers and stakeholders a false sense of security in our testing using measures and statistics. Then we have the context driven school of thought who are much more in your face about presenting an unenhanced version of reality for others to deal with. I don't believe I belong with either group. I see myself somewhere in the middle. I'd like to present both a polished view with some science basis, and explain what it is based on and let others make their judgments. Bringing reality to the table IS part of my job, but that doesn't mean I have to bring the harshest reality in a blunt presentation to the table. I am certainly tough enough to handle confrontation when needed, but unlike some people I've met, I don't enjoy it. I find it makes future collaboration more difficult. I also understand that there is a need for art, beauty, and false reality that is born into us. We all have imagination. No person is all science and all fact, at least no person I'd invite over to my house. Who is to say how far we can impact reality with our ideas and imagination? I'd hate to find out what the world would be like without it.

The Paperless Office

Testy Redhead — Wed, 22 Oct 2008 08:59:58 GMT

When "The Paperless Office" was mentioned at the conference it hurt to hear everyone laughing knowingly at what a failure it is. I wonder if people making automation to replace testing feel that way yet. I got to thinking of how they compare and why it is folly to dismiss them wholesale. Far be it from me to point out the ways that automation is useful, but when it is done responsibly it has great purpose and potential.

1. The goal should be go as "paperless" or as "automated" as makes sense in the context.

While our office isn't entirely paperless, things have changed a great deal in the last 10 years. Insurance forms are done online. Taxes are done in PDF format. PDF format was created with the understanding that the ability to print is IMPORTANT. That's what makes it such a great technology. I think I was the only person who freaked out about the first version of Acrobat. My immediate reaction was "It looks exactly the same on ANY platform? Imagine the potential!" The fact that it doesn't make sense to go entirely paperless doesn't mean that it isn't worthwhile to try. Any progress we make saves money, time, mess, and trees.

BVTs need to be automated so that they can cover more builds in more languages at any time of the day to speed up testing. It just makes sense. Why should one person be mindlessly running the same basic tests on every build and holding people up to start real testing? I really think there should be a rule that until your BVTs are good enough to catch 100% of untestable builds without human intervention that you can't move on to automate anything else. This is the single best use of automation that I've seen and until it is good, time of humans is being wasted. Any software company that has fully solved the time wasting problem of bad builds from code checkin out to final media without human intervention, without false pass/fail results can be very proud even if they don't automate anything else.

2. Even as people knowingly laugh at failure, change is happening. Results are being enjoyed.

Almost all offices are more paperless than they were and almost all companies have more working and successful automation than 5 years ago even if it falls short of the paperless and fully automated world some people imagined.

So, welcome to the paper reduced and automation enhanced world already in progress.

On a very personal note-Long, about surgery, healthcare, and other non-testing stuff:
I am trying to think of how to solve my own paper issue at home. My medical paperwork is an absolute mess. I can't find what I need. My healthcare account card was suspended because I couldn't find the receipts they wanted while I was recovering from the worst surgery ever. I have decided this year to give up on having a managed healthcare account which is the most scathing review I could possibly give the company who "manages" my health care account. I know no other person who needs a medical account more than I do, but they make it so difficult that it isn't worth my time. Instead, this year, I intend to pay for what I need, collect every receipt, scan it in, and deliver it to my tax guy at the end of the year for a tax discount. I tallied up the time I spend trying to jump through hoops, find claim forms and come up with my own medical codes to file claims, calling to substantiate that NO, this wasn't due to and injury, same spine problem. I spend HOURS every month on this task and now I have to get all of my prescriptions rewritten for mail order to avoid paying $260 a month more in copays in 2009. I need a paperless system so that I can search by date, by place, by doctor. For my own sanity, I need a digital solution. I can't deal with all of these receipts while also managing my health. I already have 3 doctor's appointments per month, 2 hours of Physical Therapy appointments per week, 30 minutes of exercise appointments each day just to stay functional. Because of this I took today off of work. I put off going to the dentist and getting my vision checked for an entire year because I'd already missed so much time on my project due to other health problems.

I have to help myself, so for that reason I have taken today off of work to get my affairs in better order. First, I'm going to the dentist, getting my blood work checked, and I'm having surgery next Wednesday on my good leg, so I will be gone for awhile. I forgot to mention that almost a year ago I stubbed my toe so hard that I tore the tendon out of my own toe and still walked on it for 6 months before getting it checked out. Compared to the nerve pain it barely hurts although it does make it hard to walk. I am having my toe surgically fused next Wednesday so it will stop swelling and I can walk more normally. Everyone knows how amused I am by robots, so now I'll be slightly a cyborg (we can rebuild her). If only they could replace my spine it would be amazing! It's going to be a riot to see how I walk with partial nerve function in the right leg and a healing "boot" on the left foot. It gives gimpy a whole new meaning.

Anyhow, I am coming up with a plan so that I don't end up compromising my health during my next project. I love working on software. I don't want to end up having to change careers to an industry where it is easier to work part time. Part of how I survive is that I've trained myself not to panic. I have divided up my brain so that I can focus when in pain and talk to people. We all have pain at some point in our lives. I just have practice living with it and accepting it sooner than most other people do. It seems that this year I've pushed it past it's useful and safe limits, however. By ignoring an injury that needed help and by staying on a medication with a 23 day migraine side effect until I ended up in the hospital needing an $8000 medication, and by losing 15lbs unintentionally so that I have no buffer if I do get sick, I have put off reaching out for help too long in my desire to keep living a normal life despite physical challenges.

I am very thankful that I have the means to pay for the medical care that I need and that I have insurance and a great support system. That said, I am sad and worried for those in our country and around the world who do not have access to health care. Until each person who is sick is able to get healthcare and medication, I'll be voting with them at every turn. Healthcare is not a privilege in my world. It's a basic necessity. Those with great need currently have no voice. It impacts all of us and lessens us as a group when the weakest are blamed, ignored, and rebuked. I know all too well how easily I could become bankrupt due to my health. Last year even with insurance I spent over $20k on healthcare. Without insurance I would have lost my home.

Measure the Quality?

Testy Redhead — Tue, 21 Oct 2008 12:25:49 GMT

Measure everything of significance.
"I swear this is true. Anything that is measured and watched, improves." -Bob Parsons

I think the opposite also has to be considered. Be careful what you measure to make sure it is the MOST important because you are robbing the unwatched areas to put focus on the area being measured.

I believe that there are only 4 important measures of quality in software.

1. Customer Satisfaction.

2. Sales verses the last release and vs the competition.

3. Costs of creating and maintaining the software overall.

4. Total cost of tech support.

You must raise number 1 and 2 without sending 3 and 4 higher, or you can reduce 3 and 4. It's a choice much like you get with food and ladies. Healthy, cheap, and tasty. Pick any 2. Pretty, Smart, or Laidback. Pick any 2. I am sure there are some exceptions where you can raise 1 and 2 WHILE reducing 3 and 4, but in general it's tough to do.

Common Measures	My Opinion
Test Cases Passed/Failed	Waste of time
Number of bugs written	Total Waste of time
Number of bugs fixed	Can be useful if you know where and use this as a way to judge risk
Lines of Code Covered	Can be useful IF used wisely with known numbers for 1-4 above. Those trying to get to 100% deserve rebuke.
Percentage of test cases Automated	Total waste of time. I realize that people measuring this way just don't understand and aren't really evil, but I have to remind myself.
Duplicates	Only of value if used to determine how many testers noticed this bug.
Number of crashes	Somewhat useful if taken in context.
Days/Hours/Weeks/Months/Percentage of up time or mean time to crash.	Very useful if this is critical for the workflow of the users. A good measure taken in context of items 1-4 above.

I am pretty sure there are hundreds of ways to measure if not more. How do you measure? I have reasons why and abuses of measures I've seen for each of the items I think are harmful to measure. I am hoping that you can convince me otherwise. Explain to me why these items are worth the time, effort, and expense to track?

p.s. Whomever found this blog by searching for testyredhead and boyfriend, I've got one, but you should read my blog anyways! I swear I am qualified to make a testing blog, boyfriend or no. I'm a very difficult woman and certainly am easier to talk about testing with than to date.

When you hear hoofbeats do you think Zebras?

Testy Redhead — Mon, 20 Oct 2008 14:44:12 GMT

The last few days I've had a chance to help some customers with a few issues. As one of a group, I remember my tech support days and it troubles me that some engineers (both developers and test engineers) seem to be missing the basics.

When you hear hoof beats, think HORSES first, not zebras. All of these elaborate possibilities are considered rather than finding out by covering the basics. While I don't believe we should EVER be condescending to the end user, it's more likely we are missing some of the basic information than that some elaborate and exotic situation has caused the software to fail. When isolating a bug or troublshooting for a customer-look for the following first.

1. Scope
-How large is this problem? When did it begin? Has it always happened? Does it happen with other software? Can we even reproduce it? It is operating system or hardware specific?

2. Expectations
-Does the software even do this? Is this a workflow we expect to be supported? Many times as a customer or a tester we are expecting the software to do something it isn't even designed to do. One customer was using a server 3 versions old! That was never expected to work or tested with this version of the client software. Rather than all of these elaborate zebra stripes painted on the client, we needed an upgrade to the workhorse server badly. They can upgrade and migrate the data fairly painlessly if they know the server is the issue. GET the versions on everything. Investigate first, act later.

3. What is happening again?
-I will say as users go we have AWESOME users. They give us screenshots, exact errors, and often times even log files. Most software companies do not have users even half as educated as ours are. They certainly know their business and can show us things about our own software we didn't even know in some cases, however, they sometimes are blinded by their own focus and area of expertise, just like we are as testers. Take a step back from what you KNOW is happening and consider the bigger picture. JUST the facts. What are the experiencing overall. Take out the context and consider just the undesirable results. Not what they told you happened first. Not what they told you happened after. Just what is happening right now, this second. Sometimes they forget to tell you about the many beta versions they installed and didn't fully remove, or the custom plug-ins they have. There are times when just considering the current state you can more clearly isolate the issue than with all of the extra information. It's like one of the story problems in math when you need to strip out the irrelevant information in order to discover the answer.

4. What is our goal?
-Does this customer need to meet a deadline? Are we looking for a solution, or a clear problem? What do they need to accomplish? Can we do that a different way to help them first, and figure out what went wrong later? Do they need to get up and running, or can they help us understand what went wrong? Is what went wrong even important if we can fix it? Many times a problem will not be common and we can get them to a better state without even knowing the exact problem. Engineers hate that. Sometimes it will drive us crazy NOT KNOWING, but we need to give up and focus on the overall goal. Not in solving the puzzle, but in solving the problem at hand.

Are you testing for zebras as the herd of horses run by unchecked because you want zebras and they are more exciting? Are you looking for that bug that is a beautiful show pony when your workhorse is suffering for it?

This week I've had to ask myself these questions to get on the right track. What is important and exciting to us as engineers and technologists may not matter. Sometimes we have to get over ourselves to get to a solution and be the most useful.

One last thing, last week at PNSQC my co-worker and fellow conference attendee told me that someone at the conference said in surprise, "That's the redhead I saw you with?" in shocked tone after reading my paper. I asked her, why is that? Do I not look like I can write a paper? She just said, "Well, I think he was surprised because you are pretty." Of course I guess that was a shock to me because I don't see things that way. I am used to just being me. I am not always the same and while I enjoy makeup, glitter, and being girly, I don't see that as what defines me. I simply don't understand why anyone would want to be limited by that. One thing I've always loved about software is that what I look like isn't all that matters. I can be judged by my work and my mind, and my value isn't based just on what a look like. As a female this is one of the things I value most about being in software and being an American. I feel like I am not limited or forced in to one role because of my gender or what I look like.

I had someone ask me if I've ever tried modeling and I laughed. I said that I am interested in fashion, beauty, and art only as a hobby. I've never quite understood why some people place so much value on youth and beauty and I find it interesting. It isn't the top thing I value and it isn't what I consider the most important thing about me. I consider my appearance to be only a hobby and not very important for a few reasons. First, because it is something that doesn't last. I hope to age with character and grace. Secondly, because there is no winning. If you let what your appearance define you, you always lose. There is always someone younger, smarter, and more beautiful. Also, I know that despite the love of friends and family, you really need to be 16 years old and very emaciated for that job, and I'm nearly 2 decades past and on occasion I enjoy snacks.

The best thing about me has always been that I have heart and am sincere. I can't do better with intellect or beauty. I know that I am not one of the best minds in all of software. Many people are vastly more technical the intelligent than I will ever be. I know that I'm not one of the most beautiful people in all of the world and what I do have in terms of external natural decoration is not all my doing. I was born brightly colored. That isn't something to be praised for or that I pride myself on most. My ideas, my real accomplishments, the goals I've reached, that is what I'm proud of. Who I am as a person, and what is unique about me as an individual are what continue to matter over time, and that is what I appreciate and remember when someone else notices. While I can't deny that I need to hear that I am pretty and appreciated as much as the next girl, or that I have some brain activity going on, these are not the holy grail to me or "what I want to hear". I've been told that you should always tell a pretty girl that she is smart and you should always tell a smart girl that she is pretty, and you should always tell any man he is sexy because they all believe it no matter how far from the truth it may be. While in general that may be true and it may work most of the time, that isn't what I seek or value, and it isn't what the people I respect the most and aspire to be like want to hear. For me I just want to hear that you value my ideas, my work, and my contributions to the world. That you see and value me as a human. More of that interaction could really change the world, and not just software.

Dangerous Assumptions

Testy Redhead — Thu, 16 Oct 2008 17:27:46 GMT

Alarming-Like a bucket of water over the head

One of the best things I'm taking home with me from pnsqc was the one paper presentation that I left a red card for. The speaker was nice. No problems at all with the person. The red card wasn't one bit personal. It was the dangerous assumption that their company made and was proudly sharing. They assumed, as a large and experienced group, without asking or verifying that the main thing that caused customer dissatisfaction was stability. This was not based on customer surveys, user research, or really anything at all. I know because I asked. Shocking!

The time, money, and effort they spent to reduce crashing was VAST. It raised customer satisfaction less than one percent! They still don't know why their customers aren't satisfied. Really? This is a group of smart and scientific educated people, but where is the common sense? Heavily investing in a solution when you don't understand the problem is a very common mistake.

It is part of my job to stick my neck out and give the red flag. "Hey,..wait a minute, did we ASK the customer? How do we know? What proof do we have?" What if one person in the first meeting had said instead, "The idea that stability in the form of crashes (that can be logged) is the main cause of dissatisfaction for users of our software is an interesting THEORY. How should we verify that, Bob?" (See, much like the movie Office Space, the person who stated this idea as fact has to be one of The Bobs).

So, I ask you, what research do you know of that explains what the leading causes of software dissatisfaction is for users? Does it vary widely by industry? Does it vary by program? If no one has studied this, how is Fortune Magazine able to write it's annual "Most Admired Software Companies" article? Are we just in business for the stockholders now, is it the awards our product gets? Is it the reviews, or the sales? Of course not. For the long term, we need satisfied customers who will recommend our products to others AND buy it again. How can we fail to gather data in this area? I'm just saying, this hole is a huge gaping one and it struck me, right before I slipped in the red card, which may not have been entirely fair, as I think this mistake is common in quality. What else are we assuming as "common truth" that we aren't even bothering to verify? This isn't just bad science, this is bad for software quality.

Comforting-Like a cup of tea

The best thing I learned wasn't from a speaker at all. It was from the conference participants and volunteers. There is something amazing about PNSQC and CAST that some other conferences don't have. It isn't commercial. The reason I went to this conference is not because I have an agenda. It is because I have true passion that needs to be shared for collaborative testing. These are very like minded individuals who sincerely care about the profession of testing as a craft, not just as an item to be sold. That is refreshing. Someone asked me why my blog wasn't on the corporate website and why it wasn't somewhere free like blogspot. I didn't want to advertise and I didn't want to edit. Personal content has "no place on a corporate blog". What? I can't write an interesting blog in my own voice with strict "on topic" rules. If you've met me in person, staying on one topic isn't likely. I try to be myself wherever I go, and in real life, I'm crazy about computer software. I have been since the early 90's. I don't share my ideas so I can gain profit and clicks from my google links, although I'm sure it wouldn't be considered that rude. When you come read what is on my mind, I think you'll know that it is real, it is candid, and as one of the paper reviewers said, I am colloquial. I pay a small fee for this website, to own it, because it is worth it to me that you can read what I say and interact with me here and know that I'm talking to you as one person interested in another about testing and not with any other agenda. This blog is for software quality, and nothing else.

Spoiled-Like a cat lounging in the sun

Before I sign off, I must say, WHAT A DAY! CS4 is now shipping. The larger team sent me flowers! My boss gave me a prize, and I was able to thank the people who helped me put together my presentation and share the news. For those who were not there, I did the encore paper presentation to close out PNSQC last night because Karen Johnson, who was voted first place for her paper, had to leave. She was an invited speaker who also taught an all day seminar the first day. Because I came in 2nd place and she wasn't available, I took the "Best Paper" honor in her place. You must admit, for a first time paper writer and conference presenter, that's basically a Cinderella story, with a few less seamstress mice. I am beyond thankful for the opportunity and will share the link to the presentation since the encore presentation was recorded and will be shared on the cpnference website in a few days or so.

Hello from PNSQC

Testy Redhead — Wed, 15 Oct 2008 07:52:20 GMT

How did it go?
A++++++++++++ Would present again.

While it may be hard to understand all of it, here's a version of the PDF slides from the presentation.

Well, the way it went exceeded my wildest expectations for my first time presenting. I got a little sweaty at first as I was scared, but once I relaxed it was great! There were about 100 people I estimate and they nodded, applauded, seemed to understand, and even laughed a few times. I felt very appreciated by all involved. I was still chatting with individuals and answering questions when the next speaker was ready to start! One person asked about my book and I cracked up. I have never written a book. My team of 4 people (including me) are testing the Creative Suites as a whole. I have had no time to write a book between that and The Worst Surgery Ever™. Gretchen told me that I have talent at speaking, but since she is my teammate, I assumed she just liked the topic and was biased. However, someone else told me I had talent at speaking that I never met before and meant so much to me! Now I believe Gretchen that it was a great start. While there are always things to improve, I'm happy my first presentation went well.

There are a few minor issues with me personally on my travels. First, I'm experiencing problems with the nerve pain, so if you see me limping around or laying on the floor today, that's why. The reason is, lots of sitting in less than ideal chairs. Because of the pain I'm nauseated, so not eating much. Gretchen is about to burst a blood vessel with my non-eating and chatting people up during meals. She and I will stop for hearty potroast on the way home at the Country Cousins (a.k.a. The Kissing Cousins). If you'd like to learn more about our journey back to Seattle, you must visit the website i5slog.com.

Regrets?
I didn't know how amazing the audience would be. I regret not leaving double the time for questions. Had I known how many SMART, awake, and cool people would be coming I'd have chattered on less and listened a bit more.

What Now?
I decided to write this paper and speak because I really am passionate about collaborative testing. If you came and saw me speak at PNSQC and want me to come chat with your team and see about starting up this type of testing, just let me know. I'll do what I can to help out.

Also, when I get back home I'll meet with Erin to discuss writing our abstract on reducing test case bloat to submit for PNSQC 2009. I feel we can't be ready for the future until we've dealt with the bloat from our past. We may be done with the past, but the past isn't always done with us. That's what this paper will be about. Reducing the bloat with an acceptable amount of risk so that products with a past can move on to their testing future.

Collaborative Testing Lessons Learned from Tribal Bellydance-Part 1

Testy Redhead — Wed, 08 Oct 2008 16:24:15 GMT

I was inspired and reminded of what I've learned from my years of dance lessons by Jonathan Kohl's blog which I check out from time to time although he's more "agile oriented" than I am at this point (so far).

Please check out the Improv performance video of Infusion Tribal Bellydance to get an idea of what I mean.

American Tribal Style is special in that it is an improvisational style of Belly Dance done by groups of women who communicate changes in moves using "Cues" which are seen and heard, but subtle. For those who don't know the tribal vocabulary, it looks like a choreographed routine. It incorporates dance from all over the world taking influences from the Middle East, Africa, Flamenco, and sometimes modern dance such as Hip Hop is incorporated. It's known as American style because of the "melting pot" of dance ideas concept. Also, it is danced proud, without the subservient aspect that some other dance styles have to it.

I have a sticker on my office door that says, "Life can't be choreographed: improvise." I believe that.

There are three types of Tribal Style dancing mainly
1. Practice/classes-This is where you learn technique and the vocabulary.
2. Hafla-Free dances where any number of people dance together at an open jam.
3. Performance-Two or more dancers perform for an audience.

Basics needed to Dance
1. Some amount of natural talent to hear music and some sort of rhythm.
2. Dance posture (this is how to hold your arms and position your body so you can dance without injury).
3. Know a few basics of the vocabulary including the cues.
4. Ability to lead and follow.

I would say these are extremely important aspects to have in testing before you collaborate with other testers. First, you must have a common vocabulary and a good understanding of what you plan to accomplish together. Secondly, you need a firm foundation in test methodology and some experience in testing and isolating bugs so that you are a help and not a distraction. While you can warm up by just "following", to truly collaborate as part of the group, you must be able to lead as well and take your turn, adding your self to the chorus and showing your special skills and talent when your time comes.

Some of the key things that make Tribal Dancing work well
1. Cues that are easy to read from the leader wherever you are.
2. Support and positive interaction/energy between those dancing.
3. Able to start dancing immediately! Less time learning exact choreography, more time to dance.
4. Flexibility to change the dance for maximum audience reaction.
5. Varied experience is no problem. Those with less knowledge can learn from those with more and the most experienced can show off in their solo even if the beginners can't follow.
6. No "waiting" if someone can't show, no problem if someone extra shows. So long as you have space and music, the dance is on.
7. More creative than other forms of dance because you aren't following set rules.

A few No No's
1. Know your space. You can injure another person if you aren't paying attention. This is where technique comes in. We all learn to raise our hands while spinning so you don't knock out the teeth of your neighbor.
2. If you mess up keep going. A big picture perspective is vital. What role do I play in the larger context?
3. You must always DO something or ruin the overall look of the dance. When all else fails, go back to the first move you learned and build on it. What is your "Hail Mary" of testing?
4. Failure to cue decisively, lead decisively, or get out of the lead decisively will cause chaos.

PNSQC Presentation Prep Status

Testy Redhead — Mon, 06 Oct 2008 12:25:00 GMT

I've been working my tail off to ship CS4 suites as well as get my technical paper presentation ready for PNSQC. My co-worker Gretchen and I have our rooms all booked and transportation arranged. I am lucky enough to have a chauffeur (Gretchen volunteered to drive) for this event now so hopefully I'll be in less pain when we arrive. My role will be navigator/beverage girl. We will arrive in time for the Monday night festivities, so if you are going, please look for us! I am going to post a photo in this blog so you can find me and say hello, and even introduce yourself.

Version 1 of the slides turned out to be 19 slides. Then they announced CS4 shipping and I revised them with new examples and they ended up being 23 slides long. I then found that I didn't like the lack of focus on collaboration and it didn't give enough background for those who weren't familiar with this sort of testing to figure out how we created our documentation or why we did it this way from the feedback I got on Friday during the first dry run. I'm now on revision 2 and I am scheduling several more dry runs before October 12th so that it can be a tight presentation. I'm really excited that I'm one of the earlier speakers, so that I can enjoy the rest of the topics without being nervous about my first presentation ever done external to my company. If you are willing to review my slides, please comment with your email and I'd really appreciate the feedback.

Anyhow, if you are going, please look for Gretchen and I at the conference. I'll be in my reading glasses all day so that I can see people far away and read small fonts.

Anyhow, this is me (yes, this is a super dorky smile in my office on my iMac camera). If I really like what you are geeking out about I might give you this look. Yay! We love Roombas, lipgloss, and StumbleUpon as well as collaborative testing!

In the below photo I've been unleashed on unsuspecting SW Canada. Gretchen is a tall willowy lady (and a brilliant web designer/goddess of all web technologies) with shorter blonde hair. Both of us are pencil necked geeks and a bit on the slim side. Anyhow come say hello, and PLEASE come see the presentation if you are attending. It's in the "testing" track.

Anyhow, definitely come say hi if you are there. There shouldn't be too many people with bright red hair and rhinestones in their glasses. I promised I won't say, "Blog? What blog?"

Organizing Automated Cases

Testy Redhead — Thu, 25 Sep 2008 08:55:59 GMT

Erin and I met yesterday on the topic of reducing test case bloat. While on her team Automated cases have not yet grown to the level that they are causing bloat, I'm worried about it as a potential problem. Automated cases are no different than manual cases in the fact that they take resources and time to maintain. It may be free to run them each time once it is set up, but fixing them when they break and going through false error reports is a huge time sink and that adds up to real money a company is spending.

For that reason, I believe we should set up a better process for reducing test case bloat for automated cases. What strategy does your team use? Are you using the addition method like we are? Just keep adding more and more cases, never remove any? How long have you done it for? Is it still working, or is it causing madness and wasted time/effort?

I think the idea that we should always add more automated cases is based in false assumption and we should only bother to run and maintain the most important automtaed cases. What would you use to pick the optimum set of automated cases to run?

Beyond the Requirements, Beyond the Bugs

Testy Redhead — Tue, 23 Sep 2008 12:05:14 GMT

Requirements-Not to be Taken as Scripture

I've been thinking of the important reasons to go beyond testing "to requirements". I've fought for and gotten 3 bugs fixed recently that are clearly stated as "not supported" in requirements. You have to make sure you have a good case for how many users it will impact, how leaving this as "unsupported" makes the product/company look bad, or has a negative impact on adopting the technology. Something like "_____________ happens when you use _____________ with _____________" and explain that ________ people use ___________ and the interaction is likely with __% of customers potentially having (customer impact). I find it helps to say that it is a usability problem and not a code bug so that it isn't instantly closed "as designed". "As designed" is no excuse if it is harmful to the user experience. I don't really check my deferred or closed "as designed" bug count or feel it is a problem to be corrected. I've had bugs closed "as designed" which were later huge customer complaints that got fixed in dot releases. I don't feel bad about having written those bugs. They were not a mistake. The key to testing "unsupported" areas and is making sure you know which ones are important, and never fighting for a trivial bug needlessly.

I attended some training where the teacher told us that it isn't our job as testers to be involved to this level and that those sorts of questions should be raised during requirements review. I agree that test needs to be involved in requirements review, of course, but some situations come up long after the requirements are set. How about new environments or technologies that become important? The web moves faster than our product cycles, so you have to be flexible and adapt as things change. I just realized, I seem to be making an argument for agile development as well as going beyond the requirements.

Keeping your mind active and the user first is always better than feeling "good" about the scope of your testing. If you are sure you did everything in "your area of ownership", but nothing beyond it, that isn't good enough to promote quality improvements.

On Bugs

As a test lead, I've had testers get really caught up in what their "bug count" is, or what percentage of them gets fixed. I hear little about what disaster was averted, or how important the bug was. Bug impact should be just as important as number of bugs. One high impact bug can be much more important than 50 bugs found. Don't measure your progress just in bugs. All it takes to have a high bug count is a very careless Dev counterpart. Testing talent isn't measured just in bugs. It should be measured on the improved overall quality going out the door. In fact, moving your testing upstream can be one of the most positive ways to impact quality. I'm pleased to see that happening more and more at my company.

Me, Company, Products, Presentation

In the past I haven't included anything about my specific company to avoid unforeseen problems. I'm speaking soon at http://www.pnsqc.org/ and put my blog URL in my profile, so who I am is now public domain on the internet. Please come see my presentation if you can. It is in Portland, OR in the Convention Center on Tuesday, October 14th from 10:15am-11am and is in the Testing track on the schedule and is called Testing for the User Experience. If you would like to read my bio, here it is.

My products were announced today! Well, I suppose since they are most of the work for an entire company, they aren't just MY products, but I'm proud as a new parent, so I consider them "mine".

Anyhow, do not ask me for software. I use my employee discount yearly to raise money for the MS Walk, and I adhere strictly to the rules. All money goes to my charity, the MS Society. My sister has MS and has lost vision in one eye due to it, robbing her of depth perception. It has a devastating impact on my family, so I'm very interested in finding a cure. Those who join my MS Walk team get first choice.

This is NOT a corporate blog or it would be hosted on the company website. These are my opinions as a tester in general. I do not speak for my company, but only for myself on my testing ideas, my career growth, and software in general. I'm proud to work on all of these products for the past 8 years as I used and loved them long before I ever worked on them. The things I love about blogging do not fit into a corporate blog easily. I think the company I work for is the best place to work in the industry.

Reducing Test Case Bloat

Testy Redhead — Tue, 16 Sep 2008 12:38:51 GMT

I'm meeting up with a long time colleague next week to discuss my ideas for reducing test case bloat. I thought I'd share my ideas with you all in hopes that you'll share your thoughts with me as well!

Here are my ideas starting with the most common and ending with my favorite ideas.

1. Pairwise testing-Make sure to screen with equivalency cases.
2. Tiered by importance-Create a frequency subset based on risk.
3. Change based-Do a second pass and add more to lower priority tiers based on low risk due to code change.
4. Timing based-Ignore some test cases until major code changes are made, so schedule WHEN the testing will have maximum impact. If it isn't that time window, plan to ignore those tests.
5. Performance of the test case -How many bugs did that test case find last time? Tier accordingly, if low risk and low impact, ditch it.
6. Complexity-How many code paths does this test case cover? I prefer one testcase that covers maximum lines of code over a simple case.
7. Model Based-Draw model using UML. Map out which test cases cover what. Based on risk and planned code changes, assign tiered priority that way. Lower priority/low risk goes into "if time allows" bucket.
8. This is what I actually do-Use customer surveys and ask product marketing and project managers what their "top features" are for this version. Use actual usage data to prioritize tests-How many customers will this impact? If very few, ditch the test. If many, automate as BVT. Try to automate at least the top 5 for testability of basics. Set out in test plan what new features and what legacy workflows you are protecting and what you are ignoring because they aren't important enough. Recognize the RISK and get the guts to not test the low priority areas and get people to sign off on it. If the test doesn't fall into one of the most used workflows or one of the top priority experiences that the software is delivering, it can't be a tier 1 test. Tier 1 means that the test failure will stop shipment of the product. Tier 2 should be ran until RC submit. It means that if there is time, most likely it will be fixed if the test fails. Tier 3 means it may or may not be fixed, but would be good to know about. All of this testing should be complete and abandoned (as finished for the cycle) before RC submit.

So, when you have infinite paths which could be tested, what makes sense for selecting test cases? In my situation, testing between products, my assignment is too large to do model based testing, or I would. I think it is a fantastic way to arrange tests. I hope that there are other ways to prioritize and reduce bloat that I missed here that some of you can share with me and I also hope some of these help you get some new ideas.

I tend to agree with James Bach when he says that the best test case is the one that hasn't been thought of yet. Never let your old test cases take priority over the new. Just like the girl scout motto, but a bit altered. Make new friends, but keep the BEST of the old. One is silver, the other is gold, the last one is growing mold.

How long is too long?

Testy Redhead — Tue, 09 Sep 2008 15:22:46 GMT

Never get too comfortable. Always be looking to the future.

This is advice I take to heart, but I'm not sure how to express it sometimes. I'm still learning and growing. I wonder if it really is ok for me to continue working in a job with the same name for so long. It's been since 2006 and my job title hasn't changed, but my abilities and duties certainly have. I'm happy with what I'm doing, but I feel like I can do even more. I want the chance to do more. I've tried asking what I have to do to get more opportunity and the answer I hear back is that I am doing these things and I am performing well. That I have to keep my eyes open for an opportunity. I have even asked flat out if I need a different degree in order to go further. I don't believe this has anything at all to do with my gender or me personally, but with the software industry.

I think I need to search inside myself and figure out how long for. How long does the "grow, prove yourself, wait and see" last for? Is 5 years too long with the same job title? Have I already hurt myself by waiting too long? Has my company loyalty limited my potential career? Would I do better to get some variety of experience? I am so deeply invested in my current company and I love the software we make. I always thought that was a great asset. Now I'm not entirely sure that it hasn't clouded my logic. Did I already choose wrong? Some of my favorite people, people who have talent more in line with my kind of talent have already left QE and gone to Program Management. Am I making an error by not transitioning my love of the software we make to a different position? I flat out love doing testing. Is that no longer important?

I've been asking these sorts of questions. I asked this week if it was important that QE Developers know how to use our software and can advocate for the customer. The answer I heard back was not what I had hoped for. I heard that QE Developers need to know testing so that they can understand THEIR customer, which is the "product tester". Ok, but since all product testers also must code, shouldn't all coders also know the product? Apparently it isn't that important.

When I see survey results change in terms of employee satisfaction, I wonder, how much of that is change in employees and getting rid of anyone who isn't satisfied or doesn't agree? How expensive was that turn over? I mean, I hate working with a bunch of negative nellys myself, but replacing independent thinking collaborators with yes people is dangerous to the company and bad for quality. This is the way of business, I know it, but it does feel wrong to me. Overall, I very much trust the decision makers at our company. They make good business decisions. I sometimes feel like the right business decisions for the short term are not good decisions for long term quality.

I'm getting these things out of my head because I have to be positive. When decisions are made that I don't agree with, I realize I have to focus where I can make a meaningful impact on future quality. I take my responsibility to fight for better quality very seriously.

While approaching a new corporate year, I'm feeling really good personally and inquisitively confident. I'm feeling like whatever happens, I will react and my future will be bright. My worries are for my company which I still love, and I wonder by deciding I want in for another year if I'm harming myself. I know I'm not harming the company by staying, in fact, I'm confident I'll be able to be a big positive in my org this year by bringing passion, excitment, and new ideas. Will it hurt my long term potential to do it?

How long will I feel like to some extent I'm waiting in the wings? I hope some day soon I post here that I've taken a new position in the company and that it is a huge challenge for me, but I'm happy to have the chance. I want to do something that really tests the limits of what is possible for me. Can I find that chance in my current position somehow? In many cases I've had great support to try new things from my managers which has really helped me grow. Right now, the closest I've come to getting in over my head is by presenting outside of the company for the first time. It could be that the only opportunities that exist are not going to come to me. If so, I'm going to find a way to come for them. But for now, I'm watching, I'm waiting, somewhat patiently.

Dealing with Bugs across Teams

Testy Redhead — Mon, 25 Aug 2008 18:32:03 GMT

One of the biggest challenges my team faces is getting the bug to the right person. This seems like such a simple problem. You just properly isolate the bug, and enter it in the bug database. What could be easier?

Just about anything when you are dealing with dozens of products, at least that many shared technologies, and now, more than ever, a number of services which are on an entirely different product cycle than all of the standard desktop products.

I got a chance to work with an amazing intern who recently became an employee on a new tool to make version of components and products easy to verify and detect problems with as it became impossible to do manually with any accuracy. Now, if only I could make it crawl our bug database and detect when any bug was sent to the wrong person or team, we could save major money. But the problem is, with a lack of consistency, there is a twisted web of logic to follow.

Who owns this problem? The first step to finding out is isolating the bug. Can you try it directly on the server? Does it happen from multiple products/paths? How about multiple operating systems/browsers? Other software that is released? Did it happen in earlier versions?

How about coordination? What if the service update on the staging server isn't testable live until well after you ship a product that it should work with? What will the experience be? What if that item is delayed? It's easy to let another team know that you'll provide no testing and call it a day, but ultimately, you need to know what your customer will experience if your product interacts.

So, here are some things I find useful in getting a bug to the correct place.
1. When in doubt, ask in email to all of the QE owners for the possibly responsible product/technology/service, and set the bug status as awaiting information if it is not urgent. You can network this way and learn how they isolate where the problem is happening. You may find that they have a tool that you don't.
2. If urgent, write the bug for the part that ships first and email the dev responsible. Be as factual about the impact and isolation information as possible.
3. Ask how they determined where the bug was so that your skills improve at routing the bugs and you can save time in the future. Sometimes "there is no way to tell without more access" is the answer. If they choose not to give me access, they get a few more emails.
4. The bottom line is now the top line. Be concise and link to the information for all of the details. If you are going with the product that ships first as your default in cases of urgency to be the best possible customer advocate, you are putting your reputation on the line. Waste as little precious time as possible and make it count.

Be a fountain, not a drain.

Testy Redhead — Tue, 19 Aug 2008 10:59:00 GMT

This only relates to testing if you are working on teams, with other people, or trying to attract people to your team for collaboration. I didn't come up with this saying. I saw it on a small rural city church sign 7 years ago, but recently have been wondering why it keeps coming to my mind and why during times of difficulty it resonates with me.

I'll start with the simplest reason that I've always identified with water in that it is unsurpassed in strength, flexibility, usefulness, and beauty.

I don't want to just be a fountain. I aspire to become this fountain, one of the most ambitious, lovely, appreciated, and well resourced fountains that does great good for the city of Rome:

1. Useful: A source of refreshement and vital life sustaining force. Also a source of comfort and fun.

2. Enduring and self-sustaining: Under many circumstances, when properly designed, fountains remain useful for hundreds of years.

3. Able to accept input of varied intensity and still output something beautiful, safe, and useful. This is a hard one for me. First off, you must be selective about where you get your input. If it is from somewhere unreliable or contaminated, you may stop the fountain's function. It's said that the original aqueduct of Rome's source was found by a virgin. When in doubt, get your input from the innocent, but built with experience.

4. To function well, fountains need to be cleaned and maintained and on occasion repaired and rebuilt. It is worth taking the time to do this so that they can serve the greater good.

5. The water is part of the beauty, but there is beauty even without the water. When the water isn't flowing, the potential for usefulness doesn't go away.

6. The outdoor fountain is fed by and in tune with nature. For the fountain to remain functional and useful, it can't be protected from the elements. It depends on the elements.

Blatent Disresepect for the Rigors of Science

Testy Redhead — Tue, 12 Aug 2008 09:12:17 GMT

Long time no write! I'm finally back from the most awful surgery of all time™. I don't remember the first 2 weeks after it, and quite honestly I've only slept 10 nights uninterrupted in the last 49 days. The good news is my surgery is a modern miracle of science and my 60" of incisions are healing up like a champ although swelling remains a major problem. I start Physical Therapy today, thus may spend tonight in the land of Nopantistan due to swelling. It's possible I'll lie belly down on a slab of ice like slide around like a penguin, but with my laptop so I can finish my paper.

Well, back on topic, I'm working on my "Technical Paper" and have been. It is due on Friday. I was stuck, stuck, stuck. My boyfriend helped me identify the problem by talking it out with me. The problem is, per the usual, I think I am a unique and special butterfly. Because I have the charisma in person, I don't feel I should be required to dig mud in the trenches with everyone else. I call it "pretty girl syndrome" and it's shameful. Yes, in addition to the surgery, I was having an arrogance problem.

Me: I don't want to write a scientific paper! I never did. My presentation kicks butt! All of the people who saw it (both teams) joined us for the next test exercise! Can't they see that Collaboration has little to do with making my paper boring? I feel like they are trying to limit creativity. Why must all square pegs go into round holes? My paper is going to be boring and dull and changing it this way is not going to make the presentation better. Besides, I feel like crap, they don't like it, I'm gonna withdraw it, they are going to kick me out of their conference anyhow.

Craig: Listen to you! You have a great idea. You have all of the talent and passion. They ACCEPTED and like your idea and here you are flipping a bird to proper scientific methodology! If you really are too immature to write your paper out in proper form, you don't deserve to give a presentation. You are smarter than this. If you didn't have an attitude problem this paper would be done. I watch you write PAGES every day. Yet you procrastinate because you are too arrogant to put your idea into scientific format?

Ummm. One thing about that boyfriend of mine. He can read me like a book. I already have a new outline and am writing my little fingers off. A little humility and respect for science isn't too much to ask, even IF it makes me feel hostile and bored.

Outline, Introduction, Title Page, and Conclusion are finished. Now on to the meat and "figures".

Working with People-Disabilities

Testy Redhead — Mon, 09 Jun 2008 10:57:56 GMT

I'm thrilled to report that I've just graduated my 6 month training program! Business travel is something I love. Last Thursday, sitting in a hotel in San Francisco, the best meals you can get, and being in so much pain I was unable to leave the room or even eat dinner got me to the point where I have to admit it. I can't travel for business until my health has improved and my pain is under better control.

It's been really bad lately, and that got me to thinking, why would anyone hire a person with disabilities? Here are my reasons why you should, and how to work with such a person, although each person is different. First off, I am a person with a disability, not a disabled person. I have nerve damage in my right leg which causes significant pain. It is not something that is currently curable, so for right now, keeping the pain under control to live the most excellent life possible is the strategy. I believe it will be cured in our lifetime, but until then, it is simply something to live with.

-Hire a person WITH disability, not a disabled person. Know the difference. Does everything "happen to them"? Is it an all day pity party every day? Are they actually doing their part to get excellent care? Do they have a victim attitude? Does the health challenge they have define everything about who they are? If so, it's useless to try. Don't hire. The disability isn't physical.

-I really want to be working. My health problems are severe enough that it is quite possible I could fight to not work and get benefits. I don't want to. I want to be here. Not just to pay the bills. That's HUGE. Having a job helps give me a reason to keep a regular schedule. To get up every day. To keep my personality. So many people with the problems I have just get lost. They lose who they are. They take more and more narcotics and before you know it, they aren't themselves anymore. I don't want to be that person. I'll fight as hard as I can to avoid it.

-I'm more loyal than most employees because I need my health insurance. I can't function without it. Please understand this and never needlessly make me worry about the stability of my employment. If there is a stability problem, please give me as much notice as possible so that I can get this covered. A gap in health care really could knock me out of the workforce long term. It really could change the course of my life in a negative way. I'm a planner, so I have savings to make sure I'm reasonably able to take care of myself in this regard, but I can't be productive if threatened and it just isn't cool to do.

-Give me feedback about my performance just like you would anyone else. I don't want to know if I'm doing good "for a person with my challenges". I expect to kick butt. If I'm not, tell me why not. Don't baby me. A mediocre performance will never be acceptable to me. Throw me to the wolves and when I come out scratched up expect me to be holding wolf pelts.

-Do not measure me in too short of increments. I need to be measured in what I accomplish over a month, not what I did in 2 days. I sometimes have a terrible week because I'm in so much pain it's hard to see. I can't work a long day if the pain is too draining. I'll make up for it just as soon as I can. I need more flexibility around schedule, around how to meet deadlines, and around working from home. You may see me show up at 9am, but you didn't see me get up at 6am, have to sit on the couch waiting for my medication to work to even move enough to get into the shower.

-I can cope with change and uncertainty better than most people because I have daily practice. I don't know if I can make plans, keep plans, or do certain things in advance because of my body. It isn't going to phase me at work if things change. For this reason, having a person that is dealing with disability can be a huge team advantage. Count on me to help other people cope and get them to a place of accepting and working with changes.

-Try to be somewhat sensitive and perceptive. If you stop by my office and my eyes are red, face is pale, and when I'm walking around you can tell I'm limping really badly, most likely it isn't the best day to have a "difficult discussion" with me because it's really hard to hear over the screaming pain. If you do have to have a serious talk, give me 20 minutes warning if possible and at least let's do it sitting down and in private. If I have to stand on said uncooperative leg while having the conversation, it's even harder to focus.

-Never laugh at me or ridicule me or mock me because I'm in pain. Do not assume that if I'm a mess it is because of drugs. Nothing is more insulting to me. I tolerate more pain because of my refusal to be overly medicated so that I can think. It is absolutely cruel and a slap in the face to start rumors continuing this undeserved stigma. If you worry about me and drugs, it should be concern about my lack of them. I can't think straight if pain is out of control.

-If possible, and you have an employee with physical disabilities or chronic illness who isn't doing well, let them know that going part time or having a medical leave of absence so that you can keep them long term is an option, but don't make them feel forced out.

-Employees with disabilities still need opportunity just like everyone else. In fact, they may be more qualified because they are used to prioritizing what really "needs" to be done versus what is optional as they have to cut activities out of the day sometimes.

New Features

Testy Redhead — Thu, 29 May 2008 15:41:12 GMT

I just got my first look at a must anticipated upcoming feature and I'm blown away in a good way and now I am so excited!

I wish that 3 other features I looked at and was disappointed in would be magically removed and every resource used given to this one feature that outshines the rest of them. Why waste engineering resources by spreading them out so much? When a test team is working really hard and their area of focus is just lame, there is nothing they can do that will make people want to use it. However, over here there is a feature with all the potential in the world if the quality is high enough not getting test resources. Software project planning is pretty complex, and I know there are lots of negotiations that take place.

I'd love to have a release where someone is tough and says, "We are cutting half of the planned features and taking twice as long for this project." Not financially viable initially, but what if the half of the features you are doing are groundbreaking and have world class quality?

We have this one feature that has disappointed me every time I've tested in for over 5 years now. In my entire testing career, I had one opportunity to ask a question of our CEO in a small setting. I asked him simply, "Have you ever used feature ______?" We don't have that same CEO anymore. His answer was clear, honest, and diplomatic. He had used it, recognized problems with it, and expressed hope for the future with it. Have you ever spoken with executives? They say more in a few sentences than I can convey with 2 pages of text. That kind of consolodation doesn't happen overnight. They are true artists at communication efficiency.

I'm not sure who in the company is so smart and charismatic that they are able to keep resourced with something so terrible to use that I was willing to use my one question to the CEO to find out if he'd ever used it, but whomever they are, I promise I want to stay off of their bad side, so I'll never specify which feature it was or bring it up to a CEO again. It's caused major resource drain and stability problems, while remaining unpopular with the vast majority of our users. As a serious advocate of usability, this particular feature is a villian in my world.

Anyhow, this new feature I can't talk about. Simple, elegant, fast, easy, AMAZING! What you can do with this is going to make my top 10 list.

I freaked out about chatting in 1993 and people thought I was crazy using the modem and talking to people with my computer. In 2000 I thought Livejournal was very cool and I started blogging. Digital photography was the coolest thing I'd ever seen in the early 1990's and people thought I was misdirected for taking so many photos and never printing them. When PDF format came out I just loved it! How could people not understand how awesome that is? This new feature is that awesome. It's gmail good! I'm giving it extra testing because it earns free testing from me for being useful and for the "cool factor". We should have a tester survey about new features and just ask what is cool. Cool points matter. Who's voting on cool points before we ship new stuff? I want to. I'm pretty good at it! Really! My fellow testers who know the products (not those making automation, but ya know, blackbox testers?) also are good at that. It's an untapped source of information based not JUST on gut feeling, but also on using the stuff. If one features blows another away on cool points, they should get to steal a tester from the loser. I think this may be a harsh awakening for features that need to improve in usability and coolness if they lose resources for bad behavior, or dull behavior.

New product features should be a bit more like dating. Sure, they all look ok on the first date, but as you get to know them, some are liars. Some stop showering. Some start being jerks and cause crashes too often. Some are just too high drama and require resources from everywhere. Then you get some that are so darn cool you drop everything and buy them fancy jewelry and take them to the Bahamas. I think this new feature I love should get a trip to Beaches all inclusive. I think the feature that has been lame for 5 years needs to be dumped already. It would be better for both of us.

If you are a tester, and you're working on something that sucks, don't spend extra time on it. Cover just what you said you were going to cover, do your best to find enough bugs that the feature gets dropped and you can focus elsewhere. Express your concerns about the user experience in the bug database in sensible, well researched, calm terms. If you lose, at least you sleep well at night. As a test lead, I've flat out told testers on my team, "What I'm looking for on this task is fast mediocrity. I know you are talented and good, but please just be fast on this task. Your best needs to be spent elsewhere." We can't all do our best work every hour of every day. Use the bursts of genius where they make a difference. Spend the extra time on those features that contribute more to the overall user experience. Don't stay in your area. Wildly color outside the lines. I'd never test any other way. Then again, I believe there is no picture but the big picture.

Pure Loathing of Software

Testy Redhead — Thu, 22 May 2008 20:10:09 GMT

Today was a brilliant day! I had a wonderful day of work in every way. Dinner was fantastic. Even the cats behaved well.

So why did I just go on a 5 minute swearing tangent including writing hate mail in my mind?

Because it just took me 5 minutes to get a hyperlink into my Word 2007 document. Brilliantly, even the help menu was hidden to protect me from peril!! Hooray! Nothing on the context menu indicating that hyperlinks exist even though I have text selected and a hyperlink on my clipboard. I also need a psychic friend to paste special. Also, hyperlinks are now considered links and not "text formatting". Ok, that makes sense, but since when did Word try to make sense? They have gone so far protecting me from menu items that I can't do anything. It's sort of like the fine security we got with Vista. A great idea, but I'm so safe I can't do anything in this straightjacket. Little harm of me hurting myself (or getting any work done). Someone, please take the protective lid off of my spork?

I casually bring up my lack of joy with the new Word. The TWO users who used to work at Microsoft tell me they LOVE this interface. *blinks* *stares blankly more* I have no response for that. They have some very powerful kool-aid over there. Either that, or it's their policy of hiring only very very smart people. I will admit that both of these people are much more intelligent and patient than I am. They are quite amazing that way. That does however, make them sort of aliens in the American culture. I call this calm rationalization a problem of sick pants. I can't spell sycophant without a dictionary, so I call it sickpants. Too many smart people loving eachother. No one willing to remember that users may HATE your clever idea. This is why you need some testers willing to point out the naked regent about to stroll down the street even if it is career limiting. I want to shake the hand of the one MS tester (most likely a contractor who can't code), who brought up that in the future some crazy redhead who's been using word since the DOS days is going to go on a 5 minute tangent and hate this so much she will blog about it and scare other people. Maybe enough people love it that it was worth making me hostile. Somehow, I'm guessing on that particular product they have more upgrade users than newbies, but that's just a guess.

Well, I suppose at least people notice it? And have a strong reaction? I just want to see the percentages. I'm thinking there are more users with the hatred that I have than the joy and love that they are showing, but perhaps I'm a small (and admittedly ranting) minority.

Here's some background. I stopped watching Lost after the first episode. I do not want to be toyed with. I am not entertained. I know it's a vastly popular tv show, but not everyone loves it. The second they sucked that guy through the airplane engine I rolled my eyes and I was out. Fool me once, shame on you. I didn't come back to be fooled twice. Who are these people who find it fun to feel bad and be tricked? There must be many of them because horror movies are also wildly popular.

I have to stay with this version that I despise. How do I get my menus back so that I don't end up having to go to relationship therapy due to my "angry outbursts"? I may have to seek support in user forums or start using Wordpad and forsaking Word again.

And how do I convince my well intended UI Designer friends that this is no way to treat loyal users and they should never ever do this to the software I love. Really. It may be hip and trendy, but it is cruel. While it may be well intended, and new users may enjoy it, this old dog wants to use this software as a fire hydrant.

Coming soon to Pacific NW Software Quality Conference-Testy Redhead!

Testy Redhead — Tue, 20 May 2008 10:30:34 GMT

My abstract was selected for pcsqc 2008 which happens in Portland from October 13th-October 15th! The theme is collaboration.

I am just over the moon with excitement to be speaking on my favorite topic at a testing convention for the first time. I have lots of work to do before the conference, but I hope that some of you will come out to the conference and attend. Come talk testing with me.

It could have been the Grand Canyon, the training I've been going to, or all of the wonderful people I work with who have been supporting me all year in trying new things, but I'm so delighted to have this opportunity. I feel like I did the day I got my first job in tech support. I have the feeling that the hardest part is getting that once chance, and now I've been given one chance. That's all I really need is the opportunity, and where it goes from there depends on my hard work, dedication, passion, and talent. The part that I can't control (being given a chance), due to luck, due to persistance, due to kindness from other people, has fallen in to place. I'm overwhelmed with gratitude. It may seem like it isn't a big deal to those of you who speak at conferences all of the time, have multiple doctorates, or are published authors. To me it is huge!

One of my goals is to add my voice, my perspective, and my passion for software to the chorus that is constantly changing in the industry. Just as we need people who are brilliant with tools, who are fantastic with numbers, and who are great with theory, we also need people who have intimate knowledge of users, who care about the soul of software, and who never stop fighting for an improved experience when you sit down at your computer to get a task accomplished. I may never be the person who has the most impressive metrics, or who wrote the best testing tool, but I can be the person who contributes some new ideas to protect the less tangible aspects of software that make it memorable and amazing to use, and that is something worth working to contribute.

I've also learned something else comforting. Not being a manager doesn't mean you aren't a leader. Also, being a good follower doesn't mean you aren't a leader. If I believe in the person, I love to follow other people. There isn't any shame in being a good team member. I don't have to lead everything I participate in in order to be happy. In fact, all of the leaders I like and respect are good at following too. I want to remember that as I try new things. Listening and taking feedback is how you learn. Following the right person and ideas is a sign of good leadership and followership, not a sign of weakness or lack of initiative.

Was it fun?

Testy Redhead — Fri, 28 Mar 2008 13:13:22 GMT

My company has something about the culture for years that has been really special. Real substance behind the philanthropy efforts, a very human feel, and a sense that fun belongs everywhere, not just in a play hard, then work hard (mostly work hard), but never combine the two sort of way.

I had a testing assignment this week and last night was FUN! I worked really hard. I found a great problem, and I had so much fun communicating it. It made my whole night and I was late to dinner and I didn't even care. That's the sort of thing I like to work on.

I want to be the person who makes sure as we move to every kind of possible metric to measure a person and a task that fun doesn't go away. Just as the soul of software can be at risk when you make changes, so can the soul of your entire workforce, and with it, what made it special and successful in the first place. If you hire just one type of person, you lose every voice of dissent, and with it, often the voice of reason. It is generally bad to mention anything negative to those above you in the food chain, but sometimes they need to hear it. Otherwise they have a year like Britney Spears and everything's gone down the tubes and someone else has to go in and do a very expensive cleanup. When there is a cleanup like that, it's never announced "someone Royally made some poor choices and apologized and now we are going to fix it". Instead we are just "going in a new direction" and "improving our process". I have a way with words so long as I believe them. My friend will sometimes ask me to rephrase what she says before she has fights with her boyfriend so that they go over more favorably. However, as a matter of integrity, I think if you make a huge error, you admit it, apologize, and explain how you are going to move forward.

I recently found out that pretty much you have to be into code or have a CS degree and significant coding chops to be considered for a QE Manager job. I think that is industry standard. Why does no one ask you to give them a demo of the software they are supposed to be managing, yet they must know the code? Do they even know software has a soul? Do they know that their people do, or are they just good at making charts to show how the metrics are doing?

So instead of conversation 1, you have conversation 2.

Conversation 1
Person 1: "We should make this feature. It's really cool!"
Person 2: "Yeah, but it isn't useful and really sucks when you take out all of the stuff you can't fit into THIS version."

Conversation 2
Person 1: "We should make this feature. It's really cool!"
Person 2: "Yes. I've investigated your coding logic and rate it as "pass". More input Stephanie."

I wish I could walk down the hall at my work and ask each tester what they did this week that was fun and get them all to tell me one thing about the TESTING that was fun. Now something else they did at work. Not a conversation about an idea, but that testing was still fun.

Testing should be fun. I don't want to be the only one who had fun testing last week. Saying this anywhere feels about as effective as peeing into the Ocean. I have to focus on the positive, I had fun this week and I'm still here.

Large Dirt Hole a.k.a. Grand Canyon

Testy Redhead — Mon, 17 Mar 2008 10:29:39 GMT

As promised, I'm reporting out on the Large Dirt Hole from the perspective of the upper South Rim.

I did an exploratory pass of the entire South Rim by doing a quick sanity check on the edge and going in deeper and random points up to the fence at viewpoints as well as looking into binoculars for a closer view. We did climb the tower at Desert View on the far east end for an overview. At first the functionality was overwhelming!

The depth could not be explained in photos or numbers or written comparisons, so I understand why people told me I had to just experience it for myself.

Luckily I had someone there with me who was unwilling to accept the current boundaries. Safety was really not a concern. After watching him go on one life risking stroll after another, I followed him out one area. Do you see in the photo below the portion in the foreground that juts out into the canyon?

It doesn't seem that impressive in pixels, but I walked down a pretty steep area on to the very end with him. At one point I had to step a slight 8" from one rock to the other (see the rock back from the end? Those don't overlap entirely). It was an easy step, but certain death if you slip. For that reason I was shaking. My brother (seen in the red shirt far left in the photo scoping out the place) took my hand and told me that fear makes an accident far more likely and that he wasn't going to let me fall. He might scrape me up by tackling me to the rocks if I start to fall, but there is no way he'll let me fall over the edge, so just get going. I did, and the view from the edge was like no other. I now know for sure that it will never be a "Large Dirt Hole" so long as I get away from the fence.

They have a new 20' "skywalk" to give you a fake experience like this where you pay $25 for what already exists for free. The faux risk will never compare to taking the real one, but I'm sure it will be as close as many people get, and not everyone has someone willing to tackle them if things go wrong and encourage them if they are so afraid that they may stop short of what is possible.

I'd like to report one bug however. The Colorado river is very ugly and brown, unlike the postcards and drawings. As a visitor it was far less lovely than expected and I was shocked to find I'd been looking at it many times, but due to expecting something more impressive, I didn't even see it until it was pointed out to me!

Message received from Canyon: Disguarding boundaries is always important in discovering the truth. Having an experience is worth more than safety. To really know something, standing at the edge isn't enough.

Message received from the River: Having the power to carve an amazing canyon isn't always pretty. Sometimes functionality and looks don't go together. You've got to decide if you want Eleanor Roosevelt or Kate Moss on occasion.

So, on the paper? I've decided to go as far as I can. This means it will follow MY style. It will be personal. It will have jokes. It will have more heart and fewer numbers than most other technical papers. In fact, it won't be a technical paper. It will be an article of ideas. If that is too far over the edge, I'm lucky enough to have backup.

Brilliance Formed?

Testy Redhead — Thu, 13 Mar 2008 09:26:57 GMT

Look for a few moments at "Pillars of Creation", one of NASA's most famous images of the Eagle Nebula.
The most common way the formation of stars is explained is that when a collapsing cloud of material is
sufficiently dense to form the stellar core, the process to form the star begins (nuclear fusion). It is much more complicated than that, of course, but I like to look at the way it begins and think about it in terms of ideas. It is often said that there aren't new ideas. I agree with that to some extent.

I'm in the middle of writing my paper and much of what I've written has been said before. True, but a really good idea or paper takes what exists and combines it in a new way. If it contains the right combination of ideas that already existed, it is indeed a new creation that could serve the purpose of igniting new ideas in other people. I can't let my insecurity that my ideas may not be the most scientific ideas ever to exist prevent me from forming them. Who knows? It could be put out there and not much will happen from it, but I won't know if I decide that only those with a doctorate deserve to write a technical paper, or that only those with more of a reputation have a chance. Only pre-formed existing stars are allowed in the universe? That's crazy talk.

I'm about to go see the Grand Canyon this weekend for the first time ever. I got to thinking, "Why am I paying so much money to go see a hole in the ground? Is it going to be disappointing?" People I say that to look at me with horror. They tell me I just have to see it. It isn't called the "big dirt hole", it's called the "Grand Canyon". I'll report back on how much I think is marketing hype.

No one is going to bother to read my paper if I call it the "big dirt hole". Perhaps some marketing is needed to get people to come and see it. If it is good, word of mouth will help me. If it is bad, I can get feedback and try again. Why would this be terrifying? Only because when I finish it, I face the chance of rejection. Also because I overthink everything I do. How many people out there just do it? Just declare "Grand Canyon" when they wonder somewhere deep down, "Is it possibly big dirt hole?"

Cold Hard Logic

Testy Redhead — Wed, 12 Mar 2008 15:24:22 GMT

I had the pleasure of attending a User Group last night of a product near to my heart. I worked on the first version of it and always was a huge supporter.

During the event the speaker and teacher kept referring to "cold hard logic" to explain that while he could understand WHY things worked they way they did, or could explain it away, that he still couldn't do what he wanted. It made sense logically, but it wasn't intuitive.

This is why listening to your testers is important. This is why testing for the user experience is important. No one cares if your decision makes sense. They care if they can do what they want to easily. They care if they are disappointed and have to use workarounds, or if you provide what they need and more.

Obviously, you can't make all of the users happy all of the time, but if your decisions have to be explained away by "cold hard logic", obviously you've made some regrettable choices along the way. Yes, there are reasons, but the facts must be faced that cold hard logic isn't what is important in life.

Love of a thing or love of software for most of us is how it connects us to people. This is what Web 2.0 is about. This is what viral video is about. Cold hard logic just won't cut it anymore.

The next time I hear a complex explanation that makes sense about why a feature is usable, I'm going to think of it as an excuse. Yes, you make sense, but it still doesn't create a passable user experience, let alone a good one. Not to say that we should be uncooperative or unconstructive in our language or dealings with others, especially well intended developers. I'm just saying, it is our job as testers to represent the customer, even when it doesn't make logical sense.

Protecting Awesome User Experiences

Testy Redhead — Tue, 11 Mar 2008 16:16:32 GMT

I had the honor to visit an office I'd never been to the last few days. I met some people who not
only want to work with my team, but are willing to train and mentor us in something.
They also understand that web creations do not maintain themselves and still remain relevant. The important data is the data added by humans. There is information everywhere, but what do we care about? We care about things that make us feel and think.

I gave a short presentation in a meeting about collaborative testing. I showed one way we represent an overview of a path through multiple applications in complex scenarios. We showed areas where there were some problems, areas where there were serious problems, but we could work around it, and areas where we were totally blocked from completing a task during the collaborative testing. I then told them that in representing it this way, we just weren't good enough. We aren't representing the experience. In order to do that, we must also show what things were delightful. What should we "not mess with"? Just as software can need improvement, I believe it also needs wildlife preserves. If it is something so delightful that it is the only reason many users enjoy it, please, just leave it alone unless that changes. It is fine to add to that. Maybe new options, but do NOT change the default when it is brilliant. The team I met with contributed many ideas about this and they took my overview to play with it. They had never even seen the overview before and thought it was great even without the missing part, but they liked the idea of seeing both.

I'm not sure why we have been ignoring the opportunity to provide this data. It is a huge part of overall quality. Testers, managers and developers assume that if it wasn't fantastic, bugs would be written against it. I've tested some very stable code for a feature that sucked so much to use that I met a loyal customer who was using a script to work around using the feature entirely. Software users ultimately will provide some of this data, as will the market and research. However, as a tester, why not share this critical information? I think it is because it is subjective, and so often rejected as information of value. Collaboratively, however, if we agree on what the top 5 delightful things about the software are when we use it, our odds of predicting user reaction improve dramatically.

I know I harp on this collaborative testing, as it is my passion, but we are getting better at finding the dull subjective data. Does it work as designed? Does it do more than it was designed to do? These questions can be answered with "Yes" or "No". These are things that can be determined with automation.

How do I feel about this software? Is it just fine if this one feature is mediocre? What is the worst thing about using it? What things make me excited to use this? Is it just sort of good, or does it thrill me to the point I am going to tell someone else? These are the questions I want to help answer with collaborative testing.

Currently, the person who writes the most automation in the most languages wins a testing job. I know that phase will go on for years. What then? Where are the thinkers? Where are those with the passion to answer the more subjective questions quickly and with accuracy? I hope they are on my team, coding just enough to get past the trend, using any buzzwords they have to.

First Technical Paper

Testy Redhead — Fri, 29 Feb 2008 13:27:15 GMT

I'm in the process of putting together my first technical paper. In general it is about how you can use collaborative testing to test the user experience. I'm not sure what is going to happen with the paper, but I hope that once it is approved, I can share it here.

If you have any tips for me on writing a compelling abstract, an original and focused technical paper, and/or presenting based on a technical paper, this is my first time. I could use some guidance from the old pros.

In other news, I participated in my first every Pinewood Car Derby. My auto, based on a lipgloss theme, did well enough to make the finals, but did not win a medal. However, I stayed on the track and looked good doing it. For a first attempt, I'm quite proud. I know where to improve next time.