Testy Redhead
http://blog.testyredhead.com
Testy Testy

User Experience Matters

I've been putting off getting a new phone for many reasons. The last time I got a phone was 2 years ago and I got so angry about a text messaging bug that I got in trouble with Craig for cursing and talking bad about Verizon. Craig even argued with me that it isn't a bug, but I told him they had more than 5 choices of how to handle this issue and they chose the 1 worst possible answer for the user. Here is the situation.

When you send a text message from a Razr to any non-verizon phone which has more than 160 characters the additional characters would not fit into one message. What that results in is a series of choices. Either Verizon could restrict the entry to 160 characters if they KNEW the message was going to a non-verizon number (but that would require more work to actually know in advance what network the message was going to), they could alert the user before sending that the message would be lost after 160 characters IF anyone they are sending to was not on Verizon. They could give the user a choice of sending the rest in a new message before sending. They could offer a "settings" option where in this situation a user could set the default to send 2 text messages in this case. Worse, but still useful, they could save the rest of the characters in a draft message if it couldn't be sent. But no. Here is what they did.

They give the user NO alert, but once you sent the message they text you back immediately that you MAY have lost the rest of the message without specifying WHICH recipient wasn't on Verizon. You lose all of the remaining characters, so have no way to send them again. This has resulted in partial freaking addresses. Unintended meaning in sentences. Jokes with no punchline. Frankly it makes me so mad when I hear that sound of an immediate text message coming back that it LOST my message and I have no idea who would get the rest even if it bothered to save it for me (which it didn't) that I hate my phone, I hate Verizon, and I don't want to buy anything from them again even though the reception for phone calls was better than any other network. What Verizon fails to understand is that I don't like to talk on the phone. I like email and text messages. They made a terrible decision on ONE common situation and failed to make a reasonable option for a texter who can get verbose.

Yesterday I bought an iPhone. WOW. I am blown away. I feel so bad for Craig. He bought a Fuse. I experienced absolute wonder and delight discovering my iPhone features. He discovered frustration and disappointment with intermittent excitement. The difference? It's all the UI and the experience. I can not believe how attached I already am to my iPhone. Now I get ...<< MORE >>

Trig for measuring gutters from the ground

You will be happy to know that our house is 17' tall. We first measured with the laser. I then got the rickety old ladder out and measured by flinging the tape to the gutter and measuring from there. I have video of the laser remeasure to share with you and the math.

After the measuring was complete we watched a TV lecture about robotic cars. I brought in the gutter cleaning robot for Craig to cuddle up to while we watched it. I have such a fortunate and geeky life! 



FYI-you should have seen Craig's irritated expression when I told him that 5 and 1/8th inch was the same as 5.18 inches. It really is too easy to tease him.

I just wanted to share. I'm writing like mad to finish up draft 1 of my PNSQC paper. I hope the reviewers like it. I'm really open to input and I just want so much to present and discuss this topic with others. I'm considering doing the poster paper just so I can hear the ideas others have on it.

Measure gutters with laser.
...<< MORE >>

Gutter Cleaning with Engineers

I share this with you because as a tester, one of the things I love the most about my job is working with other geeky people. Now that I have my very own dev counterpart at home, I am also amused with how engineers approach problems other than just customer problems, software problems, and bugs.

Mission: Clean the Gutters

My Idea: Hire someone.
Craig's Response: Too expensive, besides, needs to be done often. Let's do this ourselves.

My Next Move-Buy
adjustable ladder which claims to be the "only ladder we need" on sale
for $99. Assumes this is absolutely good enough for the gutters.

Craig-Reads
reviews, watches online performance, and then buys gutter cleaning
robot from Roomba to automate this task while negotiating half payment
of robot by me.

Testy Redhead-Gets robot in the mail, reads all instructions, puts it together and charges it.

Craig-Finds ladder not tall enough to reach gutters in some areas of the house.

Both of us last weekend-Go seeking extension ladders. Even the $200
ladder holds only up to 200lbs WITH all supplies including the ladder
itself and the robot. Realizing this means I now have to do ALL
tasks on this ladder, we refuse to buy it as to be safe with the ladder
itself being 33lbs anyone over 167lbs shouldn't be climbing the ladder
according to Craig, which rules him out even if I don't feed him for
quite some time.

Testy Redhead-Sends Craigslist links to Craig for
ladders that are taller, cost less, and hold enough weight for Craig to
climb it with the robot.

Craig-Being unsure how tall we need the ladder to be determines we need to know maximum height.

Testy Redhead-Suggests we get a tape measure and climb our current ladder to measure the difference.

Craig-Shoots
down this idea because there is no way that will work and my tape
measure will flop over (I don't think it will, but he does).

Testy Redhead-Suggest
we tie a rock to a long piece of her knitting yarn, throw it into the
gutter, straighten it to the floor, mark it off and measure the string.

Craig:
I've seen you throw and we have windows. I don't like the idea of you
hurling rocks at the house. This could end very badly. I have a better
idea.

Craig's Brilliant Idea (that we are about to go do): Measure the height of the gutters using a laser pointer and the Pythagorean Theorem.
We'll measure the distance we stand from the house and the angle it
takes to get the laser to the top of the gutter. I kid you not.

My reaction to this was to laugh hard for about 4 minutes, and finally say, "I'm so blogging this." ...<< MORE >>

Writing and Appreciation

I've been out from work ill this week with an irritating virus. Considering that I've emerged victorious from 3 surgeries in the last year I believe I deserve a break from all airborne illness, but I digress. Stay away from others who I could infect gives me the perfect opportunity to take this entire weekend and get my technical paper on reducing test case bloat to a reviewable state so I can goof off next weekend instead of working furiously towards the deadline and falling asleep on my laptop risking getting drool into the keyboard like last year (ick), now that I've said that I want to sanitize my poor laptop.

I just attended a tech talk on virtualization (cloud computing in particular) and it energized me so much. Then I got my detailed assignments for next week and after a moment's panic realized, YES, I CAN do this now. While I'm so happy I wanted to write it out. Here is it.

Reasons I'm Thankful

1. The opportunity to learn has never been more apparent than at this time in my career and the work of mentors has made it possible.
2. My boss and Ajay J all working so hard so my team has a good build to go. They listen, they act, they make it happen.
3. My co-worker Chris for giving a Java class and being so patient. I'm learning and having some moments now where I don't HATE coding. Having a good teacher helps so much, and being able to work on building skills over weeks rather than in 2 days works much better for how I learn.
4. My team for being able to take over so that our team goals don't ever fall apart if I'm not there. I'm so proud of them and I believe there is nothing they can't do or learn. They amaze me and I am proud of how resilient and professional they are under pressure (which everyone IN test has been this year, in fact everyone in the country has been). How someone acts when things are rough shows their true character more than just how they behave during a good economy when budgets are plush.
5. My Action Script is improving! This is going to sound so silly, but for the first time ever, I'm assigned Action Script code to write next week and I'm excited about it! After doing just 3 lessons of Java I'm feeling less intimidated by having some scripting on my plate that I get to do, and if I run into trouble I can scale down, but if it goes well (and when I'm happy things tend to), I'll add some really cool visuals which will be so fun!
6. I have joined our Wiffle Ball Team, and while it's likely I'll be mostly a backup player until I get more experience, just the fact that I'm in good enough health finally to join any sport for fun? That is amazing.
7. Virtualization continues to make testing more fun ...<< MORE >>

Presenting at PSNQC 2009!

In email today I was thrilled to see this:

Congratulations! The Program Committee of the Pacific Northwest Software Quality Conference has selected your paper (Title: "Reducing Test Case Bloat") for inclusion in this year's conference!

So, pending final paper acceptance, I'll be presenting at PNSQC and attending!

Now, on to writing the Technical Paper with "the best research ever", which I'm looking forward to! I want this paper to be my best work. First draft is due June 20th. I'm going to possibly take the train down to Portland this time so I can read on the way if I'm the only one from my office going. If you live in the greater Seattle area want to carpool down to Portland, let me know. I'm an excellent navigator and can pitch in for gas. I'm generally cheerful and pleasant so long as I have lots of cool Diet Coke to drink and you don't force me to listen to country music or right wing talk radio. ...<< MORE >>

Statistics Tolerance Training

While I almost always prefer to focus on my areas of strength, there are a few areas of weakness that I'd like to address to some extent because I feel it would help in terms of credibility and make me a better tester and enable me to better collaborate with and understand other people.

For this reason I'm taking on some exercises to practice my thinking and raise my tolerance for tasks that I think of as "uninteresting" and mix them with things I do find interesting, like research.

So, I present to you the results of last weekend's training exercise. This is an excel spreadsheet that is a breakdown of household grocery expenses over the last 3 years. It also includes the national average adjusted for the cost of living in King County Washington (which is higher than much of the nation). Were I able to more easily find the data I'd compare against the costs of eating out because what this doesn't show is that I cook on average at least 10 times per week and only buy lunch 1-2 times per week at work. If the only goal were to lower the grocery bill, just eating out more often would do that, but it would also mean that food and beverage would consume more of our budget. I should also note that while most people get coffee out or go to the bar, we only do so about once per month, so the wine consumed at home is part of the grocery budget. What this chart also doesn't show is that when we first moved into the house we had never owned a home before and we had to buy many basics at the grocery store that were non-food household items. Those items tend to be expensive things like cleaning supplies, laundry detergent, cleaning tools, cooking utensils, and one time staples that are only replaced every so often. What looks like "waste" may not be. Yet most business decisions are made by this kind of "valid data". Creating data that is viewed as valid is very powerful. It needs to be "not wrong" and show how things are trending.

...<< MORE >>

Like Christmas Morning! I love my job today.

I got up at 6am today so I'd be ready for today. I had emails in to my colleagues in India clarifying something about the builds I needed to know and got a very thoughtful and helpful response. Today kicked off the very first cross product workflow testing of this product cycle! The setup is all automated on the client side and I'm working over the next 4 months in that legendary spare time I'm rumored to have to automate the creation part which I'm doing manually. The people participating are great thinkers, have decades of experience as a group, and I have much respect for them. They care about testing end-to-end scenarios and reporting back on usability.

This time it feels even better than ever to start my testing engines. It makes every conversation where a person just "doesn't get it", every difficulty getting setup where it feels like herding cats, every conversation I've had with other people who feel like they should be the top priority and direct all of the testing that is done, every assumption that the reason for confusion is somehow communication on our part is all well worth it just because this testing is happening at all. Less often and with fewer resources than I might wish for, but it IS happening and that is a very exciting thing. That is worth every downside. That makes my entire year.

The thing that most people don't understand is that coordinating testing is much harder than working on one product or technology. The planning is insanely complex. Talk about stakeholders! It's a conglomerate of stakeholders and ultimately "the software user" is the most important stakeholder, but not everyone agrees on which customer is important. It's the ultimate test of managing up, down and sideways all at once.

While most people involved in software that I know will claim that user focus is important, when it comes down to making the tough business decision to slip a date, allocate resources, or follow the advice of a user study rather than design what engineering wants to make, you find out just how important it is. The truth of priorities comes down to the question of, "Is it funded?" Companies vote for which customers are important by investing time and money. In testing usability we try to report back what they are getting for the investment, both in the new user and the power user scenarios.

It's tough to explain when someone who is very focused on their particular product asks what is in it for them if they choose to participate in collaborative testing for the user experience. It seems very flippant to answer sincerely. There is nothing in it for you personally unless you use multiple products or a majority of your users do and you care about their experience. Immediately there would be no gain, because you can hit milestones more quickly by only verifying that you match the spec exactly and never looking at the bigger picture. The ...<< MORE >>

Make me a Model!

There MIGHT be an opportunity for me to create some models and work on some non-static automation! Oh just the thought of it has me so happy. I'm geeking out. I know, with my critcism of automation, why? Well, when the automation changes some each time you run it and is based on likelyhood I get super excited because I can see this becoming the ultimate smoketest! It's like a super smoketest. It's not at all the same as user testing, but this is the type of automation I want to work on because I believe in it. I think it is interesting. It's doing what I consider "real testing" and it isn't dull and repetative.

Anyhow, I need a UML book, tutorials, and practice as well as a few good books on model based testing. We have a tool here called "gliffy" that is part of a wiki. It's pretty painful to use to create models. Are there less painful modeling tools out there? How about FREE tools?

I'm not exactly sure how to get my boss to pick me for this project but I'm like the Donkey on the Shrek DVD leaping up and down "Oh! Pick me! Pick me!" Enthusiasm might help, but I think what will seal the deal is showing up with an amazing example. The problem is I'm "high will" in this area, but not so much the "high skill" that I want to be. However, I'm more motivated to do it than the other people and I want to do it more than some of my currently assigned tasks. Any tips for me on this? Reading recommendations?
...<< MORE >>

