Testing is not a stepping stone to Programming

OK, so this morning I possibly jumped onto my soap box quite quickly - but I thought, no, I can't keep quiet while someone trivialises testing yet again.

A post went up on the 'Australian IT Industry' group on LinkedIn a month ago, with a member asking "Is a Masters degree worth it?". In summary, this member has 2 yrs experience working with ASP, VBA and MS Access - however is currently working for McDonalds while trying to get back into an IT role.

Another member posted this yesterday in response:

"Hi Alan, I was in the same boat as you 4 years ago. The IT industry is a challenge. Your first official IT role is probably not your ideal role but do your best in that role and you'll definitely get somewhere. Important thing is getting your foot at the IT door regardless of any role (tester/help desk/junior roles). Once you're in it, attempt to get any certifications or career progression training."

Now, maybe I'm jumping the gun, however - since when has testing been an entry level role to IT? Haven't we progressed and evolved to realise that testers are a very important part of a development team? This type of comment put IT back 20 years.

However, not to attack this member - it seems there are still quite a few people and companies that trivialise testing, believing that any untrained monkey can test. This type of attitude irritates me. I still don't understand why this is still an issue today?

I have previously been on a project where the Project Manager was of the same opinion - as you could imagine, we didn't share the same values. I commenced on the project after the project schedule had been set in stone and announced to stakeholders and business owners. Looking at the schedule, I realised insufficient time had been allocated to testing - 12 months of programming, large volume of complex business rules which were legislative based, and only 5 weeks of testing at the end - very waterfall..... I tried to build a team with professional testers, however, with no budget, this didn't work out well for me, and I only got half the number of staff that I needed to meet the impossible timeline. I was able to work with the programmers to allow us do early testing in the sandpit environment prior to the formal testing stage, to at least allow us to identify issues / defects early. When the formal testing phase commenced, we realised there was no way we were going to meet the scheduled date, so the PM's response was to throw business staff, admin staff, etc at testing - as his opinion was testing could be done by anyone. After ripping out my hair, and inheriting another couple of ulcers, there I was, with a couple of professional testers and a bunch of staff that didn't know or understand testing. This isn't too bad if you are able to screen the people being offered to you, to see if they have the aptitude to test, however, the staff I was given didn't have this. They didn't question and they didn't think outside the basics. This increased my work load and that of my testers. We had to retest functionality, as serious defects had been missed. I was also bogged down in defect management as defects were being raised by inexperienced staff as "I don't understand this", which were a misunderstanding of the test case. These staff didn't like the idea of getting up and speaking to someone about an issue they've found, instead raising invalid bug reports, or just ignoring the issue altogether.

As you could imagine - this wasn't going to be a very successful release - however, thanks to a great team of professional testers, we were able to work the extra hours to identify the serious defects for fixing prior to the release to production. This caused a lot of unnecessary stress on the team.

Another project I inherited also had quite a few issues due to staffing of the test team. The test team had been hired by a HR manager, who didn't understand testing. Incorrect test analysis was conducted, and some serious functional defects were missed. Thankfully this project was saved in time by re-building the test team with experienced testers - which allowed a successful release to production.

We continually see the statistics and hear the horror stories about projects that have failed due to inadequate testing, or no testing at all. We see the costs associated with testing too late or not at all. We sit in Lessons Learned sessions at the end of a release or project - yet, the same mistakes or attitude continue into the next project or release by the same people.

Thankfully I only have 2 horror stories from my 12 years as a career tester in both waterfall and agile project teams. The majority of projects I have worked on have been brilliant, and the testers and programmers have successfully worked together to build some fantastic products. Both testers and programmers had been given the same level of respect by the Project Managers and Senior Management on these projects - as they understood the importance of both roles in a development team.

We have some influential testers in the industry, who have been able to change attitudes towards testing to put the testing profession in the same repute as programmers, business analysts, etc. Testing is now considered a career in it's own right - yet, for some reason, there are still people and companies out there that have the attitude that testing is an entry level or stepping stone into programming. Please realise - testing is a completely different and unique skillset to programming. That's not to say a programmer can't test, or a tester can't develop code. It is just a different role in the development team, and each equally serves an important role in a successful product release.

What do you do when you cannot get any code out of your developers

A few years back, while working for an R&D company, I was part of a group of commercial developers and testers brought on to bring a research project into production development. After quite a few assessments on the prototype, our architecture team decided to keep the underlying engines, however, completely re-engineer the UI and business-logic layers.

So, the technology for the UI and business-layer was eventually decided upon.

At this stage, I was the sole test team - so I worked closely with my team of 10 developers to spec out the entire application.

However, one of our lead developers got caught up in the technology. He had decided on a framework, gave the devs an overview of it - and set them on their merry way to code "the new world"........... until....... a few days into development, he decided there was a better technology to do what he wanted to do.

