Developing People

As a single mother in the 21st Century, there is a lot you want to say and do for your children to help them avoid the pitfalls that this world sets up to snare them and make their life more difficult. As any/every parent knows, it is difficult to see the fruit of your conversations and prompts with your children. But every now and again something shines through that makes you see that all you say and do really does have an affect on them. I had one such moment this week with my 17-year-old daughter.

She is a senior in high school and struggles with the system the same way I did when I was in it. The way the English classes are run/taught has been difficult for her since her Freshman year. However, give her something to write about that she feels deeply enough about and you can "see" who she is and what is "in" her.

Today I am going to switch from software development to people development. Today I want to share her essay on "A Satisfying Life".

"A Satisfying Life" by Rebekah Smith
Dissatisfaction comes from ourselves. People constantly blame others for the way they feel when really we are the ones that control our own feelings. If people would realize that they are responsible for their own lives, including their levels of happiness, that would be the first step in being happy. People these days don't want to admit to being the cause of their own problems. It's easy to point fingers at teh people who have hurt you, and you can blame them for your current state of mental crisis. , but in reality, no one else controls you except for you. Brent from the book, "Whirligig" proves my point. He went to that party and was rejected by the one girl he had always wanted, and his friend wasn't being all that friendly either. So he took the car and drove until he spotted another vehicle, and he ends up killing another girl, rather than himself. He blamed his unhappiness on the fact that he was rejected rather than the fact that his mood hadn't been so good earlier in the weeks either.

Another thing that prevents every from being happy is the amount of artificial crap they buy to give them a temporary bout of happiness. That's the thing. People go through life just experiencing bouts of happiness here and there and that's what they live with. They're used to this concept and it's all they know. Yet when those bouts are over, they're unhappy again. So they buy something else. From drugs to new cars; and laptops to houses. None of it gives you a long term good feeling, it all just makes you happy for a minute and then you're back to feeling like junk. Mitch in "Tuesdays with Morrie" was like this. He thought that a beautiful house and a great paying job would make him happy. It didn't. The new shiny car he had didn't make him happy. Things don't make people happy.

Actions can prevent happiness. We do something wrong, we hurt someone else and we end up damaging our own mentality rather than the person we had targeted in the first place.

It makes me feel exceptionally proud to read the words of this essay and the thoughts behind them. And it helps me to understand that developing people... or helping people develop to put it in the correct context... pays dividends not only to the people in the "relationship" but is paid forward in time as well.

This week think about the interactions you have with people. Think about what you would like to invest in with the "relationship". Think about what you would like to see as the dividends. I am willing to bet that you notice some things about yourself as well when you do this.

A Revelation...

Michael Bolton, as I stated in a previous blog, suggested the book The Inmates Are Running the Asylum to me to read.

Not quite into Chapter 2 and I wish I had read this book a long time ago. Because I use software in my daily work, the following paragraph from the book jumped out at me:

"Most software is used in a business context, so most victims of bad interaction are paid for their suffering. Their job forces them to use software, so they cannot choose not to use it - they can only tolerate it as well as they can. They are forced to submerge their frustration and to ignore the embarrassment they feel when the software makes them feel stupid."

What a simple, yet powerful statement. How many times I have been at my wits-end with the defect and test case management tools I have been "forced" to use. And yet I never really gave much thought to the user/customer base of the products that I test within the same light. I wondered why that is.... and I think I gained some insight into it.

The software I test is delivered to me along with conversations with developers, product managers, documentation, flow charts, etc. I understand the "expected" behavior. I understand what the software is "supposed" to be doing. But the huge missing peice is that I hardly know the customer/end user. And that missing peice is huge because that customer/end user is the one that is "forced" to use it to do their job. What a revelation....

Which part is the revelation? Understanding that I am a customer, paid/forced to use some software products/applications that make me feel either "stupid" or "frustrated". How can I use this "revelation" in testing? While it is unlikely for me to get to know the actual end users/customers, I can advocate for simplicity in UI, performance issues to be resolved, and spend a bit more time researching the way that the users interact withthe software/application/product.

Some of this I already cover: I read forums that users of the application/product/software I test - and similar/competitive applications - communicate in. I check out reviews that are available to compare the product/application/software I test with other comparable ones. But the customer voice may still be missing in this. We - most of humanity in the 21st Century - have grown accustomed to using software, even less-than-worthy/frustrating software, just because it does part of our job for us, just because we have become dependant upon it. We are, quite frankly, so used to bugs that we tolerate and expect them.

Can software actually be user-friendly? Something to think about while testing and while navigating through the world of software we live in each day....

ET and the Bug Bash

Michael Bolton suggested, via a comment on my last blog, that I might like the book The Inmates are Running the Asylum by Alan Cooper. (At first I thought he had visited my team without me knowing - ha ha.)

I ordered the book using a gift certificate from Amazon.com that I won as a prize from a "Bug Bash" at work. This "Bug Bash" consisted of some rules. I broke just about every one of the rules...

I thought I pulled myself out of the contest by doing this... and that didn't bother me because I was interested in a couple of other things. I wanted to see the bugs that were submitted by my colleagues - especially those who generally don't do exploratory testing, and I wanted to see if my instict of focusing on something else was viable - I guess I was testing my mind.

Both of these things had interesting outcomes. Those who generally did use exploratory testing skills excelled as always. Those who did not, or were newer to the field, did not. This brought to mind a few questions and added fuel to the fire of my belief that ET IS a skill. (If I hear one more person say "monkey's banging on a keyboard"... ) Wouldn't it be interesting to interview a tester who was new to the experience of exploratory testing and ask them just a few questions? I have met a couple testers along the way who just could not wrap their brain around the concept. They wanted... no - needed... to be pointed in the right direction.

