|
You should create a presentation analyzing tickets for QA and include a word cloud to help everybody deduce the main topics of interest in them. I'm just sayin'. For QA.
|
#
?
Jul 30, 2018 18:52
|
|
|
|
| # ? May 10, 2024 20:42 |
|
|
Apparently a few tens of thousands of dollars of computer equipment was delivered to the lab today and no one seems to know who the gently caress ordered it. This should be fun to watch....
|
|
#
?
Jul 31, 2018 17:50
|
|
|
BaronVonVaderham posted:Apparently a few tens of thousands of dollars of computer equipment was delivered to the lab today and no one seems to know who the gently caress ordered it. This should be fun to watch.... 
|
|
#
?
Jul 31, 2018 21:06
|
|
|
Friday afternoon, 12 outstanding PR's to merge in a repo and a half-hour deploy cycle for each because our security team insisted that every build run multiple linters and a dependency vulnerability analysis.
|
|
#
?
Aug 3, 2018 19:48
|
|
|
baquerd posted:Friday afternoon, 12 outstanding PR's to merge in a repo and a half-hour deploy cycle for each because our security team insisted that every build run multiple linters and a dependency vulnerability analysis. Merge on Monday, problem solved.
|
|
#
?
Aug 3, 2018 22:24
|
|
|
Don’t wait til Friday to submit prs?
|
|
#
?
Aug 3, 2018 22:50
|
|
|
Haha good one haha the sprint ends on Friday and the release is on Monday haha when are you supposed to submit PR's? haha
|
|
#
?
Aug 3, 2018 22:58
|
|
|
baquerd posted:Friday afternoon, 12 outstanding PR's to merge in a repo and a half-hour deploy cycle for each because our security team insisted that every build run multiple linters and a dependency vulnerability analysis. Manually cancel the first eleven deploy jobs?
|
|
#
?
Aug 3, 2018 23:57
|
|
|
smackfu posted:Don’t wait til Friday to submit prs? One week sprints. All the earlier PRs are merged, not a terrible burn down, but when you have multiple dev teams active on the same repo stuff gets backed up with a serial deploy pipeline.
|
|
#
?
Aug 4, 2018 00:07
|
|
|
Run analysis on the last submitted commit. If there's a problem, bisect until you find the culprit and toss it back. Have enough dependency analysis that commits depending on failing ones also get chucked out. Like is the site actually cycling through all 12 versions for the length of the testing? Is that a necessary part of this?
|
|
#
?
Aug 4, 2018 00:16
|
|
|
JawnV6 posted:Run analysis on the last submitted commit. If there's a problem, bisect until you find the culprit and toss it back. Have enough dependency analysis that commits depending on failing ones also get chucked out. Each PR is fine and passes unit and integration tests. They are probably all fine minus some merge conflicts. The bottleneck is that only one PR goes to deployment and deployment testing at a time, and this process includes merging to master and lengthy tests mandated outside the dev team.
|
|
#
?
Aug 4, 2018 00:28
|
|
|
baquerd posted:Each PR is fine and passes unit and integration tests. They are probably all fine minus some merge conflicts. The bottleneck is that only one PR goes to deployment and deployment testing at a time, and this process includes merging to master and lengthy tests mandated outside the dev team. Prior to merging to master, merge them all onto a single branch ("deploy") and handle it upstream of the crazy testing bottleneck?
|
|
#
?
Aug 4, 2018 00:34
|
|
|
vonnegutt posted:Prior to merging to master, merge them all onto a single branch ("deploy") and handle it upstream of the crazy testing bottleneck? Or use The Cloud (or your virtualization platform of choice) to spin up as many ephemeral environments as needed so you can continue to test in parallel.
|
|
#
?
Aug 4, 2018 00:36
|
|
|
vonnegutt posted:Prior to merging to master, merge them all onto a single branch ("deploy") and handle it upstream of the crazy testing bottleneck? That could be an interesting solution. Definitely not the accepted CI/CD path we've got so there's bound to be some pushback, and there would need to be a build cop person doing the manual merges, but it could work.
|
|
#
?
Aug 4, 2018 00:41
|
|
|
baquerd posted:That could be an interesting solution. Definitely not the accepted CI/CD path we've got so there's bound to be some pushback, and there would need to be a build cop person doing the manual merges, but it could work. sounds like you need a dirty build cop
|
|
#
?
Aug 4, 2018 00:48
|
|
|
New Yorp New Yorp posted:Or use The Cloud (or your virtualization platform of choice) to spin up as many ephemeral environments as needed so you can continue to test in parallel. Bonus if you start doing Factorial Merging as well. Fire off branch A B C D E F G H I J builds Then AB AC AD AE AF AG AH AI AJ builds so if A and X succeed you can merge that combined branch then ABC ACD...
|
|
#
?
Aug 4, 2018 01:30
|
|
|
https://twitter.com/stefanbc/status/1024915619131609088
|
|
#
?
Aug 4, 2018 07:10
|
|
|
Kill all nerds and the internet
|
|
#
?
Aug 4, 2018 08:12
|
|
|
CPColin posted:Haha good one haha the sprint ends on Friday and the release is on Monday haha when are you supposed to submit PR's? haha
|
|
#
?
Aug 4, 2018 09:40
|
|
|
baquerd posted:Friday afternoon, 12 outstanding PR's to merge in a repo and a half-hour deploy cycle for each because our security team insisted that every build run multiple linters and a dependency vulnerability analysis.
|
|
#
?
Aug 4, 2018 13:13
|
|
|
The Leck posted:Okay, stupid question here. How long would you expect the deploy cycle to be in a normal situation, and does that include testing and db schema deployment? Not trying to be snarky, just trying to figure out how bad my previous experiences have been, because they’re generally worse than that. I'm pretty happy with around 15 minutes. Prior to the new security scans effectively doubling our deploy time, we were pretty much at that point. That includes unit tests (sub minute), tests with embedded resources and mocked services (1-2 minutes), actual build and containerization (1-2 minutes), db updates (1 minute, cql updates are really fast), instance spin up and service registration (5-10 minutes), and deployment tests integrating with other live systems in the staging/preprod environment (3-4 minutes). I'm not saying that this is achievable for every project or every situation, but for me, prioritizing fast iteration at all levels of the SDLC is super important.
|
|
#
?
Aug 4, 2018 14:10
|
|
|
baquerd posted:I'm pretty happy with around 15 minutes. Prior to the new security scans effectively doubling our deploy time, we were pretty much at that point. That includes unit tests (sub minute), tests with embedded resources and mocked services (1-2 minutes), actual build and containerization (1-2 minutes), db updates (1 minute, cql updates are really fast), instance spin up and service registration (5-10 minutes), and deployment tests integrating with other live systems in the staging/preprod environment (3-4 minutes). In an ideal world where does security live in that process?
|
|
#
?
Aug 4, 2018 14:59
|
|
|
Blinkz0rz posted:In an ideal world where does security live in that process? I'd be interested in seeing once a day scans. Some dependency has a new security vulnerability? OK, need to fix that, but that shouldn't hold up merges, it's not like the stuff already out there isn't vulnerable as well (unless a new dep was just added with security issues). Also, some of the "security" stuff is pretty out there, like failing builds on unused imports.
|
|
#
?
Aug 4, 2018 15:18
|
|
|
baquerd posted:I'd be interested in seeing once a day scans. Some dependency has a new security vulnerability? OK, need to fix that, but that shouldn't hold up merges, it's not like the stuff already out there isn't vulnerable as well (unless a new dep was just added with security issues). Also, some of the "security" stuff is pretty out there, like failing builds on unused imports. Yeah failing on unused imports is kind of ridiculous. Your regular linting task should pick that stuff up anyway. But vulnerable deps don't always mean vulnerable code and vice versa. It's very easy to introduce security issues in first party code that should be scanned for in some way. I'm just not sure what the right way is. Maybe when you open a PR?
|
|
#
?
Aug 4, 2018 16:06
|
|
|
baquerd posted:Friday afternoon, 12 outstanding PR's to merge in a repo and a half-hour deploy cycle for each because our security team insisted that every build run multiple linters and a dependency vulnerability analysis. oh, that's easy. don't check anything in. if you just don't check anything in (don't actually say you're doing nothing, just keep saying things like "trying to make fixes to accommodate security team), you can wait for people to realize that there's no product and make the logical connection "why are we paying a security team if there's no product"?
|
|
#
?
Aug 4, 2018 17:26
|
|
|
Chaff Bugs: Deterring Attackers by Making Software Buggierquote:Sophisticated attackers find bugs in software, evaluate their exploitability, and then create and launch exploits for bugs found to be exploitable. Most efforts to secure software attempt either to eliminate bugs or to add mitigations that make exploitation more difficult. In this paper, we introduce a new defensive technique called chaff bugs, which instead target the bug discovery and exploit creation stages of this process. Rather than eliminating bugs, we instead add large numbers of bugs that are provably (but not obviously) non-exploitable. Attackers who attempt to find and exploit bugs in software will, with high probability, find an intentionally placed non-exploitable bug and waste precious resources in trying to build a working exploit. We develop two strategies for ensuring non-exploitability and use them to automatically add thousands of non-exploitable bugs to real-world software such as nginx and libFLAC; we show that the functionality of the software is not harmed and demonstrate that our bugs look exploitable to current triage tools. We believe that chaff bugs can serve as an effective deterrent against both human attackers and automated Cyber Reasoning Systems (CRSes).
|
|
#
?
Aug 5, 2018 04:32
|
|
|
This is loving incredible and I'm adding the paper to read at work/troll coworkers with.
|
|
#
?
Aug 5, 2018 04:44
|
|
|
Ghost of Reagan Past posted:This is loving incredible and I'm adding the paper to read at work/troll coworkers with. I already slacked mine with the "hey we already do this" joke.
|
|
#
?
Aug 5, 2018 06:42
|
|
|
We work around long security scans by using the multi-branche pipeline thing in Jenkins. Every time I push a feature branch, all tests including sonar and security checks are done on the branch, giving me the certainty that by the time I want to deploy to prod, there will be no nasty delays thanks to CLM or anything. Security scans failing on unused imports is stupid.
|
|
#
?
Aug 5, 2018 08:10
|
|
|
One of the testers on my team is really starting to try my patience. I'm assuming the issues stem from personality flaws in the first place but they've developed a real "Me vs Them" attitude to being a tester that means when they find a bug in a feature it's time to go find the dev that wrote the feature and talk about how there's a bug in it for 10 minutes while being entirely unable to provide any information on how it was caused, which forces my devs to have to get up and go round to watch them recreate the bug, and then take over the machine to look at the logs/traceback because no matter how many times I explain to the tester where to look all the evidence they can provide is a screenshot of the error in question. To make matters worse they'll dig their heels in and refuse to budge once they've settled on an idea. Tester  : I've found a bug in ticket-01234Me: What happens? Tester : <describes something that isn't a bug>Me: That's not a bug, do this thing instead Tester : I'm assigning this ticket back to development because of the bugMe: Again, it's not a bug you're doing that in the wrong place, read the instructions in the ticket Tester : Well it's not working the way I expected it to, so I'm assigning it back to developmentMe:  I've taken them aside for a private chat and that helped for about a week. I've spoken to the PM and voiced my concerns. At this point I'm looking to get them moved off the team because they're slowing everything down so much. God what I wouldn't give for an experienced tester with some experience in automation at this point.
|
|
#
?
Aug 5, 2018 11:22
|
|
|
baquerd posted:unused imports. Ah, I see you too have faced my greatest nemesis, the forgotten import from java.util that you used to test something out. NtotheTC posted:I've taken them aside for a private chat and that helped for about a week. I've spoken to the PM and voiced my concerns. At this point I'm looking to get them moved off the team because they're slowing everything down so much. God what I wouldn't give for an experienced tester with some experience in automation at this point. Getting QA testers who can actually engage their brain is a tremendous challenge and by the time they get competent with your stuff they're usually ready to move on to something more prestigious (and higher paying). I feel your pain.
|
|
#
?
Aug 5, 2018 14:10
|
|
|
Volmarias posted:Getting QA testers who can actually engage their brain is a tremendous challenge and by the time they get competent with your stuff they're usually ready to move on to something more prestigious (and higher paying). I feel your pain. But in general, a tester is someone who has no other options or ambition so the exchange sounds accurate. Another thing to remember is that many testers are frustrated being stuck in this job and consider developers assholes who release buggy code (why else would they be needed) so they behave like idiots. The whole reason we have tester vs developers anyway is because management is not allowing developers for enough time and direction to deliver proper quality code so instead of altering their own behavior, management hires testers as a stop-gap. Another reason could be complex, integrated systems where no-one can have insight into all the technical implications but then there are many other problems as well.
|
|
#
?
Aug 5, 2018 15:19
|
|
|
NtotheTC posted:One of the testers on my team is really starting to try my patience. I'm assuming the issues stem from personality flaws in the first place but they've developed a real "Me vs Them" attitude to being a tester that means when they find a bug in a feature it's time to go find the dev that wrote the feature and talk about how there's a bug in it for 10 minutes while being entirely unable to provide any information on how it was caused, which forces my devs to have to get up and go round to watch them recreate the bug, and then take over the machine to look at the logs/traceback because no matter how many times I explain to the tester where to look all the evidence they can provide is a screenshot of the error in question. Generally what I'll do is: a) Don't assign the tester's bugs directly to your team and waste their time. If a bug doesn't have solid repro steps, on basis of severity 1) If there is nothing at all the work with, just kick it back to the tester with 'can't reproduce. please provide reproduction steps'. 2) If the repro steps are there but either lovely or don't work, give an example set of repro steps that follow the directions as given but don't reproduce the result. Don't try to test around, you don't have time. 3) Once you've confirmed you can reproduce the bug - update the bug with non-moronic steps, and give it to your team. Another thing you can do is teach the tester how to use tools other than screenshots. Don't make the assumption that stuff like repro steps, etc. is explained by their department at all - a lot of these people are liberal arts majors or recent college grads that were literally hired off the street by some contracting company making fifteen bucks an hour, it's entirely possible that they were given zero training. You should explain what you want to see in a bug if you want good results. 1) If it's a webapp, maybe it'd a be a good idea to capture fiddler logs. 2) Does your product have logging? Where are the log files created? If you see a problem in X area, where should you get the logs? What would the developers be looking for in the log file? 3) How is your product configured? What configuration settings are pertinent to your product? 4) Maybe try getting a video of the bug with camtasia studio... (this is the easiest way to improve the quality of a QA defect report) Another thing you can do to get the tester on your side is to just show them how to build the product and where the source code is and walk through how to debug and how to get stack traces etc. I would only do this if the tester is becoming a problem because the smart, motivated ones will probably just leave and become developers, the slackers will just be content to churn out one or two well-researched bugs a day with great stack traces that are easy to fix, but can no longer be trusted to click all the buttons like a superstitious person, while the stupid ones will get lost and cowed and lose their self-confidence (but at the same time the Holy Knight of Quality Assurance escutcheon might lower just a touch, you can always dream.) Trying to teach people things generally gets them on your side. If you go into the interaction just trying to be nice and polite and soft serving everything, they'll think you're being condescending and blow up the bug tracker.
|
|
#
?
Aug 5, 2018 16:31
|
|
|
Volmarias posted:Ah, I see you too have faced my greatest nemesis, the forgotten import from java.util that you used to test something out.
|
|
#
?
Aug 5, 2018 17:26
|
|
|
Sagacity posted:The nemesis whose only weakness is the "Optimize imports before committing" checkbox in IntelliJ! And then I hate you for "optimizing" away System.Linq and System.Collections.Generic, because the functionality is not used yet in the new class (but will be as soon as the actual implementation starts)
|
|
#
?
Aug 5, 2018 18:21
|
|
|
Turambar posted:And then I hate you for "optimizing" away System.Linq and System.Collections.Generic, because the functionality is not used yet in the new class (but will be as soon as the actual implementation starts) Why would you ever set up imports before writing the code? Everything you need gets imported automatically...
|
|
#
?
Aug 5, 2018 18:27
|
|
|
Taffer posted:Why would you ever set up imports before writing the code? Everything you need gets imported automatically... Some people use vscode or notepad to write java applications. Optimizing imports is a way to find out who they are so you never have to be in the same team to long.
|
|
#
?
Aug 5, 2018 18:52
|
|
|
Bruegels Fuckbooks posted:
however teaching them to follow instructions might be a leap.
|
|
#
?
Aug 5, 2018 21:03
|
|
be nice to testers
|
Hello thread, I need to cry into the void. 2 months ago I took a job at a relatively large and stable startup, after working at a very small and unstable startup. I took the job almost entirely because the founders and CTO who interviewed me seemed really accommodating and relaxed and that's something I was really looking for at the time. Things start out, everything seems cool. The team is a little older than I'm used to (30s-50s, I'm late twenties) which was a slight adjustment, but everyone was super nice and helpful, which was a good change for me. I work on a couple tech demos and familiarize myself with the tech stack. About a month ago, I hear about a big event coming up, seems like everyone's projects are focused all on that. I get put on an app project with another guy, just doing some refactoring and polishing etc to get out ready for said event, all good. Then that Thursday, at 4pm, I get told I need to demo one of my tech demos to a potential client, in 30 minutes. Okay. Details of our tech aside, I find out the scenario for my demo was completely altered and I can't run it. My boss is pissed (despite me having no control over this), and demands I come out of town in 2 days where they're showing my demo, and hadn't thought to tell me. Hooray. I despise traveling for work, but the demo goes fine. 3 weeks ago the PM tells me he's going to move me to another task, a new feature needs to be developed in a separate app, and ready before the event. I tell him that's pretty tight time-wise but I can probably get a rough version done at least. He understands, so I'm feeling comfortable. 2 weeks ago on Monday (also 2 weeks before the event), an email goes out to everyone from our administrator telling them that it's time to buy your plane tickets for the big event! Attached was a schedule for everyone. My name was on that list. Oh. I'm supposed to go halfway across the country for 7 full days and no one thought to mention that to me. Ok. The next day, Tuesday, my boss tells me he wants my initial tech demo to become a full product to be shown at the event. At this point there is 8.5 business days remaining. I initially tell him that's impossible, but he (and and my other boss) lay on pressure super thick. Like brutally bad. Emotional manipulation, blaming me for not having done this already (no one told me it needed to be) asking me what else I had been working on (the things that they and the PM had told me to focus on), so like the fucker I am, I cave. I give lots of caveats and maybes but I tell them I can get them something in time. So I start working on it. I frantically pick the brains of my (also overworked) coworkers to figure out how it can be done. Immediately I find out there are some big roadblocks. Awesome. But I keep working anyway because I have a massively overdeveloped sense of responsibility and never want to disappoint people. Thursday, i find out from the same boss that the parameters of my tech-demo-turned-product have completely changed, and he never thought to mention it or consult with me. Of course I instantly tell him that this is a big problem and that will probably derail everything I'm doing. He gives me a "this has to get done" and I get told we won't be able to get details on what's changed until Monday (it involves outside people). At this point, my boss tells me I like to focus on the negatives, so how badly will this REALLY affect me (loving what) Monday comes, he wanted me to work on this all weekend but I didn't because I don't like to ruin my life for other people's issues. I find out the details on what's changed, I tell him I can probably account for them, but it'll take all my time, e.g. tech demo stays as is. He seems very upset but sayas okay. So I spend the entire week working on that. During this entire period he's constantly asking me how close I am, pressuring me to spend more time on it and work nights, through the weekend, etc It's Sunday night and I leave for Event in a few hours. My boss kept texting me for updates, I told him exactly as expected: I accounted for the changes and that's all there was time for. No new features. Immediately I get a torrent of texts, "why didn't you finish it", "we have to get this done", "there are no excuses on this" (that's verbatim), "I need a full update tonight". I'm so loving stressed, I barely slept all week from the pressure, I want desperately to quit but I'm about to move and worried about stability. I work in a small job market and this company and its founders are very prominent, I'm terrified of them spreading bad words about me because due to their stature they'll almost certainly be believed. Someone help me  Holy poo poo that post got long. Tl;dr I want to die Taffer fucked around with this message at 04:37 on Aug 6, 2018 |
|
#
?
Aug 6, 2018 04:33
|
|
|
|
| # ? May 10, 2024 20:42 |
|
|
gently caress them, they can deal. There's no shortage of Dev jobs out there. If your boss gave a gently caress he'd be pushing back to whatever idiot committed to last minute demos. And If this is actually a company do or die demo and just lumped all the work on the new guy without nailing down scope then he is an even bigger idiot.
|
|
#
?
Aug 6, 2018 04:48
|
|
