Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "manual testing"
-
>22 year old college student
>Apply for a QA internship
>Interview goes well,they see I have plenty of experience and doubt it's real
>Hard questions are thrown
>Answer them and they admit the position is for manual testing
I honestly don't care I need the money, plus manual testing doesn't usually strain me.
>A week goes by
>A month goes by
>Call them
>...Sorry we were looking for someone with less technical and dev experience.
My fucking face when I don't have a title, still overqualified, fighting with WordPress devs on freelancer.14 -
Welcome back to practiseSafeHex's new life as a manager.
Episode 2: Why automate when you can spend all day doing it by hand
This is a particularly special episode for me, as these problems are taking up so much of my time with non-sensical bullshit, that i'm delayed with everything else. Some badly require tooling or new products. Some are just unnecessary processes or annoyances that should not need to be handled by another human. So lets jump right in, in no particular order:
- Jira ... nuff said? not quite because somehow some blue moon, planets aligning, act of god style set of circumstances lined up to allow this team to somehow make Jira worse. On one hand we have a gigantic Jira project containing 7 separate sub teams, a million different labels / epics and 4.2 million possible assignees, all making sure the loading page takes as long as possible to open. But the new country we've added support for in the app gets a separate project. So we have product, backend, mobile, design, management etc on one, and mobile-country2 on another. This delightfully means a lot of duplication and copy pasting from one to the other, for literally no reason what so ever.
- Everything on Jira is found through a label. Every time something happens, a new one is created. So I need to check for "iOS", "Android", "iOS-country2", "Android-country2", "mobile-<feature>", "mobile-<feature>-issues", "mobile-<feature>-prod-issues", "mobile-<feature>-existing-issues" and "<project>-July31" ... why July31? Because some fucking moron decided to do a round of testing, and tag all the issues with the current date (despite the fact Jira does that anyway), which somehow still gets used from time to time because nobody pays attention to what they are doing. This means creating and modifying filters on a daily basis ... after spending time trying to figure out what its not in the first one.
- One of my favourite morning rituals I like to call "Jira dumpster diving". This involves me removing all the filters and reading all the tickets. Why would I do such a thing? oh remember the 9000 labels I mentioned earlier? right well its very likely that they actually won't use any of them ... or the wrong ones ... or assign to the wrong person, so I have to go find them and fix them. If I don't, i'll get yelled at, because clearly it's my fault.
- Moving on from Jira. As some of you might have seen in your companies, if you use things like TestFlight, HockeyApp, AppCenter, BuddyBuild etc. that when you release a new app version for testing, each version comes with an automated change-log, listing ticket numbers addressed ...... yeah we don't do that. No we use this shitty service, which is effectively an FTP server and a webpage, that only allows you to host the new versions. Sending out those emails is all manual ... distribution groups?? ... whats that?
- Moving back to Jira. Can't even automate the changelog with a script, because I can't even make sense of the tickets, in order to translate that to a script.
- Moving on from Jira. Me and one of the remote testers play this great game I like to call "tag team ticketing". It's so much fun. Right heres how to play, you'll need a QA and a PM.
*QA creates a ticket, and puts nothing of any use inside it, and assigns to the PM.
*PM fires it back asking for clarification.
*QA adds in what he feels is clarification (hes wrong) and assigns it back to the PM.
*PM sends detailed instructions, with examples as to what is needed and assigns it back.
*QA adds 1 of the 3 things required and assigns it back.
*PM assigns it back saying the one thing added is from the wrong day, and reminds him about the other 2 items.
*QA adds some random piece of unrelated info to the ticket instead, forgetting about the 3 things and assigns it back.
and you just continue doing this for the whole dev / release cycle hahaha. Oh you guys have no idea how much fun it is, seriously give it a go, you'll thank me later ... or kill yourselves, each to their own.
- Moving back to Jira. I decided to take an action of creating a new project for my team (the mobile team) and set it up the way we want and just ignore everything going on around us. Use proper automation, and a kanban board. Maybe only give product a slack bot interface that won't allow them to create a ticket without what we need etc. Spent 25 minutes looking for the "create new project" button before finding the link which says I need to open a ticket with support and wait ... 5 ... fucking ... long ... painful ... unnecessary ... business days.
... Heres hoping my head continues to not have a bullet hole in it by then.
Id love to talk more, but those filters ain't gonna fix themselves. So we'll have to leave it here for today. Tune in again for another episode soon.
And remember to always practiseSafeHex13 -
Why is the contributing manual of your open source project more thoughtfully cultivated than your code style guide and testing procedure?
Why the fuck do you care about the message in my PR, or even merge vs rebase of commits, when your spaghetti-tomatosource is so richly saturated with critically minced bugmeat?
Why are you standing there, shouting at me about your convoluted rules, in your little brown uniform? Why do I feel like the enemy when I contribute a useful fix, something which makes the code work better?
You know what, fuck all of you, you jilted acetous neckbeards, I will deploy my secret weapon, I will bypass the power you hold over your tiny fascist digital dominions.
If you play it like this, I will summon the nefarious vile side of Open Source. I will usurp your throne. I will stab out your crying eyes, rip out your conceited tongue, impale your lonely heart.
Tremble before me! I wield the almighty, legendary Fork!
The king is dead, long live the king!5 -
I'm fixing a security exploit, and it's a goddamn mountain of fuckups.
First, some idiot (read: the legendary dev himself) decided to use a gem to do some basic fucking searching instead of writing a simple fucking query.
Second, security ... didn't just drop the ball, they shit on it and flushed it down the toilet. The gem in question allows users to search by FUCKING EVERYTHING on EVERY FUCKING TABLE IN THE DB using really nice tools, actually, that let you do fancy things like traverse all the internal associations to find the users table, then list all users whose password reset hashes begin with "a" then "ab" then "abc" ... Want to steal an account? Hell, want to automate stealing all accounts? Only takes a few hundred requests apiece! Oooh, there's CC data, too, and its encryption keys!
Third, the gem does actually allow whitelisting associations, methods, etc. but ... well, the documentation actually recommends against it for whatever fucking reason, and that whitelisting is about as fine-grained as a club. You wanna restrict it to accessing the "name" column, but it needs to access both the "site" and "user" tables? Cool, users can now access site.name AND user.name... which is PII and totally leads to hefty fines. Thanks!
Fourth. If the gem can't access something thanks to the whitelist, it doesn't catch the exception and give you a useful error message or anything, no way. It just throws NoMethodErrors because fuck you. Good luck figuring out what they mean, especially if you have no idea you're even using the fucking thing.
Fifth. Thanks to the follower mentality prevalent in this hellhole, this shit is now used in a lot of places (and all indirectly!) so there's no searching for uses. Once I banhammer everything... well, loads of shit is going to break, and I won't have a fucking clue where because very few of these brainless sheep write decent test coverage (or even fucking write view tests), so I'll be doing tons of manual fucking testing. Oh, and I only have a week to finish everything, because fucking of course.
So, in summary. The stupid and lazy (and legendary!) dev fucked up. The stupid gem's author fucked up, and kept fucking up. The stupid devs followed the first fuckup's lead and repeated his fuck up, and fucked up on their own some more. It's fuckups all the fucking way down.rant security exploit root swears a lot actually root swears oh my stupid fucking people what the fuck fucking stupid fucking people20 -
Hey guys,
this rant will be long again. I'm sorry for any grammar errors or something like that, english isn't my native language. Furthermore I'm actually very sad and not in a good mood.
Why? What happened? Some of you may already know - I'm doing my apprenticeship / education in a smal company.
There I'm learning a lot, I'm developing awesome features directly for the clients, experience of which other in my age (I'm only 19 years old) can only dream.
Working in such a small company is very exhausting, but I love my job, I love programming. I turned my hobby into a profession and I'm very proud of it.
But then there are moments like the last time, when I had to present something for a client - the first presentation was good, the last was a disaster, nothing worked - but I learned from it.
But this time everything is worse than bad - I mean really, really worse than bad.
I've worked the whole week on a cool new feature - I've done everything that it works yesterday, that everything gets done before the deadline of yesterday.
To achieve this I've coded thursday till 10pm ! At home! Friday I tested the whole day everything to ensure that everything is working properly. I fixed several bugs and then at the end of the day everything seems to be working. Even my boss said that it looks good and he thinks that the rollout to all clients will become good and without any issues.
But unfortunately deceived.
Yesterday evening I wrote a long mail to my boss - with a "manual". He was very proud and said that he is confident that everything will work fine. He trusts me completly.
Then, this morning I received a mail from him - nothing works anymore - all clients have issues, everything stays blank - because I've forgotten to ensure that the new feature (a plugin) and its functionality is supported by the device (needs a installation).
First - I was very shoked - but in the same moment I thought - one moment - you've written an if statement, if the plugin is installed - so why the fuck should it broken everything?!
I looked instant to the code via git. This has to be a very bad joke from my boss I thought. But then I saw the fucking bug - I've written:
if(plugin) { // do shit }
but it has to be if(typeof plugin !== 'undefined')
I fucked up everything - due to this fucking mistake. This little piece of shit I've forgotten on one single line fucked up everything. I'm sorry for this mode of expression but I thought - no this can not be true - it must be a bad bad nightmare.
I've tested this so long, every scenario, everything. Worked till the night so it gets finished. No one, no one from my classmates would ever think of working so long. But I did it, because I love my job. I've implemented a check to ensure that the plugin is installed - but implemented it wrong - exactly this line which caused all the errors should prevent exactly this - what an irony of fate.
I've instantly called my boss and apologized for this mistake. The mistake can't be undone. My boss now has to go to all clients to fix it. This will be very expensive...
Oh my goodnes, I just cried.
I'm only working about half a year in this company - they trust me so much - but I'm not perfect - I make mistakes - like everyone else. This time my boss didn't looked over my code, didn't review it, because he trusted me completly - now this happens. I think this destroyed the trust :( I'm so sad.
He only said that we will talk on monday, how we can prevent such things in the feature..
Oh guys, I don't know - I've fucked up everything, we were so overhelmed that everything would work :(
Now I'm the looser who fucked up - because not testing enough - even when I tested it for days, even at home - worked at home - till the night - for free, for nothing - voluntary.
This is the thanks for that.
Thousand good things - but one mistake and you're the little asshole. You - a 19 year old guy, which works since 6 months in a company. A boss which trusts you and don't look over your code. One line which should prevent crashing, crashed everything.
I'm sorry that this rant is so long, I just need to talk to you guys because I'm so sad. Again. This has happend to frequently lately.16 -
On the first day of Christmas, the bossman gave to me: The fact that my new computer purchase order needs to be OKed by the CEO and I need to continue working on a 2014 Mac Mini (i5-4260U, 8 Gig RAM, GPU shot by an ESD on the case long ago) for the next year.
On the second day of Christmas, my family gave to me... a good reason to get shitfaced
On the third day of Christmas, getting shitfaced gave to me: A hangover and some urgent plastic welding job that had to be done with a soldering iron. FML, I've had a headache before breathing in pure hydro-cyano-whatthefuckyougetwhenyoumeltplastics
On the fourth day of Christmas, my team gave to me: A legacy, age-old Rails 2 project that was written by an intern and never reviewed, went to prod in 2014 and can't be changed anymore, but needs to be changed after the fact that it has zero test coverage and needs 100 % now to prevent issues and costly manual testing.
On the fifth day of Christmas, devrant gave to me: The Idea that making fun of Christmas songs to get over the sheer amount of dicks that working over the twelve days of Christmas sucks.
To be continued...2 -
(Best read while listening to AEnima by Tool, loudly)
Dear Current Workplace,
Fuck you, for the reasons enumerated below.
Fuck your enterprise grey blue offices, the stifling warm air of a hundreds of bodies and sub par "development laptops".
Fuck your shitty carbonated water machines which were a cost saving measure over decent drinkable water.
Fuck your fake "flexi time", "you can do home office whenever you want" bullshit. You're still inviting me to mandatory meetings at 09:00 regularly.
Fuck your shitty, in house, third part IT provider sister company. They're the worst of all worlds. If it was in company, we'd get to give out to them, if it was an external company we'd fire them. And yes, when I quit I will quote the dumpster fire that is our corporate VPN as a major factor.
Fuck your cheery, bland, enterprise communication. Words coming under the corporate letterhead seem to lose all association with meaning. Agile, communication, open are things you write and profess to respect, but it seems your totally lack understanding of their meaning.
Fuck your client driven development. Sometime you actually have to fix the foundations before you can actually add new features. And fuck you management who keep on asking "why are there so many bugs and why is it always taking longer to deliver new releases". Because of you, you fucknuts, Because you can't say "NO" to the customer. Because you never listen to your own experienced developers.
Fuck your bullshit "code quality is important to us" line. If it's so important, then let us fix the heap of shit you're selling so that it works like a quasi functional program.
Fuck you development environment which has 250 projects in a single VS solution. Which takes 5mins plus to compile on a quad core i7 with 32 gb of ram.
Fuck this bullshit ball of mud "architecture". I spend most of my time trying to figure out where the logic should go and the rest of the time writing converters between different components. All because 7 years ago some idiot "architect" made a decision that they didn't have to live with.
Actually, fuck that guy in particular. Yeah, that guy who was the responsible architect for the project for 4 years and not once opened the solution to look a the code.
Fuck the manual testing of every business process. Manual setup of the entities takes 10mins plus and then when you run, boom either no message or some bullshit error code.
Fuck the antiquated technology choices which cause loads of bugs and slow down development. Fuck you for forcing me to do manual tests of another developers code at 20:00 on a Friday night because we can't get our act together to do this automatically.
Fuck you for making sure it's very clear I'm never going to be anything but a code monkey in this structure. Managers are brought in from outside.
Fuck you for being surprised that it's hard to hire competent developers in this second rate, overpriced town. It's hard to hire anywhere but this bland shithole would have anyone with half a clue running away at top speed.
Fuck you for valuing long hours and loyalty over actual performance. That one guy who everyone hated and was totally incompetent couldn't even get himself fired. He had to quit.
Fuck you for your mediocrity.
Fuck you for being the only employer for my skill-set in the region; paying just well enough that changing jobs locally doesn't make sense, but badly enough that it's difficult to move.
Fuck you for being the stable "safe" option so that any move is "risky".
Fuck your mediocrity.
Fuck you for being something I think about when I'm not at work. Not only is it shit from 9 to 5 you manage to suck the joy out of everything else in my life as well?
Fuck you for making me feel like a worse developer every day I work here. Fuck you for making every day feel like a personal and professional failure. Fuck you for making me seriously leave a career I love for something, anything else.
Fuck you for making the most I can hope for when I get up in the morning is to just make it until the night.6 -
➡️You Are Not A Software Developer⬅️
When I became a developer, I thought that my job is to write software. When my customer had a problem, I was ready to write software that solves that problem. I was taught to write software.
But what customers need is not software. They need a solution to their problem. Your job is to find the most cost-effective solution, what software often is not.
According to the universal law of software development, more code leads to more bugs:
e = mc²
Or
errors = (more code)²
The number of bugs grows with the amount of code. You have to prioritize, reproduce and fix bugs.
The more code you write, the more your team and the team after it has to maintain. Even if you split the system into micro services, the complexity remains.
Writing well-tested, clean code takes a lot of time. When you’re writing code, other important work is idle. The work that prevents your company from becoming rich.
A for-profit company wants to make money and reduce expenses. Then the company hires you to solve problems that prevent it from becoming rich. Confused by your job title, you take their money and turn it into expensive software.
But business has nothing to do about software. Even software business is not about software. Business is about making money.
Your job is to understand how the company is making money, help make more money and reduce expenses. Once you know that, you will become the most valuable asset in the company.
Stop viewing yourself as a software developer. You are a money maker.
Think about how to save and make money for your customers.
Find the most annoying problem and fix it:
▶️Is adding a new feature too costly? Solve the problem manually.
▶️Is testing slow? Become a tester.
▶️Is hiring not going well? Speak at a meetup and advertise your company.
▶️Is your team not productive enough? Bring them coffee.
Your job title doesn’t matter. Ego doesn’t matter either.
Titles and roles are distracting us from what matters to our customers – money.💸
You are a money maker. Thinking as a money maker can help choose the next skill for development. For example:
Serverless: pay only for resources you consume, spend less time on capacity planning = 💰
Machine Learning: get rid of manual decision-making = 💰
TDD: shorter feedback cycle, fewer bugs = 💰
Soft Skills: inspire teammates, so they are more productive and happy = 💰
If you don’t know what to learn next — answer a simple question:
What skills can help my company make more money and reduce expenses?
Very unlikely it’s another web framework written in JavaScript.
Article by Eduards Sizovs
Sizovs.net18 -
A discussion about writing tests for frontend applications.
Context: my frontend coworkers don't write tests, at all. Yeah, really. Our testing process is very manual. We test manually when developing. We test manually when reviewing code. After merging, the application is deployed to a staging server and the design team does a QA Sprint. Lots of manual testing and some bugs still crawl by.
So I decided to start pushing my coworkers to start writing tests. One of the reasons I constantly hear them say to not write tests in the frontend is: "It's not worth the time, because design keeps changing, which means we have to take time to fix the tests. Time that we usually don't have."
I've been thinking about this a lot and it seems to me that this is more related to bad tests than to tests in general.
Tests should not break with design changes (small changes at least). They should test funcionality, not how things look. A form should not break if the submit button's style changes, so why should its tests fail? I also think that tests help save time, as they prevent some back and forth because of bugs.
Writing good tests is the hard part. Tests that cover what's really important and aren't frail and break with things that shouldn't break them. What (and how) should we test? And what shouldn't be tested?
Writing them fast is another hard thing. Are you doing it right if they take more time to write than the actual code?
What do you think about this? Do you write tests for your frontend applications? What do you test? How much time do you spend writing tests? What are your testing tools/frameworks?6 -
I have this project I've inherited, yea I seem to do that a lot, but this damn thing, has to run in php5.4, has deprecated functions for php7 everywhere and a lot of them and there's no classes anywhere beyond some libraries.
Everything is procedural with random scripts being injected left right and center.
I kid you not,
$thisThing = true;
If(x==y)
require "path/to/some/script.php";
else
require "path/to/a/slightly/different/script.php";
If($thisThing === false){
// well it was modified in that small block about 10 different times
}
Those injected scripts then accept data from the parent scope so, looking at file X, you need to have open file A,B, E, and M to understand where variables have been initialised and what there current state could potentially be.
Basically this thing was bandaid after bandaid for feature requests with 0 refactoring.
Here I am trying to implement some basic functionality (should only take an hour or so + a bit of manual testing) but no, I'm literally at the point of hitting the delete button on the entire project and starting again.rant why you no work what did i do to deserve this alcohol is your friend commented out blocks everywhere even with git there was no deleted code kill me now where the hell did that thing come from cocaine may help is this v2 file the right one don't do drugs18 -
Our project at work goes live in 3 weeks.
The code base has no automated tests, breaks very often, has never had any level of manual testing
will not be releasing with any form of enforced roles or permissions in our first release now due to no time to enforce, however there is a whole admin api where you can literally change anything in our database including roles.
We also have teams in various countries all working separately on the same solution using microservices with shared nuget packages and they aren't using them properly.
Our pull requests are so big - as much as, 75 file changes - in our fe app that I can't keep up with it and I honestly have no idea if it even works or not due to no automated tests and no time to manually test.
We have no testing team, or qa team of any sort.
Every request into the system has to hit a minimum of 3 different databases via 3 different microservices so 1 request = 4 requests with the load on the servers.
We don't use any file streams so everything is just shoved in the buffer on the server.
Most of the people working on the angular apps cba to learn angular, no one across 2 teams cba to learn git. We use git so they constantly face problems. The guy in charge has 0 experience in angular but makes me do things how he wants architecturally so half the patterns make no sense.
No one looks at the pull requests, they just click approve so they may as well push directly to master.
Unfinished work gets put in for pull request so we don't know if the app is in a release state since aall teams are working independently, but on the same code base.
I sat down and tested the app myself for an hour and found 25 fe only issues, and 5 breaking cross browser issues.
Most of our databases are not normalised. Most of our databases make no sense. 99% of our tables have no indexing since there is no expertise with free time to do it.
No one there understands css properly. Or javascript.
Our. Net core microservices all directly use ef in the controller actions so there is no shared code there.
Our customer facing fe app is not dry because no tests so it was decided it was better this way.
Management has no idea on code state, it seems team lead is lieing to them about things like having any level of tests.
Management hire devs that claim to be experts but then it turns out they have basically no knowledge of what they were hired to do, even don't know what json is or the framework or language they are hired for, but we just leave them to get on with it and again make prs too big to review.
Honestly I have no hope that this will go well now but I am morbidly curious to watch. I've never seen anything like the train wreck that we are about to get experience.5 -
Fuck the managers !! Fucking Fuck Fuck !!!
I am in manual testing for 3 years. Wanted to move in to automation since 2016 January !
They kept delaying.
While waiting I kept autating stuffs and making utilities to use for everyone.
Recently automated a 5 yr old manual process.
Made an utility that can perform a 5 hours manual activity in 5 mins.
Our automation team had a vacancy.
The managers were asked to nominate names who could fill the spot from the current manual team.
They didn't suggested my name.
I am not bragging but I am the only person in the team who nows Selenium , UFT , Java , Python even though being in the manual testers.
The team is going to hire someone from the outside.
I just got to know it all this today.
These bastards should die in hell !!!!
I hate these bastards !!!!6 -
I have to make a big decision about my future as a developer...
(Long rant)
I am currently in an apprenticeship as a dev.
The thing is i was forced to do testautomatization.
I was there for half a year and had a good time.
But now my trainer (the guy who assigned me all the work and showed me all the stuff I learned) has been fired.
And now it sucks... they don't teach me new things anymore and don't give me time to catch up with the new technologies.
(This was different in the past!)
I was forced to do manual testing for the past few week.
Therefor i am working with a friend and his trainer.
One day i was talking to my friend about how things have changed in the testing-team.
His trainer was listening (we did not know) and sayed: If you want i can ask my boss if it is possible that i can teach you as well.
Now the point is i woud love to work with him. I love the work they do!! (Java; don't hate me)
But it will make the testing guys mad and I dont know how HR will react.
I am pretty sure it will reduce my chances of getting a job (at this company) if I change the team...
Should I talk to HR or not? What do you think?
Thanks for reading and sorry for my english bugs.6 -
This week at work I spent 20 hours debugging automated tests to avoid manual testing that would've taken a few hours.5
-
when youre working on a API and every testCase is all green plus manual testing thru Postman extension is all good..
then makes a web app use that API, authorization works as intended but the token is immedially invalid...
just..how..2 -
"Manual testing is often quick and easy and satisfying – you can directly test your application, one can see the results immediately on your screen, and one can interact with the application “for real”, instead of in the sometimes-awkward scripted/mocked mode of unit tests. It’s a very natural instinct.
However, it’s also largely-wasted effort! A manual test only verifies the current state of the code base. As soon as you make a change, you’ve started to invalidate the results. If, however, you take the effort to encode the test in code as an automated test, it continues to be valid indefinitely into the future."
https://blog.nelhage.com/2016/12/... -
Yet another ticket comes in about a feature not working after we push another update. So in my meeting I bring up adding testing would reduce this. Yeah boss just wants me to fix this issue and just do manual tests....fml1
-
Following my first rant, my boss had the brilliant idea of running the old and the new architecture in parallel. I had advised that it won’t be ideal since the same Scala code was ingesting into 2 different Kinesis streams and one was running an old KCL written in Java where as other was consumed by a Firehose delivery stream(eventually we will be ingesting it into Firehose directly). I had told few manual + automated tests on Code as well as from a functionality of the new architecture and a set of tests for checking the integration of the new Producer code with Consumer.
The statement I got from my boss was “This is the test, we test it on production in parallel”. My boss had a brilliant idea to fucking test the new code on the production directly but running them in parallel without accounting for undefined behaviour it might cause in the current production system. I mean my boss should get a Nobel peace prize for shattering our mental peace.
Anywho, we started the deployment today at 5AM in the morning. I had all the aws services deployed. Was just waiting to deploy the new Collector code which we did at 5AM. Immediately after 5 minutes the system went bonkers, there was fire, blood, demons and I was smoking a cigarette with the biggest “I told you so smile” on my face. I’ve just written an email to my boss and have told him calmly that “Listen motherfucker, 90 percent of the software companies aren’t idiots to focus on testing and quality. We need to start spending time on testing and quality else we’ll again be in the same soup after few weeks again”.waiting for his reply1 -
There are days I imagine what my life would be like as a farmer instead of being a developer.
Two major sets of fully manual tests due on one day, after I've been alone in the office for two weeks handling all development, testing and support requests; inbox full of dumb questions that are answered in docs; people at my desk asking for shit that won't get done; and although the other devs are all back, one is "working" from home, one has no permissions to SVN, and the other is still learning how to do anything useful.
To top it all off, I've a meeting in twenty minutes, and I've managed to get coffee on my shirt and in my ear buds in a curious incident involving my headphones getting dunked in my coffee and going towards me at high speed.
Oh, and my wife just called saying the baby is screaming like a banshee at home, so I have that to look forward to.
Ugh...2 -
When the CTO/CEO of your "startup" is always AFK and it takes weeks to get anything approved by them (or even secure a meeting with them) and they have almost-exclusive access to production and the admin account for all third party services.
Want to create a new messaging channel? Too bad! What about a new repository for that cool idea you had, or that new microservice you're expected to build. Expect to be blocked for at least a week.
When they also hold themselves solely responsible for security and operations, they've built their own proprietary framework that handles all the authentication, database models and microservice communications.
Speaking of which, there's more than six microservices per developer!
Oh there's a bug or limitation in the framework? Too bad. It's a black box that nobody else in the company can touch. Good luck with the two week lead time on getting anything changed there. Oh and there's no dedicated issue tracker. Have you heard of email?
When the systems and processes in place were designed for "consistency" and "scalability" in mind you can be certain that everything is consistently broken at scale. Each microservice offers:
1. Anemic & non-idempotent CRUD APIs (Can't believe it's not a Database Table™) because the consumer should do all the work.
2. Race Conditions, because transactions are "not portable" (but not to worry, all the code is written as if it were running single threaded on a single machine).
3. Fault Intolerance, just a single failure in a chain of layered microservice calls will leave the requested operation in a partially applied and corrupted state. Ger ready for manual intervention.
4. Completely Redundant Documentation, our web documentation is automatically generated and is always of the form //[FieldName] of the [ObjectName].
5. Happy Path Support, only the intended use cases and fields work, we added a bunch of others because YouAreGoingToNeedIt™ but it won't work when you do need it. The only record of this happy path is the code itself.
Consider this, you're been building a new microservice, you've carefully followed all the unwritten highly specific technical implementation standards enforced by the CTO/CEO (that your aware of). You've decided to write some unit tests, well um.. didn't you know? There's nothing scalable and consistent about running the system locally! That's not built-in to the framework. So just use curl to test your service whilst it is deployed or connected to the development environment. Then you can open a PR and once it has been approved it will be included in the next full deployment (at least a week later).
Most new 'services' feel like the are about one to five days of writing straightforward code followed by weeks to months of integration hell, testing and blocked dependencies.
When confronted/advised about these issues the response from the CTO/CEO
varies:
(A) "yes but it's an edge case, the cloud is highly available and reliable, our software doesn't crash frequently".
(B) "yes, that's why I'm thinking about adding [idempotency] to the framework to address that when I'm not so busy" two weeks go by...
(C) "yes, but we are still doing better than all of our competitors".
(D) "oh, but you can just [highly specific sequence of undocumented steps, that probably won't work when you try it].
(E) "yes, let's setup a meeting to go through this in more detail" *doesn't show up to the meeting*.
(F) "oh, but our customers are really happy with our level of [Documentation]".
Sometimes it can feel like a bit of a cult, as all of the project managers (and some of the developers) see the CTO/CEO as a sort of 'programming god' because they are never blocked on anything they work on, they're able to bypass all the limitations and obstacles they've placed in front of the 'ordinary' developers.
There's been several instances where the CTO/CEO will suddenly make widespread changes to the codebase (to enforce some 'standard') without having to go through the same review process as everybody else, these changes will usually break something like the automatic build process or something in the dev environment and its up to the developers to pick up the pieces. I think developers find it intimidating to identify issues in the CTO/CEO's code because it's implicitly defined due to their status as the "gold standard".
It's certainly frustrating but I hope this story serves as a bit of a foil to those who wish they had a more technical CTO/CEO in their organisation. Does anybody else have a similar experience or is this situation an absolute one of a kind?2 -
A colleague of mine was assigned to do a manual testing of application. It involved testing application in no-network / offline conditions.
While doing this he disconnected the virtual ethernet of Remote desktop thus crashing the VM forever....
Dear Elon Musk, send him to Mars right away.2 -
Had my first ever final interview as a developer after passing the first ever coding assignment, now can't stop thinking if I should have answered the questions differently.
I was very honest to my answer when they asked "How do you test your application?" As I started building the app with 0 knowledge about software development and know nothing about software testing. So I just told them the truth that I did not do any proper test, I just used a checklist and manual test to test my app and the app that I created for the assignment was the first app that I write a proper test cases and implement an automated test. The same goes to other questions like automated deployment and OOP experience. I just told them the honest truth even though I know that they are not the best practice. Did I just f*cked up the interview??
Arghh can't stop thinking2 -
Critical bug in production? Sorry, can't fix it right now: We've got a build running with 1 hour of build time left, 8 hours of automatic tests, 3 days of manual testing, and a partridge in a pear tree. Your fix can be in the next release.
-
I like the people I work with although they are very shit, I get paid a lot and I mostly enjoy the company but..
Our scrum implementation is incredibly fucked so much so that it is not even close to scrum but our scrum master doesn't know scrum and no one else cares so we do everything fucked.
Our prs are roughly 60 file hangers at a time, we only complete 50% of our work each sprint because the stories are so fucked up, we have no testers at all, team lead insists on creating sql table designs but doesn't understand normalisation so our tables often hold 3 or 4 sets of data types just jammed in.
Our software sits broken for months on end until someone notices (pre release), our architecture is garbage or practically non existent. Our front end apps that only I know the technology have approaches dictated by team lead that has no clue of the language or framework.
Our front end app is now about 50% tech debt because project management is so ineffectual and approaches are constantly changing. For instance we used to use view models for domain transfer objects... Now we use database entities, so there is no commonality between models but the system used to have shared features relying on that..sour roles and permissions are fucked since a role is a page regardless of the pages functionality so there is no ability to toggle features, but even though I know the design is fucked I still had to implement after hours of trying to convince team lead of it. Fast forward a few months and it's a huge cluster fuck to enforce.
We have no automated testing of any sort or manual testing in place.
I know of a few security vulnerabilities I can nuke our databases with but it got ignored.
Pr reviews are obviously a nightmare since they're so big.
I just tried to talk to scrum master again about story creation since any story involving front end ui as an aspect of it is crammed in under one pointed story as sub tasks, essentially throwing away any ability to calculate velocity. Been here a year now and the scrum master doesn't know what I mean by velocity... Her entire job is scrum master.
So anyway I am thinking about leaving because I like being a developer and it is slowly making me give up on doing things to a high standard and I have no chance of improving things, but at the same time the pay is great and I like the people. -
Currently in our 4th cycle of manual regression testing for a release and still finding bugs. Automated tests? What are those? That sounds an awful lot like it would take time to implement. Time that could be spent fixing the bugs and getting the release out the door.
When release dates take priority over quality.... -
I'm an iOS developer and I cringe when I read job specs that require TDD or excessive unit testing. By excessive I mean demanding that unit tests need to written almost everywhere and using line coverage as a measure of success. I have many years of experience developing iOS apps in agencies and startups where I needed to be extremely time efficient while also keeping the code maintainable. And what I've learned is the importance of DRY, YAGNI and KISS over excessive unit testing. Sadly our industry has become obsessed with unit tests. I'm of the opinion that unit tests have their place, but integration and e2e tests have more value and should be prioritised, reserving unit tests for algorithmic code. Pushing for unit tests everywhere in my view is a ginormous waste of time that can't ever be repaid in quality, bug free code. Why? Because leads to making code testable through dependency injection and 'humble object' indirection layers, which increases the LoC and fragments code that would be easier to read over different classes. Add mocks, and together with the tests your LoC and complexity have tripled. 200% code size takes 200% the time to maintain. This time needs to be repaid - all this unit testing needs to save us 200% time in debugging or manual testing, which it doesn't unless you are an absolute rookie who writes the most terrible and buggy code imaginable, but if you're this terrible writing your production code, why should your tests be any better? It seems that especially big corporate shops love unit tests. Maybe they have enough money and resources to pay for all these hours wasted on unit tests. Maybe the developers can point their 10,000 unit tests when something goes wrong and say 'at least we tried'? Or maybe most developers don't know how to think and reason about their code before they type, and unit tests force them to do that?12
-
Being pretty much the only one who has some knowledge of how to code and get my way around tech (even if minimal, I'm too lazy for my own good) in my familiar household - and by extension, my family (Family extends FamiliarHousehold - LoL I'm sorry) - (my brother is on his first grade of a programming course in high school, I'm a 2nd grade uni student aiming to become a game dev) sometimes I wish I knew nothing of it.
Don't get me wrong, I do like working on code (if in Java. C is making me wanna tear my eyes out) but sometimes ignorant family members push me through the edge.
I worked on a business thing my family started this summer and one of the "jobs" was managing everything via a website.
Fair enough, I knew nothing of it when I started but I learn fast and just like that I knew my way around it. The problem came when I had to teach the person who started the project how it worked. This doesn't sound all that bad except he is kinda in the stone age regarding informatics.
He got a computer a few years ago and he pretty much only played poker in it, and he still had one of those old nokias you could throw to a wall and get a hole into it. The computer is like 9y and runs like crap.
To make things worse he bought a new phone, a smartphone, and pestered me to teach him. I swear trying to teach him is like repeating the same thing 1000x and pray he keeps it in his head. Spoiler: he doesn't. ( sanity--; )
So to try and easy my suffering I decided to make a manual for the website (which is outdated by now because the team behind the website did a 180 and some things looks different), but it acted as if I'd done nothing. ( sanity--; )
To top this off he keeps on saying I don't wanna help him. ( sanity--; )
This kept going for the whole damn summer, and meanwhile I had to go back to uni and in the first days I still got like 4-5 calls/day, half of those might about the smallest things because he's so panicky.
Like (both examples happened while I was still there but it kinda goes along those lines sometimes):
- (During the period they changed the website the first time since we're there; they were mostly doing changes back and forth and testing because it had a new layout for a day or 2 before going back; also the site was totally functional, except for a thing or 2)
Him: "They're changing the website, why are they doing that?"
Me: "Because it's their website and they can?"
Him: "WHY DIDN'T THEY LET US KNOW"
Me: "They don't have to, they don't work for you." ( sanity--; )
Or (during the same period; the pages have a menu on the left; one of the submenus has a counter that resets every time the session ends; during that maintenance time they must've "disabled" the function because the number kept growing even after the session ended):
Him: "WHY IS THE NUMBER GROWING?"
Me: "They're working on the code, relax, it's nothing."
Him: "But why." ( sanity--; )
The only quesion he pretty much hasn't asked me yet is why "Is the website's colour this one and not that one?".2 -
- "Two months" training upon hire, with all the other hires too.
- Entire thing takes place in a hotel's larger room meant for small conventions or whatever.
- Brought on as Java developers, told there was Java work for all of us
- By the end of it, there wasn't
- Sit at our company's office for a month doing nothing, waiting for work
- It's summer time, 90F+ heat, and the A/C not only wasn't on most of the time, when it was on it was actually heating the building instead of cooling
- Get on a project, join the client site, takes at least a week to get a laptop, takes a month to get most of the needed accesses
- Was brought on because they needed a SQL Developer, I do not know more than basic syntax which I told them
- Project is 3 months behind already
- Really no development since Offshore handles it (poorly)
- For the first year+ of my time here I am doing nothing but manual quality assurance testing, and no development
It's hard to leave when you aren't learning -
Only when the latest feature is implemented, the last bugfix and the last workaround are found, the last unit test is written, the latest CI/CD pipeline done, the customer guy does manual testing and acceptance tests on the staging server and let's them pass and a few days later it's pushed to production...
You will be reminded (again) that shitty customers do exist! A customer is the least capable person to tell you what the customer actually wants and is also the least trustworthy person to test the features he requested...
Holy fuck come on! Just test that shit on the staging Server! One Look could have already shown you that that's Not what you expected!
I checked the logs after that and yup you guessed correctly... The said endpoints weren't even used on staging, only on production...1 -
!rant
Finally managed to implement a proper E2E testing solution for our app with Protractor and Jasmine. Some basic tests (login and dashboard) are already working.
I'm just so happy to automate everything, going to cut down our manual testing time from 2h to about 20 to 30min if I'm estimating this correctly.
That's all. Just wanted to say I'm very happy with the results 😊5 -
My current task is the one I abhor most - manual testing. Lots and lots of manual testing to find a performance bug, which may or may not exist. Am I able to take a couple of days to write a tool to automate this task? No, no I'm not. I must report my findings daily.
-
Manual tests (the only way of testing within my team) fails one after the other.
The fault was a manual misconfiguration.
Why the fuck in 15 years since he got this job that test manager hasn't improved this?3 -
Upgrading my tech skills.. Once again I feel my personal my personal dev environment and told are much more up-to-date than what I use at work.... Though the book Kim reading is on TDD and was written 3 years ago.
Maybe I should read another on in cloud services and ML... but don't have any motivation for these topics.
I need TDD for work because now we're emphasizing unit test coverage...
I usually only use manual functional tests to verify the final outputs as either the testing framework is broken (JS) or I don't have time to relearn the frameworks for the particular language...
Anyway got off topic... So questions after:
1. Do you ever feel your technologically always more ahead than what you do at work and essentially you bring skills to the job but you don't learn much out of it?
2. How do you test? I actually got into a bit of a argument/discussion with my colleagues about how to implement unit tests. Apparently there are 2 ways to test? Black box vs WhiteBox. She said she tests only Public methods using mock inputs, dependencies. She read online and seems there is an opinion that should only test public functions and if you can't then your app is designed incorrectly, not separated enough.
For me I test the private functions individually (WhiteBox/Java reflection) because the public one is like generateReport and as a whole is like a Pachinko machine, too many unique paths that would need a test case for.
So thoughts? Yes sorry for turning it into a remake I guess...24 -
So, I’m currently a software tester (please don’t hate me) who is looking to move into development. I’ve been teaching myself programming and have been applying for junior dev jobs.
But it’s been tough, places I’ve been applying for want candidates who have had at least 1 year experience developing in a previous role.
I’ve had an interview for a junior role, but they wanted someone with more experience (and it was my first technical interview so I may have made a few mistakes)
I don’t want to be testing software manually forever (seriously, the manual regression test pack where I work is 1000+ test cases), I find programming more interesting and fun.
What can I do devRant?
Onwards and upwards with the applications. 👍4 -
I loathe manual regression testing. So much so, that today I made a quick bash script to move my mouse every minute to make it look like I'm online and doing stuff while I watch Twitch and YouTube videos.
The worst part is that we have Cypress to automate this and my company puts more value in pushing out features instead of automating all this unnecessary manual testing. Soooo I'm just not gonna participate because there's no way for them to know that I'm *not* testing.1 -
how do I test long scenarios? I have an app with 10 screens to complete. I have a dropdown on the first screen which creates a table row element on the last screen. should I do selenium or unit test or both? selenium will have to click through the whole app and call every API just for 1 assertion. unit test will only check the dropdown has the right options which are subject to change and not really worth testing. I run into this problem every time I want to write a test. i always miss something in my manual testing and introduce defects. what should I do?3
-
So I'm the only tester at my company, and I've had to adapt a lot of my skills to fit in with our in house expectations. So everything was fine when I focused on trying one component (manual and automation).
Slowly over time I've had more components to test with exact same resource of me.
Eventually my automatic breaks as I could no longer maintain that and all the other manual tests and all the other jobs I do ( light level internal it support, jira ticket rangerling, rollbar (error messages) basic investigation).
My boss keeps saying why is x,y,z not tested / missed while I can point to time periods where was focused on v instead so didn't get to others.
I keep wanting to just hit them with a keyboard until they realise 10± devs to one qa in our environment just isn't going to work.
I keep getting promised some dev time to help with qa so I can play catch up but never seems to arrive.
Don't get me wrong I'm not the best I used to be at testing(before joining I was proud of my abilities, maybe all stick and not enough carrot wears you down)
We keep taking on new work flows that make no sense (create a bug ticket, then a task ticket if bug take more than hour to do, then I'm stuck chasing developers to update their task ticket so I cam update the bug ticket (if its a bug then log sodding log time against it).
I've gotten to point now where I'm stopping my suggestions, explaining why something didn't get dome and will see if they can answer their own stupid questions
At what point do you stop ignoring the voices in your head (metaphorically).
Do other people go through this cycle where feel like pushing a boulder up the hill, for them to either push your boulder down the hill, replace it with a bigger boulder, move to a bigger hill, get you to move more rocks at once or all the above.
I know QA has its quite and busy phases but for me it seems to be constantly busy with no respite4