@Lensflare Query parameters are of course secured by ssl. Http as a whole is plain text, on the transport layer the only difference between data in the query or the body is if it's on the first or last line of the request.

Just look at the encrypted request with Wireshark, all thats leaked is the domain to resolve to.
Doesn't mean that I'm a fan though, makes our server logs into a valuable target and sms is a pretty insecure transfer but that doesn't mean that one needs to create a enumerable list of urls^^.

Technical management, at least good technical management, functions as a translator between business and IT. They make sure that you get clean requirements instead of vague business goals that need hours of follow-up questions and they keep CTAnythings and PMs off your back so you can focus on your work.

Only problem is that good ones are pretty rare, the rest recites one of five "motivational speeches" in between every 4 sentences and leans back feeling good about themselves and putting blame on "their techies".

IMO, g is the only valid point in the list. "I'm not good at xy" is an incentive to put in the leg work, read, learn, do and become better at what you do. If they fire you while doing so, well bad luck but you're in IT so finding something new shouldn't be that hard, if they don't you have a chance to master a new skillset which allows you to become a specialist in what you do and being a cross field specialist is where the big bucks hide.

Remember, 10.000 hours to master a skill, if the concept itself interests you, it's worth putting them in.

I'm almost certain that I will get some backlash for that BUT: In my opinion communication is one of the most important skills for someone in IT to master, and master well.

It's part of the job to whistle back management when they make promises the code can't hold and its your responsibility to fight for your convictions. If things break down the line because you didn't interject in a meeting because you weren't explicitly asked that shit is on you and nobody else. You're hired for your expertise and that doesn't mean just writing expert level code in your silent corner of the office but to be able to advise the business on, in your opinion, best courses of action. If they don't listen, fine you did your job, they did theirs. If you do not speak up when your project is talked about you force others to act on incomplete data which is not okay. Being shy to the extent that you endanger your user base is a personality flaw that should be worked on because it is a danger to others.

@rolexpo If it isn't expected that an actual product is created in that time and participation isn't mandatory its more or less an exercise for fun. Of course does the company benefit from their devs refining their skills and exchanging knowledge across teams but so do the devs who participate. Under those circumstances (and only those circumstances) I'd be fully okay with an Amazon voucher as a small incentive.

Oh, hard one. The language I work most with and would be closest to being an expert would probably be python but my favorite is, without a doubt C. There is just some elegance in working close to the metal those high level "Getting shit done" language lack.

Record and playback tests are notoriously unstable and will, in the long run, cost you more than you save by not setting up proper test automation so let go of the selenium IDE.

Setting up pagemodels and attaching them to actions allow you to abstract the actual test away from the code so you can spread the creation of tests to non coding team members, for a keyword you can look into behavior driven frameworks and gherkin.

Going this way (and maybe hiring a testing professional) will result in a much more reliable testing infrastructure and believe me when I say that while good tests give a huge boost to productivity bad ones are an enormous slow down.

Honestly, strangle your QA. They have no right to change requirements. They can advise the PO to do so because xyz but the second they start to fiddle with requirements they're failed PMs and should be removed from the evolutionary pool.

@linuxxx As long as you stay away from the scripting interface it's actually quite nice, accidentally found 4 unsafe input reflections in our api while trying to set it up as a simple proxy. If you try to extend it with custom scripts though, you will suffer.

Yes and no. A specialized tool that uses your companies lingo and is designed to especially tackle your use cases pays off in the long run by needing less onboarding for new staff using it than having a more general solution. Also you control what it does so the situation of an update breaking your work flow and forcing a migration of all your data will not happen.

On the other hand you put the burden on you to develop a system that will eat up dev, admin, test and hardware capacity because you can't just file a ticket with another company.

@Parzi How exactly should the sum of two files be defined?

@nnee You're actually asking the wrong person, everything after it went live was our devops peoples baby. I remember it being some kubernetes endpoint slices magic but I do really not know how exactly it was done.

@provector Now I'm really curious to know how not deploying on a Friday will keep your roof from leaking.

@hatemyjob Why is 194 times a week too much? In my old company (new one is getting there) every push was taken to the CI system, unit tested, build a new container, attached it to kubernetes, ran all applicable integration tests, ran critical E2E tests, deployed the container to live, routed roughly 10% through the new deployment, monitored errors per minute and if everything went fine it took down the old one otherwise it blocked the new one for external access and sent out a review note to dev and QA. Without any human involvement. We had times where we deployed multiple times per hour and no critical failures occurred.

