Testers

[Cenobite]

Views on testing

I don't think I've ever worked with someone I'd consider a professional tester. I'd like to because I think the function is very important and I'd like to learn more about it. What I'm expecting is someone who:

• liked taking things apart as a kid;
• has some programming experience, so knows where developers might cut corners;
• has a good sense of how to break an app; and
• can write automated tests.

I know there are professional testers on this forum, but the ones I worked with have not been like this. They've no real skills and were just general dogsbodies. If I were a professional tester, they'd be giving my profession a bad name. Please don't think I'm sticking up for developers: the average developer is crap. However, when companies are recruiting devs, they might expect them to have a degree in computing and some decent code on Github. But I can't see what their expectations are for testers.

One place where I worked as a developer, it was a developer's responsibility to write a test script which was a set of manual instructions for a tester to work through. (Automated testing tools were available but the team wasn't doing that). This is bad because these served as the user acceptance tests, but written from the perspective of a developer. Essentially, the product ended up doing what the developer thought it should, but this is not what the customer wanted. The testers just ran through the manual steps written for them like automata. This was my first experience with a test team and us developers spent a lot of time questioning what value the testers were adding. Also when things got tight, developers had to do manual testing too (I didn't envy the testers though, this was mind-numblingly boring). Whereas all the devs on the team had Russell Group computing degrees, the testers were people from non-technical backgrounds who had been made redundant from other parts of the business, but we were all on the same payscale.

I don't see testers doing much exploratory testing. I checked my Scrum book to check testers' responsibilities, and it stated that one of things testers are there to do is help developers automate tests but the reality seems to be completely the other way round since they seem to need a developer-in-test to help them. If I was stuck automating a test, I'd ask another developer.

I'm only jealous: with the pace of offshoring coding, onshore testing rates are looking pretty good.

[SussexSeagull]

I consider myself a professional tester (been doing it for 18 years across a variety of sectors) and had I been in some of the scenarios outlined above I would have done my best to change it but failing that walking away.

For anything more than the most minor of changes I make it something of a policy to ignore any 'testing' advice given by a developer and write and execute my own tests. If you are taking advice from the developer you are testing to his understanding of the requirement, not the actual requirement (granted this can of course be the same thing).

It is not the testers role to pass judgement on software, it is their job to run an agreed series of tests then report the results and let others decide what happens next. So long as any issues are reported and the relevant people are made aware, it is not a personal crusade to get them fixed.

This should be done before any Exploratory testing takes place, however if you find a problem you should be looking to perform ad-hoc testing round it to see how wide spread it is. To be honest in most projects I have been involved in there is no time for exploratory testing on top of this and testers doing this while they should be running scripts is in the main an ego trip.

Automated Testing has it's place in a system that is going to be around for a while but it isn't the silver bullet some techies make out as someone still needs to design the test, code it and run it and if it is going to get binned at the end of the project or even if it is only run once or twice afterwards then you won't see a ROI.

I have noticed over the years coding standards have gone down hill and more regression testing needs to be performed as surgical development doesn't seem to happen anymore where the change happens but nothing else. This is where a lot of so called Agile projects go wrong as regression testing doesn't fit well in it.

Getting the business to do testing is fine but I some organisations are over reliant on it and they are brought in too early when really they should only get involved when it is at a stage of development where you can run it end to end with limited documented issues outstanding.

Bit old fashioned but pays my mortgage.

[GlenSausio]

I worked at one bank recently for two years. They had a test harness there that cost one million USD to develop and required 3 full time staff to maintain test cases for.

It caught one bug in two years that I was there.

Bugs would be found in production, they update the test harness and then you prevent a regression.

A complex system is to hard to test thoroughly. So you identify your most important test scenarios and focus on them. Knock up a test program to make that repeatable. Why do you need a tester?

I spend some of my time explaining the functionality to a tester that most of the time doesn't fully understand. It's an exercise in convincing them to take my word for it. "If that box says 1, and that one says 2, that one should say 6". A decent tester usually ends up a Test Manager, or a BA. Corporate bludgers.

[GlenSausio]

I consider myself a professional tester (been doing it for 18 years across a variety of sectors) and had I been in some of the scenarios outlined above I would have done my best to change it but failing that walking away.

For anything more than the most minor of changes I make it something of a policy to ignore any 'testing' advice given by a developer and write and execute my own tests. If you are taking advice from the developer you are testing to his understanding of the requirement, not the actual requirement (granted this can of course be the same thing).

It is not the testers role to pass judgement on software, it is their job to run an agreed series of tests then report the results and let others decide what happens next. So long as any issues are reported and the relevant people are made aware, it is not a personal crusade to get them fixed.

This should be done before any Exploratory testing takes place, however if you find a problem you should be looking to perform ad-hoc testing round it to see how wide spread it is. To be honest in most projects I have been involved in there is no time for exploratory testing on top of this and testers doing this while they should be running scripts is in the main an ego trip.

Automated Testing has it's place in a system that is going to be around for a while but it isn't the silver bullet some techies make out as someone still needs to design the test, code it and run it and if it is going to get binned at the end of the project or even if it is only run once or twice afterwards then you won't see a ROI.

I have noticed over the years coding standards have gone down hill and more regression testing needs to be performed as surgical development doesn't seem to happen anymore where the change happens but nothing else. This is where a lot of so called Agile projects go wrong as regression testing doesn't fit well in it.

Getting the business to do testing is fine but I some organisations are over reliant on it and they are brought in too early when really they should only get involved when it is at a stage of development where you can run it end to end with limited documented issues outstanding.

Bit old fashioned but pays my mortgage.

Good points, well made. But regression testing is key to agile projects. It doesn't work without it.

[SussexSeagull]

I worked at one bank recently for two years. They had a test harness there that cost one million USD to develop and required 3 full time staff to maintain test cases for.

It caught one bug in two years that I was there.

Bugs would be found in production, they update the test harness and then you prevent a regression.

A complex system is to hard to test thoroughly. So you identify your most important test scenarios and focus on them. Knock up a test program to make that repeatable. Why do you need a tester?

I spend some of my time explaining the functionality to a tester that most of the time doesn't fully understand. It's an exercise in convincing them to take my word for it. "If that box says 1, and that one says 2, that one should say 6". A decent tester usually ends up a Test Manager, or a BA. Corporate bludgers.

Finding issues is only part of testing. Being seen to attempt to find issues and building confidence is a major part. In your example (assuming it wasn't missing any regression defects) the test harness did this to a large extent.

Regression testing rarely covers everything, especially on a complex system, but is an attempt to build confidence in the new release of a system. In my experience developers don't make good testers once you get past unit testing as they think code and not functionality so you need a tester to identify test requirements and write scripts.

Besides which, it allows developers to have more time to develop.

If you are having to explain new functionality to a tester that suggests a hero culture and a distinct lack of documentation.

[SussexSeagull]

Good points, well made. But regression testing is key to agile projects. It doesn't work without it.

Absolutely, but it often gets overlooked.

[woohoo]

I have noticed over the years coding standards have gone down hill and more regression testing needs to be performed as surgical development doesn't seem to happen anymore where the change happens but nothing else. This is where a lot of so called Agile projects go wrong as regression testing doesn't fit well in it.

In my experience coding standards have not gone down hill. Developers in my opinion are more productive now than ever before. More productivity = more bugs. Expectation have also risen.

Bugs should be expected especially with more pressure to release code to production early and often. I had a reputation for producing work with few or no bugs and it's an awful thing to live up to. It stops you being productive and creative as everything has to be perfect.

Often bugs can be managed, have work-arounds or can be easily fixed even in a live environment - it's not the end of the world - usually

Bugs do not always mean a bad programmer.

[GlenSausio]

Finding issues is only part of testing. Being seen to attempt to find issues and building confidence is a major part. In your example (assuming it wasn't missing any regression defects) the test harness did this to a large extent.

Regression testing rarely covers everything, especially on a complex system, but is an attempt to build confidence in the new release of a system. In my experience developers don't make good testers once you get past unit testing as they think code and not functionality so you need a tester to identify test requirements and write scripts.

Besides which, it allows developers to have more time to develop.

If you are having to explain new functionality to a tester that suggests a hero culture and a distinct lack of documentation.

Yep, fair enough. I'll accept that.

[Zero Liability]

I totally agree. I'm an ex-Java developer. Most C++ programmers know their stuff and I think companies would have a lot more trouble bobbing out C++ work than Java. My top tip is Clojure, a functional programming language: I've found functional languages really separate the wheat from the chaff because a lot of average developers just can't get their head around it.

What would you recommend someone considering a career change to IT look into as far as programming languages go?

[SussexSeagull]

In my experience coding standards have not gone down hill. Developers in my opinion are more productive now than ever before. More productivity = more bugs. Expectation have also risen.

Bugs should be expected especially with more pressure to release code to production early and often. I had a reputation for producing work with few or no bugs and it's an awful thing to live up to. It stops you being productive and creative as everything has to be perfect.

Often bugs can be managed, have work-arounds or can be easily fixed even in a live environment - it's not the end of the world - usually

Bugs do not always mean a bad programmer.

I do agree deadlines are becoming more and more unrealistic to the point no one actually seems to expect people to meet them any more. It is just in my experience new releases tend to have more regression problems than they used to.

Having said that, it does vary and some are much better than others. Also environmental and deployment problems come into play as well.