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 - "user acceptance"
-
At one of my former jobs, I had a four-day-week. I remember once being called on my free Friday by an agitated colleague of mine arguing that I crashed the entire application on the staging environment and I shall fix it that very day.
I refused. It was my free day after all and I had made plans. Yet I told him: OK, I take a look at it in Sunday and see what all the fuzz is all about. Because I honestly could fathom what big issue I could have caused.
On that Sunday, I realized that the feature I implemented worked as expected. And it took me two minutes to realize the problem: It was a minor thing, as it so often is: If the user was not logged in, instead of a user object, null got passed somewhere and boom -- 500 error screen. Some older feature broke due to some of my changes and I never noticed it as while I was developing I was always in a logged in state and I never bothered to test that feature as I assumed it working. Only my boss was not logged in when testing on the stage environment, and so he ran into it.
So what really pushed my buttons was:
It was not a bug. It was a regression.
Why is that distinction important?
My boss tried to guilt me into admitting that I did not deliver quality software. Yet he was the one explicitly forbidding me to write tests for that software. Well, this is what you get then! You pay in the long run by strange bugs, hotfixes, and annoyed developers. I salute you! :/
Yet I did not fix the bug right away. I could have. It would have just taken me just another two minutes again. Yet for once, instead of doing it quickly, I did it right: I, albeit unfamiliar with writing tests, searched for a way to write a test for that case. It came not easy for me as I was not accustomed to writing tests, and the solution I came up with a functional test not that ideal, as it required certain content to be in the database. But in the end, it worked good enough: I had a failing test. And then I made it pass again. That made the whole ordeal worthwhile to me. (Also the realization that that very Sunday, alone in that office, was one of the most productive since a long while really made me reflect my job choice.)
At the following Monday I just entered the office for the stand-up to declare that I fixed the regression and that I won't take responsibility for that crash on the staging environment. If you don't let me write test, don't expect me to test the entire application again and again. I don't want to ensure that the existing software doesn't break. That's what tests are for. Don't try to blame me for not having tests on critical infrastructure. And that's all I did on Monday. I have a policy to not do long hours, and when I do due to an "emergency", I will get my free time back another day. And so I went home that Monday right after the stand-up.
Do I even need to spell it out that I made a requirement for my next job to have a culture that requires testing? I did, and never looked back and I grew a lot as a developer.
I have familiarized myself with both the wonderful world of unit and acceptance testing. And deploying suddenly becomes cheap and easy. Sure, there sometimes are problems. But almost always they are related to infrastructure and not the underlying code base. (And yeah, sometimes you have randomly failing tests, but that's for another rant.)9 -
Fuck my life...
Okay, so I’m working on a web app with a small group... the app is basically a lead generator for new business in another country. We just need contact details cause they’re a fucker to buy.
Step 1: prototype to the investors, working with the ceo to make this thing look shiny AF.
Goes well as fuck.
CEO: “when can we get this out?”
Me: “it’s basically done mate, get your guys to look at it and we can talk about marketing”
Que a shower of 10 or so bellends with senior in their title going into a room and coming out with:
Bellends: “so on this page we want the user to confirm and accept the contract”
Me: “cool, makes some sense, that’s what it’s already doing.”
Bellends: “afterwards we want to show them the price and have them put in their banking details.”
Me: “Wait, you what when?”
Bellends: “Yeah, well Jenny says we should have as few clicks as possible to get to the final stage and have the customer accept.”
Me: “Jenny’s on fucking crack, moving the contract formation phase to after the contract acceptance stage is not an option”
Bellends: “Oh it’s okay, Andy in legal said that would be okay”
Me: “Andy’s a fucking moron, tell him that online contract formation laws were updated 2014/2015 and you can’t do that anymore”
Bellends: “No, andy’s legal, surely he knows”
Bellends: “We want all of this above the fold”
Me: “OH FUCKING SUCK A DICK YOU ABSOLUTE BAND OF FUCKWADS... which one of you, which one hasn’t looked at a website this millennia!?”
Needless to say I ignored all their shit, got the lead generator out and told the CEO those ten people are certifiably fucking useless.
Bonus round; recent, but “it has to be on internal infrastructure”
“Why? It’s a mobile app sending rest calls to a third party saas.”
“It just has to, we have this thing called the private cloud and w”
“Wait... you what son, priv 🤦🏼♂️ private what mate?”
“Private cloud”
“You... you mean a server rack?”
“Nah we spent £2mn on it, it’s brilliant”
“Hahahaha you fucking dick, you blew £2mn on server infra with fuckall to put on it!?”
“No, no it’s the private cloud”
“Fucking idiot, aye son, where’s the fucking bean stalk you prick!?”
“It has to go on internal infr”
“Shut up, that won’t work”9 -
Apparently, part of being a software engineer means knowing how to read minds and do other people's jobs.
While implementing a user story for marketing, we found some associated features that, according to the database, have not been used for years. We tell them this. We do the courtesy of asking, "Hey, is there anything on the site that is utilizing these features? We'd like to clean up the DB."
"We don't know."
Engineering suggests, "Ok, lets turn the feature off, then, and see if anyone complains. It's been years according to the DB."
Marketing gets angry and hostile and says, "That's not the way to do things!"
I don't vocalize, "Well, not knowing how to do your own damned job is not the way to do things."
-
Marketing asks us to integrate a third party feature to the site. We ask, "Ok, what page do you want it on, and what information do you want to collect, and what should it look like?"
"I don't know. You're engineering. You tell us."
We implement it as best we can.
Marketing says, "HEY! This isn't done right! It's missing this and this and this!"
"Did you ask us to implement that? According to the user story, it passes acceptance criteria."
Marketing says, "I thought you would just know that! I didn't know it was a separate thing. Just put it on all the pages, then. You guys really should know the site better."
Engineering gets angry and hostile
-
Marketing says, "We need this removed from the site."
Engineering replies, "We have a GUI for that. Just go to this URL and you can do it yourself."
Marketing replies, "Well, if that's a really complicated thing, can you just run a script against the DB?"
Engineering says, "If we've built a UI for you, we really shouldn't be executing SQL scripts directly against the DB."
Marketing gets angry and hostile.
-
Engineering tries asking nicely.
"Marketing, if you want us to add new stuff to the site, or change stuff, please tell us what it is and where it should go and what the customer experience should be like."
Marketing replies, "We don't know the site that well. We are leaning on you to tell us."
I do not vocalize, all while trying to keep my eyes from bulging out of my head, my face red with rage, "YOU ARE IN CHARGE OF SELLING SHIT ON A WEBSITE THAT YOU KNOW NOTHING ABOUT. YOU ARE ASKING FOR CHANGES TO SOMETHING YOU DON'T EVEN UNDERSTAND. WHAT IS WRONG WITH THIS PICTURE?"
Engineering is angry and hostile.3 -
Hi everyone, long time no see.
Today I want to tell you a story about Linux, and its acceptance on the desktop.
Long ago I found myself a girlfriend, a wonderful woman who is an engineer too but who couldn't be further from CS. For those in the know, she absolutely despises architects. She doesn't know the size units of computers, i.e. the multiples of the byte. Breaks cables on the regular, and so on. For all intents and purposes, she's a user. She has written some code for a college project before, but she is by no means a developer.
She has seen me using Linux quite passionately for the last year or so, and a few weeks ago she got so fed up with how Windows refused to work on both her computers (on one of them literally failing to run exe's, go figure), that she allowed me to reinstall both systems, with one of them being dualbooted Windows 10 + Linux.
The computer that runs Linux is not one she uses very often, but for gaming (The Sims) it's her platform to go. On it I installed Debian KDE, for the following reasons:
- It had to be stable as I didn't want another box to maintain.
- It had to be pretty OOTB, as first impressions are crucial.
- It had to be easy to use, given her skill level.
- It had to have a GUI abstraction to apt, the KDE team built Discover which looks gorgeous.
She had the following things to say about Linux, when she went to download The Sims from a torrent (I installed qBittorrent for her iirc).
"Linux is better, there's no need to download anything"
"Still figuring things out, but I'm liking it"
"I'm scared of using Windows again, it's so laggy"
"Linux works fine, I'm becoming a Linux user"
Which you can imagine, it filled me with pride. We've done it boys. We've built a superior system that even regular users can use, if the system is set up to be user-friendly.
There are a few gripes I still have, and pitfalls I want to address. There's still too many options, users can drown in the sheer amount of distro's to choose from. For us that's extremely important but they need to have a guide there. However, don't do remote administration for them! That's even worse than Microsoft's tracking! Whenever you install Linux on someone else's computer, don't be all about efficiency, they are coming from Windows and just want it to be easy to use. I use Mate myself, but it is not the thing I would recommend to others. In other words, put your own preferences aside in favor of objective usability. You're trying to sell people on a product, not to impose your own point of view. Dualboot with Windows is fine, gaming still sucks on Linux for the most part. Lots of people don't have their games on Steam. CAD software and such is still nonexistent (OpenSCAD is very interesting but don't tell me it's user-friendly). People are familiar with Windows. If you were to be swimming for the first time in the deep water, would you go without aids? I don't think so.
So, Linux can be shown and be actually usable by regular people. Just pitch it in the right way.11 -
Dear Client,
You said it was of paramount importance that this software work flawlessly. I've worked hard to make it so, even when your indecision and lack of attention to detail indicate you don't care as much as you say and have made the project late.
Yesterday when I handed you a step-by-step user acceptance test plan, you delegated it to someone not as familiar with your specific requirements. You said you don't have time for such things.
I will remind you of those words when the project launches and you find something you dislike.
Sincerely,
Me -
Holy crap, I can't take it anymore.
I know that user acceptance testing is supposed to be done by the end user but it's as if they entirely skipped UNIT TESTING and QUALITY ENGINEERING.
Does their API work? Yes. It does.
Are their endpoints working? Sort of... why are query parameters required again?
Is it good overall? No, there are CORNER CASES ALL OVER THE PLACE (are they even still corner cases at this point?). It feels like it was made by amateurs!
Why am I doing quality testing on their services??? holy crap, they should pay ME for doing this1 -
I absolutely hate software to the point where I started converting from sysadmin to becoming more like a dev. That way I could just write my own implementations at will. Easier said than done, that's for sure. And it goes both ways.
I think that in order to be a good dev, you need these skills the most:
- Problem solving skills
- Creativity, you're making stuff
- Logical reasoning
- Connecting the dots
- Reading complex documentation
- Breaking down said documentation
- A strong desire to create order and patterns
- ...
If you don't have the above, you may still be able to become a dev.. but it would be harder for sure, and in some cases acceptance will be lower (seriously, learn to Google!)
One thing I don't think you need in development is mathematics. Sure there's a correlation between it and logic reasoning, but you're not solving big mathematical monsters here. At most you'd probably be dealing with arrays and loops (well.. program logic).
Also, written and spoken English! The language of the internet must be known. If it's not your first language, learn it. All the good (and crucial) documentation out there is in English after all.
One final thing would be security in my opinion, since you're releasing your application to the internet and may even run certain services, and deal with a lot of user data. Making those things secure takes some effort and knowledge on security, but it's so worth it. At the most basic level, it requires a certain mindset: "how would I break this thing I just made?"4 -
I really hate it when I work on a user story consisting only of a cryptic title: "Implement feature X".
Esp. when I missed planning during a holiday and can only wonder who in their right mind would have given it 3 points.
Why thank you.
Sometimes, just pulling the acceptance criteria out of somebody's nose takes days. It doesn't get better once I realize that not all external dependencies have been properly resolved. It's worse if there are other departments involved, as then you get into politics.
Me: "We are dependent on team X to deliver Y before we should have even planned this ticket. I'm amazed that our team was even able to estimate this ticket as I would have only raised a question mark during estimation meeting. We could have thrown dices during estimation as the number would have been as meaningful and I'd have more time to actually figure out what we should be doing."
Dev lead / PO: "I understand. But let's just do <crazy workaround that will be live until hell freezes over> temporarily."
It's borderline insane how much a chaotic work flow is branded as agile. Let's call it scrum but let's get rid of all the meaningful artefacts that make it scrum.1 -
Today is day two of User Acceptance Testing for one of our biggest and most complicated developments.
Today is also the day the requirements were agreed.
Somebody, somewhere is taking the piss. -
One day, the Director of Web Ops (marketing role) submitted a ticket to update the list of product categories on the website’s navigation. Sounds like a simple ticket right? Just some html edits. Nope. Every day for three days, she changes her mind and adds new changes. What should have taken me 10 minutes stretched out to three days. She held up code review of my ticket because she kept making changes.
She had plenty of time to sort out what she wanted. That ticket had been sitting in the To Do pile for two days before I touched it.
She was being an asshole because she knew she could get away with it and I had no recourse: my direct manager was on vacation, the entire dev team was going to be laid off anyway so no one was going to defend us on “trivial” matters, and we were going to enter code freeze soon so she’d just argue it was critical business changes for our critical revenue season.
I suspect she was also just not good at her job. I never met her in person because she was hired during the 2020 pandemic and we were all working remotely. I did see her make a five minute presentation during an all staff meeting…and she didn’t come off too well. Her voice was trembling during her turn to speak…like she was not confident or not prepared.
She knew she was causing chaos but she put on this act of not knowing. She was definitely trained on our dev team’s practices for tickets and deployments. She knows about code review, beta testing, and user acceptance testing that has to happen before a ticket can be deployed.
It happened to be before Thanksgiving weekend 2020. Our deploy was going to happen on Tuesday instead of Thursday because Thursday was a holiday (no one would be working) and Wednesday was a half day.
Tuesday afternoon at 1pm, she messages me and the dev in charge of deploy about more changes! My time is already occupied because our Product Manager went on vacation and dumped a large amount of user acceptance testing on me. I scream at my computer at that point because I realize I’m in the ninth circle of hell. I tell the other dev in a separate message that Web Ops has been making changes EVERY DAY since I picked up that ticket.
Other dev tells her that we have to check with the C-suite executive for engineering because we’re not allowed to make changes to tickets so close to the deploy. This is actually the policy. He also tries to give Web Ops the benefit of the doubt because we’re not deploying on our usual day. He had to do that to so she didn’t feel bad (and so she doesn’t complain about us not working towards the company’s goals).
Other dev had to do the code changes because I was otherwise occupied with user acceptance testing. If I were him, I’d be pissed that I was distracted from concentrating on the deploy so close to the holiday.
Director of Web Ops was actually capable of even more chaos. I ranted about it before. For that dramatization and if you want to go down the rabbit hole, see: https://devrant.com/rants/4811518/...4 -
Sigh Im getting depressed from going to work whilst a few weeks ago it gave me a bunch of happines.
I think its due that management is approaching a triple deadline (?!?!?!) project in an agile/scrum way (?!?!??!)..
We can not change our data model completely when we have to be in acceptance in 3 weeks and do a demo in a few days..
Yes we can work around that but fuck database design theory and lets ignore all primary keys and foreign keys, great idea
We have to create and prioritise user stories on our own? We have two product owners and a scrum master.
Scrum master offers to deal with organising and creating tickets to organise Infrastructure without having a laptop of the client, so no Service Now access or any other system..
Guess who has to do it in the end..
Many question marks about this project -
Hate it when clients told you a specific requirement but then changes it the last minutes. You can't justify or argue. Can't do nothing about it but only follow. Just a high paid slave.
Example:
Client-verbal: background color of all 5 pages
Me-with email verification: ok. I will bg color of all pages will be red based from our last meeting.
Client email reply: ok
After a few days
Client: I think we have misunderstanding. What I meant was 4 pages red only. The 5th page should be maroon.
Me in my mind: wtf. Of course I can't argue but just agree and follow. The demo is near and he'll just inform the last minute. I will not win this argument.
Also, there are no acceptance criterias in the user story.6 -
Can anyone suggest any websites or resources for a breakdown of how to handle requests for features or handling bugs. Basically, I want some kind of background on best practices for managing the process of receiving a feature request/or bug report from a user to it reaching the dev team, to production/user acceptance testing.5
-
Let me share my sprint with you.
So, we lost a developer this at the start of the sprint because the organisation we work for is total cancer.
Project manager frequently says to us that it's better to under commit than over commit.
Come sprint planning, we commit to exactly what we know we can achieve.
Of course, the PM whinges and says we need to put more in the sprint. So, we say sure, but we can't guarantee we will deliver everything on time.
Fast forward 2 weeks, we complete 90% of what we committed to.
PM is whinging at stand ups, asking us why some user stories are still in 'ready for test'.
We try to explain to the PM that 2 weeks ago we made ourselves very clear that this point 2 weeks later would most likely happen.
PM stops whining.
Tester starts whinging about only having a couple of days to test. Blames developers for not adhering to acceptance criteria.
>User stories aren't actually user stories, they're user essays.
How do you deal with this?3