Getting into Software Testing

Status
Not open for further replies.
For those of you that were in software testing but since moved on, what role did you move to? Did you move across to a more technicial role, eg. programming, or perhaps move up to a more managerial role, or move away to the requirements/design side of things? Or did you change to a wildly differnt role, perhaps not even in IT?

Also, has anyone done it the other way? Gone from a programming role to a testing role? I'm considering moving from software development to our testing practice but would want to go in as a Test Analyst/Manager rather than at the bottom (I've some experience of this already). Realistic? I could potentially get the Intermediate ISEB qualification next year.

One other thing I'd say is that the Foundation ISEB course is really good if you want to do software development too, after all a developer needs to know how to write unit tests.
 
"independent QA" - why independent and not integrated? :p

Independent from the development process. Otherwise the problem tends to be that your testing shares the same blind spots as the code.

OP - i would definitely recommend the ISEB Foundation. It is a pretty easy course with a bit of study, and it's generally a must have for any decent testing roles.

The practitioner level is much more difficult, but does allow you to specialise - either as an analyst, manager or technical (automation) tester. If you can get with a decent company they should put you through that maybe a year or so after you join.

As to whether testing is boring or not? It really depends on the role and the company. I've been quite lucky in that i've always had pretty interesting and challenging roles. I started out with zero experience testing software for sports clubs (ticketing, online sales, merchandise etc) and found it a really interesting environment to work in. I've spent the last 3 years in the finance industry in a more technical testing role (sybase/oracle and unix/linux mostly) and that has been pretty good so far. Sure, if you take a job where you are just re-running regression tests that can get pretty dull. But a lot of that kind of stuff tends to get automated or out-sourced to asia these days anyway. I've tended to work more on designing test cases, onboarding test scripts for new apps, building test harnesses and these days i manage my own team as well. Actually creating tests can be a great challenge, certainly engages the brain on a daily basis. And as i say, depending on what you're testing you can end up doing quite a lot of more technical stuff as part of it.
 
Last edited:
People don't get into software testing, they fall in. If you do choose too try and get into writing test automation scripts.
 
Last edited:
Don't do the ISEB foundation course, it's a big waste of money (what, £1000?).

You can get the self-study course for £150 on CD (www.leysen.com) (or borrow all the notes you'll need off me!) and book the exam for £75. It's easy to get through and this will save you £800. Course = waste of time unnecessary. I even got through all the practioner courses with no course, just self study. It's not rocket science anyone who knows how to graft a bit can do it.

The foundation may get you into a testing job. You'll have most luck if you're in the city. If I was you I'd lie and SAY you had the foundation on your cv first for a few weeks just to see if it gets you any interviews, if it does, don't go for the role (as you've lied on your CV). At least then you know whether bothering with the thing at all will help you. And no, I'm not joking ..

Software testing is a growing market, anyone that says it is dying is naive. Most of the developers I've worked with haven't even considered any system or integration tests, and do some kind of sloppy undocumented unit test on how they think from the spec it should probably work (!!). In other words, smoke testing. All a bit naff.

For goodness sake when you go for your interviews make sure you know about development life-cycles (especially AGILE). Also knowing the concepts behind risk based testing is a must.

With very little experience you should be the right side of 30K. With more experience you should really be commanding the low 40s minimum ..
 
Last edited:
Independent from the development process. Otherwise the problem tends to be that your testing shares the same blind spots as the code.
Simply not true. :) Testers should be involved from the start, they will be the ones who give the second best input for design, right behind the product owner/stakeholder. :)
 
Simply not true. :) Testers should be involved from the start, they will be the ones who give the second best input for design, right behind the product owner/stakeholder. :)

Well just to be pedantic, it depends on whether your software life-cycle model is 'Waterfall', 'V-Model' or 'AGILE'.

Lot's of companys still operate WATERFALL :/ It's rubbish, but if that's the way the company wants to work, it's not necessarily wrong!
 
Agile is not an acronym! (Sorry, pet hate..)

To an extent it does, but in all models there will be benefits from collaboration. And also a massive ":/" from me for Waterfall. It has its place, but so many organisations just cannot fathom it.
 
Simply not true. :) Testers should be involved from the start, they will be the ones who give the second best input for design, right behind the product owner/stakeholder. :)

I think we're agreeing here. Yes, testers should be involved right from the start - but as an independent set of eyes on what is being delivered. ie, not just relying on the developers to test their own code.
 
Personally I would rather hire a single good developer than a mediocre developer plus a software tester. It works out to be cheaper and causes less cost/time/management/red-tape overheads in the business. But I am very much of the lean/agile methodology mindset that encourages this, so perhaps biased.
 
Being slightly pedantic,Remember that Agile is not a methodology, it is a set of principles that allows us to get a product to market quickly and with the least cost, most importantly it gives the customer what they want!

http://agilemanifesto.org/principles.html

