Reply to: Should I give up on finding first ever contract

[Bluenose]

Hi all,

New here so bare with me. I'm a Software Tester. Long story short I finished permanent role December last year. Decided to try contracting. Set up LTD Company, Business bank account etc and got ready to go in January. I upped CV to the usual places

Since then though I've had very little contact. One phone interview that didn't go well (But I wouldn't have wanted anyway). I get a few calls about Contracts that sound positive but then I never hear anything again. Have I picked the worst time ever to do this with a quiet market

So I'm thinking maybe I give up an go back to Permanent? I'm confused about the whole thing. I do have some savings to fall back on but they won't last forever and are depleting fast!

Thanks for any advice

Every word of the replies from the poster “fool” above is correct. Good luck.

[Hobosapien]

In the context of this thread, automation even if done right doesn't cover all the bases when ensuring complex business rules are met, user interfaces are meeting all requirements, the system is meeting non-functional requirements, and integration is working, so either that level of testing is pushed closer to the user, done by dedicated human testers, done by devs that are really being asked to be testers, or not done at all.

Automation of testing at the higher levels requires good technical business analysis (to ensure the requirements are solid from a stakeholder and dev perspective), flexible software architecture (to aid an agile iterative process of change), developers with domain knowledge (so they interpret requirements accurately), and a company with the resource and motivation to pay for it all.

Even something as simple as whether an email is sent and received, what the content of that email is, and whether the recipient should have received it in the first place, would be much easier for a human to test. So there is a balance between using the tools and keeping things simple, in terms of cost, quality, and sanity of those having to work within the development process.

I'm sure there are sectors and companies closer to some automated testing nirvana using bleeding edge tools and methods, but there are many more even if they are on that path that are either doing it wrong or inadequately, or have an approach that recognises sometimes its quicker and cheaper to get humans to do it.

So the OP is not redundant just yet.

[fool]

I presume those deploys are to an environment where integration testing can take place to make sure all those changes work together properly. i.e. If doing that many deploys a day then likely to be several developers involved and none of them will be doing more than one piece at a time.

Right.

A single integration environment is thinking a bit oldschool, and it's unlikely you'll be able to deploy, test, and clean 10x a day. So you automate environment building and create both infrastructure and app deploy, then run your end2end tests in ephemeral environment.

Based on the suite of tests passing, and the investment that when you come across failure, you write a new test, you merge, and then run it through your static deploy pipeline. You use feature flags to deploy with a feature turned off, then canary it out to a subset of users. You rely on metrics to tell you when you've screwed up.

Things get a bit complicated here, you're going to need to re-run some tests after you've merged in one of the new sets, and tests being slow is going to be your next problem. This a reason some developers prefer microservices or you start to add sophistication into how you run these tests, such as not retesting parts of the codebase that haven't been changed.

Anyhoo, long story short is this requires a higher level of talent and investment than you find in your typical outsourced tech team, and thus unless you specialise in modern transformations or modern dev teams, you probably aren't doing these things as a crusty old contractor.

The 10 deploys a day refers to Flickr and is discussed in the phoenix project. The reality is the tech giants and large funded startups are doing more per day, and if you're competing with them, such as you're a bank and you're worried about Monzo, or you're a shop thats losing to Amazon, then this is what you're competing with.

So this is where a QA test step is vital before putting it in front of users for acceptance, unless the user is accepting each of the deploys as each change is committed, therefore doing the QA role themself.

Otherwise unless doing something to check overall functionality at a higher level than each individual dev is working at you end up with some of the crap user experiences mentioned in this article I read earlier and thought of this thread.

These are end2end tests and BDD. Again, not to say nobody looks at the product, we just don't wait for someone to click all the endpoints before we deploy.

What bugs me the most? World+dog just accepts crap software resilience • The Register

So it is obvious there is a need for manual QA testing. How the company handles that is their business but those that don't rely on end users to know how to test thoroughly are likely to end up with a better product and therefore fewer support issues, if that matters to them enough to pay for it.

Maybe the OP could contact some of the companies (and countless others doing a similar half assed approach) as a QA consultant to ensure their product is fit for purpose.

I disagree that it's "obvious". Obviously we need testing, I just don't think it's the automation causing problems. Underfunding, cutting corners, and tulip management lead development probably has more to answer for. When you talk about quality, you start talking about Toyota, engineering cultures and automation.

I've worked for banks via consultancies. They cause most of the problems themselves because they're short sighted, and the first thing they cut is tests. Then they're suprised when it doesn't work.

I've worked for retail with slow deploys, manual testing, and they still go down on black friday, whilst amazon rakes it in.

These aren't problems with automation. They're problems with management who think they can sit a semi competent engineer in a room, demand they produce a series of tests in a single sprint and the problems dealt with. You're either all in on the automation or you ain't, and I totally get why people are suspect about it, the quality of the average contractor shop is abysmal and the project based funding doesn't really fit with doing automated testing or security well.

A lot of this is discussed in the SRE book. Google - Site Reliability Engineering

P.S. The actual failure you've linked to is suspected to be because of management interfering with engineering because they didn't want to recertify parts of the product. It's a cute comparision, but it doesn't really compare to an infrastructure that becomes insecure because it hasn't been patched in years. It would be more like the plane operators not doing maintenance for 9 months.

We should probably argue about modern dev elsewhere.

[Hobosapien]

I don't think my opinion on this means that I don't understand test, but hows a manual QA going to keep up with 10 deploys a day?

I presume those deploys are to an environment where integration testing can take place to make sure all those changes work together properly. i.e. If doing that many deploys a day then likely to be several developers involved and none of them will be doing more than one piece at a time.

So this is where a QA test step is vital before putting it in front of users for acceptance, unless the user is accepting each of the deploys as each change is committed, therefore doing the QA role themself.

Otherwise unless doing something to check overall functionality at a higher level than each individual dev is working at you end up with some of the crap user experiences mentioned in this article I read earlier and thought of this thread.

What bugs me the most? World+dog just accepts crap software resilience • The Register

So it is obvious there is a need for manual QA testing. How the company handles that is their business but those that don't rely on end users to know how to test thoroughly are likely to end up with a better product and therefore fewer support issues, if that matters to them enough to pay for it.

Maybe the OP could contact some of the companies (and countless others doing a similar half assed approach) as a QA consultant to ensure their product is fit for purpose.

[fool]

Ah this bollocks again. Developers are tulip at testing. Ive never met a developer yet who thinks there are bug in their code yet miss even the obvious. So no, you dont want developers writing tests. Anyone who does should only get them to write positive test scenarios not negative ones.

As regards testing. the number of roles has dried up. Many clients have moved over to automation. Frankly, unless you can write automation tests, anyone is going to find work very hard to come by. Of course there will always be exceptions.

Let me guess, you work for large bureaucratic orgs where everything is outsourced to donkies? I've did the same. The winds are blowing the other way now. The same consultants that sold us on outsourcing are now selling insourcing, which is fun, but also means as orgs get better at doing this, they hire better devs. You don't trust the guy who wrote the code to write a good test? Pair on the problem. It's not rocket science.

@fool You appear to not understand testing or the role of testing in delivering products of good quality.

I know plenty of automation QAs (or SDET) on similar salaries and day rates to mid/senior level devs.

@OP There’s lots of good advice in this thread. There are a lot of really bad testers out there. It’s not too difficult to shine.

I could be wrong, but I doubt that I am.

For the most part "automated tester" roles exist because it's easier for Accenture to sell you two people if they give them different job roles, despite the fact that unless they're both decent devs, they're probably creating brittle annoying tests.

I don't think my opinion on this means that I don't understand test, but hows a manual QA going to keep up with 10 deploys a day?

Not just trying to be a tulip though, the guys struggling on the first role and probably wants to spend 5-10 years doing this. NLUK made the point better than I am doing, skate to where the puck is going.

[MrButton]

@fool You appear to not understand testing or the role of testing in delivering products of good quality.

I know plenty of automation QAs (or SDET) on similar salaries and day rates to mid/senior level devs.

@OP There’s lots of good advice in this thread. There are a lot of really bad testers out there. It’s not too difficult to shine.

[SussexSeagull]

I have been manual testing for 20 years, the last 10 contracting. Only times I struggled to find a contract were post crash (where most were struggling) and after the Referendum when industry seemed to lose it's nerve striating any projects.

That said having a long CV in a variety of sectors can, contrary to some who look down on 'general manual testers', be an advantage when they are looking for someone to pick something up quickly and knows how things work. I am not sure how I would cope without the experience bit now.

As for manual testing disappearing due to automation, that was being said when i started out in the late 90s. Also if developers are capable of fully testing something, how come I still find lot's go problems when I test something?

[washed up contractor]

It's easy to find automated QAs. They're called developers and they're the ones who should be writing your tests.

The problem is, the second you find an automated tester worth their salt, you're looking at someone who is at the very least a junior dev who'll enjoy being a dev and get paid more than being a tester.

However, it's much easier to sell Big co lots of different resources who can break repos with bad tests than it is to sell them more developers, so the struggle persists.

Obviously, what matters to people here is whether or not you can get decent a day rate from it, but the market will always be weird because it largely sits in an area of doing it wrong. This weirdly may make it a good niche though, because smart companies usually don't need contractors on the regular.

Ah this bollocks again. Developers are tulip at testing. Ive never met a developer yet who thinks there are bug in their code yet miss even the obvious. So no, you dont want developers writing tests. Anyone who does should only get them to write positive test scenarios not negative ones.

As regards testing. the number of roles has dried up. Many clients have moved over to automation. Frankly, unless you can write automation tests, anyone is going to find work very hard to come by. Of course there will always be exceptions.

[Hobosapien]

If suitable work is thin on the ground, apply for both permie and contract vacancies and see what turns up first.

Even if not that keen on a particular permie vacancy the info gleaned at interview may be useful in determining what skills to improve and where the shortfall lies in not getting the permie job or alternative contracts. If they offer you the job you can always turn it down if other opportunities come along at the same time, or you feel you can survive longer without taking the first job on offer.

[northernladuk]

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.

Possibly but it is only an assumption at best. The only tangibles he has to go on aren't looking great so future gigs and income should be very carefully considered. If this (fairly vague) assumption is does not carry through will he be in a situation where he can't pay his mortgage, lose his house and so on. Some very serious ramifications should a pure assumption not pan out.

If he thinks about it, plans it and is ready for the worst case then happy days.

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

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

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

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

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