So, after re-scoping the framework, and re-educating the entire development team in the new technology he had found on the net the night before (and had spent all night working on it)...... he set the development team on their merry way again, to re-code the code they had already written, in the newer, better technology he had found....... until....... a few weeks into development, he decided there was a better technology / way to do what he wanted to do....

So, at this point, there were developers who were getting quite upset re-working the same area every time this guy changed his mind.... and then there was me - going out of my mind waiting for code to come through.

Yes, I worked with each of the developers in the development environment - as I couldn't get a release out of them while the framework was constantly changing - however, frustration was an understatement.

When I did get a release out of him - I heard those words that I had come to dread "hey guys, I saw this new advancement in last night, I think we should do it this way".... yes, here we were, back at square one....

So, with all business specs, SRS's, Functional Flow Block Diagrams, test strategies, test plans, test scenarios, test cases, etc written - I was here stuck with nothing to test. I couldn't start automating, as the foundations of the application were constantly changing - even the developers had given up on writing unit tests, for the fear of those dreaded words again......

So, I put to everyone out there - what do you do in situations like these?

Personally - I assisted the developers as much as possible, by doing pair testing with them (ie: sitting next to them in their development environment, and testing their code changes as they made them locally), but this was becoming time consuming for them, as they had to quickly make up for lost development time every time they had to re-work their code....

So, I started self-educating myself with everything and anything testing related I could find on the net - but this proved to become quite boring after 3 months of not getting anything to physically test.

So, out of complete frustration (boredom is a greater stressor to me than impossible deadlines) - I found another job and moved on.......

So, did I make the right decision? Did I do everything I could to make this job work for me?

I think so - if it wasn't for that move, I wouldn't be where I am today - which I believe, is a very good place to be ;-)

Come on Google - fix the gmail error with IE7 already!!

Seriously Google, this error is getting a bit old - and its annoying me no end.....

Logging into gmail using IE 7, users are presented with an error message:

"Internet Explorer cannot open the Internet site http://mail.gmail.com/mail/. Operation aborted."


OK - we know that it is a known problem - as defined here:

http://mail.google.com/support/bin/static.py?page=known_issues.cs&knownissue=gmail_issue_ie7operationaborted&topic=12778

but come on..... surely this is an error worth fixing - as a lot of people are moving onto IE7

The OK Corral - where testers are second class citizens

Well, howdy partners, it's time to strap on the spurs and mosey on down to the OK Corral. This ain't for the feint hearted - testers will be treated as second class citizens.....

So, when is agile development not agile development?....... When it is run by a bunch of cowboys!

A few of my friends (testers) are currently working for companies that claim to be a "lean development agile shop"..... this, you guessed, includes NO documentation, NO process, NO responsibilities and NO accountabilities..... and testers, well, they're just the things that get in the way of the code getting into production.

It's quite upsetting that companies such as these exploit the term agile - and use it as an excuse for poor management.

Seriously people - wake up and see what you are doing!

And, to my friends - please, please come to your senses, and move onto a company that will appreciate your skills and experience, and will reward you accordingly....... Remember, loyalty is a two-way street!

Forum etiquette

OK - let the ranting begin.......

I subscribe to a number of testing related forums. One forum in particular, I registered with in 2002, then by 2003 I stopped reading it. I got upset with the number of *lazy* / *misguided* people using it as a short-cut to doing research.

Let me give you an example of one of the posts that was allowed through on the forum:

"How to do testing" - this was posted by a person who was trying to apply for a testing position, with no testing experience. This isn't too bad, people have to start somewhere, HOWEVER, this person had not taken the time to read through this forum, do research on the web, etc. They wanted a quick answer so that they could give unsubstantiated responses to interview questions....

So, why has this upset me? There are a number of reasons:
1. As a hiring test manager - I do NOT want someone who is going to constantly be at my desk, or annoying other team members on basic questions, where they could have gotten the answers to by using a little initiative and doing a bit of research.
2. As a hiring test manager - it REALLY annoys me when interviewing someone who tries to bamboozle you with buzz words - yet when challenged (which I LOVE to do) about the context in which they would use said buzz word, they try again by throwing in a few new buzz words. At this point, my blood is boiling, and I quickly finish the interview, and then stamp their applications with a NO HIRE EVER recommendation to HR. I do not like my time being wasted by someone, who has not put in the effort to apply for a position.

Now, don't get me wrong - I have hired people with very little testing experience, who have turned out to be superstars on the test team. But, the difference with these people - they didn't try to BS me during interview. When they didn't know the answer to a question, they were happy to tell me that - and were able to give me examples of other times when they were not familiar with the situation, and what they did to remedy this. They also asked me the right questions during the interview. These people displayed to me the initiative and ability to research a problem, and present solutions.

Why is that important, rather than someone who knows all the buzz-words?

Because testing is a constant challenge! You have to be able to think on your feet - know when to say "I don't know, but I'll get back to you within an hour with a response". Testing is also not about following the latest buzz-words, or following a text book description of testing.