The New Fight for Feminism-Respect in a Male Domniated Industry

Before I share personal entry, I know I'm one of the most fortunate females in all of the world to earn a living with my mind and to be judged on what I do  rather than my gender or any other traits. That said, even in the country where the best opportunity for equality exists, sometimes something will happen where it is clear that there is still a need for women to fight for equality. This represents only my impression of one rare event, not an impartial view of any intentional bias.


You make me feel so stupid sometimes that for a second I forget that I'm a fantastic person and a capable employee. But
then slowly the truth leaks out. The fact that you don't value my
talent doesn't make it disappear. You look at me like I am nothing but
a problem. You aren't even the only one or the first one today to
entirely overlook my value.

I had to look in the mirror, stand
up straight, smile sideways at myself, and envision a tiny pebble
*dink* bouncing off of my armor.

So the
tide of confidence pulls away, dragging me in to doubt and insecurity. Telling me just to
quit, just to avoid you and let another man deal with you that it isn't
worth it, that talking to you is pointless and that I don't have the
ability to even make you understand. That negative voice just creeps
in. You don't know enough, silly GIRL and that is implied in the way
you look at me and I almost believe it for a moment too. My knowledge
and passion is worth nothing
and you make it clear that you don't support me and
that see nothing I contribute as valuable and you even sort of laugh
when I offer to help you or work with you.

When you are judging
a person as an idiot, what criteria are using? I would hope that the way they treat you would come in to
play at some point. I'd never treat you as though you had no value even
if I disagreed with most of what you said. So long as you had ethics, I
would respect you as a person.

So I don't have the depth of
knowledge that you do. I don't mind if you consider me less intelligent
than you are at all. I'm not even close to one of the top 1000 most
intelligent persons in the state, let alone in the world. Scores of
minds are thinking circles around mine at any moment. It's only the
fact that you don't acknowledge my value at all that hurts.

It's
small incidents like this where for a few minutes I want to be done
working in a male dominated industry, take my ball and go home. Just be
done playing with those mean boys where each day I go to work there are
fewer females in the role I'm in. I look around and it scares me. I
remind myself it isn't personal. I hold my head up just a little bit,
and I remind myself that I belong here. It wasn't a gift. I deserve to
be here. I didn't ...<< MORE >>

Virtualization

I got my first chance yesterday to really use a web hosted server/client virtualization tool and I loved it so much that I've become sadly spoiled in one day and now feel upset when I have to test using a regular machine. THIS is how I want to test from now on. To log-in, start the environment I want in exactly the state I want, not manually be messing with multiple machines anymore, not having to manage my own disk space or resources anymore, but to be the queen of the virtual palace of testing!

I Love it Because
1. Quick!
2. Easy to share the "exact state" with others by just sending them a link.
3. No one else can mess up my state or configuration, NOT even me! A tired testy redhead without caffeine is no longer a threat!
4. I can keep the configurations I need and if I want to get rid of any it is super quick and automatic.
5. It just makes sense to share hardware this way.
6. No more annoying switches that beep.
7. I love to work from my laptop. I've been switching between machines all day for so long that just switching browser tabs is so much nicer. It feels organized, in control, and great.

Still not perfect
1. Why no Mac OS? I can't use this until it supports the Mac as well.
2. The tool still crashes IE all of the time and has issues on Vista. Need to test the testing tool. I'm glad to send in bugs, but PLEASE take stability seriously? If you can't run the VM in the "supported" browsers, it shouldn't be on the box.
3. Very expensive per user, so hard in this economy to convince others that it is needed.
4. I haven't figured out yet how in the world I'm planning to print from my virtual world. Input/Output is still a bit hazy to me. I need to learn more.
...<< MORE >>

Automation Often doesn't Accurately Represent the User

This weekend we used my Garmin Nuvi GPS to direct us to a friend's house we've never been to before and got some interesting results.

1. According to the GPS we were driving on water! As I don't own an amphibious vehicle, this data was false.
2. The humans told us why we shouldn't go the way the GPS had us go even though both paths technically would work.

Good things about the GPS
-It didn't seem to mind that we were driving on the water, so at least it didn't stop working or error out. Our car was on a ferry, so in a way, we were driving on water.
-The GPS efficiently got us from point A to point B with the fewest turns possible.

Factors the GPS Disregards
-Safety. The humans don't take that route because it is hard to see around the corner with the overgrown vegetation.
-Comfort. The GPS doesn't know which roads are bumpy or smooth or which have potholes.
-Police. One of the roads contains a speed trap often. Locals avoid this road.

I bring this up to explain why unit testing and a high percentage of code coverage is NOT enough testing alone. It's a great start. We most certainly should perform this testing and move quality upstream as much as possible, but when we neglect user research, user input, and devalue product expertise in the profession of testing, we are driving like a GPS and not like a human. We are shipping software with an unknown user experience which lowers overall quality.

Using the product is not enough. Testing the code is not enough. A brilliant combination of both can come together to make a good software testing strategy.
...<< MORE >>

Email that Prompts Action!

I wrote an email yesterday that got results. Yes, on a Sunday I wrote an email and as a result, two of my neighbors ended up in my livingroom giving me a high five and we are getting together in a few weeks to have a wine tasting in celebration of some positive changes that are being made in the neighborhood.

Two years ago I could not have written an email with that result. There is no possible way because instead I would have been.

1. Avoiding conflict.
2. Beating around the bush (not getting to the point).
3. Escalating anger and riots with a snarky response which while it may have been funny would NOT have been productive.
4. Rambling on for 2 pages writing a charming but unconvincing prose filled page.

So, what has changed? How did I go from writing a totally ineffective email to one that not only got across the key points, but gained promoters who are now friends and also support my ideas? It is only through the mentorship of some amazing test managers who both by example and feedback have helped me gain a few skills. When you get an email or there is an issue you strongly disagree with, here are the things that have worked for me.

1. Respond while it still matters. Time moves fast. People move on. You may need to take 15 minutes to calm down, but when it is really important waiting 24 hours may mean your response is irrelavant. Don't react out of anger, but respond in a timely manner. Do not put off responding when it is important. This could not wait even one more day because I wasn't willing to dream about it at night.

2. Don't take it personal and don't make it personal. If you are defensive, offensive, or just clueless you aren't going to be effective. There is never a reason to be unkind, personal, or use a low blow. I'd say not taking it personally is really really hard and I'm only just now getting some practice at it. People with self-esteem don't take it personally even if it was intended to be. A confident person can take an insult and put it in context. That's just the opinion of one person. Don't let their opinion define reality nor should you assume that your opinion IS reality or can define their reality.

3. State your assumptions and your intent. Don't make it a guessing game. If there is a common interest or even somewhat of a shared goal, state that.

4. What's in it for them? Why should they care? This information should be on a silver platter.

5. The bottom line is now the top line. (Thank you to Laura Browne who taught me this). People hate reading. The conclusion should be the first line of the email right under your greeting.

6. Details should be labeled as details, contain a summary of the numbers in an easy to read format and if you are asking for a decision, make sure ...<< MORE >>

Reducing Test Case Bloat Abstract-Please Review

Ok--Scratch that. -Please review this


Draft 2


"We may be through with the past, but the past ain't through with us." Magnolia (1999)

How
are you dealing with your existing test cases, and what does this have
to do with the future of testing? Unless you are on a new product
without any existing test cases, you may have some test case bloat you
are carrying around with you. All of the time that you spend dealing
with the quality of existing code is directly taking time away from
developing and testing innovative new features and software. In short,
the past may be hampering or even preventing you from having a future.

I'll
discuss six different strategies which can be used either in
combination or alone, the barriers to ruthless reduction, many ways to
identify the keepers, and a few strategies for letting go. Once you
decide on a reduction strategy it may be difficult to execute on unless
you deal with the emotional attachment and fear that comes with leaving
what some consider "needed survival supplies" behind. In addition to
sharing many methods for reducing test case bloat, we'll discuss
reducing duplication in the form of trusting the automation, trusting
other teams, and finding areas of overlap. Find out why more is not
better and go home with a goal to test less. If you are covering what
is most critical, reducing testing where the priority is lower can result in improved efficiency while maintaining excellent quality.


First Draft Below

"We may be through with the past, but the past ain't through with us." Magnolia (1999)


 


Picture two groups of plane crash survivors suddenly stranded together in a remote location, a few survivors out of hundreds, yet somehow all of the luggage has made it through unscathed. These groups of people must travel to make it out of the wilderness effectively together, with as many of them as possible surviving. Group 1 takes all of the luggage, distributes it equally on to the backs of each member, and as a member falls to being eaten by predators, hunger, or injury, they redistribute the load on to the remaining survivors risking more fatigue and injury. The forward progress is hampered by the weight of the supplies they have with them.


 


Having seen this strategy fail, Group 2 instead gathers information about where they are and what is likely to be found along the way, assesses the ability to safely carry the load, and distributes items based on need and ability. As members fall, they ruthlessly cull through the items, balancing the need for forward progress with the need for the items they will carry for their ultimate survival. In the end, a strategy is not enough. A well muscled person from Group 1 may emerge victorious with a huge pile, where an unmotivated and injured person from Group 2 may not make it, however, the odds are in the favor of Group 2.  Not only is Group 2 more likely to get out of the Wilderness alive and far ahead of Group1, but they are more likely to be healthier, happier, and working well ...<< MORE >>

Abstract for PNSQC 2009

What topic sounds more interesting on the topic of the future of software?

Automating User Workflows-Strategies for identifying, prioritizing, and testing end to end user scenarios and then automating them.

Constant Beta-Testing to "good enough". More and more it seems that consumer software is expecting the end user to do most of the testing. How do we increase our smoke tests to cover what is important in order to get user feedback. How is the user feedback then verified and made actionable in an efficient way? What does it mean for testers when the new "good enough" doesn't have to be that good in some sectors?

Testing by Numbers-In this very difficult economic environment companies are looking for quick solutions. Any cost cutting measures can be the difference in a company surviving. For that reason, numbers are being considered more than ever. As test leaders and individual testers, how can we find the metrics that matter and present them to best show our value? What can we do to communicate the options to company leadership when they want to cut testing and quality or the schedule to ship a product sooner?

Reducing Test Case Bloat
-See earlier blog about this, but I'd go into detail with examples about all of the ways to reduce bloat so that we can move on to testing future features.
...<< MORE >>

Development Environments

Comparison chart of Integrated Development Environments.

Most everything I've tested in my career has been C++ code, but lately I've had a chance to work with some ActionScript based web hosted applications. I had a chance to look at one browser based application and I realized I have no idea what language it is written in!

Why does it matter? Well, look at this chart. Depending on the development environment, the challenges and advantages vary greatly. This means the risk of introducing bugs will vary to some extent by the attributes of the environment the software being tested was created in.

Have you found in your testing that the programming language or development environment used can accurately predict where bugs are introduced?
...<< MORE >>

Twilight Vampire Testing Lessons

In the last few weeks I've read the entire Twilight series. Although I'll admit sometimes I had to stop and laugh and read the dialog outloud. While it was a good stress reducer while mourning the loss of our much loved cat who lost kidney function and sadly passed away on Wednesday, I thought it had some good lessons for testing.

1. Does it dazzle you in the sunlight? Beauty.

As yourself, as a user, is this stuff sparkley? Is it really something special? If not, what would be like sunlight for this user experience? As a tester it's your job to help shape the product. We get so used to thinking in the negative that sometimes we forget that we can have a powerful influence for the good of the user beyond just protecting them from bugs.

2. Don't forget to be human. Imperfection.

For our vampire friends, it's all about moving enough, blinking, but for testers who've been in the industry for awhile, we have knowledge the user may not have. Well perfect! That makes us enhanced with supertester vampire powers, but mere humans are going to be using the products, so let's not forget the impatient, imperfect humans and pretend to be human for your test cases. Don't forget that your automation isn't usually the best at being human, so it may need to be supplimented to get that sort of coverage. I mean REAL human. A very imperfect scenario.

3. When things go all Werewolf--be prepared. Phases.

No what are the wolf phasers? That would be leap years, that darn Globalization/Localizability (test early, test often, phase in advance), environmental changes (operating system, browser, ect), and that most dreaded PHASE of all, maintaining and supporting it once it's out the door. Also, don't forget our natural enemies, those who are waiting to exploit any security hole.

4. Hunt early, Hunt often, Hunt together.

In the books it is dangerous for the vampires to wait too long to hunt because they will lose control and start killing. So it is also dangerous for us to wait too long to test, let the project get out of control, and kill the quality. The hunting may not be ideal, but as soon as something is ready to test, jump right on it. If the timing is just right, set up a hunting party with a few buddies and really take advantage.

5. What you want may not be possible, but explore what is.

