|
All this QA chat means I've come to the right place. Maybe. We'll see! Been working sysadmin jobs for the last ~8 years and I am finally, finally getting out. I took a QA position working with two of my good dev friends (we're also in a band) after a lengthy interview process, mostly due to me not having any QA experience. They're confident in my abilities and I'm confident that I can do the job, so away we go. To that point: Ither posted:A developer shouldn't tell a QA what to test. They should suggest what to test. 
|
#
?
Mar 14, 2019 15:34
|
|
|
|
| # ? May 26, 2024 09:27 |
|
|
The best QA person I've worked with used a variety of scripts to help test various scenarios for each new feature. He would first create a success scenario based on the feature description, as in, "The new feature allows managers to upload documents that are automatically sent to their reports. Documents may be [x,y,z] supported types and < 500 mb." This would be confirmed by whatever dev was developing the feature. Then he would hammer the app with his scripts which tested a huge variation of permissions, mimetypes, and file sizes. Bugs were reported with clear reproduction instructions (because he would repro things from his own instructions, which is huge), and if he wasn't sure if something was a bug or not, he would take screencasts and attach them with his explanation of what he thought was buggy behavior. He was an absolute delight to work with, mainly because his goal was always to have the feature be as good as we could build it. Unfortunately, last I heard he was promoted to feature development. I hate how QA => dev => management seems to be the standard pipeline, when it should be three roles of equal ability and importance.
|
|
#
?
Mar 14, 2019 16:04
|
|
|
Until we start paying individual contributors what most companies tend to pay managers ambitious, talented people have all the incentives to stop contributing technically. Only at extremely engineering-focused and competitive companies like in Big Tech do you see handsomely compensated engineers. In most companies, sales will take over the opex of compensation packages not just because most companies can't really scale without sales but because their compensation is tied much closer to company revenue. This is moreso an American thing than anything else though I'll argue (EMEA and Asia have sales but not to the outrageous degree of American sales worship as a culture). QA persons range a huge gamut between warm bodies that vaguely know what a computer is to full-blown software engineers that just happen to be focused upon discovering issues in software written by feature developers. There's a bit of a triad currently going on with three software engineers that seem to be required nowadays for SaaS products (and may be better off with just pair-programming?): feature / product developer, SDET, and SRE (and maybe with a security engineer or business analyst thrown in the mix). It's a bit telling how buggy features in general are when you need that many more engineers to make it not suck when exposed to reality.
|
|
#
?
Mar 14, 2019 16:24
|
|
|
Ither posted:A developer shouldn't tell a QA what to test. They should suggest what to test. That's nice. How are you posting in our hell dimension from your regular dimension?
|
|
#
?
Mar 15, 2019 02:57
|
|
|
Gildiss posted:That's nice. How are you posting in our hell dimension from your regular dimension? Right? Where do you work that people actually do their jobs competently? (Myself not excluded.)
|
|
#
?
Mar 15, 2019 03:19
|
|
|
Everyone thinks they are good at their job, in reality you are just someone else's incompetent coworker. You'll never know because even the most garbage workers can get accolades and promotions. For tester chat, QA are exactly like developers in that there is a huge diversity of skill levels and general intelligence. You know which ones to trust if you work with them for a bit. In my last place, there was this dude where you can explain extremely basic situations to ten times, in different ways from different people, and he would just give you a blank stare. Then proceed to do nothing and complain to his manager the developers aren't helping. Could honestly barely work a computer. Another one on the same team was literally the best tester I have ever worked with, I would go to explain a ~situation~ to her and she would have already read the bug report, all the linked user stories and preemptively glanced through the tech spec to find original intent and attempted to provide the most minimal reproducible steps. Sometimes even link to the commit in vsts that likely introduced the bug. But she had sort of broken English, so a bunch of people would interpret her as hostile. I would just laugh when she would yell out across the room "Xik, come here! Show you!" 
|
|
#
?
Mar 15, 2019 03:48
|
|
|
I just had some guy tell me that we need to do things fast and not right. If I wanted to do things right then I need a personal project. Luckily everyone else on my team thinks that's insane and are pushing back against this attitude.
|
|
#
?
Mar 15, 2019 15:44
|
|
|
Slimy Hog posted:I just had some guy tell me that we need to do things fast and not right. If I wanted to do things right then I need a personal project. Just put a return at the start of every function and say that you’re doing it as fast as possible.
|
|
#
?
Mar 15, 2019 16:02
|
|
|
Slimy Hog posted:I just had some guy tell me that we need to do things fast and not right. If I wanted to do things right then I need a personal project. Let me guess... when someone mentions documentation, I bet this guy says something like "Read the source, Luke"
|
|
#
?
Mar 15, 2019 16:15
|
|
|
My Rhythmic Crotch posted:Let me guess... when someone mentions documentation, I bet this guy says something like "Read the source, Luke" Worse, it's more like "Oh I wrote that 2 years ago; we should re-write it at some point, just ask me questions if you need anything" Management keeps him around for his knowledge of old lovely systems he wrote and keeps putting him on projects where he can do whatever he wants without oversight. It's infuriating.
|
|
#
?
Mar 15, 2019 16:24
|
|
|
Gildiss posted:That's nice. How are you posting in our hell dimension from your regular dimension? That was the platonic ideal. Only 1 of the 3 QAs I work with even comes close.
|
|
#
?
Mar 15, 2019 16:29
|
|
|
Ither posted:That was the platonic ideal. Only 1 of the 3 QAs I work with even comes close. Well someone has to document that your web application doesn't work if you pull the ethernet cable.
|
|
#
?
Mar 15, 2019 16:29
|
|
|
Awesome feedback, y'all, very thankful for the tips. Sounds like since I have half of an analytical brain and want to actually help my friends make software gooder that I'm a leg up already! 
|
|
#
?
Mar 15, 2019 16:44
|
|
|
Slimy Hog posted:I just had some guy tell me that we need to do things fast and not right. If I wanted to do things right then I need a personal project. I want to be charitable and say that he meant to use the word "perfect." As in, perfect is the enemy of good. Because yeah, sometimes you have to ship something and "good" is where you should stop. But I've met too many people that don't care how poo poo something works if they can tell the customer we delivered something.  Similar: The management of my company has told the devs straight up that they'd rather we spread ourselves so thin that we make almost no progress on a dozen things simultaneously, so they can tell each customer that we're "making progress" on their pet request and have it be the truth. Goddammit, LIE, it's not like we're providing documented evidence! Or better yet, just tell the customer that we won't be able to get to their poo poo for a while because we don't have the staff for it. Whatever lets us focus enough to get anything out the door.
|
|
#
?
Mar 15, 2019 18:42
|
|
|
Che Delilas posted:Similar: The management of my company has told the devs straight up that they'd rather we spread ourselves so thin that we make almost no progress on a dozen things simultaneously, so they can tell each customer that we're "making progress" on their pet request and have it be the truth. Goddammit, LIE, it's not like we're providing documented evidence! Or better yet, just tell the customer that we won't be able to get to their poo poo for a while because we don't have the staff for it. Whatever lets us focus enough to get anything out the door. It sounds like you're not managing your managers properly. Have you tried agile development?
|
|
#
?
Mar 15, 2019 19:31
|
|
|
Bruegels Fuckbooks posted:It sounds like you're not managing your managers properly. Have you tried agile development? Most of our customers aren't willing to be part of the feedback loop, so that's a big fat nope.
|
|
#
?
Mar 15, 2019 20:30
|
|
|
How do y'all feel about take-home coding assignments as being part of the interview process? My company is re-thinking how we do interviewing. We've done a take-home for years. I'm not a fan of it, and at a minimum our take-home stuff needs to be refreshed significantly. I'd rather not require any time from someone outside of standard work hours. I do appreciate the value in seeing actual design and code, but I feel like it is a bit of an ask and biased against those with busy out-of-work lives, like parents. I think I'd prefer than we allocate some time when the candidate is in-office for some coding. Others on the team think it is preferable to do a take-home assignment because the person gets to code in their preferred environment without any time constraints and not under particular pressure, which I understand.
|
|
#
?
Mar 15, 2019 21:35
|
|
|
Che Delilas posted:Similar: The management of my company has told the devs straight up that they'd rather we spread ourselves so thin that we make almost no progress on a dozen things simultaneously, so they can tell each customer that we're "making progress" on their pet request and have it be the truth. Goddammit, LIE, it's not like we're providing documented evidence! Or better yet, just tell the customer that we won't be able to get to their poo poo for a while because we don't have the staff for it. Whatever lets us focus enough to get anything out the door. Some years back I remember telling my manager that I was so overstretched with people directly demanding stuff that I was just systematically rotating between tasks in 15-minute chunks--which included the time to context switch, so it was more like doing 5-10 minutes of any substantial work. He just said, "Good."
|
|
#
?
Mar 15, 2019 21:49
|
|
|
venutolo posted:How do y'all feel about take-home coding assignments as being part of the interview process? I hate it and push back against it as much as possible. Why don't you also try doing quoted string searches for part of your ask and see how many solutions are on the internet. You can always use that as ammo against it. I've never seen a place that had one that didn't have at least one solution published somewhere.
|
|
#
?
Mar 15, 2019 21:51
|
|
|
Hughlander posted:I've never seen a place that had one that didn't have at least one solution published somewhere. For what it is worth, our current one asks the candidate to design an API for a system that is a simplified version of some of our stuff. It isn't a series of FizzBuzz type programming tasks.
|
|
#
?
Mar 15, 2019 21:56
|
|
|
One way to make it slightly more fair is to set and communicate a time limit as well as a deadline. As in, "We expect this to take you no more than 4 total hours. Please return it to us in a week or less." This way, busy people can find the time, and you can hopefully direct the tryhards into returning it sooner rather than working on it longer. Another thing: your team devs should be able to finish the task in far less than the time limit - preferably half of it. Don't estimate, actually try it yourselves and time it. Estimating time is notoriously impossible, and if you don't try it, you can't know what strange problems your candidates might encounter.
|
|
#
?
Mar 15, 2019 21:56
|
|
|
Take-home exercises are better than whiteboard exercises. However, you should be aware of what kind of applicants you're screening out by using it. Because they're a large time commitment and they presume possession of a working dev environment, you're more likely to exclude people who don't match the no-life affluent tech bro archetype. If you know why you shouldn't demand applicants have projects outside of work, you understand the problem with take-home tests. If you want to see how a candidate works, put them to work. Actually have them spend a day working in your office alongside people who already do the job they're applying for. And, ideally, pay them for it. Actually evaluating the quality of a tech worker's work is expensive. Trying to put it earlier in the process and make it a cheap screen will affect the quality.
|
|
#
?
Mar 15, 2019 22:00
|
|
|
venutolo posted:How do y'all feel about take-home coding assignments as being part of the interview process? Depends on the size of the assignment. If it's more than an hour or two, I would offer compensation for applicants. But it's not really a preferred method of interviewing/evaluating for me. I much prefer asking for some code snippets and simply going through various relevant coding questions during the interview (not the whiteboard kind). If they don't have code to share because they only code in a work environment, that's also an interesting information to have. (making due consideration of family/life situations of the applicant). I am not particularly interested in whether an applicant can solve some specific assignment/problem right now - I am interested in how the person has approached challenges in the past, what her general toolkit looks like, does he spout buzzwords and dogma without actual understanding of the principles, technology/platform/language preferences, etc. Asking questions related to SOLID, MVVM, or a number of other excellent interview subjects, will expose the professional bullshitters and cargo cultists. Granted, while this style of interview is good at gauging overall level of expertise and potential - it's not good at figuring out whether someone is productive or not. A take-home assignment will weed out the exceedingly slow coders - but overall it's not a good measure of productivity once the initial learning period is over. On-premise tests I prefer to take with a grain of salt, as some people get really bad nerves, and may not perform anywhere near their actual skill level. To sum up: I prefer conducting an old-fashioned chatty interview and looking through some snippets of prior work. No need to waste company or applicant time with comprehensive tests and assignments. Exceptional situations/roles may require such tests - but for general cases, I think the interview/hiring process is broken if they're needed. My own experience being interviewed is that the vast majority of interviews are either sloppy, done by non-developers or (most common of all) they are trying to sell me on the position, rather than the other way around. I think most companies here find it a waste of time to spend too much time on interviews. They'll just make use of the trial period if it turns out the developer wasn't as good as they thought. In practice developers are in such short supply that a new hire getting fired, even if incompetent and/or unproductive, is pretty rare.
|
|
#
?
Mar 15, 2019 22:24
|
|
|
I think a whiteboard coding exercise is enough. It gives you some insight into the applicant's thought process. Take-home coding assignments seem like unnecessary homework and you have no idea how the applicant got to their solution, if it was even their own solution. I'd much rather vet an applicant to make sure their personality won't cause issues with the folks who would be their coworkers, and that they have some decent problem solving skills, which you should be able to get a feel for if you're doing some simple whiteboard exercises (not FizzBuzz for obvious reasons, but you can come up with other questions. I'm the guy who asks questions on DB normalization and relationships. It gives me a feel on whether or not the applicant has any idea how a database should work.)
|
|
#
?
Mar 15, 2019 22:42
|
|
|
For my current job, which is building software helping out traffic information systems and the execution of large logistic operations, the question I got during the interview was "Imagine you got a truck which needs to load and unload stuff in several locations. How would you calculate the travel times between those locations? If you need any more information we will answer your questions." It was very generically asked. What they wanted to hear is how I would approach such a problem in general, what I would consider valid data sources, if I thought about performance issues, and so on. I don't think I used the whiteboard at all, maybe to draw a single diagram but certainly not to write code. I think it was a good question for the kind of work we do here. We always have to keep the bigger picture in mind when coding.
|
|
#
?
Mar 16, 2019 09:27
|
|
|
Code tests are wonderful at being canaries towards bullshitters. The thing is, you don't tend to need a 'hey can you please write up a full-stack app' type test. And sure, fizzbuzz is antiquated. But what has been very successful for us is to have a handful of toy problems that shouldn't take more than an hour or two to complete, make sure a candidate is given a week to get them back, and we try to leave the problems slightly obfuscated. It's been wildly successful in two parts: First - it's a surprising filter. Second, it gives an easy hook into a technical interview to ask questions and look at how a candidate talks about a 'non textbook' topic. In the first case, we've had some people fail to complete them, we've had some candidates *refuse* to complete them. And in the second, we've caught out people who can 'talk shop' about code, textbook and blog lingo, but when asked about code itself they just fall apart and show a lack of understanding. A distillation of one example being to find the deepest nested element given an input string of faux-ML. So "<a><b><c></c><d><e/></d></b><f></f></a>" would output "e". It's a toy problem, but on the one hand, we've had so many failures, everything from fresh-grads to career developers. And on the other hand we've seen some patterns in how people think about the problem - often erroneously - and they just make for good questions to try and get into someone's mindset and abillity to talk through their thinking.
|
|
#
?
Mar 16, 2019 09:44
|
|
|
I dislike take home assignments. Wouldn't do them unless I was desperate.
|
|
#
?
Mar 16, 2019 10:39
|
|
|
Rocko Bonaparte posted:Some years back I remember telling my manager that I was so overstretched with people directly demanding stuff that I was just systematically rotating between tasks in 15-minute chunks--which included the time to context switch, so it was more like doing 5-10 minutes of any substantial work. He just said, "Good." I had a similar conversation with my manager recently about how I’m having problems getting things finished because I’m working on so many disparate things and priorities keep shifting. The response: “Just finish everything quicker so that you have more time to work on the other things”
|
|
#
?
Mar 16, 2019 12:32
|
|
|
Hughlander posted:I hate it and push back against it as much as possible. Why don't you also try doing quoted string searches for part of your ask and see how many solutions are on the internet. You can always use that as ammo against it. I've never seen a place that had one that didn't have at least one solution published somewhere. I think I want to give people the option of doing a task on their own time, or taking 45 mins in the interview alone to do it, but I need to think about whether that will get what I want. It doesn’t really matter if there are solutions published somewhere, to me. That’s going to be the case for most of their work, too. The point of them producing this code is so you have something to hang a conversation around. I’m not marking a test, I’m discussing how and why they made the decisions manifest in their code, and what they think of different alternatives. You can do this “create artifact and discuss” thing for lots of roles, including management (career development plan, performance review template, goal-setting process, interview rubric, level descriptions), product managers (market research plan, validation criteria), researchers (the job talk is basically this), administrative staff, lawyers, designers, etc etc. It does require more work in training and calibrating the interviewers, though. It also means you can pretty easily let the candidate pick between a few different options so they get to show off their strengths, which is very much my preference in an interview process.
|
|
#
?
Mar 16, 2019 14:02
|
|
|
That reminds me of the time I told the BA that we wanted a few days in the plan to try out a new testing framework and he totally seriously said “Why don’t you just not write bugs?”
|
|
#
?
Mar 16, 2019 14:04
|
|
|
raminasi posted:That reminds me of the time I told the BA that we wanted a few days in the plan to try out a new testing framework and he totally seriously said “Why don’t you just not write bugs?” Did you spit in his face ?
|
|
#
?
Mar 16, 2019 15:56
|
|
|
raminasi posted:That reminds me of the time I told the BA that we wanted a few days in the plan to try out a new testing framework and he totally seriously said “Why don’t you just not write bugs?” I think I mentioned this before, but at a former company the CFO (I think) talked about how much better we would be doing if the product just didn't have any bugs introduced into it. This is the same place where there were FREQUENT emails along the lines of "if anyone knows why XYZ INC just sent us a check for $50k please let us know". I was strongly tempted to make a comment about that in response to him but I still gave a gently caress at that point.
|
|
#
?
Mar 16, 2019 16:17
|
|
|
raminasi posted:That reminds me of the time I told the BA that we wanted a few days in the plan to try out a new testing framework and he totally seriously said “Why don’t you just not write bugs?” Why is your BA responsible for planning development work?
|
|
#
?
Mar 16, 2019 16:18
|
|
|
raminasi posted:That reminds me of the time I told the BA that we wanted a few days in the plan to try out a new testing framework and he totally seriously said “Why don’t you just not write bugs?” Are you sure this was serious? It's a fairly common joke, at least around my office.
|
|
#
?
Mar 16, 2019 16:21
|
|
|
It's easy to not write bugs if you don't write code. So just do that.
|
|
#
?
Mar 16, 2019 16:47
|
|
|
a foolish pianist posted:Are you sure this was serious? It's a fairly common joke, at least around my office. Search your feelings.
|
|
#
?
Mar 16, 2019 16:57
|
|
|
Rocko Bonaparte posted:Search your feelings. Idiot manager or goon not understanding social cues? I can't get further than 50-50.
|
|
#
?
Mar 16, 2019 17:02
|
|
|
PederP posted:Why is your BA responsible for planning development work? Because my company is just that dysfunctional. "Product management" is the thing that developers whine about when they're trying to avoid doing work, apparently. But since it actually does have to get done, BAs get stuck with it because otherwise users would have to actually talk to..ugh...IT. And since they're not hired to be PMs and they're not valued as PMs, turns out they're poo poo at it! a foolish pianist posted:Are you sure this was serious? It's a fairly common joke, at least around my office. 100%, I've known this guy for a while. He was genuinely confused.
|
|
#
?
Mar 16, 2019 20:05
|
|
|
raminasi posted:Because my company is just that dysfunctional. "Product management" is the thing that developers whine about when they're trying to avoid doing work, apparently. But since it actually does have to get done, BAs get stuck with it because otherwise users would have to actually talk to..ugh...IT. And since they're not hired to be PMs and they're not valued as PMs, turns out they're poo poo at it! Yeah, absolutely. I have known a few BAs who turned out to be excellent PMs, so it's not an impossible transition to make. But I think it's crazy to combine the roles. I find it odd that your users don't want to interact with developers - I've always found that when developers are targeting users internal to the organization, the users will tend towards trying to circumvent project and organizational structures, directly asking developers for bug fixes, design changes, features, support, etc. Thus necessating that the BA, PM and/or product owner step in and filter/limit/prioritize the communication and wishlisting. It's sad how many companies have absolutely terrible organizational integration and management of in-house software development. Once management and/or other organizational units lose trust in the developers, it's often a matter of time before internal development is shut down - instead being outsourced/contracted to an external partner. I digress, but I am appalled by how many executives think that such a move is good at "reducing complexity", "focusing on our core business" and similar mantras. Many modern companies and institutions have such intrinsic dependencies on their data, software and/or IT infrastructure, that it's completely insane to try and externalize it. That ended up more of a rant than intended, but your mention of dysfunctional relations between IT and the rest of the business touched a nerve. So much time, money and effort is spent on process and technology - when there are often far bigger organizational and/or cultural problems poisoning the well and resulting in very dangerous strategic decisions.
|
|
#
?
Mar 16, 2019 21:48
|
|
|
|
| # ? May 26, 2024 09:27 |
|
|
a foolish pianist posted:Are you sure this was serious? It's a fairly common joke, at least around my office. Years ago, a manager once asked me what "compiling" meant. He'd been working for the company for several years and knew that "compiling takes 30 minutes" and could sort of parrot back things about it, but never knew what it actually meant.
|
|
#
?
Mar 17, 2019 00:10
|
|