IT/Software career thread: Invert binary trees for dollars.

  • Guest, it's time once again for the massively important and exciting FoH Asshat Tournament!



    Go here and give us your nominations!
    Who's been the biggest Asshat in the last year? Give us your worst ones!
Deathwing

Deathwing

<Bronze Donator>
16,967
7,988
Nija said:
Deathwing Deathwing I wrote up a big reply, but re-reading your post it wasn't quite what you asked.

It's not that developers don't want to review the output of the tests ran against their code. Instead, it's usually that development deadlines are so tight that they don't have time to do that kind of thing.

I would instead suggest that you don't have anyone examining the output of the tests. Use a computer - that's what they are for. When code is checked into certain branches it should kick off automated tests which will notify the person who checked in the code of the problems. Work on implementing that kind of system along with a way to keep on top of adding new tests as the product evolves. Setting up and expanding systems like that are roughly an infinite amount of work. The results are usually measurable, too, so it looks good for you long term.

Get the ball rolling with open source tools. Jenkins + your test framework of choice.
Click to expand...
That's pretty close to what I want to do. We already have an in-house test system that does continuous testing against trunk(or whatever branch we're in). 99% of it is continuous in the true sense of the word, so results are being generated that need reviewing regardless of commits. My idea was to have developer "interrupt" continuous testing with their commits(before actually committing) so they could get targeted coverage based on what their code is touching. When that comes back clean, they'll likely get permission to commit to trunk.

I understand the comment about development deadlines, but isn't that exactly why a better accounting of the true cost? If it cost 2 weeks to program something and then 1 week to fix the bugs it caused, shouldn't you be given 3 weeks, not 2?
 
T

Tenks

Bronze Knight of the Realm
14,163
607
Deathwing said:
I understand the comment about development deadlines, but isn't that exactly why a better accounting of the true cost? If it cost 2 weeks to program something and then 1 week to fix the bugs it caused, shouldn't you be given 3 weeks, not 2?
Click to expand...

Thats why you should attach the bugs to the main story. Honestly I think time tracking and everything is pretty fucking worthless but if you're really concerned about it just roll up the time spent by the story + subtasks/bugs.
 
Deathwing

Deathwing

<Bronze Donator>
16,967
7,988
Tenks said:
Thats why you should attach the bugs to the main story. Honestly I think time tracking and everything is pretty fucking worthless but if you're really concerned about it just roll up the time spent by the story + subtasks/bugs.
Click to expand...
And time spent monitoring test results and filing bugs(not a specific bug) goes where? When QA monitors trunk instead of a specific branch, that time becomes much harder to bill accurately.
 
T

Tenks

Bronze Knight of the Realm
14,163
607
Deathwing said:
And time spent monitoring test results and filing bugs(not a specific bug) goes where? When QA monitors trunk instead of a specific branch, that time becomes much harder to bill accurately.
Click to expand...

We have a jira plug-in for QA called TestRail that seems to take care of that. I don't really pay too much attention to their time tracking but the QA higher-ups are really anal about it.
 
Lendarios

Lendarios

Trump's Staff
<Gold Donor>
19,360
-17,424
Deathwing said:
I understand the comment about development deadlines, but isn't that exactly why a better accounting of the true cost? If it cost 2 weeks to program something and then 1 week to fix the bugs it caused, shouldn't you be given 3 weeks, not 2?
Click to expand...

The problem with numbers, is that sooner or later those numbers will be used against developers, It is also hard to estimate properly.
 
Deathwing

Deathwing

<Bronze Donator>
16,967
7,988
Tenks said:
I can't speak for Team5 and how they do their QA since I haven't really worked with them a whole ton but I can go over how we do QA here on battle.net purchasing.

First, and pretty obvious, all your work you do is attached to some sort of story/bug in jira. Though not required for the most part you create a branch for each story in jira unless you're doing very greenfield development work. You branch off master and implement your changes. I then build my stack locally and do a very brief test to make sure the main-line case works. We then have a central CI location for integration testing and first-pass QA testing. The CI environment is ok but not perfect since it can get out of date with what master really is because sometimes people put experimental shit in there that never goes to master. But it works out fairly well.

At this point I drag my story over to ready for QA. Here on BNet we have embedded QA staff. This isn't always the case for game teams. But we have our "QA guys" who sit in the bullpen with us in case they need to ask questions and get clarity. This is pretty important. It is required that developers and QA have a symbiotic relationship. I know QA isn't out to get me and QA knows I'm trying to give them quality code. We're all in this together trying to put out the highest quality product we can put out. So anyways at this point QA does a more rigorous test of various edge cases and scenarios. This isn't really engineering's job to do this. As an engineer I'm expected to write features and fix bugs. If you expect the engineers to spend half a day doing QA work that engineer should be paid less. I want very easy to understand reproducible steps. I am a smart guy so I don't need QA to belabor me with results just let me know the expected behavior and the failing behavior and how to do it. I'll work it out from there.