We all know that love between a vampire and a frail human has many limitations. You are but one frail tester in a den of test cases. What will you do when ideal isn't available? Well, you will do what you can the whole time working towards ideal. Impossible is not an excuse.



6. Love is powerful, but you can't ignore fact.


If Edward just went on instict alone it would be a short series indeed. For this reason, use your passion to drive you to do the best job possible but use the data to help with what your priorities are ...<< MORE >>

When Negativity is Useful

Feedback is always useful because it's information, but it's only useful if you consider the source. How do you go about addressing concerns and complaints that other people have? What if everything you do to address their concerns just backfires and anytime you interact with them at all it gets worse and you don't know why?

What if you have to defend, define, explain, backup, and triple check every thing you ever do or say but they don't? The balance of power is not in place for a fair debate, my friend. Don't be fooled. Professionally there is no room to be defensive if you get "other than positive" feedback in any area. Suck it up, say thank you, and ask for details if possible, but sometimes, just a thank you is the best you can do. I've seen different ways of handling this in the past. As a team, if this happens higher up in an org, the culture changes to one of top down feedback only in some cases, because that's the only direction that "matters", or people game the system as they find how it's measured. How about when the effort you put in to please the person and talk in their language is dismissed entirely? What about when you find out that you have no voice? Well, you stop for one. You stop entirely because you are at the end of usefulness for that one way discussion and you take it. Then you get back up.

Why? Because you are resilient, passionate, diverse, have more than one stakeholder. You get up because others are counting on you. You don't take it personally because it is just business, it really isn't personal (even if it IS about personality). If one direction fails, you try another. If you can't please some people no matter how hard you try, you please enough of the others to make their opinion less relevant. For every detractor you may find, you are going to need about 10 very strong supporters. I don't mean networking when you need it. I mean you are holding up others when they NEED it. They can count on you. You helped them at every turn. Why? Because you have ethics and you spend your time trying to be positive and helpful and honest. For each bad thing you say, you need 10 good things I estimate. In some situations you just can't win. For them is it just about winning? Can you give them the, "You win" that they need and move on? Can you find other stakeholders?

A female executive who I admire told me last year, "Never let the opinion of one man stop you." To make a difference you need visibility. With increased visibility will come more feedback, both positive and negative. All of it can be of help in context, but none of it can make or break you. One man's opinion at one point in time should not be enough to stop you if ...<< MORE >>

When the Big Wigs "Get it".

An online friend shared this link and I did check it out and it's over 5 years old, but some of these problems are STILL happening today. Why does it take the CEO to notice or someone high up for usability concerns to be taken serious? To read the entire thread, check out http://blog.seattlepi.nwsource.com/microsoft/archives/141821.asp



From: Bill Gates

Sent: Wednesday, January 15, 2003 10:05 AM

To: Jim Allchin

Cc: Chris Jones (WINDOWS); Bharat Shah (NT); Joe Peterson; Will Poole; Brian Valentine; Anoop Gupta (RESEARCH)


Subject: Windows Usability Systematic degradation flame

I am quite disappointed at how Windows Usability has been going
backwards and the program management groups don't drive usability
issues.



Let me give you my experience from yesterday.


I decided to download (Moviemaker) and buy the Digital Plus pack ... so
I went to Microsoft.com. They have a download place so I went there.


The first 5 times I used the site it timed out while trying to bring up
the download page. Then after an 8 second delay I got it to come up.


This site is so slow it is unusable.


It wasn't in the top 5 so I expanded the other 45.


These 45 names are totally confusing. These names make stuff like:
C:\Documents and Settings\billg\My Documents\My Pictures seem clear.


They are not filtered by the system ... and so many of the things are strange.


I tried scoping to Media stuff. Still no moviemaker. I typed in movie. Nothing. I typed in movie maker. Nothing.


So I gave up and sent mail to Amir saying - where is this Moviemaker download? Does it exist?


So they told me that using the download page to download something was not something they anticipated.


They told me to go to the main page search button and type movie maker (not moviemaker!).


I tried that. The site was pathetically slow but after 6 seconds of waiting up it came.


I thought for sure now I would see a button to just go do the download.


In fact it is more like a puzzle that you get to solve. It told me to go to Windows Update and do a bunch of incantations.


This struck me as completely odd. Why should I have to go somewhere else and do a scan to download moviemaker?


So I went to Windows update. Windows Update decides I need to download
a bunch of controls. (Not) just once but multiple times where I get to
see weird dialog boxes.


Doesn't Windows update know some key to talk to Windows?


Then I did the scan. This took quite some time and I was told it was critical for me to download 17megs of stuff.


This is after I was told we were doing delta patches to things but
instead just to get 6 things that are labeled in the SCARIEST possible
way I had to download 17meg.


So I did the download. That part was fast. Then it wanted to do an
install. This took 6 minutes and the machine was so slow I couldn't use
it for anything else during this time.


What the heck is going on during those 6 minutes? That is crazy. This is ...<< MORE >>

Unseen Metrics

How do businesses evaluate and measure their test effort? How do we know if we are doing the right thing, taking the right risks, or investing in the right area?

I've heard many presentations lately where automation teams will say that finding bugs is not their goal.

These developers in test have the goal of either driving a product direction (Test driven methodology), making sure bugs aren't reintroduced (Pure regression automation), validating that functionality is working and stays working (pure functional testing), or my favorite cause of all, inventing tools for other people to create tests (automation as a service).

So, what happens when the overall number of people expected to "find bugs" goes down and all of the investment is on the number of tests run? How are they prioritized, run, maintained, reported on, and how is quality evaluated? When you see a number, what numbers don't you see?

What did 90% code coverage cost you? What code did you cut? How is the user experience impacted? What did you trade for to get to that number? What didn't get tested? Is the product actually better for it?

I ask not because I have the answer, but because I am seeing some terrifying responses industry wide.

If testers don't find bugs and test the product who does?

Customers BUY and use the software. Why are businesses deciding not to invest in the product of value? That's the product of value? Why do I feel like I'm taking crazy pills to say something like this. I love good software. It makes my life better. I have passion for it. I don't want to use crappy software that some companies are making and I certainly don't want to participate in making really bad software to use.

Good software makes money. New methodology and internal tools do not, especially if they don't save money. Why is it politically incorrect to say this?

Metrics that matter=Customers buy product. Customers like product, can do what they want better than ever before, recommend product! Perceived quality from the customer is what matters, and long term at that.

Are you in quality? What are you doing to avoid buying the test snake oil? How do you convince others that having people to find bugs is important?
...<< MORE >>

Throw Someone Under the Bus,..

When you throw someone under the bus you harm more than just that person. You make a mess and you slow down the bus.

One would hope that karma,  or the law would kick in at some point. Even if it never DOES you still are less efficient. The tech industry is really hard and competitive right now. It's going through a difficult time. Don't forget that it isn't worth your integrity. Even life itself is temporary. Do not sell your soul for the illusion of security. ...<< MORE >>

Mac Language Switching

Switching Languages for Mac OSX

Select Apple menu, System Preferences. In System Preferences, select the flag, also known as “International”. From here you can scan the list of languages and select the one you need and drag it to the top and log out and in again. If you don’t speak the language you are using, it’s helpful to remember that Shift+Command+Q is log out.

If the language you need to test in isn’t present, click the Edit List button on the right to add additional languages.
...<< MORE >>

Ineffective Tests and Unintentional Delays

Why is it that medical tests don't have to show much to still be run often?

