Working with User Stories: The Existing Parts

Posted on June 28, 2009 by karennjohnson

Let me digress to make a comparison (in the process I may age myself but so be it) – I think back to the time when desktop publishing was first introduced. With desktop publishing draft copies gained a way of looking complete, finalized and picked up an air of authority based solely on the crisp appearance of the material.

I think of user stories in the same way.

I don’t like to review user stories and believe that they are always “right.” I don’t believe that the stories are always “complete.” And I don’t believe user stories can be the authoritative source for anything more than “what the author thought the application would do at the time they wrote the story.” I am a committed skeptic.

Like reading the answer key while taking a quiz, I don’t like to read user stories before I’ve gathered my own ideas. I worry that the user stories will stifle my testing thoughts.

So what do I really do with user stories? I put them aside at first and …

I think about what functionality is either being introduced or enhanced in the coming build and what test ideas I have collected in my notes already.

I think about existing functionality and what might need to be regression tested.

I review the data model. I expect myself to be able to envision how the application is being changed by reviewing the database changes. I usually can. I pick up more test ideas this way.

Then I pick up the user stories and …

I scan stories for their titles, if the title is written well, I get the point. I don’t continue to read for the details until after I’ve thought about the functionality being introduced or improved. So I’ll take the title of a user story and then think through ways to challenge the premise of the story.

I go back and read the user stories thoroughly. I ask questions. The questions I ask often result in early bug finds and more user stories being written. If I can find issues that early in the process, that’s great.

I write notes while I read the stories. My notes are often more test ideas.

In my experiences with user stories, the most helpful aspect is whenever I learn about a scenario that I didn’t think about – some nuance that I didn’t foresee. I bump these test ideas up early in the process because these are the stories that I feel I can learn from – the stuff I might not have expected.

Despite sounding somewhat negative or skeptical towards user stories, I actually do like them. I generally prefer user stories to more formally written requirements.

User stories are especially more helpful than the requirements that often get written around the medical software I’ve worked with that has so many requirements commanding: “the system shall X” but yet much of the nuance of “how” is not addressed.

I also like to think about and test for the “what if the system doesn’t.” Testing around error conditions and seeing how graceful a system handles certain states or conditions is important. I don’t see user stories written around these concepts though, instead the user stories I’ve worked with have been pretty happy path focused. And I am a rainy day person.

My largest frustration with user stories is if I follow the detailed path that has been drawn out and I find a bug just following the story – a large functional bug. I’m disappointed to realize that unit testing didn’t pick up on the issue. If I think of a variance or nuance from the story, I don’t necessarily expect those issues to have been found or thought about – but I do expect the happy path basic operations to be functional. Just because I expect this and wish for this to be true, doesn’t mean that is what I’ve experienced.

Overall, I think user stories are more digestible than requirements but I can appreciate that some features of an application aren’t described as well in the story format as well as other features. This is why I think having too prescriptive of a story format is a detriment that can be avoided. While, I would not vary the format of each user story because that might result in making the collection of stories hard to follow, I would not use the same format just to be consistent. Some features might be better told in longer prose and some features might be better explained with a grid or a table. I think any format used whether a user story or a requirement stands the chance for not being the best format for the requirement being described. I suppose user stories are like any tool or hammer we learn, there may be a temptation to overuse the format, seeing everything as a nail as the saying goes.

On a recent project where I was working with user stories, I would like to have more involvement earlier on with reviewing and participating in writing the stories. I’m surprised I didn’t/haven’t had that opportunity. I’d like that opportunity – any time I can gain experience from a different perspective (like gaining the experience of producing the stories versus being a consumer of the stories) I learn a great deal.

Posted in storytelling, usability | Comments Off on Working with User Stories: The Existing Parts

Working with User Stories: The Missing Parts

Posted on May 26, 2009 by karennjohnson

Not long ago, someone emailed me asking me to write about working with user stories. I have a few thoughts about working with user stories. I thought I would write about what I call the “missing parts problem” this time.

