If you've just dropped by or random'ed into me, please leave a comment and say hello.

Let me know how you found me, where you're from, why you're here, a little about yourself, recommend a book, recommend a movie, tell me a secret, tell me something, ask me a question, etc. =)

Ad Astra,

The Bride of the First House.
bride (at) livejournal (dot) com

---

weather	:		light drizzle
outside	:		10.6°C
mood	:		pensive

They key to getting the salary you want is to make sure you deserve it first.

I've never negotiated for my salary in my life, so maybe I don't know what I'm talking about. I've always been given what I wanted, and frequently have been given more than I thought I could get. Sometimes a lot more. And not always at designated salary review times.

weather	:		cloudy
outside	:		18.2°C
mood	:		...

I've been trying to spend time dunking my head into test automation lately. It hasn't been easy.

Part of that is because of the high rate of distraction. And that really is just me. People seem to gravitate towards asking me those "quick questions" that are sometimes not so quick. Rather than just plain helping them, I have been working on helping others help themselves. Coaching/mentoring/guiding/tutoring/teaching was one of the goals from performance reviews in previous years. Judging by my last performance review, it's been working out really well. =)

But the other part of my struggle with automation is the fact that automation and getting it right is not easy, in and of itself. I said before that you're not making a hard job easier by automating. You're making a hard job equally as hard, but in a different way.

Test automation IS development. It's a programming job. It isn't solely a QA responsibility. QA cannot just do it in their spare time. The skill set that you traditionally want for QA positions is not the same as what you'd want for a QA position for automation. Not understanding this is probably the key reason that most shops don't have good automated test suites.

A lot of developers don't understand this either. I remember the whole crew being hauled into the big boardroom to discuss the snowballing issue of regression getting more and more complex. All the developers are pulling a Hermione Granger and going "QA can automate it". And all the QA staff are staring daggers. =}

I see signs of Work getting it™ and moving towards an staff organizational structure that supports doing it right, so we're off to a really good start. I may or may not get into automation that deeply, I don't know yet. But just looking at what we have and before actually even creating anything, I could see where things needed to be done differently.

We needed source control on all our automation scripts and assets. Priority one.

We have to map out development procedures for what to check in and what NOT to check in. Anything that is generated by running the test scripts should NEVER be checked in. It drove me stark raving bananas to see temporary files, lock files, compiled intermediate binary files, and test run results checked in to the source repository. I cleaned out what I could. I tried to make sure that the Results folders weren't being used as a baseline for comparisons. I have a feeling there are other files that don't need to be checked in either, but I just wanted to get rid of the obvious ones. I need to do more homework and maybe toss out more unnecessary stuff.

From looking at what's checked in, we're still struggling with how to manage scripts for the same features for the same product but differences in the automation assets coming from underlying implementation. I've tried to cut down on the number of copies of the same thing all over the place as much as I can. But for now there are times when there is no feasible or sane way to deal with something, other than to make a copy and remembering to make the same changes in two places.

I have in my mind a general sense of how to approach it, but I wanted to solidify it exactly for myself before I recommend it to everyone. I'm positive that we can do something by branching and merging the source code. But "merging" will have to be done differently and it isn't going to mean the same thing as the development source repository because we're dealing with mostly binary files. Using the merge feature of the version control tool isn't going to work for us.

Alongside of managing automation assets, the automated testing approach is an important direction to get right.

Automation testing tools will usually allow you to show it what to do (in a manner of speaking) and it will do the same thing automatically. It's like creating a Macro. You hit the Record button. You do whatever you want to in whatever window you have open. You hit Stop. You hit Play and it does exactly what you just did.

This is well and fine, but as soon as something changes in the window or screen that you've recorded your steps in, the automation script also has to be changed, otherwise it can't find the buttons or text fields and the script run fails.

And when you're developing software, things change. A lot. And constantly.

It takes a lot more skill, training and experience to create automation scripts that are robust enough that are able to function correctly even with those changes constantly taking place. The person you hire to do this has to be a hybrid of developer and QA.

