| weather | : | raining | |
| outside | : | 11°C | |
| mood | : |  | perplexed |
It's amusing. People will very carefully shift their eyebrows and rearrange their face to create this somewhat menacing look, complete with a well-practiced evil gleam in their eyes. Some will even go so far as to clench both fists and either make a small whipping motion or come just short of pounding them both simultaneously on the conference room table, presumably to show extra determination to break something.
Why on earth would people think that destructiveness is a good trait in a human being?
Quality Assurance is not [only] about breaking things... at least not in software... at least not in my shop. If you inadvertently break something that should not be broken by what you have done, then that's a problem that needs to be raised. But that really isn't the point.
My top pick was the same as my boss': the guy who didn't say he liked to break things.
Comments
Sure making things work is important, but I think a lot of times its easier to describe the problems that don't work, than those who do. --Ray
- defining what it actually _means_ to "work" or "break" and how that will be measured/judged
- answering the most fundamental question, "how will you know when you've found something that is wrong?"
- identifying problems in the design and implementation that could lead to problems later on
- writing the scripts, internal tools, test harnesses, etc. used to run tests
- how to keep track of things that don't work
- how to keep track of what's been implented, what's been tested
- how to keep track of what problems have been fixed and tested
- how to make sure that the fix didn't actually cause more problems
- how to make sure that the problems don't actually come back with more work on the project
- how to manage bugs that become new features
- how to manage which bugs get fixed and which ones can be ignored (if your application crashes while it's launching, then who cares that all menus are spelled right?)
- how to manage test assets
I'm sure there's stuff I've left out, but I'm building more than breaking =)
The concepts of extreme programming (XP), more specifically, building test cases, before even designing code is quite intriguing. Unfortunately, not all development are XP-based.
The difference I find about QA and Testing is like the difference between a programmer and a computer scientist. One is all-econpassing, while the other is a primary subset.
In any case, meeting the (functional) requirements through high standards of QA benefit not only the end-user, but everyone in between.... --Ray
I also disagree with some of the things and I'm sure that as a company, we'd never do — Pair Programming, for example. It's a complete waste of time. It's far more efficient to have developers implement their bit and then have code reviews, either peer reviews or group reviews with someone from outside of the project auditing.
meeting the (functional) requirements through high standards of QA benefit not only the end-user, but everyone in between
Absolutely. =)
I take back what I said. =) On the way home last night, I realized that we _do_ do that in some cases and I have done that in previous jobs, just not in a formal way and not full time. It's a very ad hoc thing, we just walk over to someone's office, start talking about the problem and it turns into Pair or even Triplet Programming (which I've been a part of as well) =)
But when your entire company is only 30 people big, it's not very feasible to make that general practice.
Mind if I ask how long you've been at this?
I started out as a fulltime Developer about five years ago. I was doing dev and other software related jobs part time while I was doing my Bachelor of Science in CS. I've been in QA for just over two years now.
I'm still crack on a BSc Computer Science, with concentrations in possible Software Engineering or Network Security, as well as a Pure Math Degree (BSc Pure Math). We'll see what happens.
Cheers. --Ray
The pair programming thing is incredible if you are not both full time on a project or if you are developing a really really critical resource under insane time constraints.
Discussing the dynamics of how something is going to be written and the overhead that comes with it aren't for every project, but xp is not about optimium production efficiency, its about looking at projects from different angles.
I've always gathered that xp isn't so much a methodology as a patch to the standard dogma, a book of tricks for when you get to the bottom of your own black bag and still haven't come up with a good alternate strategy.
That said, I use case studies on everything from crm relationships to streamlining my own processes internally here for the isp I work for. I find people find them much less threatening (behold my stick people and cloud diagrams) than flowcharts or bulletted lists.
If you are looking for qa qualifications, I'd look at uml experience and possibly people that have been exposed to the rational rose modeling system. Typically those type of people are more comfortable with abstraction, and tend to be more critical systemically instead of just "breakers".
Its too bad I couldn't use crc card styles for responding to posts like this one, it might help my encapsulation and structure.
I take back what I said. =) On the way home last night, I realized that we _do_ do that in some cases and I have done that in previous jobs, just not in a formal way and not full time. It's a very ad hoc thing, we just walk over to someone's office, start talking about the problem and it turns into Pair or Triplet Programming (which I've been a part of as well) =)
But when your entire company is only 30 people big, it's not very feasible to make that general practice.
Typically those type of people are more comfortable with abstraction, and tend to be more critical systemically instead of just "breakers".
I totally agree. There's a better chance that someone who has UML/Rational experience would understand the process.
Good luck in your job search! {{{ EMPLOYMENT VIBES }}} =)
Er... do I have you confused with another LJ friend's husband? There were a few unemployed husbands that I knew of =P Sorry...
I could stay here for a while if I needed to, but I'm being underutilized. Know what i mean ?
Re: underutilized — oh yeah, been there. That's icky in it's own way too =P I hope you find a fulfilling position soon.