@netikras Yes. Are they frequently different people? sadly no. are those different skillsets? definitely. Testing is usually quite technical, if you do it well it's a well set up scientific experiment that allows you to set up your null hypothesis (shits fucked up) and enrich it with data until you can make a rather certain statement about the hypothesis being true. Extra points if your hypothesis is precise enough to actually allow for a diagnosis of why shits fucked up.

QA usually deals with processes and the question why they produce errors. It's much closer to the realm of management. Finding systemic flaws in communication, fighting for time to write unit tests, tackling bullshit requirements like maximum estimates on features and so on.

Then of course there are your 0815 "Testers" who just click around on an application and wouldn't recognize a risk assessment if it'd bite their failed developer asses. Those are neither QA or testers, those are a waste of salary.

Selenium doesn't fail, your implementation does. Refine your selectors and logic. Only a bad craftsman blames his tools.

Math is a bitch, especially since most university profs see teaching just as a distraction from their research and half ass any lecture before the 4th or 5th semester. If you really dislike it I could recommend the university of applied science in Cologne for computer engineering. They moved most of the computer science courses to another campus and only left the profs who really couldn't care less, giving out top marks for at best mediocre shit. Their maths is pretty much Abi level (actually I think my Grundkurs Abi was a bit harder) but on the downside they require you to learn everything else on your own because, well, the profs (most at least) are as capable as mountain goats.

Testers test against specs. If the specs are shit and impossible a good QA will argue with the stakeholders but if we lose we will flag anything breaking those specifications.

Reporting stuff we know is not fixable but is still demanded by the non IT folks (only to be ignored at any release either way) is the shittiest part of our job but it's still the job we do. Bad on your tester if he doesn't communicate it to you but don't judge him for doing what he's paid for. Also your "Measuring margins with a ruler" line makes me assume that you're an insufferable idiot with a god complex without respect for other peoples jobs which gives me a hint way he wouldn't want to spend time communicating with you.

Well as a QA engineer, if your job contains no coding you're doing something wrong. Why don't you start automating your regression suite? Set up api tests, UI tests, build up a central reporting system, start working with the shit ton of data you generate, create automated risk and impact predictions on commit and become the expert in your company when it comes to how your application works and I guarantee you, in less than a year you'll have a resume with which recruiters will hunt you down for junior or professional position. If you still want to leave, what in my experience are few after they tasted what QA can be if done right.

Make wild assumptions about the data you'll work with, put those assumptions into an email, send it to pm and cc the highest boss you can think of and ask for approval "before you waste valuable company time". Since you are now on an open field your pm, being management, will write up a lengthy, elaborate definition of the data you can expect just to look good in front of the higher ups.

He got to stroke his ego, said higher ups will probably never even look into that mail and you get the specs you need. Added benefit: If it inevitably turns out to be bullshit you got your approval in written form.

@BlueSky You should just pressure your company to hire some QA engineers or software engineers in test. QA as a role has sadly been tainted nowadays and comes down to who at best have a very basic idea of technology. I personally blame the ISTQB but that's an entirely different battle. Also voice your concerns, loudly. Before I started at my current company a broken live build once or twice a week has been the norm so the higher ups got kind of numb regarding this problem.

Might seem like an asshole move to constantly nag about a department but it might be necessary just to make people aware that there even is a problem. Ceterum censeo is sometimes the only way to create that awareness.

If all of that fails, plan the task for your team. Explain that you have no trust into your builds and that you need API tests as a safety net. Let your bosses make the decision if they want to waste valuable dev time for something your QA should already be doing.

@BlueSky You can, they're just much more expensive than people who just click around. Also, would you do me a favor and just call these people you work with testers and not QA? It's slightly insulting towards any of us who put time and effort into actually mastering our craft.

Glenfiddich > 20 years here. Love that shit.

60*60*1.5*1000... Automated test suite ran roughly 1.5 hours and i wanted to create an alert for when it finished. I was stupid back then.

@VaderNT It doesn't have tabs, no native editor and no history beyond the current session. It also doesn't allow to elevate user privileges within a session. I'm not saying that it can't be used, just that it's not a reasonable choice for a terminal.

@NarkoCat Reasonable

@Stuxnet Well, they do willingly work on a system without a reasonable terminal... doesn't that already qualify as a mental disorder?

@ScriptCoded Depends, if we're talking about 500 character regexes that should obviously be a separate function, they're a pain. If we're taking about reasonable use they can be lifesavers.

@Owenvii Well, thats how the industry works, you won't always have someone to mentor you. Lower pay usually means they grant you more tolerance for mistakes and making your own mistakes is the best way to learn how to do it better.

So, electron is the thing we hate without reasons now? Don't get me wrong, I'm okay with that I'd just wish someone would include me in the memos when a new target is chosen...