Some Agile methodologies are

Scrum
XP
RUP

Regarding testers and Unit tests etc

I think a lot of it depends on the project and how good the dev team are :p. I have worked on numerous products that had no test team and used TDD. We worked closely with the sponser to follow true TDD (writing failing tests, making them pass and then refactoring)

This alllows you to define the input/output to a component and all possible failure paths. For applications that have little UI or user interaction this process is fine. (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.
 
I'm also wanting out of support. The past 6 months I was involved in system testing and now want to further my career in this path. I'm now back on support and researching which books to self study with. I have no programming or developer experience and am now 30 - I'm just wondering if it's a bit late for me?
 
the first few years you are most likely to just be executing tests and not designing them and this can be very tedious work indeed. (In some companies you would have to run the exact same tests every week for like a year)

Maybe so in some companies, typically those supporting very mature/legacy systems where you are doing pure regression I'd imagine, but I certainly wouldn't say that is the norm. I was designing tests within a month of starting in software testing. The idea of having banks of mindless zombies running and monitoring scripts is something I think the industry is starting to move away from (those type of roles, if required, should be easy to outsource or even replace with the below....)

Software Testing is a legacy role that is dying a slow death anyway. Automated testing that is developed by the programmers themselves is replacing it.

Having all the tests designed by the programmer is fundamentally flawed because it means that if the developer has misunderstood the requirement, by definition the tester has as well, meaning that the tests won't identify that problem. You can write 100% perfect, 100% efficient code to achieve what you want to achieve - but if what you want to achieve is different from what the stakeholders want, there is a problem. Testers are not just validating code, they are validating that the requirement has been met, and this is commonly overlooked by many developers [I met a developer once, who said that there was no point anybody testing his code, as it had 100% unit test coverage, and therefore it was impossible for it to have any defects. What I took from that, was that he clearly doesn't understand what a defect is.]

Obviously under agile models where there is a closer link between the business / product owner and the development team, you'd hope that such misunderstandings are less common. But even then, effectively what you'll see is that during demos, prototyping sessions, effectively 'testing' is being done even if it isn't formally described as such. Under Agile testers will also be expected (or at least, they SHOULD be expected!) to give feedback, come up with ideas, suggest ways of improving things etc. I felt valued as a tester because I was on a project where people would listen to and implement my ideas on how to improve the product. I once had a colleague tell me that I was 'wasted' in testing, but on the contrary, I'd say the company was very lucky to have me as a tester on a poor salary and thus adding value :)

For those of you that were in software testing but since moved on, what role did you move to? Did you move across to a more technicial role, eg. programming, or perhaps move up to a more managerial role, or move away to the requirements/design side of things? Or did you change to a wildly differnt role, perhaps not even in IT?

I moved into Business Consultancy. This was more a question of it being a way to progress within my organisation (they abolished the Test Manager role and moved towards matrix/project rather than functional reporting lines) rather than because I wanted to 'get out' of testing.


Anyway, back to the OP. IMO the best way to get into software testing is simply to apply for some jobs making sure you highlight where you have done the following in your support roles:

-Awareness of SDLC
-Any testing or validation you may have done (IVT, UAT etc)
-Liaisons you've had with project team members e.g. Developers, PMs, Testers etc
-Specialist skills i.e. Unix, SQL / DB admin, IIS/websphere etc..... stuff like that is always in demand for more technical testing roles

If there are any testing jobs at your current employer it can be a good way to get your foot in the door, typically most people seem to enter testing via one of 2 routes:

1) Internal appointment
2) Junior graduate position

ISEB would undoubtedly help (if nothing else, showing prospective employers that you are serious about wanting to get into it) but if you play your cards right you may be able to get an employer to fund it for you if you can find a role.

edit: in a funny sort of way I think testing isn't actually that difficult to get into, the hard part is probably choosing the right organisation to work for and/or having a strategy to progress your career forwards once you've got your foot in the door.
 
Last edited:
I was more thinking of

Web Development
Front end work (HTML / CSS etc)

This will allow you to focus on one area to learn. And step up from.

Its to vague to say something like "learn .NET" as it has so many frameworks and project types for someone starting new to absorb it all (unless you the next anders hejlsberg!)
 
If you're bored, I'd consider going towards Development rather than testing. Testing, for the most part, can be very monotonous. When you become a bit more senior it can become interesting, but as a Junior Tester you'll discover a new definition of boring.

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.
 
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.

As long as developers keep thinking this, I am going to have a job for a very long time :D I am actually moving from development into testing. The testing toolset just requires core Java knowledge (for the automation side).

To the op, look at the ISEB online course. I just passed mine using ILX and managed it in a week. At Foundation level it is buzzword bingo so it is not very hard.

At the moment I'm finding that there is a huge demand for Agile testers with automation experience. Without a lie the automated testers here are on more than the developers.
 
Status
Not open for further replies.
Back
Top Bottom