In my experiences working with user stories, one element often missing is how a new feature will work with existing features. Notice that I stated “in my experience” because this doesn’t need to be the case. I realize this statement might bring questions to mind – it raised questions in my mind as I tried to explain the missing part problem to a project stakeholder recently. These are the questions and thoughts that roll through my mind and are darn close to a conversation I had recently.

What’s missing in the stories?

The user stories are usually about the new features without hashing out how a new feature will work with existing features. So I end up with 10 user stories about a new feature but the feature is alone. The stories are missing how the new feature will play with other features.

How do I look for the missing parts?

What I do is I create a vision of the new or upgraded feature in my mind; I then walk through the rest of the application with that new feature in mind. Some features will have no – um, perhaps this word works – interplay, no interaction with the new feature. If there’s no interplay to consider, I move on. I do this with aspects of the application that might not be thought of as features – such as active, inactive users, user permissions, etc.

It takes some discipline to walk through that same course over and over but the upside is you get faster at this the more often you use this approach. I’m sweeping through the whole application. I’m not thinking about features in a staccato disconnected fashion.

If you can’t draw that vision in your head, map it out in your notebook. I probably look like I’m zoning out when I gaze out windows or close my eyes but I can see things in my mind pretty clearly. An alternate approach would be to draw a table with a list of the application features and continually run through the list. It’s kind of fun because it’s like holding a puzzle piece and your hand, looking at a jigsaw puzzle and asking yourself, does it (the new feature) fit here? How about here?

I do write a fair amount of grids/tables in my notebooks as I plot out combinations. And if it helps to know, I don’t get my grids right on first drawing – I frequently have to draw them out 2 or 3 times before it’s a grid that works for what I want.
And that thought process is massively helpful because now I’m part of the application, I’m learning. I could be handed the same grid of combinations or permutations of whatever I’ve thought of but I wouldn’t have consumed the knowledge as much as if I drew it out myself. This is the same reason that when I’m given a table I try to force myself to not see the table as complete but instead ask, is anything missing?

Why are there missing parts?

I don’t know. Deep sigh. On one project I worked remotely with a virtual team, the person writing the stories didn’t think I would have input despite my asking to be involved. On another project, the stories were in place when I joined the team. But here’s the more important perspective – I don’t want to whine about not being involved – yeah sure that happens sometimes but more importantly – I would never look to user stories or requirements to think that everything I needed to think about would be written down anyway.

I expect to be the person on the project who thinks of the combinations of things that result in unfortunate results. Or sometimes gets to discover a rock-solid application – whichever the case may be. The combinations of a new feature with an old feature, a new feature under stress, a new feature with challenging data, race conditions, and boundary conditions – the list continues.

If the user stories covered everything, and I all I needed to do was test the user stories, then I wouldn’t be an exploratory tester. I would be a test script executioner or a user story executioner. In either case, I would have disengaged thinking from my work. (Ok, I’ll stop the soapbox.)

How do I continue with testing in this situation?

Happily. I know this is one of the first areas I’m going to think through and see if I can find issues. When I do, I nearly always hear the same reaction from the developers, “Oh.”

But this is probably a good time to point out that I never want to be snotty about finding a defect. Building a good rapport with development is so important. And I make mistakes too – all the time – so it’s best to remember that.

If you have other questions on this subtopic, let me know.

I’ll post about what I do with the parts that are there – the next time.

Posted in storytelling, usability | Comments Off on Working with User Stories: The Missing Parts

It is complicated

Posted on May 17, 2009 by karennjohnson

I recently finished reading the novel, Complications, A Surgeon’s Notes on an Imperfect Science. It was one of those books that I sometimes had a hard time staying physically seated to read because I had such strong reactions to what the author had to say. My spiked reactions were centered on how frequently the author described what I have felt in my own career, albeit we are in slightly different professions. The book is divided into three parts: Fallibility, Mystery, and Uncertainty. Perhaps you can already see the correlations I was making.

The other reaction that I had is not directly related to the book but instead is a larger question I’ve been walking around with for some months now: how can software testers who test products such as medical devices get to know medical practitioners?