In the CI environment is where most bugs are found. Bugs with the story get attached and priority is assigned. Sometimes bugs are fine to go live with but other times not. In general QA has the final say if a story can go live or not. I'll fix and implement the bugs, smoke test, put into CI and re-assign back to QA. Once everything has passed I then go into the release pipeline. We deploy for the most part weekly here. I'd estimate maybe 45 planned deploys a year or so. I merge all my branches into the release branches and then QA tests once again in the release environment. For the most part everything passes here but it is important to release test again since this is the candidate for production. Once QA has given the go-ahead for the deploy we are ready to go to prod.

This is all the manual process. We also have automation engineers that generally do in-project automation against the CI environment.
Click to expand...
Sorry, this is a slight tangent, but why is QA work less valuable than development? And I don't mean from the market demand vs supply standpoint. I get that less people can hack it as developers than QA, though I honestly don't have any data to back that up from either standpoint.

But, as I mentioned in the original post, I've been QA my entire career. That feeling of second class citizen is not isolated or new and I know other people feel it. The guy we hired to replace my vacancy when I was promoted is already trying to move into a dev position(within the company), stating he thinks staying in QA is damaging to his career.

I think I'm a little emotionally invested in this argument at this point. All I know is that I'm happy when development testing tools for developers. Or just plain developing The more time I spend reviewing their mistakes, the less time I have to do the (interesting) stuff I'm already tasked to do. I thought it logical to make the connection that the people causing the mistakes should be spending the time cleaning them up. Maybe I'm in the wrong and I should get out of QA. Definitely a thought I have to continuously fight.
 
T

Tenks

Bronze Knight of the Realm
14,163
607
Deathwing said:
Sorry, this is a slight tangent, but why is QA work less valuable than development? And I don't mean from the market demand vs supply standpoint. I get that less people can hack it as developers than QA, though I honestly don't have any data to back that up from either standpoint.
Click to expand...

You basically just said it. It is harder to find competent developers than it is to find competent QA. Purely anecdotal but almost every person I worked with at my internship who couldn't program themselves out of a brown paper bag are now professional QA analysts or do PM work. You can train up anyone to call an API and mutate arguments into it but you can't train up everyone on how to actually write the API. I honestly have great respect for the QA staff on my team because I wouldn't want to do it but I also wouldn't want to work a cash register at WalMart. That doesn't mean everyone deserves equal pay.

Also to really hammer it home I love it here because the QA staff actually gives a shit. At my old job the entire QA staff was worthless and wouldn't test shit. When they did test shit they basically just re-ran my mainline cases.
 
Big_w_powah

Big_w_powah

Trakanon Raider
1,887
750
What is you guys' opinion on development passing on everything "production/deployment" to the systems team?

Development builds a release, QA signs off, and then....we manually deploy files, manually create/update any services, etc..

Ive had my guys building/updating installers just to make our lives easier....But I get push back from Development if I tell them they need to build an installer..They claim deployment/production/releases are our problem, and if they can pass QA with their in house builds they're done.
 
Noodleface

Noodleface

A Mod Real Quick
38,377
16,298
Here I am wondering what qa is

At Emc we had a dedicated firmware QA group and they were great. They ran regression testing every night that would pull any commits from master in, build the UEFI roms, flash them, and run through an automated test suite. The entire dev team got emailed the results of the previous nights test. If a bios test failed, my boss would delegate one of us (probably who did the commit) to look into the log and try to make sense of it. If it was a real issue then we'd assign it to an appropriate team member and triage.

I never felt that reviewing logs was a burden or even something I'd want QA doing. If my feature was to add bifurcation to a pcie card and the test is failing because the card is showing up with a x16 bus instead of two x8x8 busses what the hell is the QA guy gonna know about that?

I did part of my internship there working with the QA team and it was a pretty thankless job by many. Maybe working there made me appreciate it a little more.

Here our QA just makes sure tests aren't broken. It seems scary because this shit goes out to the fleet.
 
Deathwing

Deathwing

<Bronze Donator>
16,967
7,988
Tenks said:
You basically just said it. It is harder to find competent developers than it is to find competent QA. Purely anecdotal but almost every person I worked with at my internship who couldn't program themselves out of a brown paper bag are now professional QA analysts or do PM work. You can train up anyone to call an API and mutate arguments into it but you can't train up everyone on how to actually write the API. I honestly have great respect for the QA staff on my team because I wouldn't want to do it but I also wouldn't want to work a cash register at WalMart. That doesn't mean everyone deserves equal pay.

