|
|
boliver46
Junior Member
Reged: 02/06/02
Posts: 234
Loc: Toledo, Ohio USA
|
|
Hi All,
In my current organization, we have very disparate functional groups: internal facing applications development, external development, and shop-floor application development. We are trying to standardize some of the roles/practices in the organization - to the point where we're trying to define "what exactly should the core competencies of a QA person be?" This can involve anything from Test Management, Requirements Management, all the way down to Test Tool Administration and Maintenance. To give you an idea of how vague my edict is, here is the actual email I received from my manager:
"How about this…can you give me an objective assessment of a QA skill-set and show core competencies and highlight the core areas of QA."
Vague much?
Anyways, just looking to see if anyone has put together a similar list or has input on how best to respond to this request.
Thanks much!
-Brett
--------------------
http://www.sqaforums.com/showflat.php?Cat=0&Number=590749&an=0&page=0#Post590749
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
Well, first of all, yes that is very vague. Since that is so vague, are they talking about core competencies for a QA person or a tester. Sometimes we toss these into the same grab bag, when they are distimctly different in their job function.
If we're talking about testers, and I'm going to go ahead and assume we are since the vague nature of the email makes me want to believe we are, then I generally look for very intangible qualities. This might not even be seen as a skillset, really. I hire new interns on as testers just about every 4 months, so there are distinct things I look for in a candidate.
1) Problem solving. A collegue of mine that I interview with actually introduced me to a great question on this one. How would you test Pong? It's actually a gem. Some people just say, "I don't know". Others get down to the level you want to see like basic things like "Make sure it tracks teh score properly and someone wins." to "I'd measure the trajectory of the ball to ensure it's bouncing properly." It really is a gem of a question. If candidates fail on this, they usually don't get the job, in my book.
2) Communication. Does the person communicate their ideas or views well?
3) Detail. How detailed are you? There has to be just the right amount of detail in a bug explanation, right?
4) Interest (Passion). If someone is uninterested in testing then I often find they are really difficult to motivate.
Is that all? Probably not. I'm sure I'm not thinkig of something right now. Is this even what you're looking for? I don't know.
All I have to say is, "I've got a fever, and the only cure is more cowbell!"
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
Edited by brentpaine (01/19/09 08:44 AM)
|
jmg
Advanced Member
Reged: 06/11/08
Posts: 529
|
|
I wrote an article describing the what makes a good tester.
I agree with the points the Brent wrote but I also look for business orientation and the ability to self-learn.
--------------------
-joel
9 times out 10, less is actually more
PractiTest - QA and Test Management Tool
PractiTest QABlog - Testing Blog
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
Oh, wow, yeah good point Joel. I had this one tester once when I was leading a team and they had poor learning skills but also poor judgement. I guess judgement could be another, but I don't know how you could track that.
Anyway, they would be hovering over my desk, what seemed like, every 5 minnutes asking questions. In addition, I would take items off their plate, like writing a macro to do something, because I already had the basic code, and they would go off and start researching how to do it themselves. So there is a difference between self-learning and time wasting. If they had spent an hour trying to figure out how to do it themselves and then came to me, I wouldn't have a problem with that. However, if you come to me first and then I tell you I have, basically, all the code for that and I just have to chunk it together, then you go off and try to learn it fr yourself, that's poor time management.
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
|
jmg
Advanced Member
Reged: 06/11/08
Posts: 529
|
|
Hi Brent,
You've got a good point there. There's a thin line between self learning and wasting time re-inventing the wheel.
I've specially seen this in young engineers who
(1) Want to prove themselves in the eyes of the system (and their managers!),
and
(2) Suffer from the "not invented here / by me" syndrome.
Still, I think you'll agree with me in preferring these guys over the ones who wont move a finger without asking questions. With the first group you can still explain to them that they need to apply common sense and stop competing with shadows.
--------------------
-joel
9 times out 10, less is actually more
PractiTest - QA and Test Management Tool
PractiTest QABlog - Testing Blog
|
Ainars
Advanced Member
Reged: 09/16/04
Posts: 491
Loc: Riga, Latvia
|
|
Brett,
Let me guess you are in a deep trouble. I expect that QA skills and competencies actually differ from group to group in your company.
Let's take me and Joel for example. I don't think ability to analyze a product (the requirements and constraints of the business) is easy to learn. I have this skill as #1 in my list. But well, it maybe depends on my project context as we are building really large applications for big companies.
While Joel seems to be working more with low or medium sized projects, where you could be the only tester in a project.
I recommend to discus skills/competencies for (with) each group alone first and then compile the lists together. And I would describe this process in a response email.
P.S. I'm 10+ years in testing but depending on context I still like to reinvent a wheel and I welcome my team to do so http://www.testingreflections.com/node/view/7767
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
Quote:
Let me guess you are in a deep trouble. I expect that QA skills and competencies actually differ from group to group in your company.
This could definitely be the case. We have a number of business units in my shop and each has a different set of requirements, although I do often interview with a collegue of mine from another of our business units who hires based on similar characteristics to me. Diveristy isn't a problem, though, it's a gift. Understanding where and what these diversities are, and how to benefit from them, is the challenge.
Quote:
Let's take me and Joel for example. I don't think ability to analyze a product (the requirements and constraints of the business) is easy to learn. I have this skill as #1 in my list. But well, it maybe depends on my project context as we are building really large applications for big companies.
First, I don't think that the ability to analyze a product is as hard a skill to learn as you might think. We are talking about an age where kids are coming out of school after taking, what I would consider, University-level Computer Science courses and grades 11 or 12 of high school. They have grown up on computers and, many, may know more about how a product should work than what you do, regardless of experience. There is plenty they lack as far as the management side of the game is concerned, but these kids have seen hundreds of applications, have grown up on computers, and are well versed in how an application should operate.
Secondly, I don't think this skill has anything to do with the size of your product. Obviously the ability to analyze a product becomes more important the larger the product is, the result of mis-analyzing a product will always be the same, it makes it to market and nobody buys it. Whether you're talking about a $50 consumer app or a $50,000 corporate app, the end result is find a new job because the company is going under.
Quote:
I recommend to discus skills/competencies for (with) each group alone first and then compile the lists together. And I would describe this process in a response email.
I agree with this. It could be a great starting point.
Quote:
P.S. I'm 10+ years in testing but depending on context I still like to reinvent a wheel and I welcome my team to do so http://www.testingreflections.com/node/view/7767
I have a problem with this. In your post you say, "I reviewed the test documentation and found it a good one. But not mine. I can’t follow it because I never wrote it myself."
Do you honestly consider this to be a good quality? If every tester wasn't able to follow documentation because they didn't write it, we'd be in a whole lot of trouble.
Personally, if you can't follow the documentation, the you don't have a wheel. Well you might have a wheel, but it's square. You need to round that off and make it more accessible.
If it's truly just you, the you can go right ahead and do exploratory testing, that's fine. I still don't think it's an effective or efficient strategy, though. Even though you found bugs, which is our goal in QA, you never identified areas for improvement in the test cases, so you haven't done your staff any favors. Much like what Joel mentioned above, I would consider this to be trying to prove something to yourself.
I will get into the odd test cycle myself. My goal, though, isn't to find bugs. I actually hope I don't find bugs. I consider it to be a spot-check of sorts. I trust my team fully, and I feel they are probably better testers than I am, since I don't actively test all the time, every day, all day. So when I find a bug running through test cases, I raise questions. Is this new? If so, why was this missed? Are there unclear or poorly-written test cases? Are bugs being documented in their entirety? Can I make sense of the defects reported and can I reproduce the errors with ease?
I run a pretty laid back environment. However, it's still my ship, and if I can't understand what's going on in my ship, or if there is something making my ship inefficient, I want to correct it, not just get up on deck, spin the wheel a couple times to see what happens and assume everything is running as expected.
Sorry, I don't agree with you on that point at all, obviously. I totally agree that management should be getting their feet wet once and a while, but it's not necessarily to find new bugs, it's to see how things are actually working. I'm not going to lord over my staff because I found 5 bugs today and they only found 3 each. I don't see how finding bugs in a management position provides any value to the end product. Afterall you're getting paid more money to help your team find those bugs, not by going out and pulling them out yourself. The dollar value for you to pull those bugs out is likely more expensive than a tester pulling it out, unless you transfer that knowledge in some meaningful way other than, "I was poking around in the system and found these bugs."
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
|
rtehve
Active Member
Reged: 08/21/00
Posts: 1165
Loc: Warriewood, NSW, Australia
|
|
jmg
Good article, I express similar views all the time, being a good tester is more about personal attributes rather than technical skills. Even with the technical skills you only have to learn the basics as a tester, otherwise you start looking like a programmer. I know many performance test specialists that could easily cut code.
--------------------
Robert Tehve
rtehve@bigpond.com
|
Ainars
Advanced Member
Reged: 09/16/04
Posts: 491
Loc: Riga, Latvia
|
|
Quote:
If every tester wasn't able to follow documentation because they didn't write it, we'd be in a whole lot of trouble.
Bert. I didn't mean I can' follow. I mean I decided it would be more efficient and effective not to follow, but do pure Exploratory Testing instead (fact that you misinterpreted what I wrote in blog only back-up my idea that anything written by one person has a different value to other, doesn't it?). But that's my view and I accept that most of test managers will not agree with me. More over even I wouldn't agree 5 years ago.
But I'm afraid I'm stealing a thread here. So let me just say this - I think that our disagreement only prove that testing, it's management and skills required as a result depends on project specific.
And by the way analytic skill as #1 was based on 25 tester survey in my company and backed up by 3 test managers, though I myself put communications as #1. Read more http://www.softwaretestingclub.com/profiles/blogs/tester-qualificationsskills
Edited by Ainars (01/22/09 01:00 AM)
|
michaeljf
Veteran
Reged: 09/17/01
Posts: 3456
Loc: Yankee Land
|
|
Ainars when I read the blog post I got the same indication as Brent did about your statement:
Quote:
I reviewed the test documentation and found it a good one. But not mine. I can’t follow it because I never wrote it myself.
I realize English is not your first language, but this doesn't mean what you think it does, I'm not critiquing it just trying to say that it is not only Brent who was confused by what you wrote. It's not that its misinterpretation but a clarity issue, where phrasing that is not in clear language will sow confusion.
It was a good article, but I'm not sure that I would spend my time doing just Exploratory Testing because the test document was not mine, but an employee of mine. Although I have always reviewed my employee's test plans, so I was always sure that if the time ever came I needed to run their plans I was able to follow and understand what they were doing.
--------------------
- M
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
- Unknown
Now wasting blog space at QAForums Blogs - The Lookout
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
Quote:
Quote:
If every tester wasn't able to follow documentation because they didn't write it, we'd be in a whole lot of trouble.
Bert. I didn't mean I can' follow. I mean I decided it would be more efficient and effective not to follow, but do pure Exploratory Testing instead (fact that you misinterpreted what I wrote in blog only back-up my idea that anything written by one person has a different value to other, doesn't it?). But that's my view and I accept that most of test managers will not agree with me. More over even I wouldn't agree 5 years ago.
But I'm afraid I'm stealing a thread here. So let me just say this - I think that our disagreement only prove that testing, it's management and skills required as a result depends on project specific.
And by the way analytic skill as #1 was based on 25 tester survey in my company and backed up by 3 test managers, though I myself put communications as #1. Read more http://www.softwaretestingclub.com/profiles/blogs/tester-qualificationsskills
I agree, we may have hijacked the thread there a little. Thanks for noting that and we'll put it back on topic. Just one last comment, I completely acknowledge that there are different management styles and we probably won't agree on how we should be managing testing or other aspects, and that's fine. I also don't see an issue with dropping in for some quick ET here and there (that might be all we have time to do). That can provide us with an opportunity to at least pull out some bugs so we can identify why they aren't being found. I, personally, wouldn't make a practice of it though.
When I first took on a management role, I very much had delusions of grandeur, of still dipping into testing and also still managing our automation projects (which I was doing prior to that). The person I was taking over from told me there would be no way I could do that. It simply wasn't possible. I agreed with her, but always thought in the back of my head I could do it. So when reality kicked in, I saw what she meant. So that's the reason I try to spend most of the testing time I do get wading through whatever new has been created. It give me an opportunity to verify our coverage and give me warm and fuzzies that people are strolling down the right path.
Anyway, that's the last I'll say on that.
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
|
yagsy
Advanced Member
Reged: 11/26/01
Posts: 560
Loc: San Diego, CA
|
|
Brent wrote:
Quote:
First, I don't think that the ability to analyze a product is as hard a skill to learn as you might think. We are talking about an age where kids are coming out of school after taking, what I would consider, University-level Computer Science courses and grades 11 or 12 of high school. They have grown up on computers and, many, may know more about how a product should work than what you do, regardless of experience. There is plenty they lack as far as the management side of the game is concerned, but these kids have seen hundreds of applications, have grown up on computers, and are well versed in how an application should operate.
I quoted this because the number one skill I am looking for in any candidate is the ability to think...not necessarily to problem solve as I would put that on my list but as a separate skillset.
The quote above though got me to respond because what I find with those who did/do grow up with computers/cell phones and PDAs is that things are done for them and 90% of people in general cannot think outside of the context. If you have someone analyze a computer program can that person take the skill of analyzing something else in the same manner but strip the subject matter from them? I just had this exact discussion with a couple of recruiters because we're screening people out based on this one important skill - to think.
An example of what I might give a person for an exercise (and did today to one of my junior team members that I am mentoring): Recently there was an article about baseball's salary cap and how the New York Yankees will still be the team to beat no matter what with all the superstars and disregard the salary cap. A team like the Tampa Bay Rays will only be lucky to beat them because they don't have the money like the Yankees to spend on the most talented superstars. I made a strong case that the Rays were the team to beat and why, using historical evidence to prove my specific points.
As we are both baseball fans, he understood my points, and actually could see how I got the result I got. Then I said to him, "now here is your homework assignment...take the idea of the analysis breakdown about the salary cap and give me some sort of analysis on embedded testing." I told him I didn't care what the subject was, but I wanted him to use examples and historical events to prove his point and give me a paragraph or more if he chose.
The exercise is simple - choose a puzzle/statement/event etc and work together that example. Then pull the subject matter out from under and change the subject matter. If a person can give me something reasonable to prove the ability to think and then apply skills learned, I am far more interested in taking a chance on that person than someone who specifically has "engineering degree" or specific "embedded testing experience" although I would love to find someone with that as well. Training that person and their own ability to self teach are natural artifacts that come along with the ability to think and reason.
My signature line is something I personally look for in a person - not that someone gives me the right answers but HOW can recover.
--------------------
Going out of your comfort zone requires failure. True genius is measured by your recovery.
...Jean Ann
Edited by yagsy (01/22/09 01:52 PM)
|
michaeljf
Veteran
Reged: 09/17/01
Posts: 3456
Loc: Yankee Land
|
|
Jean hits on exactly what I used to look for in people who I hired, and built my team with, while they had different skills and that was a goal they were also independent thinkers. I'm not as impressed by what some people have done, though I have worked with people who've built robots that can go into the deep sea and ones that can explore volcanos, impressive people they were but were they able to think outside of their comfort zone? Not all, and not in all situations. Independent thinking is something I like to believe we all have, its a matter of tapping into it and exercising it so you can learn to apply situations from one context to another. Malcolm Gladwell is a writer I enjoy because he touches on this, and is the only writer of a non-tech nature who shares my bookshelf at work so far.
--------------------
- M
Nothing learns better than experience.
"So as I struggle with this issue I am confronted with the reality that noting is perfect."
- Unknown
Now wasting blog space at QAForums Blogs - The Lookout
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
I totally agree with Jean-Ann. We look for thinkers also, because we are rotating through interns so quickly (every 4 months, that I can't take 2 months to show yo how something works, you need to be able to figure it out in a week or a couple weeks.
I used to ask this brain teaser, "Your ping pong ball falls down a 3-foot deep pipe that is nearly the exact diameter of your ping pong ball. How can you get it out?"
That was paraphrasing, but the one answer I always remember to this was simply, "I wouldn't try to get it out, I would go buy a new one." This isn't an uncommon response, but I asked why would he waste his money on a new one when he could try to get the one out of the ground and his response to that is what impressed me. He simply said, "Well the time it would take me to think of a good solution to get the ball out of the hole and the resources I would use in trying to retrieve the ball would far outweigh the price of a new ball." He turned out to be a pretty good intern.
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
|
yagsy
Advanced Member
Reged: 11/26/01
Posts: 560
Loc: San Diego, CA
|
|
Brent I love that answer your intern gave you on that puzzle. Well thought out.
I was conducting weekly "conceptual/creative thinking" meetings to my SQA team memmbers and trying hard to encourage them to lead a class but we'll get there... Next week though, I've opened this up to the developers as well and I was pleasantly surprised that most of the developers accepted the meeting much faster than my own team members who are required to be there. I'm really looking forward to next week and Brent, I must say, I am going to use that exercise. Thanks!  I will be sure though to give you the credit!
--------------------
Going out of your comfort zone requires failure. True genius is measured by your recovery.
...Jean Ann
Edited by yagsy (01/23/09 11:05 AM)
|
rtehve
Active Member
Reged: 08/21/00
Posts: 1165
Loc: Warriewood, NSW, Australia
|
|
brentpaine
If this person really existed, I would hire them http://www.snopes.com/college/exam/barometer.asp
Education systems do tend to try to make you bricks in the wall.
--------------------
Robert Tehve
rtehve@bigpond.com
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
Oh, I'm loving the the Pink Floyd reference
Yeah, Richard, I do prefer a little common sense, for sure.
Another good example I found in my last round of invterviews. A candidate brought in a little portfolio which included some screenshots from a game he did. I asked him how he tested the game. He gave me, what I would consider, a very vanilla answer, much what I would expect from someone who never tested before. He played the game and made sure it performed how he designed it to.
The game was basically blocks dropping from the top randomly and you have to shot them, and they sometimes break into smaller blocks and you have to shoot those too. Pretty simple.
So, to give him some schooling in testing I asked him why a couple of the blocks were overlaping in one of the screen shots. I said that this is something I would report. If they were blocks and the game is in 2D, then they shouldn't be able to overlap, they would collide.
He seemed intrigued by that, even though it was very simple. He then threw one back at me and said, if the blocks were overlapping and the bullet hit the blocks at the exact same time, then what would happen? I was impressed with the kid. My only response to that was pretty much, "yeah, that's what we look for."
We to bring him in, but didn't get him, but I like to feel I opened his eyes a little anyway.
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
|
boliver46
Junior Member
Reged: 02/06/02
Posts: 234
Loc: Toledo, Ohio USA
|
|
Although this was hijacked, it opened up a whole new GREAT discussion.
I appreciate all the insight/theories/discussions. Yes, I am in a bit of trouble in that the divisions in our organization are greatly diverse, and their expectations for QA are very different. One group anticipates more of the "Tester", vs. the QA idea - churning out test cases with little input into the entire SDLC. They also see us as "non-technical", despite the fact I can create functional and performance test scripts that "expose" their technical developer's penchance for errors.
Anyways, prolly a long road ahead of me - just think - I've only been here 2 months and already being questioned on where QA fits in and it's value to the Enterprise!
Thanks all!
-Brett
--------------------
http://www.sqaforums.com/showflat.php?Cat=0&Number=590749&an=0&page=0#Post590749
|
brentpaine
Veteran
Reged: 03/09/07
Posts: 3749
Loc: Waterloo, Ontario, Canada
|
|
I don't know about hijacking, there is a lot of good information here about core competencies ;P
Technical vs Non-technical is a completely different arguement. As I said before, your testing can be as techincal or as non-techincal as you like. I've had many testers who are not technical to the point of being able to write a simple automation script. So testing could be judged as non-techincal, sure. You could, really, give an application to someone on your marketing team and have them test it. They will probably find all sorts of issues with it. I can accept that. However, I would doubt if they would expose any "real" problems.
On the other hand, some people are completely techincal, such as yourself. We write scripts to increase our test coverage, we have a knowledge of how to test a software application, we know about various programming languages and pitfalls that come along with each of them. These are all techincal characteristics of the job.
As for proving the worth of QA, you could always take an untested application and give it to a QA and also give it to someone in marketing. Let them test it for the day. See how many major issues were missed by the person in marketing. Then estimate the cost of releasing that error. This is the cost to the enterprise.
The economy is tough these days. The problem is that people start looking at where they can cut back. QA looks like a great place to start because we don't produce any sort of physical product. However, it usually goes unnoticed that without QA the product would, ultimately, fail in the marketplace.
QA is like insurance. I mean I think I've been paying for insurance for 14 years now. So I've probably paid, let's say, $35,000 in insurance in my time. I had a little fender bender once, and actually settled it outside insurance because it only, really, cost me $300 and I didn't want it to go on my record, because then I get a bad reputation with my insurance company, right? And you don't want that bad reputation. So why do I pay for insurance? I mean I've never had to use it, right? Plus, with that money, I could have bought 10 used cars in half-decent shape. Well, we all know why we pay for it, it's not the cost of the car, it's the fact that if we ever did cause an accident and get ourselves sued, it could end up bankrupting us. So without QA, you might survive for a little while, or you could get nailed straight out of the gate, but the results could end up coming at the cost of the company itself.
--------------------
Brent
--------------------
9 out of 10 people I prove wrong agree that I'm right. The other person is my wife.
--------------------
What is Holistic Testing?
|
boliver46
Junior Member
Reged: 02/06/02
Posts: 234
Loc: Toledo, Ohio USA
|
|
well i was using the term used in someone else's post. didn't mean it in a derogatory way as many times i myself open up a can of worms and go off on a tangent.
--------------------
http://www.sqaforums.com/showflat.php?Cat=0&Number=590749&an=0&page=0#Post590749
|
|
0 registered and 9 anonymous users are browsing this forum.
Moderator: Rich W., AJ, blueinatl
Print Topic
|
Forum Permissions
You cannot start new topics
You cannot reply to topics
HTML is disabled
UBBCode is enabled
|
Rating:
Topic views: 2138
|
|
|
|
|
|
Powered by UBB.threads™ 6.5.5
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
