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.
Tuesday 27 July 2010
Tuesday 29 June 2010
Well and Truly De-scoped
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.
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.
Monday 8 March 2010
Process Improvment. Small Steps
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.
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.
Thursday 4 February 2010
Brute Force
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...
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...
Tuesday 22 December 2009
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
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
Friday 23 October 2009
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.
Ah well long week, the beer is good tonight.
Wednesday 14 October 2009
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....!"
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....!"
Subscribe to:
Posts (Atom)