3 ms·
Boy oh boy oh boy do I. I was transitioning between teams and needed something to do in the meantime, so I got put on a testing and validation team for an inte
by nameless912 9y ago
Boy oh boy oh boy do I.
I was transitioning between teams and needed something to do in the meantime, so I got put on a testing and validation team for an internal product. I was to collaborate with our overseas IT team and figure out why their tests weren't catching bugs in production.
After two weeks of wrangling, hand wringing, and bad vibes, I finally got them to send me their test automation code and a link to their Jenkins where they were running their tests.
The Jenkins was in a sorry state: disk overflowing with garbage, 10+ releases behind, and not tied into our corporate LDAP (it was using local admin-everything accounts instead). But that didn't hold a candle to the test automation code itself.
It didn't compile.
No seriously, I spent two more weeks just trying to get it to compile on my laptop, and I could not make it work. Mind you, this was a pretty bog-standard setup (Python unittest-based suite, Selenium for frontend testing, and an in-house [but not terribly unusual] integration test library written in lua).
I never once got it to compile, all the while their engineers insisting that I must be doing something wrong because it works fine on their Jenkins server, as evinced by their test reports being generated every night.
Turns out that wasn't true either, though: they had built a series of obfuscations such that the Jenkins job scanned the written tests, marked most of them as passing, and randomly failed the rest. This had been going on for over a year and a half and apparently no one had noticed. They were faking test results and slowing down developers because no one could figure out why tests were failing randomly.
The worst part is, when confronted with the problem, their defense was that they were worried no one was reading their reports, so they did it once a year ago and forgot to turn it off. Problem is that the report generation was fairly sophisticated with quite a few special clauses to handle specific tests which had to "pass" or "fail" in a particular way. So they clearly invested some time into it.
They finally admitted they were in too deep a couple weeks after that initial confrontation, and fired from our team. But because they're the favorite consultancy of another manager at the company, they continue to this day to consult for the company. It's really sad.
- brianwawok 9y agoThat is a new record. I can kinda understand incompetence "ok we hired too many people, some were not very good and we haven't fired them yet"... annoying but it makes sense. But this is outright fraud. This is the literal definition of negative value. Paying someone money to test, then those testers failing "random tests" wasting actual developer time on non-bugs. (With that said, this is very weird an offshore team would own the unit tests for a project.. the developers should own it)
- nameless912 9y agoTrust me, I know. Having someone else write your tests just screams incompetence to me, but this project was like 4 years in at this point. I wasn't going to convince them to change that.