End of the Year and Project thoughts

As we all slip and slide our way to the festive break I can take a small break from running scripts to think about the last couple of projects I have been on.

The first was a big one, changing a lot of products that involved a lot of code and text changes. The work was made more complicated by the fact that they decided to merge two planned releases into one biggie. So you know the score, some of the changes in one were superseded in the next. For such a big release (and the usual carry on with specs that were supposed to be signed off being changed on ad-hoc basis) things went quite well. I say quite well as there were one or two hairy moments at the tale end of the project I could have done without. One of them was partly my fault, but is also a telling lesson in finding “gaps” between documents before you even start testing!

Uh oh!
What happened was right at the end of the project, we were in a meeting discussing defects when the business person said to me “you have been testing the product AB haven’t you? Cos there is a bloody big defect in it” . I gave the business person a look of person that had just been asked to solve a complex mathematical equation and no calculator. After the meeting I went back and checked through every damned document for a mention of product AB. Nope it wasn’t there, it wasn’t over here. It was no where to be seen. I reported back to the test lead that there was no such mention of product AB so we had not tested it.

Mea culpa!
The test lead went off to the meeting only to return later holding a print out of some spreadsheet that had supposedly been sent out by the business before test execution had started. In this elusive spreadsheet were a list of all the products and the relevant requirements form the spec, and guess what there the product AB with no requirement either! I spent a good hour wading through my emails to see if such spreadsheet was sent to me and couldn’t find it. My only thought was that I had got it and then in a fit of email deletion madness had sent it into oblivion. My only defence is that it was not in the original spec, nor in any of the subsequent updated ones. Which of course in the theory world of testing, is what you should be basing all of your testing on? It does show though in the testing world you need to keep on your toes when documents are flying hither and tither. It is a good example of what could happen if these gaps are not seen and flagged to the business as soon as possible. The business fortunately did not make a big deal of it, as they were probably aware that they too had some hand in the overall confusion.

Offshore Controversy
As soon the project that I was coordinating finished I was moved on to a new project that was just starting its execution phase. This time no stress just running lots of scripts and checking to do. The big cheese of our team has had marching orders to see if some of the checking can be off shored to make the team here more “efficient”. Taking things offshore is quite a heated and emotive subject in the testing world. I am on speaking terms with a high level manager at Global Company who I will refer going forward to as BC. The manager’s anecdotal evidence of what happened to them was not that pleasing to hear.



The big cheese has had the marching orders and so on this very small project, that some of the work has been given offshore. They have been given 50 or so scenarios to check not a great amount but enough to see how things would go. As part of the process we were given a quick demo of by one of their team to show what they would be doing.

It was eye-opening, for one thing how easy it was for them use their “tools” and then generate a report ( it took seconds). Much later on I asked the big cheese how much these tools would cost to install here and the fact it would only take one of us to run them ( for some reason it takes at least 5 of them to press a button and then check the report?) It was met with a rather blasé reply about not being that easy to install them on our network. I did a quick google and found them to be A/ cheap and B easy to install. Methinks politics is at play here. Anyway that’s the big cheese problem, in that management of sending stuff over there ( for some reason the poor dudes over there can not get access to our network) we then have to QA their work, organise the evidence for the business and put the cat out. It all seems a bit heavy on the management and does not make our team any more “efficient “. Who knows though it may all work out if they get access to the network. I still don’t get the cost savings though five of them to do a job that one or two of us could do in day or so…..I am sure this will run and run. I will no doubt write about it more next year.

So as Noel is upon us I will take this time to wish anyone who has stumbled in here by mistake a merry Christmas/happy festive/new year. Hope next year will be all the better for you!

The test dude

Test Enviroments

Why is it that when people think about testing something the last thing on the list is the test enviroment is the last thing they think about? The past week has seen a lot of down time because of the enviroment we are trying to run our tests is creaking. We would have been more or less done and dusted if it were not for the enviroment giving up the ghost. So next time you are planning for testing make sure you stipulate that the enviroment is mature and stable. If not no testing will be done, you will halt. The reality is you sit around for 3 hours trying to force and will your tests to make its to end, hoping that all those nasty errors that are being thrown are just down to the enviroment and not the code.

Ah well long week, the beer is good tonight.

Make sure you get Invited to the right meetings..

A fellow TA today got most of his work that he done had been "descoped". I was not privvy to the reasons but seemingly there was meeting some months ago that agreed that our team would not really need to test that particular part of the release. My fellow TA told me the conversation went thus

Biz Person " We had a while back, and we discussed this might be covered by the other team..why were'nt you invited to it??"

TA "Um....!"

Over proccessssssed