I have a vision of building a partnership between medical practitioners and software testers. I am uncomfortable with the thought of testing medical devices used by a group of practitioners that I’ve never met. It frustrates me deeply that I’m not able to bridge that gap. How fantastic it would be to build an association where medical practitioners and software testers could exchange ideas. I don’t mean the high-level executives from either communities, I’m sure there are sales and purchasing associates at both ends of our fields that talk and go out to occasional fabulous lunches.

I would like to create a bridge between the people who use the devices and those of us who are software testers located in office buildings far away from the real life situations where medical devices are actually used. It seems to me, we should know each other.

But with a deep sigh, I don’t at this time know how to build that association. And I don’t know if there are other people in either profession who would also believe that this could be a valuable association. I have made some attempts in recent time to investigate the possibility but nothing has come of it, yet.

In the meanwhile I’m intrigued to read passages from a surgeon who has clearly acquired years of real life experience describing his journey and to feel correlations to my own work and my thoughts and feelings towards my work. Despite years of sustained practice and training, the author mentions the doubts that creep in. The time constraints, the ethical dilemmas and the fact that sometimes despite years of training and field work, situations occur in ways where the path to proceed and the decisions to make are not clear. It sometimes takes judgment to proceed.

I think this book could be a good read for beginning software testers to recognize that some skills take years of sustained focused engaged practice. And that it is unrealistic to think that reading one book or passing one certification exam of any flavor can replace years of apprenticeship. And that even after years of practice, we still must use our own judgment and common sense mixed with what has become intuition to make decisions.

So I imagine people might think drawing correlations between software testing and surgery might be rather extreme. But is it really? When I think about the testing I’ve done with medical devices and recognize that should a device introduce an error, patient death is a possibility – all my work does is move me further down the hall from the outcome.

It saddens and frustrates me that in our world, we esteem medical practitioners to a god-like status but that too frequently I see software testing deemed by some as such a lowly occupation that they seek across the globe to find the cheapest possible resources to pawn software testing off to. Can you imagine price-shopping a surgery in the same fashion? After all if a medical device is tested poorly, the most brilliant and skilled surgeon could press a button on a device only to end up in dire consequences potentially due to poor software testing. Given that possible outcome, we should esteem software testing in its rightful place as an acquired intelligent skilled profession. And that we should pay people accordingly regardless of their location as long as the skills used and provided equate to these higher expectations.

When it comes to testing a medical device, I don’t see myself as any less responsible or removed from the outcome just because I might not be as physically close as an attending physician. Shouldn’t there be doctors and medical practitioners thrilled and relieved to know that some of us who test medical devices care that deeply. And that some of us, would like to meet?

Posted in storytelling | Comments Off on It is complicated

brain games

Posted on May 4, 2009 by karennjohnson

I finally had a chance to visit a store in Chicago, called Marbles, The Brain Store. They sell games designed to strengthen the brain. Their website and newsletters include other info centered around the brain – and not everything is about buying stuff.

I went around the store looking for games that would be interesting to me. Not surprising, I gravitated towards word games. I picked up Bananagrams. Its a game that travels well and can easily be played in small windows of time. Perfect.

I found I was getting frustrated just looking at a couple of the visual perception games like Tantrix and Tangoes. So I bought both to see if I can improve skills in that area. And I want to see if I can figure out why these games frustrate me.

Check out Marbles it’s pretty cool.

Posted in Uncategorized | Comments Off on brain games

The storyteller’s community

Posted on April 17, 2009 by karennjohnson

There is a world of storytellers and in that world there is a community just as much as there is a community in software testing. Katharine Hansen reached out to me recently with a warm welcome to the community of storytellers. She has website filled with information. I’ve added her site to my Google Reader, its packed with information. One story Kathy’s especially interested in is meeting and talking to people who are not storytellers professionally but use story in their work. She’s sought people from many different professions and has built a collection of stories on her site. She interviewed me recently, you can read it here.