I had 3 ultrasounds fail to detect endometriosis. When they finally gave up and gave me surgery I had over 81 implants of Endometriosis and stage 3 out of 4. In my support group for this chronic disease (one of the more minor health issues I'm dealing with, but still problematic), a majority of the women had been given an Ultrasound which had turned up nothing, yet they are still routinely run. This test is terrible at detecting this particular disease, yet it seems to be the first diagnostic tool they use. The second thing they do is inject women with this terrible hormone reducing medication that has side effects such as bone loss, and memory loss. When I was on this medication I would walk outside and promptly forget where I was going. I had to request things in writing at work because I couldn't remember what I'd agreed to. Needless to say, I refused the second dose (each dose lasts 6 months). They do these tests all to avoid what is now an EASY and fairly safe laproscopic surgery. The surgery is excellent at not only diagnosing the issue, but also at treating the symptoms. I'd have surgery every 6 months before enduring another round of those drugs.

So, why do we as testers use ineffective tests and put up with terrible side effects, such as spending more time troubleshooting WHY our automation broke again with each version and each change rather than just getting in there and doing what needs done? Is it an irrational fear? Is it habit? Is it because it sounds better on paper? Is it because of this false idea that it is more efficient? Why is it so unpopular to point out that it might be faster, more accurate, and save time and money to "just do it", especially in one off cases or a situation where the test just doesn't need to be run that often.

I'm had a meeting today about one of those things. You know something where there is the "right way" to do something, but it's so expensive and so many people would have to agree that it's unlikely to happen? I really hope that the "right way" happens, but I'm thinking I'm not the best person to get involved in that part of the task. A person with patience who strongly desires to negotiate a deal between two managers is the right person. I could show that leadership and be that person, but it doesn't excite me in this case. I should allow someone the opportunity who really WANTS to work on this. Passion makes many things happen that wouldn't otherwise. Part of the request was that it be "as automated as possible". I am not sure I have the heart to share the truth. The truth is that it isn't worth the cost to automate. We measured, and the automation they have ...<< MORE >>

Status=Employed

Despite layoffs at my company, I currently still have a job which I am very thankful for. It's been a difficult time seeing co-workers go, but my team is most not impacted at this time. It's a rough economy, so I'm well aware that job security isn't a given for most of us at the moment.

I couldn't possibly be more thankful for my boss and his boss who have been supportive and tolerant as I've gone through such a tough time medically, and I'm looking forward to making them very glad they kept me around during 2009. I have always loved the software I work on and the company and I'm pretty unreasonably loyal. As long as they want me here and are good to me, I'm not going anywhere anytime soon.

It was very flattering that an old friend contacted me yesterday, kind of hoping I'd been laid off and offered me a possible consulting gig. It made me feel cared for, but I wanted to set the record straight that I have a job and am not looking for another one at this time. At some point in the future, the idea of consulting sounds exciting and like it might be a good fit for me, but not right now.

I hope that some of the good people who have been laid off recently find work soon. It's a great time to be hiring right now because there are so many talented people looking for a job. I have some friends, an experienced Whitebox tester (Ex-Microsoft) and a very experienced PM friend (Ex-Microsoft and Ex-Adobe with tons of agile projects under her belt) that are looking right now in the Greater Puget Sound area.
...<< MORE >>

Software Updates=Bad User Experience

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 ...<< MORE >>

Dirty Testing Jobs

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." ...<< MORE >>

Creative Suite 4 Unofficial Highlights

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 ...<< MORE >>

Testing for the User Experience-First Scientific Paper

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.
...<< MORE >>

Greetings from my Cyborgtoe

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. ...<< MORE >>

Research in Progress-Model Based Test Planning and UML

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.
...<< MORE >>

The New Reality-Altered and Enhanced

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 ...<< MORE >>

The Paperless Office

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 ...<< MORE >>

Measure the Quality?

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. ...<< MORE >>

When you hear hoofbeats do you think Zebras?

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, ...<< MORE >>

Dangerous Assumptions

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 ...<< MORE >>

Hello from PNSQC

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 ...<< MORE >>

Collaborative Testing Lessons Learned from Tribal Bellydance-Part 1

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 ...<< MORE >>

PNSQC Presentation Prep Status

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!

...<< MORE >>

Organizing Automated Cases

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? ...<< MORE >>

Beyond the Requirements, Beyond the Bugs

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 ...<< MORE >>

Reducing Test Case Bloat

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 ...<< MORE >>

How long is too long?

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 ...<< MORE >>

Dealing with Bugs across Teams

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.
...<< MORE >>

Be a fountain, not a drain.

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.

...<< MORE >>

Blatent Disresepect for the Rigors of Science

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". ...<< MORE >>

Working with People-Disabilities

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 ...<< MORE >>

New Features

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 ...<< MORE >>

Pure Loathing of Software

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. ...<< MORE >>

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

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.

...<< MORE >>

Was it fun?

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 ...<< MORE >>

Large Dirt Hole a.k.a. Grand Canyon

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?

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. ...<< MORE >>

Brilliance Formed?

Look for a few moments at "Pillars of Creation", one of NASA's most famous images of the Eagle Nebula. 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?" ...<< MORE >>

Cold Hard Logic

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. ...<< MORE >>

Protecting Awesome User Experiences

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 ...<< MORE >>

First Technical Paper

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.

...<< MORE >>

Overcoming Fear

I've been working a great deal on professional development. I've never grown so much in so short a time. I'm looking for tips on how to raise my confidence and how to believe in myself more.

This week I submitted 2 ideas to an internal innovation website contest. I didn't win, but for a first try, both of my ideas were slightly above average in terms of votes for all ideas submitted company wide. That may seem like a loss, but if you consider how smart the people I work with are, I don't think so. In the past I would never have submitted them at all, just making excuses that my ideas wouldn't be taken seriously. You can't make the top 3 ideas if you never try, and you have to start somewhere. Mediocrity is a fine place to start because I'm not staying there. This is just my first try. Besides, average here is way above average in the world at large. It takes experience, influence, and popularity to get traction on an idea.

I'm finding out that the main thing holding me back from my dream job isn't skill or experience. It's fear. I'm afraid that I don't have experience. I'm afraid to fail.

I signed a contract last week for my special training that I'd be doing 3 things by March. One of those is applying for a job that I really want that is offered internally at my company. No matter what the results are, I need to toss my hat in the ring. When I signed that contract I tried to think of every reason in the world I shouldn't go for it. I explained to the mentoring group why it wouldn't work and why I was conflicted about doing it. I was shaking while signing that I would do it. The time for self-defeating internal talk is over. If I'm held back, it shouldn't be by me. No only means no for now. What's the worse that can happen? I hope the worse that can happen is they don't interview me and at least tell me what to work on to be qualified for that position if they don't think I am. The best that can happen is they see my passion, potential, and how fast I'm learning and give me a chance to grow in to that role. The medium thing that could happen (neither great nor terrible) is that they interview me so I can get practice interviewing, and they give me feedback. For me it isn't so much that I have to have the "job right now", it's that I want to get there and know I'm moving towards it. Besides, it's reporting to the one person I most want to work for, and opportunities don't come up that often. I feel like a crazy person to say the truth, which is, "I really want to be on your team. You want me because you don't have anyone who will work harder to make you not just look good, but BE good than I ...<< MORE >>

Fire Fighting

Things that seem strange and negative to people are considered pretty normal to me at this stage in my testing career.

Things like reorgs. We had a really good one a few weeks back. Didn't lose any people, just some people reassigned. I have a new boss. It's my new boss #8. So far, I really like him. It's kind of a setback to have to earn the trust of yet another new boss, but I consider it normal and look forward to demonstrating my talent and loyalty as quickly as I possibly can. Each new boss is another opportunity to learn something.

Things like testing that wasn't planned or agreed on coming up and having to make a decision. This "fire fighting" isn't strategic at all. However, I think it is important to efficiently do what needs to be done. I PLAN to be flexible. Some people consider it a weakness. I don't agree. If I can do something to help us ship something on time, I'm easy in. I've seen different strategies when this sort of surprise comes up. Some leads will take a hard stance and refuse any work they didn't agree to in an effort to "protect their testers". I don't agree with that strategy. Creating a false reality for your team isn't true protection. For real security, you have to be mission critical with needed skills and do something that has recognized high value. On the other hand, if you are nothing but a dung heap that people pile their unneeded work on, you can't do anything of high value. All you are is reactive.

I know that it is human to like to be rewarded by money. Money is a show of how valued your work is. While money always matters when it comes to work, mainly, I want something else.  If money were no object, I still would work. Most likely I'd work 4 days a week and not 5, but I wouldn't quit working if I had endless money. I want to feel like I matter to people. I want to feel trusted, appreciated, and special. I want someone to believe in me and give me opportunity. I would take a cut in pay to have the chance to do more of the work I love doing.

I've had some people tell me that my style is "Ready, Fire, Aim". Those people don't understand what my style really is. It is "Ready, Fire, Aim, Fire, Re-aim, Fire, Aim, Fire, Aim, Fire, Get machine gun after research, fire and continue until the objective happens." They don't take into account that I have more tenacity than they anticipate. My lack of patience for inaction is not accompanied by a lack of follow through as it usually is with people who have my personality type. I'll do what it takes to not disappoint, even if it is harmful to me. For that reason, having someone who cares about ME as a human is vital for me to do well. ...<< MORE >>

User Focus

How important is user focus? Which users and who determines that? Does a user become unimportant because they are considered a "sure thing", much like after the honeymoon? New users become the focus, so we can take our core user base for granted? Or do we only care about the loudest customers? Do we only like the nicest customers, or those who come to us willingly in a format that works better for us, like forums? Is the only user information that matters what comes through a scientific process, such as usability studies, or are survey results sufficient to stand alone?

Are money, comparative sales statistics, and support cost comparisons a true measure of focus on the user?

How do we sift through that user data?

It matters to me very much how users feel. That is not scientific. Do you love this software?

At my company, I used to feel that user advocacy was a valued part of testing. Now I feel the trends are shifting. If the user you are advocating for isn't the main focus of the target market segment they would like to capture, they are of little importance. Even in Girl Scouts we learned "Make new friends, but keep the old. One is silver and the other's gold." It isn't stubborn or holding on to the past to stand up for the CORE users who built your company and paid for everything you are developing now, nor is it betrayal to keep up with industry trends and note what people need to do right now and in the future. I think it is critical that all users are considered.

Have you ever gone to a college class where they are teaching your software and talked to the people there? I have. I helped at a class held in New York for a product I worked on on a customer visit. I also was a student. How hard is it to learn to use this stuff? Are they having fun? After that class we went to a shop that had been using it forever. There were some things still keeping them from having fun even though they knew so much about the product. More than we did in some areas, especially on how it interacted with other software.

This battle being waged for the developers has gone too far. Most users of software are not all scripting and coding (except, of course, for Visual Studio and other products which coding is their only purpose). How as testers can we stop corporations from throwing their loyal users out the window to make more room for untapped markets?

I'm still looking for the answer. I'm hoping that some percentages would help. What percent of our users are doing ________ vs. what percent are doing _________? How much do we invest in maintaining the users we already have vs. getting new ones?

Some growth is good growth, even if done fast. Do you know what you call fast growth that eats away at your health and eventually kills you? You call that ...<< MORE >>

Causing a 4 Car Pileup

Forcing an Error Pileup-A Fun Tester Trick
Long time, no blog. The holidays were brilliant, but now I'm back in action, being as testy as ever, so I want to share with you one of my favorite ways to test for errors.

Automation is a great way to "force errors", however, almost always it is one at a time. Causing error message stacking is a great way to test for race conditions, find crashes, and get into those states where you can't access a modal dialog, so you are stuck until you force quit.

Here is my big secret: I have no patience. I will not wait for an error to appear before moving on, nor will your users. They are clicky clicky mouse movers in many causes. They will refresh like mad, move on while one process is running.

So, my testing tip of the day is, don't wait for the program to finish. If you know of error conditions, in addition to trying to cause the same one to fire two at a time, try mixing them up today. The first time you find that state where you have an error dialog without focus and you have to force quit, come comment in my blog and it will make my day.

Automation and Those Darn Robots
Hope that the '08 is off to a good start. My resolution this year is to work "with those crazy robots".

Industry wide, it is time for the investment in automation to stand proud and be trusted. For those humans still testing to compliment the robots and let them be judged on their own merits. Those robots with value will prove what they are worth. Those with lower value must be allowed to come to light to improve. Improvement and not just change. I love that idea. I mean, do I really ever want to manually smoketest an installer in every language on 4 platforms again? Of course not. What a waste of testing time, experience and money. If any monkey could do it, why isn't it automated? If we paid to automate it and are still testing it manually, we are stealing our own money by not trusting our automation.  I spent part of today trying to convince someone on my team of this. They looked a bit nauseated and doubtful. I hope they will be afraid and do it anyways. I really really hope so. It's past time.

I had a discussion today with an ex-tester who is now a tech writter. I was explaining to him that what it really takes to get a testing job right now is a whole lot of coding skills, well, at least the ability to talk like you have lots of coding skills. Notice, I didn't say you need talent, experience making anything useful, creativity, or good testing methodology. You don't even have to be great at working with a team. You don't need to have any talent for finding bugs. You just have to fit the checklist of one of the Software Developer in ...<< MORE >>

Change Management

I think the main reason I ended up being a tester is because I'm more curious than average. You could say that I'm nosy, and it wouldn't be too far from the truth, but beyond nosy, I'm interested.

Last week in a meeting I heard someone refer to change management, but not in the way I understand it. I understand it as a way to track versions or a method to control code changes in a system. As I do sometimes, I wrote myself a note to find out what in the heck this change management stuff is about in the context it was mentioned.

I've attended a day long seminar before on "Introducing Change" given by a woman who was a software developer and had a doctorate in Psychology. I was approaching the information presented as a way to get my testing ideas to see the light of day.

Reading more about it, I now realize that I have been naturally doing some of this on my teams over the years. If I really believe in the ideas, regardless of who's ideas they are, I get behind them and really move them forward. I do have some of my own ideas, but over 7 years I've done much more work on bringing momentum to good ideas that other people have.

I have a double edged sword of strength/weakness in this area. The strength is, if I really believe a change is going to work, and is for the better, I'm all in. I'm the first one in line to be an early adopter. I'm not change resistant and I will use my enthusiasm and charm to get other people either excited about it, or to feel less threatened by it. This is easy for me. I am one of those people who likes change. My current job is never the same from day to day. I work on many things. This is fun, but I think it would give some people whiplash.

The downside is, if I think that the change will not work or I don't believe in it or trust you, I'm very effective at creating an angry mob. Not just a verbal group of people disagreeing, but the underground resistance as well. I don't mean to do this, and I think I'm just sharing my opinion. I give little thought to how my venting might influence other people.  I am not part of the underground resistance. I can't fake it. If I don't think an idea is good, silence or "agreeing to comply even though I don't agree" is the best I can do. I can't pretend to support the idea and lie about it. Many people will appear to do as the Romans do, but actually do what they believe is best as soon as the Romans are out of the room. Others will leave Rome never to return.

So, there are many many suggestions on how to manage change. What can I do? I can help with getting people to understand why ...<< MORE >>

Testing Idea

This morning in the shower I was thinking about collaborative testing (Yes, this is a normal thing for me). I was thinking about some of the things humans are good at doing together than machines are not. One of those things is prioritizing and eliminating unimportant tests. Those decisions take subjective information.

It is very common in testing to target tests to areas of change either code changes, or feature/product changes (what is new or altered). We use this practice on a daily basis. It is more difficult to use across multiple products and/or silos.

My idea today was what if I could simplify? Could I make a visual respresentation of the areas of change over multiple products? What information would have to go in to make it useful over time? In my context, it would be impossible at this time to compile all of that data on a build by build basis, but what if I could compile it at milestones, or even just for the release in general? Would it be useful if not precise? I think it would be a good guide as long as we knew it was just a general pointer (that way), and not accurate turn by turn directions.

I even started thinking about how it would be possible to automate for updated build to build information, but of course, I reminded myself that automation isn't my talent or interest, so while it may be possible, I'm not the right girl for that job. However, I do love maps. I'm one of those females who can not only read and fold a map, but who can navigate the roads of New Zealand, Italy, or any country we might be travelling. I have a compass on my keyring (shout out to Rick Steves). Each time I travel with other people, I make sure I have the map and say, "I'm the navigator!" Seriously. My family even refers to me as "The navigator" sometimes. When testing with other people, why are we not using more overall maps? What is this idea? Map based testing? Ha!

Have you used such a method before or heard of a team using this? I talked to one person about it who wasn't excited, but I think it is likely I wasn't expressing the idea in any detail and the discussion turned to feasability of information collection across multiple teams (human issues).

I'm thinking of the idea more from a scientific perspective. It's more of a "what if I had ___ thing? Would it help me?" Can I get ________ thing is a different discussion all together.
...<< MORE >>

The Ever Popular Pairwise Testing

Each time I review the "testing basics" to make sure I haven't forgotten anything (I do this each year or so, I recommend a refresher for anyone), the topic of Pairwise testing comes up again.

In trying to get into more depth on the topic, I came across an article from 2004 by James Bach. What I like about this article is the research he did.

Best practices only save time and money and improve efficiency if applied correctly and with context.


The typical pairwise testing story goes like this:


1) Pairwise testing protects against pairwise bugs


2) while dramatically reducing the number tests to perform,


3) which is especially cool because pairwise bugs represent the majority of combinatoric


bugs,


4) and such bugs are a lot more likely to happen than ones that only happen with more


variables.


5) Plus, you no longer need to create these tests by hand.


Critical thinking and empirical analysis requires us to change the story:


1) Pairwise testing might find some pairwise bugs


2) while dramatically reducing the number tests to perform, compared to testing all


combinations, but not necessarily compared to testing just the combinations that


matter.


3) which is especially cool because pairwise bugs might represent the majority of


combinatoric bugs, or might not, depending on the actual dependencies among


variables in the product.


4) and some such bugs are more likely to happen than ones that only happen with more


variables, or less likely to happen, because user inputs are not randomly distributed.


