Testing Times

Ever get disillusioned with testing

2010-07-27T12:15:00.000-07:00

I have been applying for the odd position here and there over the last few months. One or two have got to the interview stage which as usual has been an eye opening experience. In one interview I thought I had blazed it, the only downside was the written test that I had to do, which I was not prepared for at all and so made a real messy attempt. That was my fault and accept it. However I did not even get a courtesy feedback reply from them which might suggest that the test they stressed was not that important, suddenly became very important.

I recently went for another interview and thought I did OK, I got back feedback this time. They said I came across well, and appeared to be a solid competent TA..HOWEVER they seem to think that I lacked enthusiasm and drive. There was also the case that there was previous mutual client that I could never work for again and this client matters to them, so it meant I ruled myself out as soon as brought the whole sorry episode up. I actually thought I should have never brought up that tragic project from my previous testing experience but I thought I would be honest, perhaps I was too honest and perhaps lingered far to long on the explanation of what went wrong and my role in it. The project when I joined was already in trouble it just went further south..and I didnt cover myself in glory either.

Ah well I need to think about my life in the testing world, I am no longer young man. Feeling a bit disillusioned at the moment, it will pass.

Well and Truly De-scoped

2010-06-29T10:39:00.000-07:00

I have just spent about month working on the current release that we are doing. Now a large section of the release was always going to be in doubt because of a potential "management change" that was on the cards. Well the change happened and the mandatory change was scrapped by the new managers. Oh well we said isn't that bad as we have less things to run and there is still plenty of other bits of the release. Apart from that this piece of work had not really been thought through, above all this would mean of course Test Dude would do his De-scope dance and have less work to do!

So today I Logged into the defect meeting conference and the TM announced that that the other large section of work that was supposed to be in this release has now been pushed into the next release because they are simply having problems building it! There then followed a rather long conversation about how to back out the code for the now junked mandatory release."Why cant we just switch it off" asked one of the business analysts "Err its a little bit more trickier than that" squeaked a rather apologetic developer who sounded like he very much wanted to be somewhere else. Anyway after a half an hour of tooing and froing about environments they decided to scrap the defect meeting and have a re plan meeting sometime later. I had been enjoying watching the crows hop about outside my window, but was rather glad the meeting had finished. The release co-ordinator gathered the troops for our own meeting, along with the release co-ordinator for the next release who was tempted along with the false promise of choccie biscuits

Much later when we managed to revive the poor old Release coordinator for next release ( who had gone all the shades of white and fainted on the announcement) we sat about and thought what it meant for the currently release. All the tests we had run would have to be scrapped and re-run in the new environment that was being built. Yep lots of on the hoof planning, just the way we like it huh uh huh.

The only shades of light is that we have done all the hard work for the stuff that has been dumped into the next release. It will mean that we will have an extra couple of hundred scripts to churn through though. I went back to my desk and watched the crows fight over scraps and contemplated holidays and any new job that doesnt involve testing.

Process Improvment. Small Steps

2010-03-08T12:16:00.000-08:00

As testers we should always be asking "what can we do better, and how can we do it better?". As we all know Project stakeholders are looking for ways to their product to market quicker to market. In order to do this they look at ways to reducing the time things are done, and in particular it seems they always pick on the testing part of the project. They seem to think that testing is they easy bit!

From my own experience test teams often sit down and have their process review and say "We need to do all this, so it will save us time here and here". Quite often it’s a huge list of things which get written down in a document which invariably ends up getting buried in the Test Managers back garden next to the last document that was done last year; where it is producing rather nice roses and not much else. Even if the suggestions are acted on, they are often quite big changes and we don’t have a lot of time to get them working. We end up getting fed up after all we have this important release to do..and we slip back in to the bad habits.

My advice is to look at the small things first, quite often it is the small things that all add up. For instance today I instigated "Project Clean up" simply because our management tool we use has become far too cluttered for my taste. I had been dropping hints for months about this without any of them really catching on. So I decided to send an email to TM of UAT and the System testing outlining my plan of action

"I want to create Archive folders in TD "
"That’s a good idea why haven’t been doing that?" came the reply back from the TM's

So I am now in the process of planning this all out, might take me a morning to do it all but its small thing that in long run will make our management tool a lot easier to use and drive reports from. Small step kids, small steps.

Brute Force

2010-02-04T12:32:00.000-08:00

Execution is always a bit hairy on our projects, simply because the theory of doing something on the system is not always the same when comes to actually doing that something. This is compounded by the fact that some of the team (who have been around since the big bang, the dinosaurs and will be around log after I have gone) are not entirely sure how things work either. Sometimes it can great fun, thinking you have easy script to run off you go with a sunshine smile and full of hope . Only to discover that you need to have X and oh bit of Y and some Z before A can happen. After two hours the sunshine smile has vanished to be replaced with a blood stained forehead and face of thunder

Now I know you might think that analysis and prep you are supposed to find all of that out, sometimes we do. Unfortunately most of the time we don’t, time is just not given to do what we would like to do and when execution time is tight as it is, you do end up seeing poor TA’s banging their heads against the screen, before being carried away by the men in white suits and the back to front jacket.

There is no remedy for this, no elegant piece of theory, nifty spreadsheet or wonder tool. It is sadly brute force and dogged persistence that gets you through. That’s why we do it though isn’t it...

End of the Year and Project thoughts

2009-12-22T05:13:00.000-08:00

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

2009-10-23T12:06:00.000-07:00

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

2009-10-14T13:48:00.001-07:00

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

2009-10-12T11:59:00.000-07:00

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

2009-10-09T11:54:00.000-07:00

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

2009-10-08T13:08:00.000-07:00

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

2009-10-04T08:40:00.000-07:00

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