Should I give up on finding first ever contract

[BigDataPro]

Thanks for the honest comments. I have been thinking the same thing about Manual Testing. I guess I will have to go down the permanent route where you learn automation on the job.

I have looked into automation with Selenium and I have a good overview of it. I have never actually done it in Business though. So I can't go for those roles where you need to hit the ground running

Slight issue is that I see Automation as a Developer in Test role and I don't really want to be a Developer if I'm honest. I can't imagine many Developers want to move into Test though.

I think there is still a need for Manual Testers but that seems to be shrinking. I don't know what I can do instead though if I have been doing testing for 15 odd years. I feel a bit stuck

My final few cents. Selenium alone is insufficient. Looking at a typical 3 tier web application (Frontend, Middleware and Backend), you would see plenty of tools/technologies involved for testing alone. All of these tiers need Functional, Performance and Security testing. So Automation testing involves understanding most of,

FrontEnd - Mocha, Chai, Karma, Jasmin, Protractor (AngularJS), Jest (ReactJS)
Middleware - Web Services / MQ testing - SoapUI, JMeter
BackEnd - Just SQL would do but DBUnit helps a lot.

In addition, you need to have an understanding of BDD/TDD - therefore Java/Net and Cucumber, Fitnesse, JBehave and what not. I haven't touched Mobile App testing yet.

But good luck with whatever path you are taking.

[cannon999]

My final few cents. Selenium alone is insufficient. Looking at a typical 3 tier web application (Frontend, Middleware and Backend), you would see plenty of tools/technologies involved for testing alone. All of these tiers need Functional, Performance and Security testing

FrontEnd - Mocha, Chai, Karma, Jasmin, Protractor (AngularJS), Jest (ReactJS)
Middleware - Web Services / MQ testing - SoapUI, JMeter
BackEnd - Just SQL would do but DBUnit helps a lot.

In addition, you need to have an understanding of BDD/TDD - therefore Java/Net and Cucumber, Fitnesse, JBehave and what not. I haven't touched Mobile App testing yet.

You, quite obviously, have no idea what you are talking about. Everything you have listed (apart from maybe Protractor and SoapUI) are frameworks used by developers to test their code. It's absurd to expect an automation engineer to understand production code and write tests for it. The whole point of automation tests is that they test the application itself and not the code that runs it.

[BigDataPro]

You, quite obviously, have no idea what you are talking about. Everything you have listed (apart from maybe Protractor and SoapUI) are frameworks used by developers to test their code. It's absurd to expect an automation engineer to understand production code and write tests for it. The whole point of automation tests is that they test the application itself and not the code that runs it.

Forgot to add one more thing where obviously I have no idea . Selenium is useless when testing desktop applications. This requires another tool like QTP or WinRunner. So all of these come under the term Test Automation.

[mudskipper]

I suspect none of this "what is a tester" chat, fascinating though it is, is helpful to the OP.

As others have said, look at the CV focussing on achievements and results. Not as easy as it sounds, which is where the pros can really provide value.

[Hobosapien]

I suspect none of this "what is a tester" chat, fascinating though it is, is helpful to the OP.

Well the feedback has shown that the game has moved on somewhat since the OP last looked for work, so it should be helpful to the OP to decide which niche to target and how many of the current tools they want to bother learning.

There must still be companies out there that recognise the value of using humans rather than tools to ensure quality (e.g. finding bugs beyond the unit testing of developers) before putting the product in front of the user. Unless they are using the user as tester, which seems popular with tech giants releasing sub standard products for user to find the problems.

So perhaps the QA testing side is closer to the OP's current position. I'd avoid going anywhere near dev unless you have bags of energy and enthusiasm. These days it's an endless cycle of new tools, frameworks, and methodologies, all soon to be replaced by the next in fashion thing. I get exhausted just thinking about it.

[fool]

There must still be companies out there that recognise the value of using humans rather than tools to ensure quality (e.g. finding bugs beyond the unit testing of developers) before putting the product in front of the user. Unless they are using the user as tester, which seems popular with tech giants releasing sub standard products for user to find the problems.

This is a responsbilities thing. I get that people here think devs are piss poor at QA, but when you put the responsability for quality on someone else, you incentivize the dev to throw it over the wall.

Anyways, it's not that there'll never be a QA role on the market, we're playing a numbers game.

[Hobosapien]

This is a responsbilities thing. I get that people here think devs are piss poor at QA, but when you put the responsability for quality on someone else, you incentivize the dev to throw it over the wall.

Anyways, it's not that there'll never be a QA role on the market, we're playing a numbers game.

It depends on the boundaries defined for each role in the process, which is dependent on the company and how they implement the software methodology. Two companies may advertise a similar role but only at interview will the applicant discover the true scope of the role and the expectations of the client/employer, unless the job spec was very detailed.

So just be confident in your abilities and skills and apply for anything that looks a reasonable fit. Worse case it turns out you don't hear back or transpires at interview you aren't a good fit. Onto the next opportunity. It is a numbers game.

[northernladuk]

One thing to bear in mind here. Contracting is not about getting one contract. It's about making a career spanning many years getting (as close as possible) end to end gigs.

If it's taking so long to get the first gig what is going to happen when it comes to trying to get the second and the third? Any reasonable gap between these including what the OP hasn't earned this year so far could mean contracting is going to leave them a lot worse off vs permie and having to deal with the mental fall out of it.

[simes]

Is it not reasonable to assume that once your CV starts Looking more like that of a seasoned contractor, the ease with which one attains subsequent contract goes up?

Again, from personal experience, that was certainly my case back in 2000 to 2002. Admittedly a period that suffered from crashes in both the dotcom and the airline industries, both of which I had on the CV. That aside, and since then, it has been ever easier.

[Neikon]

Kind of on the same note as northernladuk, getting you second contract will be harder that getting the first one. My advice is get a permanent role and from there try to secure that first role.