5) Plus, you no longer need to create these tests by hand, except for the work of analyzing


the product, selecting variables and values, actually configuring and performing the


test, and analyzing the results.

...<< MORE >>

Interviewing-What makes a good QE Lead?

Today I came across some questions I'd written down nearly 2 years ago. I was looking to hire someone to replace me as QE Lead . Here are the questions I came up with.


After reading the questions, I realized I only wanted to know 2 things.


1. Is this person a good, creative tester with interest and experience in this area?


2. Can this person work well enough with different types of people to be a lead?


I guess those are the top things I consider "must have" items for a QE Lead. A pretty short list. The round of interviews resulted in a good hire. The person has worked out really well in that role. They had much more than my bare bones hope that they could "do the job". I'm glad it turned out, but I've been thinking about how to incorporate questions to find out if I can get what is "ideal" for the job, not just functional.


The most hilarious thing about the person we hired is that on paper, they had the resume that annoyed me the most of any resume I'd ever seen. It did stop slightly short of saying they invented  the entire Internet, but it came across as over the top. I was shocked to meet a humble and intelligent person who was anything but a bragger in person. It just goes to show you that you can't tell everything from the written word. Once I got to know the person better and they'd been on the job while, we discussed what my impression of the resume was and why I interpretted it that way. We both thought it was pretty funny and laughed about it.


So, I ask you, what do you think are important qualities for a QE Lead? What questions would you ask to find out if a candidate had those qualities?


Questions I Had Prepared



  1. Have you ever used (product under test) before? Describe what it does.

  2. Describe your experience with (Technology area) so far. What do you enjoy working on the most that is (technology) related? Why do you want to work on (Specific Technology)?

  3. What is the most difficult bug you've ever isolated?

  4. What is your greatest strength/weakness where testing is concerned?

  5. Do you believe that natural talent plays a role in the performance of testers? What role does it play and how would you maximize it?

  6. How would you go about isolating the following bug? Note: This is an actual fixed bug from the database. Xml file crashes application if imported with "(Edited for privacy)" option is selected. (note: Removing certain tags causes the problem.) How would you verify the fix?

  7. Describe a situation where you worked with a difficult developer.

  8. What kind of a boss works best for you and why?

  9. Describe a situation where the analysis that you performed was incorrect.

  10. If someone on your team was a solid contributor, but not developing the technical depth ...<< MORE >>

Amazing Blog!

This blog entry on software quality is one of the most amazing I've read recently.

Whenever I feel alone, or like I simply can not win the losing battle in defense of creative human testing, something like this comes along to provide me with hope. Yes! Smart people who see the value of testing beyond what you can programmatically verify.
...<< MORE >>

Performance in General

I got to thinking about performance in general. Who's responsibility is it?

1. User Research-Should get some data on what performance users expect in which context.
2. Program Managers-Should define performance with comparisons per system (Faster than, as fast as, no more than % slower than _____________ on the same machine.)
3. Developers should write the code with this in mind and explain to testers when the code is optimized and ready to be tested. This is a performance handoff.
4. Testers then test against these requirements and pre-defined goals. They try different situations, stress tests, repeat scenarios, memory intensive tasks, different OS settings and hardware, long runs, benchmark tests. These tests are some of the best automation candidates.
5. Testers look at perceived performance (Progress bars, number of steps to do something, screen feedback, cursors, ect) from a customer perspective.

So, in general, software performance has split responsibility.

Work performance does not have shared responsibility as much. If there is something getting in the way of you giving your best work performance and you say nothing and do nothing about it, that makes you responsible. It isn't the fault of your co-workers, your boss, the lack of requirements, the lack of a spec, the failed delivery of testable code. It is your fault. As a tester, it is your job to make sure that you can do the best possible testing. Obstacles will come up. Find a way around them. If you can't, directly address them.

I'm very lucky to have had some feedback last week from someone I really respect. There are people I like, and people I respect, and sometimes both, as in this case. As far as work is concerned, I'd rather work with someone I respect but don't like than someone I like and don't respect.  In my personal life, I need someone I like who likes me more than I need to respect everything about them. At work, there was a situation I was just tolerating. Basically, I was waiting for it to improve or go away. I've now had a revelation thanks to a gentle reminder. I'm no victim. The only person who can make sure that my performance is something I am proud of is me. The only criteria for me to be proud of my work is to know that I did the best I possibly could given the circumstances, and that "my best" continues to improve in a tangible way as I learn. It's been a rough few months for me on the job. This is the first time ever where I know I made some mistakes and could have done better. I know I should have been brave enough to admit when some things were a total waste of my time. Knowing when to call it quits on working on something is a tough lesson to learn. When I do things that my heart just isn't in, I can't be more than mediocre, and I'm a very open person. If I disagree, it is written all over my face. ...<< MORE >>

Hand Crafted

This holiday season has been unusual for me. Having just purchased our first home, we get the chance to host Christmas dinner! While I'm excited about it, it is expensive to make dinner for 15 people while putting up out of town guests, and we didn't have any decorations for the outside of our home, so that added expense as well. Then our cat got very ill and almost died, requiring many emergency vet visits and both cars unexpectedly needed repair. As a result, I didn't have as much budget as I would like for gifts this year, so had to think of a strategy.

I heard about hand made gifts, and love to give unique presents. I'd assumed that I could not save any money by getting hand crafted items. As a hobby, I design and make knitwear, so I know how expensive and time consuming it is to make things, especially here in the US where the supply costs are so high. I stumbled across Etsy.com and found some absolutely amazing gifts. Not only were they unique, but they were thoughtful, personal, and some created by true artists.Yes, some items were really costly, but I ended up spending an average of $23 each on many amazing gifts I gave the first one to a friend last night and she was blown away! I know she will remember and treasure it so much more than if I'd given her a $25 gift card to someplace.

So, what does this have to do with testing? Well, hand crafted testing may not cost as much as you think. There are situations where you just need the cheapest thing, or where you need some testing that isn't practical to make by hand. For example, an iPod. However, it is more meaningful and useful if it has a hand crafted cover and a song list you created for that person. How the person getting it will feel is different, because it really is customized for them from someone who cares.

How the people using your software feel about using it is vital. That is where your reputation as a software company comes from. It can not be trusted to robots. It should not be trusted to someone who doesn't take personal pride in the quality of it. I will always prefer an naturally talented tester who sincerely cares over a burned out person with the best education and "skills list" than you can imagine. It doesn't matter if you can write circles of code around another guy, have a doctorate degree, are a published author, a well known expert, or have dozens of patents if you have no personal investment in the results. You can't fake caring, and it is required to do an excellent job. You can do a mediocre job without it, but I've never seen someone do a great job without passion.

My point is, there is still a place for artistic hand crafted testing. Yes, you can ...<< MORE >>

If you read just one thing on test automation before trying it,..(or trying it again after poor results)

Test Automation Snake Oil by James Bach in 1999. Of particular interest to me are the "Reckless Assumptions" and the Sensible Approach to Test Automation section. In fact, if you could only read 1/2 a page, the Sensible Approach section alone would save time and money.

I've read this article a few times. Sadly I then got feedback on my Automation Plan telling me to "put in (this) tool". I tried to explain why it doesn't help us or suit our needs, as well as why it wasn't realistic for our entire test team to become full Java developers in one month, no matter how intense the training is. Positive thinking is good, but in testing, realistic thinking is more important. Well, I try to balance it out with this link. This is the link I wish was in my test automation plan instead of the link to the automation tool which made me think seriously about becoming a waitress.

For those of you not familiar with test automation I'd like to also provide a few fundamental things that most people don't seem to understand who have never tried it before.

"Scripting" means that you are using a scripting language such as Javascript, VBscript, AppleScript, Perl, ect. Generally it does not need to be compiled and runs within a scripting environment of some sort. While it does work outside of one application, the scripting DOM is vastly different between applications. You can learn the core concepts the basic syntax and those transfer, but just because you know how to script in one context doesn't mean you are a scripting expert in another context.

"Automation Tool" is a very generic and broad term. Does the tool schedule and run automation? Does it allow you to test through the GUI? Does it allow you to write unit tests? Does it report back results? If so, how? Can you set it to a tolerance to avoid unneeded false negatives on cases? Does it just track your automation? How easy is it to use? My point is, don't say "Automation" and think that everything that falls into the category is the same.

"Scripting" is not equal to "Test Automation". If you are using scripting to run a step by step test case, even that isn't an automated test case unless you've created proper validation and reporting. Sure, you're scripting it to DO something, but if you didn't validate properly you didn't test anything. I've seen test teams with "80% Automation Coverage" but NO Test Automation. Don't just DO something, TEST something. They are different entirely. If you didn't validate, all you know is that the machine didn't explode when you executed that script. Any number of other things could go wrong, including it not working at all, and you still wouldn't know.

"Automated" does not mean that human tests no longer need to be run.

I took a risk management class last week and we followed the "cause chain" up to ...<< MORE >>

Globalization Eye Opener

I took a special class today at work that was specifically about testing for internationalization and "localizabilty", which means you are "faux localizing" your resources and testing before your translation is completed.

I've now been testing for almost 8 years! I tried to count, and I can safely say that this is at least my tenth product cycle. I've tested in most every language (Most Latin Based languages, the Americas, Japanese, Chinese, Korean, ect). I've never tested in Middle Eastern languages or Cyrillic (Russian, Eastern Europe). 

Shockingly, having never tested on many features where sorting was of great significance, there is an entire area of testing that is brand new to me. Searching, GUI changes, Truncation, consistency, encodings,..these are all old news. Here is the biggest thing I learned all year: Not everyone sorts alphabetically in ways that make any sense to me. I've never even considered how in the heck to sort Asian characters.

It just makes my week to learn something so key, that I've been missing from my testing knowledge all of this time without ever knowing it! It wasn't just a lightbulb moment for me, it was one of minor shame that I could miss getting such an important and obvious concept. I knew this was important for search, for metadata, and have written great bugs about those items. Right now I can't wait to get in there and use my new information to break some sorting. I'm going to be looking like mad for ways that sorting is possible.

It has been so long that I forgot, many years ago I created a hilariously geeky set of test files which tested input/output of every possible UTF-16 character possible both in the file name and in XML content and allowable tag names each individually named so that it was very quick to identify problems. I think input/output is a wonderful area to automate, and I had to share that I have had good results when automating mundane tasks such as verifying correct encoding and other functionality tests. Automation is not so good at finding bugs, but it is very good at doing some functional testing, so long as the expected result is pretty well defined.

In other thoughts, MS Arial Unicode is the biggest test font I've found for doing unicode testing yet, but is there anything as large and complete in number of characters for the Mac platform specifically? Help me oh fellow lovers of Steve.
...<< MORE >>

How to create a really terrible internal Test Tool-6 Ways to cause it, 6 ways to help avoid it.

Steps to Create a Bad Internal Test Tool
1. Have people who are not testers define the requirements.

2. Have someone who doesn't understand the context of the problem, hopefully someone who doesn't speak the same native language, make a very liberal interpretation of those requirements and "let the technology guide them" to the right solution.

3. Do not listen to the main users of the software, assure them it is a staged development model that will improve as time goes on.

4. Keep implementing features on top of the features that are already impossible to use.

5. If people tell you it is difficult to use, show them how wrong they are and write down the exact 87 steps it takes to do one simple thing. Explain to them that they must not be using it correctly.

6. Have the engineer who implemented the code write all of the documentation and training, and then if someone points out that it has no context or conceptual data and doesn't make sense, argue with them and tell them, "Just follow the steps."


Steps to Help Avoid a Bad Internal Test Tool
1. Have very early pilot users who are testers, test leads, test managers, and even higher up stakeholders, but not just at one level.

2. Create a very early prototype that a person could use on a small scale.

3. Take usability bugs SERIOUSLY. This will block adoption of your tool. It isn't a minor UI issue if people can't or won't use your tool.

4. Have your power users create and review your documentation if they are willing to. Even ask them to create short training workshops and do demos for you. They will be better at explaining to people how to use it than you will because they ARE using it, not writing it.

5. If more than 20% of the people you've asked to look at it tell you that it is too difficult to use, do NOT start writing more features until you fix the useless ones you've created already.

6. Don't start adding features just because one person asks for them. It should be based on how many people need it, not on the title and visibility of the person who asked for it.

While I'm on a rant, some tester had the audacity to say, "You can never have too much automation." What? My head nearly exploded. You can never have too much well designed, effective, cost saving, reasonably maintainable automation which start to finish saves you time over running the tests manually. Sadly, there isn't enough automation currently meeting those criteria, and far too few people actually measuring. Automation doesn't equal GOOD. It just is a buzz word. Garbage in, garbage out.

Thanks for letting me vent, oh internet.
...<< MORE >>