Testing is about thinking, analysing, and researching.

If I cannot see these characteristics in a potential hire, then I will not waste my time, or the company's time entertaining these people. The last thing I want is a tester who makes up a response to questions they don't know - rather than saying "I'm not sure, I'll get back to you when I have found out". This type of person is the one who will cause a project to go off-course.

So, back to this particular forum.....

A few months back, a colleague of mine asked if I subscribed to this forum. I said that I did have an account on it, but hadn't been on for a few years due to the type of garbage that was being posted on it. He assured me that it had changed, so I bought in again......

So, here I am today - looking over the forum, posting a few grouchy responses to people who obviously haven't taken the time to research their questions before posting. But, amongst the noise of silly questions - there are some very good posts, and responses, which I have been happy to read through.

So, what is the purpose of my current rant?

Could I ask the moderators of this forum to NOT post the silly questions and answers (similar to the example given above), so that we can reduce the noise on the forum, and allow the meaningful discussions to be more prominent? And, to all those thinking about posting onto the forum - please show a little forum etiquette........

/rant over - going over to the forum now to post a few more grouchy responses to the time wasters ;-D

SQL Server Management Studio 2005 add-in

I know I put at the top of my post that I'm not very technology savvy, but I thought that this was definitely worth a mention.

I'd like to bring your attention to this SQL Server Management Studio 2005 add-in written by Joseph Cooney (one of those fabulous developers that I am currently working with)

http://jcooney.net/archive/2007/11/26/55358.aspx

After sitting and debugging our production issues at a previous company, working through some of the strangest table names we have ever seen (surely there has to be some limit to the length of a table name, for the love of God!) - Joseph came up with a wonderful "fuzzy search" add-in for SQL Server Management Studio 2005.

Now, you'd think that I'd jump at the opportunity to install this fantastic tool - given that I'm doing a fair bit of data analysis at the moment - but alas, it took me until today to install it! Now, that's a good 7 months after he developed it. Yeah, I'm slow, but I'm worth waiting for ;-P

But, today was a great milestone for me - it's installed, and up and running - and, like the promises he made me - it has made my life sooo much easier. Yes, I should have installed it sooner, I know!!

Thank you Joseph for this wonderful add-in, and thank you for having the patience with me :)

Stepping back and seeing the big picture

After years of reading other people's blogs, subscribing and contributing to forums, procrastinating about whether I should inflict my opinionated views on others, and the encouragement of my peers, I have decided to take the leap of faith and join the blogging community.

So, for my first blog post - I thought I'd start with a positive story.

A little while back, I was working for a company in which we were developing a large enterprise system. After doing some very long hours (80 to 100 hour weeks), and sitting at my desk at 9pm most nights wondering why I chose this profession, the challenge seemed to have gone out of it, as the bugs were coming through thick and fast, I felt like I was drowning in the number of defects still open. Then on one particular day, close to our scheduled release to production date, I stuck my head up from under my desk at the most inopportune moment. I was spotted, and was quickly marched into the fortnightly Project Director's update meeting. While screaming my protests all the way down the hallway, being dragged by the ear by our project coordinator, I was then promptly sat down in the meeting - and told to stay.

Gritting my teeth, I sat through the usual spiel. Looking around the participants (had to keep myself entertained somehow!!), I noticed that there were more than just the project members in the meeting. I recognised some of the extra bodies as being business representatives, and thought it was a bit strange. Then I heard the words "and, now I'd like to pass you over to our Business Analyst, who will present a live demonstration of the application".....

OK - the only thing going through my head at this point was "Holy crap, I hope they don't see this bug, or that bug, or even that bug. Ah crap, there are just too many bugs - maybe I should just slink away now and pack up my desk"

So, here we were.... our wonderful BA (who I still adore to this day) started off by explaining to the project the current difficulties faced by the business in doing their day-to-day work with systems that were quite deficient, and only met the business' very basic needs. Then she opened up the application, and I saw my life for the past several months starting to unfold up on the "big screen". Oh application, how I've become to know you so intimately!

As she started to use the application, and work through some of the more common business processes, and explain the value that these features would give the users, I sat there in stunned silence. At the end of the presentation, there was loud applause from the business representatives, and I was just sitting there like a stunned mullet.

All of a sudden, I had seen the application through the eyes of an end-user, and not through the eyes of a tester. Damn, what a great system we had developed! At that point, everything was put into perspective - I had been given the opportunity to step back and see the big picture. All of a sudden, some of the issues that had been bogging me down seemed to have become less important. Yes, we still had some serious bugs in the system, but in the grand scheme of things, they were just slight hiccups on the road to delivering an important application to the business.

So, now, when I am feeling bogged down in the details, I take a step back and have a look at the big picture. This puts everything back into perspective for me. I think testers need to have a good balance of being detail oriented and also seeing the big picture.

I hope you find inspiration in my story - and can once in a while, take a step back and see the whole picture.