When I was lead of a certain project, and a certain tester was made available to help me, I found the best way to help this tester to utilize exploratory testing skills was through Session-Based Test Management. I would lay out the features and the times the tester was to spend on them. An example: Feature A - 45 minutes. At that point, the tester was instructed to stop testing it and move on to the next feature. This worked wonders for the tester, which added value to the service for the project.

This particular tester had trouble with a few things. He/she would feel a lack of confidence when given an exploratory testing assignment. "I can't find things like so-and-so, I look at the application/product/system and my mind goes blank." When given a set of instructions, sometimes the "blank" mind becomes preoccupied with the task and forgets it may not "find things like so-and-so". Some people are task oriented. Tell them what to do and they can do it. That does not mean they don't have some level of skill, it just means it is tapped into differently. The other issue this tester faced was related to time. Thinking about doing a single task for the entire day can be daunting - even if it is something you love to do. Breaking the time into sessions is a great alternative for people geared this way. It alleviates a lot of the percieved boredom and stress.

Exploratory testing, in my opinion, is a skill. It can be learned, and it can be built upon. It is a matter of training, whether of yourself or others. Even if you have natural capabilities, in software testing you need to continue to build upon your skills as the technology changes - train yourself to keep up.

As for the second thing I wanted to see... If my instinct was correct... this time it was... oh Happy Day :)

User Characters...

User Stories are generally about an average user. When a Product Owner writes the stories he/she is considering what they believe the user would like to have the application do. This makes perfect sense until development has implemented the feature.

As a tester, it is my job to create some Users and see what happens to the story. If the User Story says, "As a user, I would like to add a sheet to the document I am working on, so that I can continue to add information to my report". It is important to have an understanding of who the user is and what an average sized document consists of - how many sheets specifically in this case.

Once the application passes the tests for the average user it is time to then test it according to the non typical user (time to have fun). A User Story typically won't mention things like:

"As a User I would like to add 200 sheets to my document and still have the application respond so that I can complete my task and continue to use my PC."

"As a User I would like to add sheets to multiple documents when I am working on them, having multiple instances of the application open, and not have all my CPU tied up, so that I can finish up before the big game."

"As a User I would like to add sheets to my document quickly so that I can get the document to the Post Office before it closes."

Depending upon what the User Story is suggesting the User wants, there are lots of other "Users" that the tester has to think about and test for. Characters can be thought of as the Story unfolds to the tester. What types of User Characters can be invented to use the application while testing? The typical User, the multi-tasking User -who has several applications running at once on their machine along with the one you are testing, the Forgetful User - who cannot remember to shut down the application, the Random User - who starts and stops and changes their mind while using the application, etc.

When testing User Stories, I find that creating User Characters, or thinking about the different types of Users that could be running the application/product enables me to feel more confident in what was tested/how it was tested before the items move to "Done" - even though it is highly likely that I will not cover them all, a random sampling of extremes can cover a lot more ground.

Balance...

I am always on a course of seeking balance in my life, and it often seemed to elude me... Until I realized that seeking balance is really the biggest part of achieving balance. Since I came upon this realization I feel a lot less "guilty" for not having achieved it to the degree my nature desires to have it (type A), and a lot happier with myself for having the desire/need/aspiration to find it, and the drive to do what is necessary to find it.

In the course of the last few months I have found peices of myself that I had left to sit in the corner of the room while I was looking to achieve certain goals I had. While some of these goals were forthcoming, they lacked something that I could not put my finger on. Turns out the peices of myself that were in the corner of the
room was what was lacking. And I discovered some wonderful things in those peices.

I have placed a large emphasis on my career and my children in the last five years - being a single mom will do this to you. In focusing so much on these two things, some aspects of my life became cob-webbed over. Astrologically, I am a Libra, the scales are the sign, yet I could not seem to get the balance inspired by this - I began to think about it - alot. I began to think about what I wanted, where I wanted to be in a few years - my personal goals, and I decided to take some time off.

I did not take the time off from work or from being a mom, that would be impossible, but I took the time off from being a driven individual with a single sight on the two things. I began to take care of some "me" things. I found I can still laugh at myself, still play, still explore the things that inspire me, and still dream like I did when I was five - with the inspiration to believe that I can have what I dream
about.

In the last couple of months I have built snow forts and back yard ice skating rinks, gone fishing, written poetry, took life a lot less seriously, and began to write what I hope will be my become my first fiction novel, took up cooking again - used to actually enter contests and sometimes win, among other things. These are things I either always wanted to do, forgot how to do, or never even thought of doing. I guess I took time off to "test" myself. To gather information for the "person that matters" in order for her to make some decisions and create some life goals. I am pleased with the results and look forward to the rewards that I will find in continuing to seek the "balance" of my life.

One of the biggest trials - with great rewards - has been the transition I have had in the project I am working on currently. I have been transitioning from a multi-project team to a single-project team.

This has brought about a lot of challenges that I am sure will stretch and grow me. It has been a lot like a young bird leaving the nest and learning to fly on their own.

The project, as a tester, is a once-in-a-lifetime challenge. Testing from the ground up on an agile team that has been put together by the powers that be in expectation of having a "dream team". (No pressure there...)

I have been learning what it means to value "individuals and interactions over processes and tools" - this was the one concept of agile development that was fuzzy in my mind prior to this project, but has begun to develop into an understanding.

Not much of a people-person by nature, I have begun to understand the value of working as a team for a common goal - because that is really the only way to achieve it, and the only road to success.

While this blog was mostly on personal discovery, isn't that what really drives the tester? Without personal discovery there can be no more questions....