Tuesday, December 21, 2010

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.