Karen Dietz, another storyteller reached out to me recently. She was the former Executive Director of the National Storytelling Network. We had a good chat on the phone and one of the ways she welcomed me to the community was to ask me about what conferences and locations I might be traveling to in the coming year. She’s helped to connect me to other storytellers throughout the world. In the local guild I attend, people reference the NSN magazine and resources available through the association. You can read more here.

In the software testing world we have Rosie Sherry who’s built a forum for testers, the Software Testing Club. In the storytelling world, Shawn Callahan has built a forum known as Worldwide Story Work. I’ve joined and have been listening to webinars and meeting other storytellers.

The storyteller’s community is a warm community. The people in the community that I’ve met have different approaches, different styles, and different outlooks but share a passion for their work, an interest in having people join their community and a desire to hone their craft. I feel like our community of software testers can easily reach out to the storyteller’s community and find great resources and people.

Posted in storytelling | Comments Off on The storyteller’s community

Testing SCDs

Posted on April 1, 2009 by karennjohnson

An SCD is a slowly changing dimension in a data warehouse. There are three different forms of SCDs. SCD1 overwrites data, SCD2 maintains historical data and SCD3 maintains some of the data.

SCDs and testing in a data warehouse is likely a topic that you’re either entirely interested in or it’s a tech area off your radar. Over the past few months I’ve been doing some work in a data warehouse again and have at times looked through blogs and forums for information and experiences, and in most cases found little information written from a testing perspective. I’m going to try to share some of my experiences being of course, mindful of client confidentially and steering very wide from any specific data – I’ll make up data if I need to. Testing SCD2s is one topic I’ve looked to hear experiences from other testers but have found little to no shared experiences.

In my experiences in data warehouses, I have yet to work with an SCD3. SCD1’s overwrite all of the data and I’ve yet to encounter issues with a data load overwriting so it’s SCD2’s that have captured my interest.

In terms of learning about SCD2’s there are places to read – the best reading material I’ve had are the Kimball books. Instead of going into a tech lesson on SCD2s what I want to share is from the testing view. A short explanation of SCD2 is that a new record gets inserted and an effective date field is set.

So what about the testing perspective? It seems to be a chant I have on Business Intelligence projects.

As data inevitably is reloaded, knowing which data is supposed to keep its history versus which data is supposed overwrite is good to know. Why? One reason is to have a sense of how data is being handled on refreshes. Another reason to know which data elements will be handled as SCD2s is to distinctly and purposefully test SCD2’s. This is where concept and reality starts to break down.
So conceptually it’s a good idea to know which data elements will be handled as an SCD2 vs. an SCD1 but where can you get that information? Typically that information is buried into the details of ETL job and in the case of the Microsoft BI stack of tools; you have to know how to navigate around SSIS to find the details. That navigation isn’t impossible but what gets unwieldy is doing that investigation times the number of data elements makes the effort a large labor spend. If a data dictionary is written that includes that information – then it could be information that’s easy to find.

In the case of a warehouse where design changes are still rippling through and it’s not only a significant labor but a time spend that might have to be executed over and over. I have no gorgeous solutions to this. Sometimes the best I can do is understand a problem, groan at the solutions when I don’t like any of them and forge ahead the best I can.

Another reality about testing SCD2’s is like testing other software – where you realize you don’t want to retest the tool. What you want to test is the implementation of something. Case in point, I don’t want to retest Microsoft’s SSIS packages to see that SCD2’s are handled as expected. But gee, it would certainly feel good to take perhaps the most vulnerable or most essential data element or two and step through the process to see that it was implemented without issue. So what if I decided to test just a couple of SCD2s. Where to start?

Building a small data set to test with has the advantage of being able to know the data set. By white boarding ideas or using Excel to map out a small data set that will test handling the updates in theory sounds straightforward. But the simple approach has a few challenges to it.

One issue is knowing all the columns for a single record and creating a small sample can be downright ugly. Ugly in the sense that all the columns for a single record could be quite a few columns and that setting or defining some of the values could be tough. Not all the values are easily readable and setting a value incorrectly can skew testing.