Also to really hammer it home I love it here because the QA staff actually gives a shit. At my old job the entire QA staff was worthless and wouldn't test shit. When they did test shit they basically just re-ran my mainline cases.
Click to expand...
Most people just hate doing QA. We're doing manual testing for a release and it's like pulling teeth to get people to follow a checklist. Spells everything out for them? Boring. Leaves stuff up to them? Why aren't you telling me what to do?

I would disagree on the dev vs QA availability part. We've had an open position for QA for at least a year, it's part of the reason why the system is so broken. Now, being in Ithaca, NY might be a non-insignificant compounding factor, but we seem to be able to fill dev positions relatively fast.

I'm wondering if the pay differential between dev and QA is much smaller at Blizzard than it was at your former employer. Again, I always have thoughts that I'm making the wrong decisions with my career but at the same time, at this company, I'm doing a job it seems no one else wants to do and I'm getting substantial bonuses and raises YTY in a low cost of living area. Thus, here I am wanting to fix the system instead of just cut and run. Maybe the QA at Blizzard are paid to give a shit, essentially.
 
T

Tenks

Bronze Knight of the Realm
14,163
607
According to glassdoor the pay difference is pretty big still. I know my company isn't like most but we get a metric fuckton of people for QA and in general most QA staff are former CS reps.
 
Lendarios

Lendarios

Trump's Staff
<Gold Donor>
19,360
-17,424
There is something on TFS called Gated Check in. on which all test must successfully run before the checkin is accepted.
I like this method. You shouldn't be checking in stuff that breaks stuff.
 
  • 1Like
Reactions: 1 user
Deathwing

Deathwing

<Bronze Donator>
16,967
7,988
Tenks said:
According to glassdoor the pay difference is pretty big still. I know my company isn't like most but we get a metric fuckton of people for QA and in general most QA staff are former CS reps.
Click to expand...
Maybe we're using the term QA term to broadly here. How you described your automation engineers is how I'd like our QA department to run. Manual testing and reviewing should be a "as required" process that should be avoided or automated if possible.

What we require of our QA people could not be accomplished by a CS rep. Which, now sounds like the elitism I was just trying to combat a few posts ago. The lines get so blurry at a smaller company.
 
T

Tenks

Bronze Knight of the Realm
14,163
607
Our automation engineers are still generally people who have just been around a while. I'm not sure if any of them hold comp sci degrees. We do try and transition some into development work if they show an aptitude.
 
Deathwing

Deathwing

<Bronze Donator>
16,967
7,988
Tenks said:
Our automation engineers are still generally people who have just been around a while. I'm not sure if any of them hold comp sci degrees. We do try and transition some into development work if they show an aptitude.
Click to expand...
Interdasting. Everyone here has to be fluent in programming applicable to their job role. Hence the frustration at rarely ever exercising said programming skills. Maybe the problem is more specific to this organization and lack of man power at this company rather than the delineation of responsibilities.

Still, would like to automate this stuff as much as possible.
 
alavaz

alavaz

Trakanon Raider
2,003
714
Just like most IT titles, QA varies greatly in scope from job to job. At most of the places I've worked QA are a couple of dudes who run a quality center server and email out automated test results to developers (and often admins as well for some reason). Most of the people either moved onto developer or project manager positions. Hell, Microsoft even completely axed their QA/Test department entirely a few years ago.
 
Xarpolis

Xarpolis

Life's a Dream
14,868
16,692
So about a week ago, a friend of mine (in the tech industry) and his co-worker were interviewing a new programmer for the company. Suddenly the co-worker starts saying all kinds of sexual stuff. How his dick gets so hard or whatever, and how my friend has a tiny dick. Anyway, the potential employee got uncomfortable with what he was saying. The meeting was over shortly after that. Keep in mind all 3 people in this meeting were male.

So I told my friend to go email both HR & his boss and report the co-worker. The very same co-worker that has repeatedly gone to his boss to complain that my friend should be fired because he's only working part time (where as my friend is the only programmer. The co-worker is just a graphics guy).

A week later and he still hasn't gone to HR to tell about the situation. I told him he's being fucking stupid. If this candidate ever decides to sue the company for not getting a job because he didn't cooperate in the sexual discussion, they're both fucked. Even if it was 100% what the co-worker was saying, and not my friend. He told me that the reason he hasn't gone to HR (or even told his boss about the incident) was because the boss said they need to be a team, and he feels that if he tries to rat on his team-mate, that will create animosity between them. Honestly, it's already there. He's also afraid that reporting it will in turn put his own job at risk.

What do you guys think? Oh, additional info, my friend works for a fortune 500 company, but he is the ONLY programmer in his division. It's a relatively small division inside of a much larger company.
 
Khane

Khane

Got something right about marriage
20,626
14,373
You have some really fucked up friends Xarpolis. Also, this is probably the wrong thread.

Maybe we should create a "Silicon Valley Sex Corruption" thread or something.
 
You must log in or register to reply here.