New Strengths or Flawed Testing?

In taking a training course I got another copy of Now Discover your Strengths 1.0. This is the third book I now own. I decided to retake the test. Only 2 of my stregths remained the same over the course of this year.


Here are the new strengthfinder results:
Ideation
People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena. ActivatorPeople strong in the Activator theme can make things happen by turning thoughts into action. They are often impatient.

Woo
People strong in the Woo theme love the challenge of meeting new people and winning them over. They derive satisfaction from breaking the ice and making a connection with another person.

Communication
People strong in the Communication theme generally find it easy to put their thoughts into words. They are good conversationalists and presenters.

Arranger
People strong in the Arranger theme can organize, but they also have a flexibility that complements this ability. They like to figure out how all of the pieces and resources can be arranged for maximum productivity.


As previously blogged, last year they were:
Connectedness
People strong in the Connectedness theme have faith in the links between all things. They believe there are few coincidences and that almost every event has a reason.


Ideation
People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.


Input
People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.


Activator
People strong in the Activator theme can make things happen by turning thoughts into action. They are often impatient.


Empathy
People strong in the Empathy theme can sense the feelings of other people by imagining themselves in others' lives or others' situations.


So, to summarize, I don't think I've lost my empathy. I think that what has happened instead is that those softer traits have taken a back seat during a time of massive change. I need the Communication and Woo skills more right now. I don't think woo is a real strength above other things. As far as the "Arranger" part goes, that is most of what my work has been this year. I've gotten better at that through practice, but I don't think it is a core part of my personality.


As a result of taking this test again, I think I have three strengths worth looking at, not five. It is silly to think that each person should have five or focus on five. In fact, Activator and Ideation above all others are strengths that are especially dominant in me. The others will change each year I'm pretty certain.


Activator (I fit the description perfectly)
Ideation
A mixture of Empathy and Communication (I use both together, but not each alone. I call this having social skills in general).

...<< MORE >>

Slipping Quality Due to Growth

How do we judge what quality customers will accept? How low is too low? When do consumers start to notice?

I saw this article about Toyota quality today. It startles me that this could be nearly ANY of the software companies who are rapidly growing right now. I hope it is never my company.

I don't blame the testing department of Toyota for this issue. It's the competative spirit gone wrong. It's a lack of emphasis being put on quality. Those little sacrifices and compromises add up. Now they have to pay in good will and customer loyalty. The decisions made back most likely in 2004 come to haunt them. I wonder how long it will take them to turn it around (if they can).

It is much easier to keep a reputation for having the highest quality than it is to gain or regain it. I wonder if it is cost-effective? I've never seen data on this.
...<< MORE >>

Testing in the Absence of Proof

I was inspired to make a blog after reading this. The context under which the word Religion is used is really interesting to me. Partly because it indicates that testing ideas and methodologies which can't be quantified aren't scientific and are just matters of belief.

As a touchy feely type person, and also a person from an artistic background who has since gained an interest in science, I feel sorry for people who have no belief beyond what they can verify. I think that the things that matter most in life can't be verified or quantified. I think that innovation can't be proven. You can't prove a new idea is good before you try it. This way of thinking makes some people feel really uncomfortable, but I'm not sure why. The most basic of scientific principles starts with a hypothesis. That is scientific curiosity. Even if an idea proves to be false after testing the theory, I have great respect for those who "wonder if" and will go find out. Those are the people making a real contribution to the testing profession. Those who seeks to stabalize, quantify, assure rather than test, and compartmentalize all testing really depress me. Trying to quantify testing is not a new idea. I find it rather boring. It is something I do because I have to, and as quickly as possible. I don't think it really adds much to the end quality of software.

I'm not suggesting that we shouldn't verify our assumptions, test our ideas, improve and adjust based on the findings, only that lack of evidence and proof is no reason to prevent us from trying something new. If we are to make true advances in human testing, small or large, we must have the courage to apply new ideas. Then as we are trying the new ideas, still have the humility to logically figure out what is working and what is not and make changes. Would the same idea work in another context?
...<< MORE >>

Automation and John Henry Plus The Perils of Training

I haven't been blogging because I'm learning to become a coder part time. I've now made a deal with my boss so that I don't go crazy (well anymore than I already am).

It looks a little something like this:
Half.day perWeek testyRedhead="coder". If testyRedhead != coder then resume testing and being <hostile

My reluctance, mistrust, and feeling that I can test better than automation can reminds me of the story of John Henry's Hammer. In this story, John Henry tries to beat a steam hammer but kills himself in the process. Ultimately, he fails to beat the industrial revolution. Is this heroism, or is he just stubborn and dead? My issues are no different. Being change resistant is unwise in the face of a steam hammer of changing industry trends.

I've been attending training. In fact, one of the best classes I've ever taken was last week. I feel 20% more comfortable with object oriented programming than before. I did quite well in the class, especially considering my lack of experience. However, it pointed out several things to me and clarified them by shedding a blinding light on several facts.

1. It isn't that I can't do it, it's just that I hate it and am not interested.

2. I like working on UIs, skinning, and overall project design and even pseudo code, but I hate writing code.

3. I'd rather get a root canal than work on any back end database code.

4. I could force myself to do this, but if it becomes a major part of my job I won't even make it one year more.

5. Each thing I learn points out the vast area that I have no knowledge of, and rather than a curious interest, it fills me with an unexpected level of dread and unhappiness.

6. My favorite part of the class was finding the bugs I found in the released software.

7. I wasn't put on the earth to be unhappy. Yes, there are things that must be done that we don't like in every job. If those things are growing and the parts you love are shrinking, much like a failing relationship, you must try to turn it around, and repair it. If you can't, you have to get out before you are no longer yourself, and become something miserable that is barely surviving life. I am hoping the "contain to 1/10th of job" compromise will take hold and will be something that works out for both parties. You can't have everything your way all of the time.

In other news, I'm hoping I don't get the "opportunity" (a.k.a. mandatory order from boss) to attend another course (a.k.a. self-impressed speech) by famed professor/author and Florida Software Testing Posse Member James A. Whittaker. The last "opportunity for learning" I had on the topic of Breaking Computer Software was the one and only training I've ever walked out of. It is the first time I've felt both insulted and horrified. I can't figure out if it was the fact that the ...<< MORE >>

Motivation

I have yet to find the man, however exalted his station, who did not do better work and put forth greater effort under a spirit of approval than under a spirit of criticism.
Charles Schwab

Each time we ship a product I have this phase afterwords which is sort of like the depression that sets in after the holidays when all you have is winter and the part you looked forward to is over. Now it's just paying the bills and taking down the decorations. The waiting and excitement are over. I'm no longer in a frantic state of final testing. Now begins the slow task of planning, requirements, and the ever dreaded "side-projects". I'm not much of a "side-project" person. I don't like writing code. I like learning, but really, I like testing. I enjoy being constantly busy and changing what I'm doing all of the time. I don't get whiplash from doing 5 different things in 2 weeks. I want someone to give me an impossible task to accomplish.

So, when things slow down, I start to get critical. Rather than doing everything I can to make it, I can see every flaw. Every way that the process can be better. That we can be better. Not just the place I work, but myself, and everyone around me. I can't stop trying to improve things. I am used to taking out all of my energy on the software I'm testing. Now what?

It's tempting to just turn that energy on something else.

I think I've lost the ability to sit back, relax, and enjoy the results of a goal met. I sit around anxiously thinking, "What now?"

To make matters stranger, I've reached two monumental goals in my personal life. I bought and moved into a beautiful house. I've always wanted a house, and this one is really wonderful. It is the culmination of years of saving and much effort and risk taking. To top it off, I've completed a very difficult health related task, and for the first time ever reached a physical "goal weight". That goal was over 5 years in the making and is always a "work in progress" even now. I felt on top of the world for a few days. Now I realize how much I have to maintain, how much I have to lose. I feel the responsibility of it and not the truth. The truth is, I am quite lucky and I can handle this. This happened in part because of my work, and in part because of luck. It didn't happen by itself.

The other truth is that I love the company I work for, the software I work on, and above all else, the team of people I work with. Being too critical is not a good quality, even in a tester. It is certainly not a good quality in a test lead. ...<< MORE >>

iLove iRobot

What fun it is to type "household appliance" as a keyword for my testing rant today. My boyfriend brought home a Roomba iRobot for us to use in our new house. Not only do I enjoy shouting, "Release the Robot!" but I also love watching it work. It also doubles as a cat toy/cat torture device, depending on which cat. The younger cat looks interested, while the old one looks horrified.

How it works
It stumbles along trying to find the boundary of a room. When it runs into a wall (imaginary as created by the false wall signal or a real wall or object), it bounces a bit as to not damage either participant in the collision, and then goes in another direction. If it encounters significant dirt, it spins in one spot for a moment before moving on.

Error Handling
We did encounter one error where it got stuck under our dining room buffet hutch. The two previous times it was stuck it was able to unstick itself easily by trying different angles. However, this time it really was stuck. It alerted me to the situation by making a sound so I could manually unstick it.

Usability
On the down side, it takes much longer than a human to vacuum a room of equal size. On the up side, the floor is really clean when it is finished, it is fun to watch, and I can do something else while it cleans the floor. Plus, it is fun to use and I think of it as my "little buddy". It is easy to remove the bin to clean the dirt out. It is easy to tell the battery state from the lights on the top of the vacuum. It even finds it's own charger when you are finished if you ask it to.

Learning Curve
Any person of reasonable intelligence willing to read the manual who has electricity and some D batteries for the fake wall can use this thing to clean floors. Now, in all fairness, repairing it would be difficult. You have to be reasonable about what limits this system can handle. I'm not going to expect it to vacuum up huge items or anything wet.


Why is my test automation not like this? How can I make it a trusty sidekick, which while it isn't perfect, is honestly useful and enjoyable for me to use? I think that the key is, I didn't create the iRobot. I didn't program it. I just use it. I love using it. It works very well for the purpose intended. I think if I tried to get it to do dishes I'd be less satisfied. The key for me is getting a tool that is already for the correct purpose and using it well. I think my attitude towards automation will improve vastly if I can do that. Not being good at writing code isn't a crime. It doesn't mean that I'm not a great tester.
...<< MORE >>

Bug Harvest Idea

PLEASE COMMENT-This is the first time I've taken this idea public and I'm really looking for honest, constructive feedback. Even if think it isn't at all useful, please explain why. It will help me.

Intent

A bug harvest is an organized and focused blackbox group testing exercise with a twist. It is called a "harvest" because just as those who pick strawberries may not be the fastest at picking apples, you want to select testers who already work on similar areas or technologies for effective and quick group testing in this context. The word harvest also implies that the fruit must be ripe. It is called a harvest because of the notion that bugs are introduced into the software with code changes, making certain times very "ripe" for the picking of bugs. Most experienced testers know exactly when that time is, and are used to using code changes to prioritize their testing. In some companies there is a handoff process when certain features are ready for test. There may be multiple times in the project where fast coverage by multiple people is very beneficial, especially if the development is staged. It is not meant to replace any other test methods, such as an open bug bash or bug hunt, but instead is an additional method that for use when bugs must be found under tight time constraints. It is intended to cover new code changes as quickly and efficiently as possible to compress the time it takes to get feedback and bugs to developers. It can be used in basically any software development model so long as your testing department has more than one tester, but I have only personally used it in a waterfall development cycle and one staged development model.

The other time I use this method is when fire drill requests come in. Wait, a new operating system and we have 3 days to test on it before they lock down the code?  Oops, we forgot to tell your team about our new dot release, and it could impact compatability with your software. In this case, why not throw every tester in the world at the problem? Well, because it leads to duplicate bugs, takes everyone off of what they are working on and stalls your project, and because you can do just as well, especially in early stages with a small focused swarm of testers attacking the area as with a large misdirected frantic swarm. I love Bug Harvest as a method for dealing with firedrills and have gone to it more than 5 times in my last product cycle with great results.

Who, When, Where
One of the keys to holding a successful bug harvest is to invite the right testers. This is not a bug hunt or an open call for all people to beat on a new feature. This will most likely overwhelm the developer with bugs, some "not bugs" and create a large pile of defects to be sifted through which may or may not be about the feature you wanted information on. Only testers with ...<< MORE >>

Test Automation Planning and Dogma

I'm working on my automation plan today and found this article. I can't believe it is written in 1999 and the same mistakes are being made at most companies still. My blogging time is really short right now, but I'm hoping in a few weeks I'll be able to blog more.

I was told by someone that my dogmatic talking about human testing is dangerous and that most people don't agree with me. It feels sort of like the mafia to hear that sort of thing, although, I know the intention was friendly, just to let me know that I'm most likely making career limiting moves. My desire for balance in testing is unpopular? With whom? Certainly not with most people who test or use software that results from it.