A system architect and I talked through this and concluded that it would be less labor to have a tester design data to test with and have a developer build the test data set. A SQL query or small extract of data can be more readily pulled out of the database by a developer who can then be paired to work with a tester to massage the data into a sample set ready for testing.

But after running the test set, the same challenge comes back to haunt meaning after the same sample data set has been run, the SQL knowledge needed to drill in and check out the data can be an issue. Each time a tester has to go back to a developer for assistance, the sense of objectivity gets rattled.

What about looking at the problem from a different perspective? Using a developer paired with a tester to set a sample test can work. After running the test data, it can be more feasible to test from the outside – meaning to view the changed data as a user might view the data – using a tool like Excel or Tableau to connect to the cube and show the data. It still requires a certain amount of know how that might not be a skill set findable in testers I meet in the market.

Another alternative is to run full data loads that include such data element changes and then test the data through a data reconciliation process to see that the new data has appeared. And that is the process I’ve seen. It doesn’t mean it’s the best solution – but it was the solution we could implement.

I think one of my core frustrations in BI testing is that the projects tend to be highly technical; testers are often not placed on the BI team leaving developers at the helm not realizing or thinking (of course) like a tester. This makes injecting ideas for testing early in the process fall by the wayside. And like any project, testing not done early on means bugs are found later and bugs are found by end users.

Posted in software testing, SQL | Comments Off on Testing SCDs

The gold star

Posted on March 19, 2009 by karennjohnson

A thought I wanted to share. Perhaps not directly related to testing but I think could be helpful in other ways. I’ll pose this as a question:

Do you give yourself a gold star? Or are you dependent on someone else giving it to you?

Some years ago I had finished up some project work and was lamenting to my coworker Chris that my boss – who we had in common – hadn’t noticed my extra work. I was looking for some recognition from my boss. I couldn’t put my finger on what it was I was seeking. But my coworker Chris could. He said to me why do you need the external validation?

He was right, dead right. I needed to be told “good job” by someone.

The problem, I think, with seeking external validation is that it leaves you in the hands of another person. It will never be enough.

It won’t be deep enough. Meaningful enough and it might not happen on the days you need it most.
When you gain the ability to approve of and think well of your own work and worth, you are freed from seeking the gold star from someone else.

Posted in self-motivation | Comments Off on The gold star

The repeat customer

Posted on March 9, 2009 by karennjohnson

Saturday morning I picked up a rental car. The process wasn’t unusual since I’ve picked up a car several times over the last few months from the same rental location. At this point, I know most of the car rental staff by name and even by their voices on the phone when I call in a reservation.

Notably as I’m getting to know the staff members, I’ve noticed most of them try to get me in the nicest car on the lot at the best price. But one of the car rental staff seems to do the opposite. It seems the more frequently I rent a car, one of the staff members, (I’ll call him Ed) is less interested in making sure I’m satisfied. Ed, it seems, sees me as a repeat customer, a customer he can shuttle out quickly. The more Ed works with me, the less interested he seems to be in making me happy. Perhaps he assumes I will return regardless of the service.

Later in the day, I was sitting down for a quite lunch alone, reflecting on the rental car situation, I was thinking about the frequent and repeat customer. How do I treat my repeat customers?

Do I get lazy or sloppy in how I handle my repeat customers? Or do I try to continually give my repeat customer the best of what I am able?

I was thinking about this as I was eating lunch. What’s the real answer to this? I scrunched up my face thinking about this. What’s the truth?

Then I looked across my lunch table and noticed my dorky bag. I had carefully printed materials the night before in preparation for a busy Saturday of errands. I had printed user stories and bug write-ups about new features coming in a new build I’ll be testing. I had my pencil case with highlighters and post-its. I had forecasted that twice during my busy errand-running Saturday I would be stuck in a waiting room somewhere and have short bursts of available time. I had planned my reading. And all of my reading Saturday was for my most frequent repeat customer.