These people are more rare and very difficult to interview for. I'm not certain if you want to interview for a developer and hope to train them into a partial QA role or if you want to interview for a QA and hope to train them to be somewhat of a developer.

In support of the automation effort though, I've begun to structure my test cases differently too.

Even without data-driven test automation in the picture, I had wanted to separate test procedures from test data. How many times have I written out test cases with exact Reproduction Steps only to have the user interface change and make a whole section of 500 test case repro steps wrong? It didn't take long to realize that test case descriptions need to be as general as possible while maintaining precision and correctness.

It also means that I have a test case structure that complements automation and is easier to interpret for creating automation scripts.

Here's what you do. And plug in these values for these data fields. If the "here's what you do" changes, then make those changes once. And it will still work for those same data values.

So, yes. Not there yet. But on my way. Full steam ahead.

weather	:		mostly sunny
outside	:		23.0°C
mood	:		...

With any software, you'll have a set of parameters you need to use as input data or environment. If each of the different combinations of the input constitutes one test case or test scenario, having a lot of parameters quickly balloons into an unrealistic number of test cases that needs to be run.

It's completely unfeasible to exhaustively test every single possible combination. I think we've done quick calculations where even simpler parts of our system would take on the order of YEARS to test if you really did every single combination of everything you can change on the screen.

Given that we can't do every single combination, we cut the test suite down to the things that really matter. Yes, we can get it wrong and problems can get past us because we didn't look at it, but it's an risk analysis exercise - what is the risk of the defect occurring? and what is the impact of its occurrence?

One of the strategies we can use is called Pairwise Testing.

Pairwise testing (or "all-pairs") means you choose the set of test cases that covers all combinations of 2 parameters and each value of all other parameters at least once. Defects that involve interactions between three or more parameters have been shown to be progressively less common.

I don't think it's a new technique, but it's a relatively new topic of discussion in the software community. There aren't a lot of statistics on it yet, but what is available seems to support this.

I've been doing it since I started my first job in Quality Assurance. But I do it manually and based on intuition. I don't use third party software tools to generate my test cases. I thought this was a cool idea and I was curious to see how the tools compared to my intuition-based choices for test cases.

Because we're a Windoze shop, I chose to use a small free tool called jenny (thanks, Bob Jenkins =).

jenny takes a "tuple" parameter to indicate that it should do pairs, triples, quads or whatever other dimension of combinations you want. Then you list the number of values for each parameter. Your parameters are labelled with integers and your values are labelled with letters. The upper limit is every single combination of every single dimension.

I have a Payments module to test. There are six main parameters I'm dealing with:

• 3 incoming payment methods
• 5 outgoing payment methods
• 4 types of customers
• 3 contract types
• 25 of the most commonly used currencies for both incoming and outgoing payments (there are actually just over 100 possible currencies that we support)

All possible combinations of those 6 input parameters means 112500 test cases. If I estimate that each one takes on average 5 minutes each to execute, that's 562500 minutes which is 9375 hours or 390.625 days.

We usually have two QA staff per project team. There are about 260 business days in a year. This comes out to 10 months. If all goes well.

Oh, HELL, no.

So, anyway, I set up the parameters and possible values in an Excel spreadsheet, numbered/lettered them off. I plugged numbers into jenny with all my exclusion rules, made the output comma delimited and sed'ed the output to get something that could be pulled into Excel.

In the 625 test cases that jenny gave me, each parameter value will be used at least once. If all goes well, two QA staff testing for 3 business days (8 hours per work day) will complete all 625 test cases.

Keep in mind that I haven't included some of the other parameters. I haven't included other modules that also have to be tested. I haven't included a few other types of customers for reasons that I didn't want to get into for this public example. I haven't included troubleshooting time when something does go wrong. I haven't included the time it takes to log bugs, argue about them with developers or verify fixed bugs.

We usually schedule 2-3 weeks (10-15 business days) for Regression, depending on the complexity of the features and we're still cutting corners where we can.