I must however give thanks for the reminder that I'm fighting a losing battle, but I've never been a political or popularity motivated person. I'm the dangerous kind. The kind who does what they believe is right despite criticism. While I view this as being ethical, I think others view it as stubborn, naive, and delusional. I also realize that taking on all of the things you perceive as injustice is one really good way to ruin your life if you don't put limits on it. Activism is tiring, so you have to be quite selective.

I may not have enough power or influence to do anything, but I have something still more important to me than having a big impact. I respect my own actions, even if other people don't. That is worth more to me than my job. I wish that more people had the courage to speak dogmatically about testing if they felt that way. Holding back ideas because they are unpopular just makes me want to scream that the Emperor is naked. Hey you, yes you, Test Automation. Put some pants on!
...<< MORE >>

How to Test Better Than Microsoft

Summary: Make usability and the customer's human experience using the software more important than creation and use of any particular method or tool in testing. You can't beat them in tools, number of people, amount of money, automation, or willingness to be competitive (well, I would argue that dog fighting rings could beat them in being competitive, but that would just be snarky). They have one huge weak spot, and that is in the area of creativity and seeing important things that can't be measured.

Judging from my views on Automation, I'm guessing most of you can deduce that I'm not a Microsoft Employee. Many people feel that Microsoft is a huge leader in software, and for that reason, they must have the best quality principles and methodologies in use, and every other company should follow them. In my blog today, I'd like to share why I completely disagree with that notion.

Having talked with many people, both Microsofties and Microserfs former and current, there are many positive things about testing at Microsoft. The availability of tools, the ease of finding them, the constant process improvements being driven by the competitive culture, and even the perception that aggression is "effective" in some groups have been sighted as strengths. I've also heard that the culture encourages people to take on side-projects which impact as many people as possible in order to get raises and bonuses. I am not suggesting that good testing isn't happening there, I'm only suggesting that it is possible to do better. I think that Google IS doing better. I think that our company IS doing better. If companies take the lead from Microsoft while they are growing, they will not be doing better for long. I haven't seen anyone have luck at imitating them and still produce better software than they do.

1. Currently having the most money is not a good measure of testing success.

2. Saving the most money is not a good measure of testing success.

3. Many of their users perceive their quality as very low and hate using their products.

4. Their products have very little "soul" and feel bland, generic, and slightly boring and inhuman in general. From this I assume that usability bugs are not taken very seriously, or, even worse, aren't being found and reported because it isn't easily tested using automation. How can something both be boring and "needlessly complicated?" Use Outlook and find out.

5. Who can automate the most and who can pass code coverage are also not a good measures of testing success. Covering the code is NOT equal to testing the product.

6. Who can cover their butts the most while testing is also not a good measure of testing success.

7. Having highest percentage of testers who can code does not mean you have the best test team.

8. The lengths someone will go to, cutting out their personal life balance is not a good measure of employee loyalty and quality.

How can I comment on this having never tested at Microsoft? First, a confession. I was married for 5 years (as ...<< MORE >>

No More Ugg Boots!

Do you remember when every celebrity under the sun was paying hundreds of dollars on Ugg boots? They were such a huge trend, and so very very ugly.

I am tired of using automation tools that could be Armani Suits but instead  are Ugg boots or a $1200 handbag, or even $3000 jelly flip-flops. Can I just get a sturdy backpack? Please? Didn't so much need the high pricepoint in learning just to have my tool go out of fashion in less than a year.

This is what happens when test managers don't understand what they are asking for. A test automation tool IS a software project. Ignoring the users of it is really not a good idea. Designing it for 2% of those using it, also not a good idea.

I have trend whiplash so badly that the last automation tool I saw (it was a mandate-I had to go), the entire time we were looking at the code, my only thought was, "I've been poor. I'm good at it. I'm a great saver. If I have to choose between doing this all day and my job there is no choice. I could wait tables. Seriously, I'm kind of cute, I'd do ok." It is not a good sign if Automation has been rammed down your throat so much that you have a gag reflex whenever Automation is so much as mentioned. Umm pushy much? I only blog about this because I think this is industry wide and a huge problem. I'm extremely passionate about testing. Does my burn out on Automation mean I'm a "burned out tester" now? How could I not be burned out when my work on automated testing in the last 3 years has been much like digging a hole just to fill it back up again? I will say, however, there are 2 automated tools which I DO support, will use, and almost (squirm) like? Yes. I like them.

Companies who are reckless with their talented testers, their brain engaged testers, who can't appreciate and value people beyond their coding skills deserve to be brain drained by other companies. We've seen the crappy results from other companies in the industry and I hope we don't need to repeat their short sighted and failed experiements in order to fully understand that having all testing automated is a horrid goal. To have all software tested by "developers in test" means that anyone creative who is scientific on the side no longer has value.

I've got my hiking boots on. Keep those furry monstrocities off of my feet. I've got somewhere to be!

...<< MORE >>

Find your Strengths-Here are mine

According to the book Now, Find your Strengths. here I think it is pretty accurate. I love the boss who had everyone on our team read the book and take the test. The idea that you should focus on areas you have natural talent is a very simple one, but effective.

Here are my "themes" as according to the test. What does a person like this love? A person like this LOVES to get ideas on collaborative testing, share ideas, and put them into practice NOW NOW NOW. Ha! I also love working on product interaction and feature integration because the way that code connects is interesting to me.


C O N N E C T E D N E S S
People strong in the Connectedness theme have faith in the links between all things. They believe there are few coincidences and that almost every event has a reason.


I D E A T I O N
People strong in the Ideation theme are fascinated by ideas. They are able to find connections between seemingly disparate phenomena.


I N P U T
People strong in the Input theme have a craving to know more. Often they like to collect and archive all kinds of information.


A C T I V A T O R
People strong in the Activator theme can make things happen by turning thoughts into action. They are often impatient.


E M P A T H Y
People strong in the Empathy theme can sense the feelings of other people by imagining themselves in others' lives or others' situations.
...<< MORE >>

I've been allowed!

This just in: My manager has agreed to allow me to follow my dreams of cross-team QE demos and bug finding competitions. At my company, agreeing to let me persue this does not mean time and budget or resources to persue it, just that I have a chance to stalk people for resources, convince them to help me do it, and to use my charm and charisma (plus begging and making cookies), to try to get it to happen. On my side? Excessive enthusiasm. Against me? I'm already pretty overloaded, but hey, it's worth some risk if you really really WANT to make a difference. It's worth me giving mediocrity to less important things to really give this area I care about my very best. Nothing gives me thrills quite like testers from multiple teams in a bug finding frenzy for prizes and small scale fame. I'm doing my best to make testing more fun and efficient at my company in the way I believe is best. What else can I work on that is as important? Making more useless automation to maintain? Covering my butt more completely with further layers of documentation?

I just heard back from the legal department at my job! I am now free to talk at will about my testing idea with the general public!

This is great news.

Plus the lawyer told me that he hopes I write a paper. I plan to not let him down, although it will be much more blog than paper.

I'm swamped with bugs this week and testing shiny future operating systems, so most likely I'll get time to start this weekend or next week. Expect few blogs here until "The big one". I want your feedback, so please be ruthless. Tell me my ideas are NOT new, NOT origional, and pick them to shreds. Umm. Then help me put them back together as the stronger leaner few survivors?

Coming Soon: My Bug Harvest Idea in detail.

*wanders off singing to herself much like Bruce Almighty-"I've got the powah!"*
...<< MORE >>

You aren't a Technical Person

It's impossible for a creative artist to be either a Puritan or a
Fascist, because both are a negation of the creative urge. The only
things a creative artist can be opposed to are ugliness and injustice.
Liam O'Flaherty

Ugliness and injustice are two of the things I really don't tolerate well in software. This is why I'm so passionate about human testing. Testing for usability. Buying software that is terrible to use is both ugly and unjust! I take great pride in preventing that from happening whenever possible.

I had a conversation with my boyfriend this week. He was telling me about his day. He writes code and actually enjoys it. He explained to me calmly what branching was, to which I replied, "I know what a branch is, remember?" He continued to tell me the tale of code until 10 minutes later I said, "Can we get to the more condensed version of this story, because you lost me 30 seconds ago?" He replied to that, "Oh, I forgot, you aren't really a technical person."

For about 3 hours I felt offended by that. Finally I came to a realization. He is entirely right. I am a creative person with technical ability. When I make effort to understand technology, I get my jollies thinking about the big picture. What that technology could do. For me, the exciting part is in the application, not the details of how the technology works.

Some people are scientists at their heart. I am proud to be me, an artist, who has learned science, but will always be an artist first.

I believe it's easier for a creative person to learn science than for a scientific person to learn to be creative, but I am delighted that we have both. I believe to be a great tester, it is important to have both, whichever way you get there.

...<< MORE >>

Goals

So, I haven't been blogging this week, but I wanted to share what I'm working on. As a test lead, I have quite a few tasks in process that I need to complete by the end of August. I have a difficult task as my team does more human testing that requires interaction with the real software than most teams, which is not very popular at any company at this point in time with software management teams who wish that everything would be static, test case based, and automated. We do very broad testing across MANY applications (well 16 applications is the most so far). I've taken some of the inspiring things that I've learned at recent conferences and by reading some blogs about some of the new directions in testing techniques and have tried to align my goals to them. I have sanitized the portions that are company specific so I could show you and also get some feedback if you can see some ways I could improve my goals to match my real overall mission.

Mission Get R Done=My overall mission is to meet any criteria needed to satisfy management which may not be useful for our team once the product is ready to test as soon as possible so that I can focus all of my time in actually testing with a user perspective as efficiently as possible.

Mission No Sucky Automation Drain=Make sure that maintaining and writing automation doesn't conflict with or take time away from the actual testing during the project.

Mission Not a Programmer Don't Wanna Be Thanks=My third goal is to not waste time learning skills that I'll never apply in my job or that I don't have talent for and interest in. I have extreme passion for learning, so why let that go to waste?

1: People Management-Lead Media Validation for (product) to deliver quality media testing in the scheduled time for all (# of) languages. This includes communicating status and escalating issues when needed.
Success will be measured by: Completing Media Validation as agreed upon in test plan on time.

This is a slam dunk and now finished. We finished early, so a big check mark for this one. I learned while doing this project that I can actually handle getting 1000+ emails per day and not cry or hurt anyone, even after working 3 weekends in a row and having little sleep.

2: Individual and People Management- (New Test Case Management Tool)-Enter at least one (list of charters for session based testing) into (Test Case Tool). Lead discussions about levels of granularity and work with the team to pick a consistent way to enter (high level exploratory testing task and collaborative testing sessions) into (Test Case Tool). Explore the possibility of moving other documentation, such as the main (testing charters) for new features into (Test Case Tool). Explore using session based test management practices in (Test Case Tool) for clearer test coverage documentation as well as for reporting automation results.
Success will be measured by: Standards for use of ...<< MORE >>

Invite the Mad Hatter to Requirements Meetings

"Take some more tea," the March Hare said to Alice, very earnestly.
"I've had nothing yet," Alice replied in an offended tone, "so I can't take more."
"You mean you can't take less," said the Hatter: "It's very easy to take more than nothing."
Lewis Carroll, Alice's Adventures in Wonderland

I'd say that it is very easy to do more than nothing and very difficult to do the right amount without considering the results. Taking one cup of tea vs. say about 15 pots of tea. How much should we do now is a good question. Is taking no tea and leaving the party a good option? ...<< MORE >>

Joy at Work-The Best Time Testing Ever

I couldn't leave that last blog out there, so negative, without the happy side.

I'm a strange tester because I don't like working alone. Collaborative testing is one area that I'm always researching, experimenting with, and trying new things with. One of my dreams is to some day make a valued contribution to this type of testing. I keep trying my ideas, and some of them fail, and some of them are works in progress, but one made it out into actual practice.

One of the days that I remember the most was the day my manager agreed to let me try out a crazy testing idea with other participants! I really want to go into detail about this idea in my blog, but I haven't been cleared yet to talk about it.

What I learned from sharing my idea and involving other people was that not all people who test imagine things visually inside of their head. Many testers understand what they are testing only in words, and pictures confuse them. Some people will look at an idea I've drawn or represented visually and say, "Oh! Now I understand", and the person next to them is staring at me like I'm some sort of fraud who came up with an idea that will never work. If I take the same information and write it out in a list with levels, the second person says, "Why did you overcomplicate this idea? Now it makes sense and I'd be willing to try it." This was earth shattering news to me. Some people are terrified of a big picture and resent those who try to present it. Not because they disagree with your view of it, or question it, but because they feel overwhelmed by it and don't feel that they should need to see it to get the job done. I was hoping that those giving me feedback were just going to argue about how I hadn't been complete in my representation, or that they disagreed with the content. I was shocked to find that seeing everything at once was a barrier to understanding for many people.

I've done some reading on learning styles, personality types, leadership, change, change resistance, introducing ideas, and different ways to visually represent data since that day. I now realize how easily a great idea can be killed by the wrong reprensentation, and by assuming that other people think like you do. Luckily, this idea wasn't killed. It was seriously reformed and more chances were allowed. It still lives in a small and very altered form.

The second "best testing day ever" was really a 2 day period of time. I kept corrupting documents while testing, but was unable to get a fix because once the corruption existed, the data was unrecoverable, and no log data was helpful enough to debug the issue and create a fix. I believed that I could find a way without an 87 step bug report to recreate the issue. I worked until 2am and the ...<< MORE >>

Personal Life Drama and Work-The Worst of Testing Times

Some of you may consider this blog quite off topic, because it is very personal. I want to share with you my survival strategy for some of the biggest problems I've ever faced since I've been testing, and none of them were testing related.

The following things happened in a 12 month span of time my 3rd year as a perm employee with a software testing job:

1. I was in intense chronic pain, and going to the doctor often, with no cure AND no definative diagnosis in sight. I'm not talking a little bit of discomfort. I'm talking about laying on the floor and crying, trying not to panic type pain. I was very worried that I was going to become fully disabled as it kept getting worse.

2. My marriage was totally falling apart and soon I was getting divorced, and 2 months after the divorce, my ex-husband remarried to someone I knew. I would go into more detail, but then it would seem even more like Jerry Springer, so I'll stop right there. Ultimately, it was the best thing that could have happened in life, but at the time it was rough.

3. My grandmother passed away.

4. My mentor, the first person to teach me how to test, who I credit with the fact I ended up staying in test and actually HAVE passion for it, died suddenly.

5. Major layoffs. I've survived 5 layoffs at my job. I have no doubt that part of this is luck. I understand that in software I am far more likely to be laid off than to retire from the industry.

So, in the face of all of these issues, I made it through that year and managed to do a decent job of taking care of myself, healing, and getting work done. I'm proud of the testing work I did during that time.

Things that helped:
a) Tell your manager if you are facing a very difficult problem.

b) Do NOT cry in your office. Go into the bathroom. I'm sure some of the people at my work thought I was developing IBS or something during this period of time, but really, if you can't leave your drama at the door, at least try to set up some sort of no crying zone. I'll add to this, carry eye drops, take some time to calm down, get it together, and come out once you are calm. If you are female (such as me), some under eye concealer in the purse is always a plus. You are testing, and can't do a good job if you are hysterical emotionally, so you might have to work later if you aren't able to focus for part of the day.