I smiled when I looked at my bag, the reading material in that bag and the prep work I often do is my answer. It’s not what you say but what you do, right? I don’t want to be lazy and I don’t want to be sloppy. And I certainly don’t want to treat a repeat customer as someone I will assume will be a repeat customer.

For this particular project and this particular client, there are a couple of people on the team who don’t really understand what I do. From their point of view, I find bugs; I am the exploratory tester on the team. I think any other details of what I do, might likely bore them – and that’s ok. I have finally realized not everyone has to think testing is one of the best possible bits of work someone could have. I would speculate that they believe, I sit down cold and unprepared to new internal releases of software and somehow just find stuff. And I do, often.

But I also do my homework.

I read every bit of what I can get my hands on. I read each user story posted on the team wiki. I frequently print off pages from the wiki and markup those user stories with my own notes. Those notes are loaded with test ideas. I spend time, sitting back, sometimes even closing my eyes and picturing the software. I try picturing the code, I try picturing the database changes. I ask for that type of information too but I also like trying to picture the details on my own. I’m thinking about test ideas all the time. This is my prep work, this is my homework and this homework is especially important to me when I have a release coming with new features. It’s not uncommon for me to read in bursts, write up ideas in bursts to try to make good use of small pockets of time. I also work in small bursts because I know better than to think all my ideas will come at once. The sooner I can read material, the longer that material has time to ferment in my head and that fermentation process appears to help.

And of course, some bugs do just find their way into my hands. And some bugs I find as I generate new ideas as I test. But I know that when I sit down with the release, I’ll be ready to pounce on those new features better, faster than if I hadn’t done my homework. Homework is part of my deliberate practice.

My client won’t know I was reading and writing and prepping intermittently on Saturday. Those aren’t the little pockets of time I bill for, that’s just how I work. Some of the details of how I do what I do – doesn’t matter to my clients. I guess I could compare a new build to sports game, when athletes walk onto a field and you don’t see their practice time. You just see the execution. But me talking about sports is a bad idea because I don’t really know much at all about sports. I just see the parallel of the unseen prep time.

Today is Monday. The new build should be out within the next few hours and I’m ready. I guess I could have skipped my homework; honestly the client would not distinctly be aware of it but I would speculate they would see a difference in the results.

I could assume the client will continue to use my services. But my work is my reputation.

Familiarity is a comfortable thing. We can talk faster based on past shared experiences, we know each other better. And over time, we get to know bits of each other’s lives. But familiarity can get too comfortable. I think about my rental agent, he’s getting sloppy and I don’t take kindly to it. The rental agent’s service is a good reminder– not to get lazy, not to get sloppy and not to assume a customer will remain a repeat customer. It’s a good mentality to have and to keep at the start of the week.

Posted in Uncategorized | Comments Off on The repeat customer

Test the Tester’s Site

Posted on February 20, 2009 by karennjohnson

So last weekend while I was supposed to be writing with Mike Kelly, I was distracted, and of course, distracted him from writing as well as we revamped my website. See: http://www.karennjohnson.com

I’m sure my new site has issues, feel free to tell me about them – you can email me. I’ve been too caught up in testing and other related activities to spend more time on my own site this week.

It occurs to me that other testers might find it interesting to hear about the kinds of actual activities I’ve been doing so here’s a list of things I was involved with this week.

I should mention that I’m currently working on two of distinctly different projects so if this list looks strange or has unrelated items, that’s why. I’m also writing an article – or supposed to be – I may be procrastinating by blogging instead.

• Search testing in Sinhalese and Tamil languages
• Search testing with Ferret and the Google custom search engine
• Confirming a bug on 64bit vs. 32 bit environment
• Reviewing specs about RSS feeds
• Source to target data reconciliation with OLAP cubes
• Review of ETL jobs to find details of specific data transformation
• Kicking off a user acceptance test cycle; writing test ideas for users, clarifying a process, etc.
• Writing user stories; experimenting with the GWT (given, when, then) format
• Writing an article based on agile project experience