You got have processes in testing; it’s the basic law in our world. If we did not have processes and procedures you would have testers running around doing all sorts of things that makes their mundane job exciting. I am not saying it would be anarchy but it would be nightmare to manage. When I am testing I like to know that you call all tests by this, you raised a defect like this and assign to Developer dude A if it’s functional and Business Dude B if it’s a business rule. You save evidence over there with this name. All your scripts must go through a review process with one of your peers and must have review log if they don’t have one it’s not getting run...bla de bla I could go on and on, but its late and my book is calling me.

Have anyone of you been on project where things have become over processed? Are you using a test management tool like Test Director/Quality Center (hence forth know as TD or QC) and for some reason your Test Lead or Test Manager also has you filling out a spreadsheet with exactly the same data you are pumping into TD? I have been on a couple of projects where this has sadly been the case, people fail to realise how much this slows the poor tester down. Now I am very aware that TD and QC have their problems, the report tool is pretty limited and some still resort to using excel to put together reports but should be testers filling three or four spreadsheets if they change something here, they have to change it over there, and oh that one there too. We all know what happens don’t we? Things get out sync, people update the one over there, and not the one here and before long..you have the Test Lead making you walk through each everyone to make sure it ties up. After two hours of going through each line by line the tester goes a funny blue color and explodes.
There some out there, and lets call them process monkeys, who have no idea the pain and time it causes the poor testers, above all less tests are run because of all the things they need to do get their job done. Think about your processes, are they good? Do they all need to be done? Is their duplication of effort? Are you using TD and QC to their fullest by using customized fields ( you will not believe how many projects I have been on where no one has even attempted to sit down and do this.) I might be a bit cynical but the impression I get that some of the process monkeys actually enjoy the fact that they hordes of tester filling out spreadsheets that take on life of themselves, some get so big and wieldy that rips in the space time continuum have to be done just to store them. Above all they like the fact they have these duplicate processes because it keeps them in job...

Okay I am being cynical, but on the serious side we all need to think about this when start a project, if you think that you are duplicating something sit down and work out how long it takes you to do and then multiply it out across your project. I bet it will be an eye watering amount of time spent, when you could be doing something far better and productive to the project. When your project is finished put your observations into the lesson learned (usually the only spreadsheet that no one updates or reads)but make sure you are polite and reasoned, process monkeys get very touchy if you threaten to take their toys away. I’ m off to read my book now.

Test Dude..feels...

A bit like he is being made to climb up the side of mountain cliff dressed only in his underpants and a very thin rope, while the project waves a loaded gun at his head.

Weekend beer tastes wonderfull tonight.

The Testing Culture

Where to start? I have been in the software testing industry for nearly 11 years now, worked in some fantastic teams, and some not so good. Worked on some interesting projects that were a joy to be involved with and have worked on others that were akin to the eighth circle of hell.

When I thought about doing this I was not sure what to write about. After taking a swing about some other testing type blogs I quickly came to the conclusion there seem to be a lot more erudite and knowledgeable people out there than I am. From the ones that I read, they were all technically brilliant, with lovingly and concisely written prose about the subject of testing. It left me thinking I could never compete with these people; I may as well give up and write about cheese and pickle sandwiches.

I then went back and took another look to see what was missing from them, and its one subject that I think is overlooked in the testing world and that’s us. How do we deal with certain situations, like a 6 foot three developer who has not slept for three days standing over you yelling at you stop raising defects. Why do project managers seem to think that testing is something that is done quickly and if things are going badly it’s the test team that have the time robbed from them. You know “Oh you really don’t need to do all that” and the test manager gets the “descope” red pen out. Weeks later the same people are the TM’s desk jumping up down about a production bug flapping about “why didn’t you find it”.

There is then the relationship we have with the business and our role in the project. When do we start talking to the business? Should we wait till everything is done and dusted before we start our analysis? When does the test team simply say “You are having a laugh we ‘aint testing any more!”? One TA told me about the experience of going on to project and asking if they could talk to someone in the business about the possibility of reading some documents. You know to get a feel of what the applications were like, stuff like that. Once the rest of the room had recovered from their fits of laughter the TA was told that they were actively discouraged from talking anyone in the business. I want to write about fun stuff too, what the best music to test to? Things like that...

I guess I want to write about the “Culture of Testing” in the real world, I might leave the more academic musings to those who are good at it. I don’t want to have the sort of ISEB vrs ISTQB or this matrix is wayyyy better than this matrix debates. Which leads me into the one area that I have been thinking about for a while now; can the testing process be over processed? Thought I would toss that out.

So there you go not all what I wanted to say on the first post but you have to start somewhere. Blogging will be light as I am in the middle of one of those eighth circle of hell projects that I mentioned above, just as well the team I am in one of the great ones!

If you have surfed in on to this blog and you are tester and got the skinny on anything you want me to relate to the wider world the drop me a line at thetestdude@yahoo.com I will of course change names and places and add a lots of swear words.

Testing Times

I shall be writing about testing stuff here. When I get my act together that is!