c) Work early or late if you need some alone time. This is one of the perks of testing at some companies, so use it when you can.

d) I set up a meditation area in my office to help with pain control. I would take 20 minutes, lie on the floor, and do pain meditation.

e) GET HELP. ...<< MORE >>

Blogs I Like

Here are some blogs I like about testing, or that I have been enjoying reading for testing inspiration.

First, we have someone else with an insane interest in collaborative testing techniques, but with more experience and internet fame than I can imagine, that is Jonathan Kohl. I've never met him, but have started reading his blog and am inspired. http://www.kohl.ca/blog/

Secondly, you may ask why this feed is about testing, but reading the Astronomy Picture of the Day is an amazing source for testing ideas. They are discovering and explaining so much that I've been inspired with testing ideas more than once from a daily glance at http://antwrp.gsfc.nasa.gov/apod/astropix.html. Seriously. It may sound silly, but it works for me.

Thirdly, one of the most hilarious people I've ever worked with has started a blog at http://pharrmentation.blogspot.com/. He is versitile, warm, and a great tester, so give his blog a read.

Next week I'm hoping to really go for it. There is one testing idea that is sort of "My Baby" and I'm going to make a big blog about it. I'm hoping for constructive feedback, but bashing my idea is also allowed. I'm making a study of collaboration in general right now, so if you have any links to help me in my learning, please comment. ...<< MORE >>

Mistakes

"The great question is not whether you have failed, but whether you are content with failure."
  — William Shakespeare

That is a great quote to bring to a contested bug deferral.

I got into a conversation about testing mistakes with someone. I don't know any practicing testers in the industry who do not have at least one bug they have shipped with which they really regret and feel ashamed of.

When I was a brand new tester, working on contract at a big company, I was assigned an area of the product which had been tested. It was legacy code and I was handed an existing spreadsheet of well defined test cases along with a spec and test plan. I went about running all of the test cases and even went off of the script from time to time. When we shipped, I certified the milestone and felt great about how well tested my area was.

Then a bug came back that if you were to drag anything over one disabled icon in a peice of UI that was MY responsibility, the application would crash! This blew my mind. I had already checked that it was disabled in the script. How could it not be disabled? It was greyed out, not disabled.

With such an obvious miss, why am I still testing? Should I have been fired? Why did they let me continue my contract? I am still testing because I learned something very useful from that missed bug. I am more curious, skeptical, and I do not follow scripted test cases a majority of the time. Missing a bug is not a good reason to fire testers. In my opinion, dishonesty, being burned out, not testing, not learning, not working with other people, not communicating, doing the minimum required, needing constant hand holding, having no passion, being brain disengaged, and refusing to seek your own answers should be career limiting offenses. Those are good reasons that you shouldn't be testing. Making a mistake is not. Being human is not. Doing the best you can with an unreasonable schedule should not, so long as you communicate the risk.

I feel that if you aren't making any mistakes, you should be increasing the level of risk that you take. ...<< MORE >>

The Soul of Software

One of the responsibilities I take very seriously in testing is protecting the "soul" of the product I work on. If people hate using it and I have not shared the reasons why I believe they will and reported that, I have not done a good job as a tester. To explain what I mean by my unapologetic anthropomorphism of software, I want to get into my favorite and least favorite software of all time and why.

Top 3
1. Adobe Photoshop-My love of this product is so insane, and NO, it isn't just because I participated in the Photoshop 5 bug hunt and won an Ikea gift card, although, Swedish furniture doesn't hurt. Before I totally show my age, here are the reasons I love Photoshop.
  a) The uses are limited to your imagination. It doesn't TRY to guess exactly what you are doing.
  b) Plays well with others. Saves in many formats.
  c) Truely one of the most innovative products ever, and remains a true origional by continually adding new things such as "align layers by content" and the new "selection" tools.
  d) Is simple or complicated, depends on what you are doing.
  e) If I take your pictures you'll never have acne, wrinkles, or bad undereye circles again (unless you want them). Trust me, if I take your picture, it is my job to make you look hot. I've been told that if the software thing doesn't work out, I should go do photos for Playboy. One side effect of this is that I picked up my boyfriends Maxim magazine and couldn't stop pointing out the Photoshop work that wasn't very good, and which tool they used. I was so engrossed in what post processing they did that I forgot to be at all jealous. Well, with Photoshop, I TOO can be a Maxim girl on print anytime I want. Did you know, I'm a software tester AND bikini model? Ok, maybe not in real life.

2. Google Mail (gmail)-While this has been beta since Orville Rednebacher was a boy, I LOVE this email program. There are a few things I'd like improved, such as notification software for the Mac, but all in all, I've never used better email anywhere at any price.
   a) Free (well, ad supported).
   b) Web Based.
   c) Archive and free space. I no longer have to use work arounds to manage my mail. This is a huge timesaver. Microsoft Outlook is even more of a clown due to gmail putting it to shame on efficiency alone, and for free.
   d) Easy to search.
   e) Handles threads nicely.
   f) Doesn't have fancy features, because it did the simple ones right. So, do you really need rules if you can instead manage your email most reasonably with just archive? They fixed a problem for 80% of users correctly instead of spending all the time on the 20% extreme users.

3. StumbleUpon plug-in for Firefox-This is a plug-in where you tell it your interests and it introduces you to websites based on that, and the voting of ...<< MORE >>

Items that are the same may not appear the same

Astronomy is one of my interests and minor hobbies and I saw this picture in the feed of the picture of the day. It is an interesting example of human bias. If those objects (In this case color squares in an image) are mean to appear the same, there is a bug here, despite the fact that the colors are entirely the same scientifically. This is a bug that won't be be found by most automation because the context of the problem is the source of the problem. This is one of the best justifications for human testing that I've seen. If software is meant to be used by humans, there must be a viable balance of thoughtful human testing.

Just because something IS the same doesn't mean it appears the same to human eyes.

I can just hear now the  response "It is working as designed" coming from the rafters as I type this. Testing SHOULD provide feedback on the design as well as the functionality. ...<< MORE >>

Automation Thoughts of the Day

Thanks to Matt Stratton, I found out that I do have an RSS feed if you'd rather read that. It is http://blog.testyredhead.com/rss.aspx.


Yesterday was a great work day for me. After much complaint, ranting, and worry, I am now in charge of writing the automation plan for our team. It seems that rather than just catagorizing me as someone who is "anti-automation" and telling me that I either comply or get out, a few people are willing to believe that I'm just anti-bad automation, automation where it doesn't belong, and the wildly irresponsible assumption that everything automated is somehow better than everything which is not. Why is this good news you ask? Because I have some ideas of how to reduce the likelyhood that the automation we are working on will become useless to us and a waste of time.

I'm putting the plan together with the following new ideas.

1. All of the automation time IN will be tracked. Just as we are using Session Based Test Management for our thoughtful hand crafted tests, we will also be using this for Automated tests. This means while creating them, investigating problems with them, sifting through results, and maintaining them, that time investment will be tracked and reported. The fact that almost all automated test plans are missing this makes me cry into my pillow at night. Representing an accurate picture of the automation costs is a vital part of making a good logical decision about the value of automating certain tests. This is going to take some evaluation on my part, and as a new process I'm sure it will be refined as we go along.

2. Protecting areas which really NEED thoughtful hand crafted testing. This is like a wildlife preserve. I get to set aside a "no drill zone" for those areas I feel would be destroyed if left to the robots.

3. Using automation to make session based test management easier for all tests. I have an idea for making this sexy, and no, I'm not talking about perl and text files my friends. I'm talking about some lipgloss on that pig. This is something I can get excited about. I'm a big believer in experimenting with the visual presentation of data, and I have some tinkering to do in this area.

4. Pimping out automation other people already made. I call this, maybe we can create a sexier wheel, but that doesn't mean it's cost effective. Now,..everyone into the shopping cart and we're headed for the Hawaii! Wish us luck! (glub glub). I kid, I kid. We will try to at least provide a hearty rubber raft with patches when we go out in the open ocean.

That reminds me of a story. On our 3rd date my boyfriend and I went to the lovely Ballard Locks here in Seattle. If you haven't been, you really should go. He noticed some Yachts going through and talked of his dreams to have one. I told him ...<< MORE >>

First Blog

Recently, I attended a testing conference named CAST 2007. I've been blogging since 2001 in my private blog, but I've never really published most of my testing thoughts for the general public, for a number of reasons. One being that non-disclosure law makes me feel kind of nervous, and I don't like criticism without a point. I've felt like I have the best job in all of testing for years, so protecting my company was more important to me than sharing with any community at large. This seems really selfish when I see it in writting. I'm not like many of the people active in the testing community. I have no problem with authority. In fact, I've even written "Best Practices" documents for creating automation that is based on written test cases. I spend months plotting out the most complete new feature test case documentation only to have it become out of date almost instantly. I have experiences that every tester has, and a few unique to me.

I was inspired enough by one of the sessions I attended to finally come out of the blogging closet, and take a chance that someone might benefit from my testing rantings, and that someone might even be me.

I want to gossip for a moment about James Bach. I've been testing for seven years now. I've seen at least 25 different speakers about testing. He is my personal favorite, and the weird thing is I don't know exactly why. It is disturbing to me that I find what he says both so charming and correct. Is it because what he says makes me feel good? Or is it because I believe he is right? Is it because he likes people and I am "people"?

I know why it isn't. It isn't because he's "My Type" and the redheaded tester girl has a romantic crush on him. First off, he has a beard. No offense to James, his lovely wife and family, or any other of my furry faced friends, but beards are a huge NO for dating in Lanetteland. Luckily, I have a wonderful boyfriend (clean shaven, of course), so the fact that many computer loving folk have beards won't be a problem. Secondly, he likes video games, and it sounds like he does quite a bit. Thirdly, he has no real problem with confrontation and discussing the meaning of the word "is" or any other philisophical discussion for as long as you may like. I bet you could even ask him, "What if the word D-O-G really spelled cat?" and he'd think about it and discuss it with you for a long time. I have the patience of a three year old waiting for a cookie.

The reason may be because he believes in the value of human minds in software. He is one of the people in the software industry who does not seem to believe that I could easily be replaced by robots were they programmed a bit more correctly.

I feel like ...<< MORE >>