Getting into Software Testing

Status
Not open for further replies.
As long as developers keep thinking this, I am going to have a job for a very long time :D

This is very true.

The problem I find with testing is that there is little creativity involved. You are basically testing someone elses work and pushing the code/program to the limit, to see if it breaks and ensure it does what it is supposed to.

Whereas, as a developer/programmer, within reason, you can be really creative.

In general, creativity tends to be more fun and is probably why most people want to be a developer rather than a tester.

Fair play to you though - if you are prepared to do a job which other people don't like, then you should be paid a big wage.
 
I think it depends a bit on your mentality, being creative tends to be more fun as you say, however some people are naturally more 'tuned' for destructive rather than constructive behaviour. The idea of somebody saying "I want this, create it for me" is quite scary, difficult to know where to start etc, whereas somebody saying "I've made this, tell me what's wrong with it" is a nice challenge.

^^not sure what exam there is that is 'extremely difficult to pass' in order to become a professional tester. I know plenty of professional testers who have no formal qualifications in the discipline. The most common qualification (ISEB foundation) is very easy (multiple choice from a choice of 4 with a 62.5% pass mark, meaning that realistically you only need to know half the answers and on average can guess the other half) and certainly no tougher than GCSE standard.
 
Even ISEB practitioner was easy. They just give a scenario and you write an essay effectively using as many buzz-words as possible!

Example scenario

'You have joined Jolly Roger holiday group. They have never had a test team or manager and have only developer unit tested their code, hence it is buggy as hell and the users hate it, and you are the brand spanking new test manager employed to sort this hassle out. Their system is VB front end, oracle back-end with C++ batch processes. They say the documentation is 'ropey at best' and some older functionality isn't documented at all and has no in-house knowledge as Geoff left (!!) it just kinda has kept working (!!) ... They have 300 staff taking bookings over the phone (onto the system) and 10,000 web hits a day from customers. They intend to double the size of their organisation within 6 months and want you to do whatever you are happy with to formally say it won't cause problems, as well as do some better testing on the regular new functionality than the developers are managing. They rather informally state 'they are sick of bugs being found by users once go-live making IT look rubbish, and your remit is to sort it out before such code gets to them'. As the new test manager in an organisation with no current test-policy or team whatsoever describe what systems and policies you would implement, resource requirements, stakeholder/management updating policies, and any methodologies or SDLC models or further strategy you would impose in order to achieve this goal'. You've got 3 hours.


In other words (as I read it, and passed!) 'Just choose any formal methodology and describe it well and in some detail, and pull something that sounds good out of your backside for the rest, sound confident and make definate decisions rather than wishy-washy 'I'd have brainstorming sessions about what everyone thought and have a gay vote on what to do' ( useless ), and you'll pass.
 
Last edited:
Waterfall is popular in defense I think.

Waterfall is but the current cuts in government spending are causing the techies in government to bend. They're faced with a more iterative agile approach instead of large projects that end up being completely different to what their original requirements were 4-5 years ago.

Part of my job is acting as a consultant to get a service product (VoIP communications) that serves the government into an agile development lifecycle - that's both business processes and the technical changes.

There's always a role for automated deployed solution acceptance testing with humans overseeing. This is becoming more important as agile results in more releases into the live system.
 
I'm currently developing an (Natural Lanuage) AI system and I love coding. However, the worst part of it is "testing". Normally, I test as I go along, however, there are some algorithms which have so many code-paths that testing them can become a job in itself. These long testing sessions fill me with dread.

I am shocked that somebody actually wants to become a hardcore/professional tester. What's worse is that there seem to be some exam, which is extremely difficult to pass, for you to become a professional tester.

Surely something like a NLP system is an ideal candidate for near-blanket Unit Test coverage?
 
(DISCLAIMER : IF YOU HAVE DEVELOPERS WHO KNOW HOW TO WRITE UNIT TESTS!)

However as soon as a complex UI or workflow is put in place I think testers are needed, if not only to make sure the automated test scripts are upto date etc.

Testing is verification that what has been delivered by a developer/vendor matches the original specification.

The problem with Agile-based development for large scale integration, products and service-based products (>£10M/yr) is that you still require a core documentation set to act as intermediary for analysis and the core design.
Having one architect for each functional area semi works but given the business continuity requirements (people leaving, accidents, vacation etc) then an intermediary design document that aligns with the requirements is still required.
Those full-time architects/functional leads will not be maintain code-based documentation but a more abstract overview as part of their role. This also helps them maintain a level of understanding about the refactoring costs during planning.

Waterfall is very much the tescos approach to development created by managers that don't understand this - have everything written down so that people can be moved/leave because they think it's as simple as re-reading the mass of documentation.

Agile based methodologies accept that part of the value is with the individual developer. Using that value as part of the business model to deliver quickly. The cost is weighed against the cost of missed opportunity, time and the resulting happy workforce that feels valued.
Sales has worked in this way for years, as has the rest of the business - knowledge is value and power.
 
Last edited:
Waterfall is popular in defense I think.

"Waterfall" is popular for the majority of government contracts, as one of the criteria is that they are managed via PRINCE2 - the posterboy for Waterfall processes.

There are a number of public sector organisations that are operating an agile-ish methodology, but still conforming to PRINCE2. In a "we're only doing it this way because we have to" way.

Hopefully that will be broken soon, and we'll see a mass influx of non-waterfall processes move into the public sector. I'm biased, so I think this will help reduce public spending. :)

A great result for Scrum just happened in the DFE - for the past 8 years a new site has been in the making for school staff. £10s of millions of pounds spent on it, with companies like CapGemini and EDS. Nothing, everything was thrown away and all that taxpayer money wasted. They recruited EduServe and implemented a full Scrum team. 3 months and ~£100,000 later, they had that website they wanted 8 years ago. :)
 
Last edited:
As others have already mentioned, increasingly there's no such thing as a test engineer in the traditional sense.

They're call Developer in Test, or just Developer. We've just changed our organisation (top 10 software company) to a "Unified Engineering" structure, which essentially means all the tester who can code have been made developed, and all the manual testers have been laid off. The devs are now responsible for writing all the test automation for their own features.
 
Status
Not open for further replies.
Back
Top Bottom