|
I've learned that it is actually possible to be completely paralyzed by regression testing and thoroughness. I have at least three PRs that have been up for over a month now that haven't budged because one or my co-workers insists on writing regression tests for every single possible result, i.e. "happy" and "sad" paths, such that it's taken about 10 times longer to deploy a feature than it should. I have no issue with regression tests, and in fact I'm trying to port the regression team's tests to Capybara so us developers can write our own tests, but it's gone way off the testing deep end without really accomplishing anything. She's seriously slowed down development due to overthinking everything and has been rather difficult to work with recently (which might be due to the fact that she's manually pulling the branch for each PR and running the manual clicky-clicky regression test on each one). The weirdest part is that she's very reluctant to let me look into establishing Capybara tests for our app so that we devs can write and run feature specs ourselves, instead preferring that we continue to write manual tests and click through everything on any PR we make, even for one-liners. I genuinely don't know what to do with her, but I'm getting frustrated enough that I'm just taking on tech debt tickets to alleviate her need to manually regression test everything solely because I'm sick of her holding everything up. I recognize the need to ensure correctness of your app, but there's a loving limit to it and automation relieves a buttload of issues yet is still being resisted by her.  Driving technical change is balls.
|
#
?
Sep 20, 2016 15:23
|
|
|
|
| # ? May 10, 2024 17:25 |
|
|
Escalate that poo poo!
|
|
#
?
Sep 20, 2016 15:38
|
|
|
Escalate as in go over her head? I dunno if it's that severe, but I do have our PM on our side when I say we need to work on tech debt before taking on more features, so maybe he'll be receptive to my concerns.
|
|
#
?
Sep 20, 2016 15:48
|
|
|
I can imagine people coming around and asking, "How come none of your projects are closing out?" because they didn't notice they've been in QA's hands for weeks. As long as your PM knows that part of the slowdown is due to possible overtesting. I've had that problem, too, where QA goes off in the weeds with regression tests on changes that carry very little risk. (Then I get really annoyed if QA actually finds a bug in the stuff I thought they were overtesting.)
|
|
#
?
Sep 20, 2016 15:57
|
|
|
Pollyanna posted:I've learned that it is actually possible to be completely paralyzed by regression testing and thoroughness. I have at least three PRs that have been up for over a month now that haven't budged because one or my co-workers insists on writing regression tests for every single possible result, i.e. "happy" and "sad" paths, such that it's taken about 10 times longer to deploy a feature than it should. I have no issue with regression tests, and in fact I'm trying to port the regression team's tests to Capybara so us developers can write our own tests, but it's gone way off the testing deep end without really accomplishing anything. She's seriously slowed down development due to overthinking everything and has been rather difficult to work with recently (which might be due to the fact that she's manually pulling the branch for each PR and running the manual clicky-clicky regression test on each one). The weirdest part is that she's very reluctant to let me look into establishing Capybara tests for our app so that we devs can write and run feature specs ourselves, instead preferring that we continue to write manual tests and click through everything on any PR we make, even for one-liners. I'm a little confused. Are they manual regression tests or is it some automated system? If it's already automated, could you offer to make some tests in whatever lovely system she's using?
|
|
#
?
Sep 20, 2016 16:39
|
|
|
Pollyanna posted:I've learned that it is actually possible to be completely paralyzed by regression testing and thoroughness. I have at least three PRs that have been up for over a month now that haven't budged because one or my co-workers insists on writing regression tests for every single possible result, i.e. "happy" and "sad" paths, such that it's taken about 10 times longer to deploy a feature than it should. I have no issue with regression tests, and in fact I'm trying to port the regression team's tests to Capybara so us developers can write our own tests, but it's gone way off the testing deep end without really accomplishing anything. She's seriously slowed down development due to overthinking everything and has been rather difficult to work with recently (which might be due to the fact that she's manually pulling the branch for each PR and running the manual clicky-clicky regression test on each one). The weirdest part is that she's very reluctant to let me look into establishing Capybara tests for our app so that we devs can write and run feature specs ourselves, instead preferring that we continue to write manual tests and click through everything on any PR we make, even for one-liners. This doesn't sound like regression testing. Regression testing is to make sure things what broke don't break again. Eg, a ticket comes in, write a test validating the issue exists and then fix the issue. Then builds fail if that test fails in the future. Also it sounds like you should go over her head. A full month waiting on a single PR is ridiculous, let alone three.
|
|
#
?
Sep 20, 2016 18:42
|
|
|
I write regression tests and I can completely imagine falling down that rabbit hole where you try to account for everything in your testing. It's just that we live in a finite universe of finite resources and most software that needs someone specifically writing regression tests for it is complex enough that even if you have automated tests, actually writing and plugging in the tests is going to take way too much time. Part of the skill in writing regression test cases is accounting for as much of your critical functionality in as little testing as possible.
|
|
#
?
Sep 20, 2016 19:03
|
|
|
Pollyanna posted:...I do have our PM on our side when I say we need to work on tech debt before taking on more features, so maybe he'll be receptive to my concerns. Wow that's rare. Maybe try to work on that instead ?
|
|
#
?
Sep 20, 2016 19:07
|
|
|
It's about Good Enough Coverage ™ e: also lol at enabling bad behaviors for team members. Depending on your environment, if its a good environment, you should be able to confront it constructively and it should go over well.
|
|
#
?
Sep 20, 2016 22:23
|
|
|
Pollyanna posted:I've learned that it is actually possible to be completely paralyzed by regression testing and thoroughness. I have at least three PRs that have been up for over a month now that haven't budged because one or my co-workers insists on writing regression tests for every single possible result, i.e. "happy" and "sad" paths, such that it's taken about 10 times longer to deploy a feature than it should. I have no issue with regression tests, and in fact I'm trying to port the regression team's tests to Capybara so us developers can write our own tests, but it's gone way off the testing deep end without really accomplishing anything. She's seriously slowed down development due to overthinking everything and has been rather difficult to work with recently (which might be due to the fact that she's manually pulling the branch for each PR and running the manual clicky-clicky regression test on each one). The weirdest part is that she's very reluctant to let me look into establishing Capybara tests for our app so that we devs can write and run feature specs ourselves, instead preferring that we continue to write manual tests and click through everything on any PR we make, even for one-liners. I ran into this problem with a project that had a bunch of manual QA people who were writing an endless amount of manual regression tests. I canceled the project and they all got canned.
|
|
#
?
Sep 21, 2016 00:55
|
|
|
I mean, I don't know if I represented the situation fairly. I've since started spiking out some browser-level tests as a proof of concept for the app (and it's awful compared to testing an API), and we've been having some discussions/venting about our confusing and frustrating situation. She's taking on a lot of responsibility by reviewing all our our PRs and trying to work through every possible situation (i actually did some combinatorics for this on a whiteboard today) and its taking a toll on her, too. I just feel like we're in a weird position re: our process and workflow, team-wide, and we've run out of insights we can gather by observing ourselves. We're at the point where we need outside help to take a look at our situation and help us figure out exactly what the hell is going on. She's better at writing this out than I am, so I'll leave it up to her. All I know is that a month for a PR is way too long, and there's just no way she has to be as thorough as she's trying to be.
|
|
#
?
Sep 22, 2016 21:44
|
|
|
leper khan posted:This doesn't sound like regression testing. Regression testing is to make sure things what broke don't break again. Eg, a ticket comes in, write a test validating the issue exists and then fix the issue. Then builds fail if that test fails in the future. In the olden days, our regression testing was just a full manual test suite across the whole app, before any production deployments, to ensure that none of the changes had unexpected side effects. Took ages and cost a fortune in tester hours. Automated testing and unit testing is a much better solution to the same problem.
|
|
#
?
Sep 24, 2016 19:17
|
|
|
CPColin posted:I can imagine people coming around and asking, "How come none of your projects are closing out?" because they didn't notice they've been in QA's hands for weeks. As long as your PM knows that part of the slowdown is due to possible overtesting. I've had that problem, too, where QA goes off in the weeds with regression tests on changes that carry very little risk.
|
|
#
?
Sep 25, 2016 21:06
|
|
|
Vulture Culture posted:QA is a big blind spot for a lot of people, even the best project managers -- they just farm it out to the QA leads and then whatever happens happens. I went out of my way to read a couple of books on old-school QA management disciplines this year because while everyone understands the nuts and bolts of running QA tests, the way to approach integrating QA with business priorities is so drastically misunderstood that I don't think anyone even tries. Which books were those?
|
|
#
?
Sep 26, 2016 01:01
|
|
|
On the subject of job titles: my work has decided to introduce the title of "senior developer", and I'm apparently one of the lucky ones. I think this is laughable, as I have only four years of experience at only one company, in total. (I'd class myself as "middling intermediate developer" at best.) How will the "senior developer" title look on my CV? I'm picturing some recruiter looking at this idiot quote-unquote senior developer with fuckall experience and binning it immediately. Obviously, titles are bullshit, but do they know that?
|
|
#
?
Sep 26, 2016 11:20
|
|
|
redleader posted:On the subject of job titles: my work has decided to introduce the title of "senior developer", and I'm apparently one of the lucky ones. I think this is laughable, as I have only four years of experience at only one company, in total. (I'd class myself as "middling intermediate developer" at best.) Welcome to the title inflation club. Did you get a raise with your "promotion"? Because you should make that argument, lol. The recruiters won't care, because title inflation is pervasive.
|
|
#
?
Sep 26, 2016 13:16
|
|
|
vonnegutt posted:Which books were those?
|
|
#
?
Sep 26, 2016 13:43
|
|
|
redleader posted:On the subject of job titles: my work has decided to introduce the title of "senior developer", and I'm apparently one of the lucky ones. I think this is laughable, as I have only four years of experience at only one company, in total. (I'd class myself as "middling intermediate developer" at best.) It's can be looked at the other way too, right? Some people have an affinity for the work, and getting 'bumped up' quickly can be a show of talent. There aren't exactly standards across the industry about what makes a 'senior' - most places seem to feel it is some equation of actual skill and/or time in the field. Quickly moving upwards, if you have references to back it up, can easily be a show of "I'm just good at this stuff".
|
|
#
?
Sep 26, 2016 15:13
|
|
|
Yeah I don't think there's any significant risk of that hurting you. To the company, you're one of THEIR more senior devs, so it's a totally reasonable title for them to assign. Recruiter/hiring manager will barely even notice your title unless it's something really goofy like VP of Engineering, or totally unrelated to development.
|
|
#
?
Sep 26, 2016 15:23
|
|
|
Cuntpunch posted:Quickly moving upwards, if you have references to back it up, can easily be a show of "I'm just good at this stuff". That's a lot of the reason I'm angling for the Architect title; I got my Senior title five years into my current job, which was also five years ago. I don't want the risk of somebody thinking, "Hmm. He's been Senior for X years. I wonder why he hasn't moved up since then."
|
|
#
?
Sep 26, 2016 15:31
|
|
|
Cuntpunch posted:It's can be looked at the other way too, right? Some people have an affinity for the work, and getting 'bumped up' quickly can be a show of talent. There aren't exactly standards across the industry about what makes a 'senior' - most places seem to feel it is some equation of actual skill and/or time in the field. Quickly moving upwards, if you have references to back it up, can easily be a show of "I'm just good at this stuff". Yeah, exactly this. I don't think people put a ton of stock into job titles, because they're so varied, but "senior" anything can usually be counted on to not need too much hand-holding and to be able to teach others. This isn't something that you magically become able to do once you hit the ten year exp / ten-inch beard mark, it's a sign of being a good, thoughtful developer as well as experience. It's strange, the tech field loves to talk about meritocracy this, meritocracy that, but when you bring up job titles, it immediately regresses back into a seniority / "you have to pay your dues" situation. Experience can be a big multiplier for your skills, but there are a lot of devs who end up in a dead-end position that doesn't have a lot to teach them past year two. If you had four years of increasing responsibility, it's possible to be equivalent of a stagnant dev with double the years.
|
|
#
?
Sep 26, 2016 15:31
|
|
|
There's plenty of people out there who do their job, but don't invest serious effort into broadening or deepening their skills. This is very true in the PHP world, at least, where someone could end up building Wordpress themes at an agency. You don't get much better at designing software by doing it, and the work is never going to change on its own. A stagnant work environment combined with a lack of personal ambition doesn't add anything to someone's skills, even if they have decades of experience at it.
|
|
#
?
Sep 26, 2016 15:39
|
|
|
Yep. Ten years of Java experience where they only worked with a legacy Java 6 code base is not super valuable to most employers. (Well, it probably is sadly useful for a surprising number of firms but they don't want to admit it.)
|
|
#
?
Sep 26, 2016 15:57
|
|
|
smackfu posted:Yep. Ten years of Java experience where they only worked with a legacy Java 6 code base is not super valuable to most employers. But then when they look for a replacement, they will look for someone with 10 years experience in their exact tech stack, reject anyone who doesn't tick off having Tapestry 2 plus applet experience in IE6 with domain knowledge, and then wonder why they can't find anyone.
|
|
#
?
Sep 26, 2016 16:14
|
|
|
baquerd posted:But then when they look for a replacement, they will look for someone with 10 years experience in their exact tech stack, reject anyone who doesn't tick off having Tapestry 2 plus applet experience in IE6 with domain knowledge, and then wonder why they can't find anyone. And then file for an H1B.
|
|
#
?
Sep 26, 2016 16:20
|
|
|
vonnegutt posted:"senior" anything can usually be counted on to not need too much hand-holding and to be able to teach others. This does not map to my experience, where 'senior' has not indicated a mentorship role or even being competent. Job titles are a joke.
|
|
#
?
Sep 26, 2016 19:53
|
|
|
See if you can angle for a Señor developer position if you feel unqualified to be a Senior developer.
|
|
#
?
Sep 27, 2016 13:08
|
|
|
Volmarias posted:See if you can angle for a Señor developer position if you feel unqualified to be a Senior developer.
|
|
#
?
Sep 27, 2016 14:17
|
|
|
Except when you are neither. 
|
|
#
?
Sep 27, 2016 14:19
|
|
|
I once worked in devops at a company that had been an accounting firm earlier in its life and had retained that job title/position model. I had a fabulous colleague who was knowledgable and thorough and provided mentorship - she also directed the team when our manager was out for surgery, which happened often because of a chronic condition. She and our manager lobbied for ages for her to be promoted to senior but this was always slapped down from on high because they had a hard and fast rule that someone had to be with the firm for 3 years before they could be a senior. So we kind of called her a senior but they wouldn't let her have a raise either due to a hard cap on raises not associated with promotion. So of course she quit, and my manager spent the next half year interviewing people who would basically be seniors but not be paid as such. Well he might have spent longer than that but I don't know because I quit too. I will say though that in the operations department (the folks that actually did the tax filing stuff) all the seniors were in fact some crazy gods of accounting and canny motherfuckers so I can see how that title/promotion model can work for some industries but it sure as hell isn't suited for dev type nonsense.
|
|
#
?
Sep 28, 2016 02:00
|
|
|
Related to testing: if your app depends on a connection to an API to work properly, is it better to bypass it/stub it out, or should the test environment enforce a live connection to the API while running tests? I added some code in the app to bypass requiring a connection to our VPN if you're running unit/integration tests, cause it was causing problems with testing stuff like login and setting users up (our app relies on an ActiveDirectory connection). My coworker argues that since the app uses AD, it should always be connected to AD, even in the test environment. Is my approach reasonable? Should I be stubbing that API out, or requiring to be there even if it makes some tests either impossible or a bitch to write?
|
|
#
?
Sep 28, 2016 16:25
|
|
|
Pollyanna posted:Related to testing: if your app depends on a connection to an API to work properly, is it better to bypass it/stub it out, or should the test environment enforce a live connection to the API while running tests? I added some code in the app to bypass requiring a connection to our VPN if you're running unit/integration tests, cause it was causing problems with testing stuff like login and setting users up (our app relies on an ActiveDirectory connection). My coworker argues that since the app uses AD, it should always be connected to AD, even in the test environment. Is my approach reasonable? Should I be stubbing that API out, or requiring to be there even if it makes some tests either impossible or a bitch to write? Someone correct me if I'm wrong, but I think this is pretty simple; if you're doing unit testing then you mock the API out. If you're doing integration testing then you test the actual API connection.
|
|
#
?
Sep 28, 2016 16:29
|
|
|
revmoo posted:Someone correct me if I'm wrong, but I think this is pretty simple; if you're doing unit testing then you mock the API out. If you're doing integration testing then you test the actual API connection. That's my rule of thumb, yeah. Ask yourself what you're actually trying to test and stub out whatever isn't relevant.
|
|
#
?
Sep 28, 2016 16:34
|
|
|
revmoo posted:Someone correct me if I'm wrong, but I think this is pretty simple; if you're doing unit testing then you mock the API out. If you're doing integration testing then you test the actual API connection. I look at it a bit different. During a smoke test that blocks a commit integration tests run against a dummy API you don't want to block someone's commit based on an external resource being unavailable. However then there should be a scheduled test run against the real API. Either scheduled in response to the push, or a nightly job against master.
|
|
#
?
Sep 28, 2016 16:56
|
|
|
Hmm, yeah, I see the point. A big reason why I disabled the API connection in testing was due to difficulty handling it during regression tests, but maybe that was too much of a sweeping change and there's something else I can do. I'll discuss the approach with my co-workers and figure it out.
|
|
#
?
Sep 28, 2016 17:07
|
|
|
Is this API your team's API, and the product is mainly a conduit to it? If so, use the real one. Otherwise, stub it out. I like the VCR gem for testing external APIs, it will 'record' (save a .json file) the first request you make to an API and then any request that matches that will use the "recorded" response. For example, if I made a request to GET google.com/user/123, it would actually do that and save the response. Then, any other test (or reruns, etc) that tries to GET google.com/user/123 would use the saved response.
|
|
#
?
Sep 28, 2016 17:07
|
|
|
It's not our API per se, as we don't own it - but we are a big consumer for it. It's an internal company API that hooks into the corporate AD database. I personally want to stub it out as much as possible, but my team member is very resistant to change and different thinking and hates the idea of not directly testing it. I'm ready to give up on that point, especially since it's not likely at all that we'll get CICD of any sort...basically ever. Work has stalled on that due to security complaining about AWS, so it's unlikely that these tests will be fun on anything but a dev's local machine anyway. Either way, I'm honestly getting pretty tired of not having a good foundation to develop on and tired of features taking months to a year to develop and deploy thanks to bad QA, plus management overhead and poor project management/direction. I don't see a future here for me. I'm going to start job hunting again.
|
|
#
?
Sep 28, 2016 17:40
|
|
|
Pollyanna posted:I'm going to start job hunting again. Protip: you might want to wait till the first of the year. There are no. loving. tech. jobs. right now. Job sites for my city in all the popular languages are absolutely dead right now. We were discussing earlier and it seems others are seeing similar things. I think the sentiment is that the combination of end-of-fiscal-year timing, the election, and impending recession are making hiring managers put a hold on things for now.
|
|
#
?
Sep 28, 2016 17:44
|
|
|
Having watched the meteoric arc of polyanna's career I'm pretty sure they're ready to hang out a shingle as a consultant.
|
|
#
?
Sep 28, 2016 18:00
|
|
|
|
| # ? May 10, 2024 17:25 |
|
|
Hey now, don't give me ideas. I don't mean right now, but to start getting a foothold on it for the future. I agree that now is a bad time. We'll see what happens.
|
|
#
?
Sep 28, 2016 18:13
|
|