IT/Software career thread: Invert binary trees for dollars.

November. But you were pretty close. Bros I had couches in my hotel room. Couches.... plural.

So a few weeks back I mentioned I joined a new development team where thetesterswere the ones writing unit tests.

Come to find out, they actually aren't unit tests. The testers (namely one guy and a new assistant) are creating automated integration tests -- so the tests involve database access, external XML configuration files, etc. The developers themselves don't write unit tests AT ALL.

What I'm noticing is how this tester is spending an inordinate amount of time having to write entire frameworks in order to test either existing features or new ones. He's not an expert coder so these tests and their fixtures take forever to create and are a mess to try and read.

So I'm sitting here wondering, is this how integration testing is typically performed? What we're doing can't possibly be an efficient use of resources -- essentially having to write entire mini-applications to test the main application's functionality. Strange things are afoot at the Circle-K.

Hm so they don't have any unit coverage just integration coverage?

Tenks_sl said:

Hm so they don't have any unit coverage just integration coverage?

Click to expand...

Correct.

ShakyJake_sl said:

So a few weeks back I mentioned I joined a new development team where thetesterswere the ones writing unit tests.

Come to find out, they actually aren't unit tests. The testers (namely one guy and a new assistant) are creating automated integration tests -- so the tests involve database access, external XML configuration files, etc. The developers themselves don't write unit tests AT ALL.

What I'm noticing is how this tester is spending an inordinate amount of time having to write entire frameworks in order to test either existing features or new ones. He's not an expert coder so these tests and their fixtures take forever to create and are a mess to try and read.

So I'm sitting here wondering, is this how integration testing is typically performed? What we're doing can't possibly be an efficient use of resources -- essentially having to write entire mini-applications to test the main application's functionality. Strange things are afoot at the Circle-K.

Click to expand...

This is common and is a valid way to test products. It is expensive and not waste of time. The biggest mistake many companies are performing now is attempting to convert Manual testers into Automated testers. Manual testing is a subset of the skills an Automated Tester should have. Automated testers should be more competent then a developer working on the same project and should be compensated accordingly. It should be expected that the automated engineer could fill the role of a developer on the same project.

I say this as a Senior Engineer on a Quality Engineering team whose background is a mix of Quality and Dev.

Anyhow,
Back when I actually wrote code... sigh (actually built the codebase locally for the first time in 6 months yesterday!!!!!!)... we had the following

Unit Tests: Written by dev, what you expect.
Integration Tests: Written by dev and qe. Usually simple calls to an API which then validate the expected action is performed within the product. (EX: POST X and then GET X and validate the output. Additionally, the underlying data store could be checked) Example: Vinen calls API to post shit to a known thread and then gets the content of the shitpost.
UI Tests: Expensive and almost useless. Recommended to only have for one end-to-end use case which covers the most common workflow of the product. Example use case: Vinen opens chrome, navigates to rerolled.org, logs in, locates a thread and shitposts and then logs out
End-to-End API Tests: API calls strung together with validation at each step in order to perform a use case. Example Use case: Vinen shitposts a thread through API and then Noodle bans him for shiposting through API. Vinen attempts to shitpost again and gets HTTP 403 Forbidden.

It makes regression testing new features infinitely less time consuming. It's a good practice indeed and every QA department should employ it

You're right, it's very rare to find a company who invests in QA which is rather annoying as a developer.

Yeah I'm not questioning the value of automated testing at all. In fact, up until a couple years ago, I don't think they were doing any sort of testing other than manual. The problem I'm seeing is that the integration test code is a mess, hard to read and understand exactlywhatis being tested (even the method names aren't exactly clear). Asserts are splattered all through a method that can be dozens of lines long.

I tried implementing an instrumentation test in one of my projects and shit just wouldn't work. The testing, not the code. Spent half a day trying to get it working and finally decided to move on and do it as I had been doing (implement, build, push, test, repeat). Which works in my environment.

ShakyJake_sl said:

Yeah I'm not questioning the value of automated testing at all. In fact, up until a couple years ago, I don't think they were doing any sort of testing other than manual. The problem I'm seeing is that the integration test code is a mess, hard to read and understand exactlywhatis being tested (even the method names aren't exactly clear). Asserts are splattered all through a method that can be dozens of lines long.

Click to expand...

The problem is 99% of QA staff are not developers and are not technically inclined to be developers. So actual developers try to build drag and drop frameworks for QA staff to create their own test cases. That wouldn't be so bad except QA is a very specific exercise and drag and drop frameworks inevitably have to be generic to be usable by non-technical people. It's a paradox.

Khane_sl said:

The problem is 99% of QA staff are not developers and are not technically inclined to be developers. So actual developers try to build drag and drop frameworks for QA staff to create their own test cases. That wouldn't be so bad except QA is a very specific exercise and drag and drop frameworks inevitably have to be generic to be usable by non-technical people. It's a paradox.

Click to expand...

Thankfully this is decreasing. More and more QA Staff is being hired with developer skillsets. Manual testing is dying (thankfully).

Defects that can be caught by manual testing should be caught by developers within their own scrum team.

I wouldn't be shocked to see Manual testers no longer being hired in 10 years.

Vinen_sl said:

Thankfully this is decreasing. More and more QA Staff is being hired with developer skillsets. Manual testing is dying (thankfully).

Defects that can be caught by manual testing should be caught by developers within their own scrum team.

I wouldn't be shocked to see Manual testers no longer being hired in 10 years.

Click to expand...

It might be decreasing in Silicon Valley, but I assure you elsewhere in the country no changes are being made. My "QA" staff consists of one guy who runs one test based on what I told him is supposed to happen and then says "Sweet! Good to go good job man!". Though I guess I can't pretend that's really the norm either. What I do is very niche and I have never really worked on a team. It's me who knows and runs everything in my space from development to deployment to server administration. It really fucking sucks outside of the fact that I don't tolerate bullshit. If I didn't grow up in an old school Italian family on Long Island I'd probably be a coding monkey for Accenture. I have a really... fucking... bad attitude. And it's served me really well in my professional career.

We have a pretty strong qa staff but they barely ever pick anything important up, Usually the product groups are reporting it to us. Kind of pointless to me.

Deathwing_sl said:

I don't disagree with you, but that doesn't seem practical from a supply & demand standpoint. It is extremely rare to find someone who genuinely wants to work in test. Even rarer is to find a company who will treat(as in, training and pay) test engineers that way.

Click to expand...

From my experience it seems many QA people I know and have worked with are just developers that couldn't hack it or have absolutely no development background. So they're really just glorified button pushers.

Tenks_sl said:

From my experience it seems many QA people I know and have worked with are just developers that couldn't hack it or have absolutely no development background. So they're really just glorified button pushers.

Click to expand...

This is true for companies that want warm bodies that produce nothing ("growth stage" VC backed companies). I turned down a job-offer from a company who I saw hire a bunch of under-performing manual testers as Principal Level. I don't care if title is cheap.

Cad_sl said:

The second part of that sentence kinda makes the first part not true...

Click to expand...

Its weird. A strong, very large qa staff. Their suite is massive and pretty thorough but they struggle to pick up anything useful. The customers are the ones doing weird shit and finding bugs.