Side Note: Automation is not always the answer. This is another post altogether, but the short story is: you're not making a hard problem easier by automating testing. You're making a hard problem equally as hard, but in a different way.

So, 625 is much more do-able than eleventy-frazillion. And I can be reasonably confident that most of the bugs that are there will be found.

However, knowing the system as I do, I can get it down to 32 test cases and still be fairly confident that I've covered the major functionality with that one module.

So, this is fairly consistent with most things in life. A software tool can save you a lot if you don't have any extra knowledge.

But it won't replace human knowledge altogether.

weather	:		sunny
outside	:		14.8°C
mood	:		...

So, the latest toy is LinkedIn. I'm in there under my maiden name. You're very welcome to add me if you're so inclined. The e-mail address is my first name at gmail dot com =)

I caved. *bibble* I was resisting joining yet another online toy just to play for a while and then have no idea what to do with afterwards. But it seems to be very accommodating for resumé-like info and I've always thought it was a good idea to have a copy of the resumé ready to go at any time anyway.

I've found a lot of people I know/knew... including a lot of LJers on my Friends List and people not on my Friends List. Yeah, I'm connected to a lot more people than that, I'm just not sure what the protocol is for adding people. Granted, the user base should be a lot more mature than certain other networkie sites, but still... when I go to add someone, I hesitate, like "What if they don't _want_ to be associated with me? What if they don't want my piddly recommendation?" =P

I took the opportunity to write some recommendations for people I'd worked with in the past, people who I enjoyed working with and who I wanted to thank for making work interesting. I plan to write some for current colleagues next. That's somewhat more intimidating to me.

It's also made me pause to wonder when might be a good time to switch to my married name entirely. "Not now" seems to be the only conclusion I can come to.

weather	:		partly cloudy
outside	:		6.0°C
mood	:		contemplative

Why? Why a Tech Writer? What made you decide to take this step?

I've been getting this a lot lately. =) Some people say that it makes total sense that I would go and do something like that. A lot of people want to know why.

Mostly because I see the need.

We have an awesome off-site Tech Writer, but that's really not enough. We're trying to hire an on-site, full-time one right now. But we somehow keep getting the candidates that act like they're too good for us.

Maybe it's an employee's market right now for Tech Writers. Maybe we were just unlucky enough to get the assholes. Maybe it's something about the way the job postings are worded. I wasn't a part of that hiring process, so I really don't know. But I do know that there's an increasing pile of documentation, manuals and such that need to be done.

I see it as valuable experience.

I'd like to be able to empathize with the Technical Writing Group of the IT Team and gain insight as to what Tech Writers need from the rest of the team. Documentation is a very important part of the process, but it doesn't seem to have a lot of presence here.

It's a corner that I haven't poked in. I've had a job in almost every role on the IT/software development team. Technical Writing was just something that I've never tried.

I also enjoy writing.

I never thought I would actually like writing because highschool English was such a miserable experience for me. It's definitely not my passion and I know I'm not the least bit creative. I feel like saying that I enjoy writing on my own terms, but that's really not it either. I am able to write to specific requirements which is what I have always done at Work.

I'm not sure I can explain this.

I obviously do love to write English prose, on some level, evidenced by the last six years of keeping this journal and randomly gabbing. If I didn't love to write and didn't think I could do it, I wouldn't have asked to help Work out as a Tech Writer.

weather	:		cloudy
outside	:		7.4°C
mood	:		eeevil

Being in software in North America means we don't have a dress code. I usually wear jeans, some random shirt (t-shirt in the summer, maybe a sweater in the winter) and a pair of sneakers to work. I don't wear makeup. I don't do my hair... I don't even comb my hair.

Today, I went to work wearing a business outfit. A burgundy shirt under a suit jacket, A SKIRT... THAT MATCHES THE JACKET (OMGOMG!!!), pantyhose, heels (but sensible shoes). I haven't worn a skirt in at least a year and NEVER to Work. I did minimal makeup, but it's still a fairly big contrast to my regular days looking like a dead broom.