If anyone is interested in any of these topics, let me know. I can try to blog in a non-client, non-data specific way – which is sometimes challenging and keeps me from blogging. Client confidentiality is important to me.

Posted in software testing | Comments Off on Test the Tester’s Site

Karen’s unedited opinion of test script writing

Posted on February 16, 2009 by karennjohnson

Ok, so some years ago – now I promise this will tie back to a very recent conversation I had with a “tester” – but first – some years ago when I starting work as a newspaper reporter, I was getting my first assignment from my editor who was a rather gruff older gentleman. I think back now and realize how green and eager I must have looked. I was certainly Mary Tyler Moore and Jason was my Lou Grant. Really – down to the cigar because back that long ago you could still smoke in offices and Jason smoked cigars. I can recall the intensity and importance of the dialog. Boy I really wanted the work and I was willing to take whatever bottom of the bucket story I was about to get assigned (and I did). I was primed. I recall Jason asking me; hey do you have a camera?

Sure I said, um, yeah of course. I didn’t own a camera but the last thing I wanted to do was create a roadblock in my getting the assignment. Hungry for the work, wanting the work – I felt like I could taste it – the last thing I wanted to do was say no. So I said yes.

When I got back into my car, I drove to the local electronics shop and bought my first camera and went onto the assignment. Up until then I had always used my big sister’s camera. I was decent with photography but had somehow squeaked by without owning my own camera. My photo was printed with my first story and time moved on. I worked as a reporter for another two years.

So now here I am some decades later, talking with a tester – a tester (who I did not hire) new to an assignment from me. And I ask – can you test without a script? Tell me what it is you do. And the response I heard was a slow paced, no. I write scripts. I read requirements and I write test scripts. Do you want to see the format of my test scripts?

I could just feel my blood boiling. No, I don’t want to see a template for test script. In fact, I’m sure it’s a gloriously long winded highly formatted waste of effort. I want to know if you can test. I want to know that you feel confident that you can be handed an application, learn at least its primary aspects at a fairly rapid pace, jump in, join this project and find bugs. I could care less about test scripts. This isn’t a medical device and this isn’t a regulated product so unless I have the FDA breathing down my back, I don’t want to create bloated documentation that serves little to no value.

Where’s the passion? Where is the pure desire to test? I can’t express strongly enough how I feel that if the only aspect of testing a person has is to read requirements and write scripts – I just don’t know what that job is. It’s a script writer right?

I’ve never felt too passionate about the whole debate of QA vs. testing. But I do feel passionately about script writers vs. testers. I think if writing scripts and executing precisely what has been written is a person’s idea of testing – then please mark your resume as a script writer and test executioner. A skill as valuable as the pay rate the market offers. A job and work that is so deathly dull I can see why executives want to hire testers at the lowest possible rate on the market.

If you want to be a reporter, you buy a camera. If you want to be a tester – at least show me you have that hunger to learn, be able to become a tester without needing directions, or scripts if that’s what we call them.

Where did the tester come from? Since I mentioned that I didn’t hire the tester, let me clarify where the tester “came from”. In this particular environment, testers get passed around from team to team. I’ve seen the pass the tester around practice before. The practice appears to come from the assumption that all testers write test scripts and that all testers have reasonably equivalent skills so moving a tester off on one project and onto another project where testing is needed must appear to be an efficient solution to management that stays from afar – how else can I comprehend seeing the practice in multiple companies?

I’ve met testers before who seem to bank on this fact – they get passed so quickly it’s tough to assess what they’re doing and how they’re doing. And yet somehow they get kept. In some environments other team members are so used to testers being more about documentation than anything that as long as they shuffle from team to team generating some volume of test scripts, it seems they could last a long time at the same company.

I think many people don’t understand what testing can be – especially if their only experiences have been with script writers. I think many people and especially for management that stays from afar, view testers as a low-end high-doc position – a situation that’s more likely to be tolerated in a regulated environment – where the fear of the FDA audit runs high and the understanding of what it means to test software may run low.

Posted in regulated software testing, software testing | Comments Off on Karen’s unedited opinion of test script writing