Now, about the only time IT folks dress like this is for job interviews.

*ominous chord*

My IT Director questioned me about it and I replied, "I have an interview."

You could just _hear_ the *schlyoop* sound of her face falling. =}

"The company is in downtown as well... you might have heard of them... Work? They're looking for a Tech Writer in the Vancouver office."

Oh, I got her good. XD XD Well, I did offer her a hug afterwards. =)

I also got a few cow-orkers too =D I've always believed in working to the Hit-By-A-Bus Rule™. I try to leave as much documentation and instructions as possible for others in my group. I try to satisfy the question: If I suddenly disappear off the face of the planet tomorrow, what does my team need to continue without me?

I also believe in letting everyone gain breadth of knowledge. I like rotating people around to different tasks. It's a little more time consuming but it really pays off when we don't lose a lot of time when someone goes on vacation or suddenly has to take bereavement leave or whatever. I don't like companies that have people "specialize" in certain components only. I'm never very vocal about that, I've never had to be because Work is very sane and usually on the same page with me about it. This week, though, I've been saying a few things out loud.

In meetings, I've been saying things like "so, who can I give this thing to?" and "I'm going to pass this task off to So&so."

I had people going too =D

So, yes, until we hire a real Tech Writer, we can pretend and hobble along with yours truly. It's just something that I haven't tried before. I've done Tech Support, I've done Development, I've done QA. This is a new corner that I haven't poked in yet.

I don't even know if I qualify, I still might not get the job. I'm so far from an English Major, it's not even funny. I found qualifications and job postings online and some of them looked kinda scary. The Project Manager is humouring me with an interview (hence the attire), but that's all I know right now.

I'm also enrolling myself in Beginning Italian come January. Our manuals are translated into French and Italian by professional translators, but I'd like to learn some very basics so that I have some familiarity and small bits can go much faster.

I say, if we're going to hobble, let's hobble with class and panache.

weather	:		cloudy
outside	:		11.3°C
mood	:		...

The last 11 weeks have been brutal. I've been taking a part-time professional development course that I feel I need at this stage in my career. It's been three-hour, occasionally four-hour sessions on Tuesday and Thursday evenings plus all day Saturdays, weekly.

The whole course has been an overwhelming amount of great stuff. Each topic has been incredibly inspiring to me. It really feels like it's opened my view to A LOT of things.

I lucked out with a really good team. In fact, the Team Project Facilitator said this is the first term that he's had REALLY strong teams, with very little member conflict, asking him the tough questions and really applying the material given to us. But, on the very first day, before we knew our groups, we all sat down in the seminar room at random. It turned out that the six of us had serendipitously all chosen to sit at the same table. It was kinda spooky =O

We did our final group presentation for our Case Study this morning. We were to present a solution to the senior executives of a medium-to-large corporation. And we were required to treat it as such.

I did my section on Quality. I didn't really want to do Quality, at first. I wanted to take on another topic to build on something I didn't have as much experience with. But come crunch time, I was typecast and that was my thing. =)

The comments I got back afterwards were very very encouraging. When people are asking you if you do public speaking a lot, I think there's something to it.

— And here I pause YET AGAIN to reflect on the recurring theme, in my life, of joining Toastmasters... —

The comments that I cherish the most, though, were from the Team Project Facilitator. I need to write this down before it fades =)

He said my presentation was "very powerful", referring to my whole thesis that "Quality is not an isolated activity; it's built-in to everything we do" and fleshed out The What and The How from there.

The other part was when I said, "if we had to distill 'quality' out of our project activities, ...". His feedback was: "that hit me like an arrow between the eyes... because of course you can't take quality out of it; of course quality is integral to your processes".

I got other comments about fluidity, cadence, "very animated", "very alive". All wonderful things to hear back =D =D And getting a "Well Done" from someone who can be a bit intimidating is just SUCH A HIGH.