-A Primer for QA/QC Contractors-
We’ve had some interesting experiences here in the past few months, and it seems to me that there are consultants/contractors out there that have a contest going to find out who can be rolled off assignment the fastest.
Well, I’m here to help.
Consider this blog a “How to Lose A Job” primer for consultants. Follow these helpful hints, and I can pretty much guarantee you’ll be booted in a few weeks, tops.
By the way, this will work for full-time employees as well, but the process will take much longer as whatever convoluted HR process your company has in place to remove your carcass from their premises will be followed. If you work for a state or federal employer, you’ll probably be able to retire first – even if you’re in your twenties.
HINT 1
One week into your new assignment, inform (do not ask) your client that you’ll be taking 6-8 weeks off for either a trip home, surgery, a wedding, or some other personal reason during the busiest time of their year. Chances are good your client will be on the phone with your account representative five minutes afterwards.
HINT 2
On your first day, inform (do not ask) your client that due to day care, transportation, or other issues, you will be working hours outside their core hours. Extra bonus points are given if you tell them you’ll “make up the time” somehow, in some way, some day. Maybe. Your client will probably put your account rep’s number on their speed-dial.
HINT 3
Tell your client the reason you leave early every day is that you “eat your lunch at your desk”.
HINT 4
Ignore your client’s dress code policy – repeatedly. This works best when some Admin in Charge of Rulebreakers humiliates your client manager by spotting you first and accosting said client manager in their office asking if they have Seen You. So be sure to parade back and forth in front of said admin until they notice you. Then look dumbfounded when your client manager sends you send you home to change. Repeat after me – “This is denim? You can see through this blouse? These are athletic shoes/flip flops? Really??? I had no idea!”. Forgetting to bathe – for a few months – is also helpful, as is dousing yourself with any type of scent that would kill roaches or rodents. Tabu or Jade East work well. You can test the efficacy of your scent by locking yourself in a room with your test object/victim. If you observe watering eyes, followed by wheezing, excessive coughing, uncontrollable spasms, violent convulsions, and finally death, you’ve found the winning combination.
HINT 5
Even though you have little or no experience with automation yourself, seek out the appropriate client team lead and inform him or her that they are doing everything wrong. You know this, of course, because you once breathed the same general air as someone who automated a test case ten years ago for a mainframe app. Bonus points are given if the position for which you’ve been hired has absolutely nothing to do with automation. Double bonus points if your sole experience with automation involves either capture/playback or setting checkpoints/parameterization for existing scripts. Triple bonus points if you think VBScript is a font like “Times New Roman”.
HINT 6
This is very similar to Hint 5. Attitude will be particularly important. You need to selectively find the most experienced client employees in the building, preferably people with at least 10 more years experience than you have, and expound on how much better Company X handles QA/QC. It’s especially important that you condescend as though your audience is somewhat challenged mentally. Bonus points are given if Company X has a reputation for poor quality, or if your work for the client has been either marginal or sub-standard thus far. Making statements regarding how you would never accept a job offer from the client, even though they’d be more likely to make a job offer to Donald Duck, will help your cause.
HINT 7
It’s always a good idea to forget you are a contractor and get involved in corporate politics. This is a particularly efficacious way to be rolled off assignment if you are really, really bad at politics and your view of success in this arena is defending the “little people” against all of the Big, Bad Management staff. Especially if the “little people” are happy with their jobs, are completely unaware that they are being mistreated, had no idea that you had suddenly become their champion, and have secretly been wishing you would just either shut up, die, or go away.
HINT 8
Drama queens are much in demand. Everything, especially personal issues, should be cause for wailing and flailing – loudly and to anyone and everyone that will listen. Bonus points are given if you cry all over your client manager’s desk. Double bonus points if you do it at least twice a week. Really personal reasons for the emotionalism are especially welcome to your client – hormonal imbalances, PMS, menopause, medication, hangovers, your crusty rashes keeping you awake at night, etc.
HINT 9
Miss every deadline set by your client and be sure to tell them the day the work is supposed to be finished. If you let them know you’re not going to make it ahead of time, they might have time to mitigate the problem. Bonus points for really creative excuses. Thus far, we haven’t heard:
“I was abducted by aliens and the anal probes put me in such pain, I couldn’t concentrate on my work.”
“I prefer to do all of my real work using OT; my spouse and I want to put an addition on our house.”
That’s about it; we’ve heard everything else.
HINT 10
Make a conscious decision to either make your client or one of your client’s employees your Love Slave. Nothing endears you more to a client than having their best analyst either sobbing into a hankie or trying to crawl into your skin during work hours instead of analyzing their latest set of specs. Bonus points are given if you stick around long enough to mow your way through more than one or two employees. Double bonus points if rolling you off will cause one or more employees to hate their management for treating you so cruelly.
_______________________________________________________
That’s it – 10 steps to help you on your downward journey to sitting on the bench – if your consulting firm has a bench. Bon chance……
Monday, October 6, 2008
Wednesday, September 10, 2008
CERTIFIABLE
Wherein One Examines One’s Wine-tasting Certification and Realizes it’s Probably the Most Valuable Certification They Possess…
Certification, education, and training continue to be hot topics in the QA/QC community. The problem is that there is nothing, at this time, that really gives a prospective employer with no experience in the field an edge for finding a qualified and talented resource. Understandably, they reason that someone with a given certification or degree must be more qualified for a job than the person without those qualifications. When you don’t know what makes a talented resource in our field or what questions to ask, you tend to lean on the “opinions” of some amorphous governing body and hope you don’t make a mistake.
There’s another problem with the fact that our field is inundated with different degrees, certifications, and training classes. Which ones are good? Which ones are bad?
Most experienced staff realize there is no piece of paper offered at this time that certifies someone is competent in their field. It’s irritating to most that someone who couldn’t test so much as a basic drop-down box on their best day could potentially be hired before someone who tested a major application by themselves, in two months, with no major errors in production because the lesser-qualified candidate has a piece of paper.
Also understandably, possessors of these various documents argue vehemently about respective worth.
I don’t normally spend much time talking about certifications, etc., because I think they’re not even worth the time to discuss, but as the number and types of certification, degrees, and training continues to proliferate, each one touting themselves as the Hottest Thing Since Sliced Bread, I find myself increasingly impatient with all of the nonsense and moved (at long last) to comment.
Let’s start with formal education. That is, college degrees. Several of the best known people in our field do not have one. Do you want to call James Bach “unqualified”? What about Edward Kit? Even if you do have a college degree, how many of you have a degree applicable to our field? If you majored in Computer Science, how many testing courses were required? Were you lucky enough to get even ONE? In what way does a college degree qualify you to work in QA/QC?
The answer is “it doesn’t”. A college degree does not qualify someone to become a tester and certainly is no indicator of talent. If the individual went to an institution that really EDUCATES, the best you can hope for is someone interested in learning and who knows how to think.
So let’s move on to certifications. Certifications certify you have an understanding of (X). (X) is determined by the certifying body, and it varies. For practioners of various kinds, many certifications require that you are already a professional in the field, that you have X years of experience in the field, and that you have demonstrated understanding of what they feel embodies a professional in the field. Note that the key is “what they feel”. What they feel embodies a “professional” and what you feel embodies a “professional” might be quite different. Furthermore, understanding something and practicing it are two different animals. This is why there is usually a “number of years in the field” associated with a certification. The hope is that knowledge/understanding of basic precepts coupled with actual experience in the field guarantees (some) degree of competency.
But does it? My answer is “no”. Because the certifying parties are often quite large, checking of credentials can be through sampling, or not done at all. Working in the field for (say) two years might mean you’ve hopped from job to job for said two years, and have been let go at every one of them. The certifying body may or may not verify their candidates understand the precepts that the bulk of professionals in the field feel are important. The purpose of many certifications is to make money for the certifying body.
So overall, certification is not an indicator of either competency or talent. In addition, the QA/QC field does not have “one” single, governing certification that is recognized as THE certification, which means everyone is not even on the same page in regards to basic precepts.
So what about TRAINING? This is the one area where I feel there is room to really “make a difference”. The definition of training (courtesy of Webster’s) is “to teach so as to make fit, qualified, or proficient”.
Well.
Now if THAT were true, every manager in the world would be snapping up graduates of said training program.
In my opinion, such a training program would need the following:
1. Only talented candidates could be accepted for the program. In other words, a robust pre-screening process would have to be in place. One thing I’ve observed, regardless of field, is that talented teachers want to teach those that truly have an interest or love for the field, and an ability to excel in it. In addition, exclusivity and a reputation for being the Best of the Best is marketable - to prospective students, prospective teachers, and prospective employers.
2. The program would have to contain classes that cover the gamut of potential working environments and methodologies. There’s a difference between working on an iterative government project involving social work and an XP GUI screen for internal ordering of office supplies, for example. Graduates of the program would have to have the ability to excel in any type of situation.
3. Teachers and the courseware offered would have to engender the respect of professionals currently in the field. That means locating and attracting big names and popular/knowledgeable people willing to teach. It also means qualification for teachers has to be somewhat different than much of the academic world. The best teachers in our field may or may not have a PhD. In fact, they may not have any diploma or certification whatsoever. If the courses were good enough, and the advantages of having such training were obvious to both students and employers, EXISTING professionals in the field would sign up for the training. Hell, I would sign up for the training.
4. Major funding. Attracting and retaining the best teachers, choosing a location (or making an on-line program available), admin costs, making a profit, etc. all need to be considered.
I believe there are many difficulties and challenges involved with putting together a meaningful training program that truly attempts to guarantee graduates would be “fit, qualified, and proficient”, but I’m also convinced it’s a worthy goal. As a hiring manager, employee, and practioner for over twenty years, I’d find it refreshing to be able at long last put the meaningless certification/diploma/training debates behind and throw my support behind something that I could really believe in. And I certainly do believe in training. I’ve been lucky enough to have some very fine teachers.
There’s been some interesting discussion on this topic lately and I’m taking note of the efforts of the AST group in this direction; there’s nothing I think is a definitive answer yet, but I find the efforts to produce talented, trained professionals heartening. All of the efforts I’ve seen thus far are starting small and will perhaps expand someday; it would be fun and exciting to see a plan that thought big and moved forward in phases. Iterations, if you will. Oops – separate blog…
Until that time, however, I remain uninterested and distinctly blasé about current degrees and certifications. The resources that possess them might be great and they might be pitiful; I don’t consider them when hiring and I don’t discuss my own when I’m interviewing. My own? Oh yes. I have enough diplomas and certifications to wallpaper my office. But those are not what gave me success in the field. Experience and the good luck to have associated with some gifted teachers gave me success in the field. My own interest and love for testing gave me success in the field. Not certifications. Those haven’t made much impact on my life.
Except, of course, for my wine-tasting certification. I learned the fine art of wine-tasting from Roger Gentile, a snob of epic proportions in this part of the country, and I can now tell a good Piesporter from a wretched Chardonnay… So if things ever get tough in this part of the US, I feel sure that piece of paper will qualify me for a sommelier position in the best Longhorn Steakhouse in town…
Certification, education, and training continue to be hot topics in the QA/QC community. The problem is that there is nothing, at this time, that really gives a prospective employer with no experience in the field an edge for finding a qualified and talented resource. Understandably, they reason that someone with a given certification or degree must be more qualified for a job than the person without those qualifications. When you don’t know what makes a talented resource in our field or what questions to ask, you tend to lean on the “opinions” of some amorphous governing body and hope you don’t make a mistake.
There’s another problem with the fact that our field is inundated with different degrees, certifications, and training classes. Which ones are good? Which ones are bad?
Most experienced staff realize there is no piece of paper offered at this time that certifies someone is competent in their field. It’s irritating to most that someone who couldn’t test so much as a basic drop-down box on their best day could potentially be hired before someone who tested a major application by themselves, in two months, with no major errors in production because the lesser-qualified candidate has a piece of paper.
Also understandably, possessors of these various documents argue vehemently about respective worth.
I don’t normally spend much time talking about certifications, etc., because I think they’re not even worth the time to discuss, but as the number and types of certification, degrees, and training continues to proliferate, each one touting themselves as the Hottest Thing Since Sliced Bread, I find myself increasingly impatient with all of the nonsense and moved (at long last) to comment.
Let’s start with formal education. That is, college degrees. Several of the best known people in our field do not have one. Do you want to call James Bach “unqualified”? What about Edward Kit? Even if you do have a college degree, how many of you have a degree applicable to our field? If you majored in Computer Science, how many testing courses were required? Were you lucky enough to get even ONE? In what way does a college degree qualify you to work in QA/QC?
The answer is “it doesn’t”. A college degree does not qualify someone to become a tester and certainly is no indicator of talent. If the individual went to an institution that really EDUCATES, the best you can hope for is someone interested in learning and who knows how to think.
So let’s move on to certifications. Certifications certify you have an understanding of (X). (X) is determined by the certifying body, and it varies. For practioners of various kinds, many certifications require that you are already a professional in the field, that you have X years of experience in the field, and that you have demonstrated understanding of what they feel embodies a professional in the field. Note that the key is “what they feel”. What they feel embodies a “professional” and what you feel embodies a “professional” might be quite different. Furthermore, understanding something and practicing it are two different animals. This is why there is usually a “number of years in the field” associated with a certification. The hope is that knowledge/understanding of basic precepts coupled with actual experience in the field guarantees (some) degree of competency.
But does it? My answer is “no”. Because the certifying parties are often quite large, checking of credentials can be through sampling, or not done at all. Working in the field for (say) two years might mean you’ve hopped from job to job for said two years, and have been let go at every one of them. The certifying body may or may not verify their candidates understand the precepts that the bulk of professionals in the field feel are important. The purpose of many certifications is to make money for the certifying body.
So overall, certification is not an indicator of either competency or talent. In addition, the QA/QC field does not have “one” single, governing certification that is recognized as THE certification, which means everyone is not even on the same page in regards to basic precepts.
So what about TRAINING? This is the one area where I feel there is room to really “make a difference”. The definition of training (courtesy of Webster’s) is “to teach so as to make fit, qualified, or proficient”.
Well.
Now if THAT were true, every manager in the world would be snapping up graduates of said training program.
In my opinion, such a training program would need the following:
1. Only talented candidates could be accepted for the program. In other words, a robust pre-screening process would have to be in place. One thing I’ve observed, regardless of field, is that talented teachers want to teach those that truly have an interest or love for the field, and an ability to excel in it. In addition, exclusivity and a reputation for being the Best of the Best is marketable - to prospective students, prospective teachers, and prospective employers.
2. The program would have to contain classes that cover the gamut of potential working environments and methodologies. There’s a difference between working on an iterative government project involving social work and an XP GUI screen for internal ordering of office supplies, for example. Graduates of the program would have to have the ability to excel in any type of situation.
3. Teachers and the courseware offered would have to engender the respect of professionals currently in the field. That means locating and attracting big names and popular/knowledgeable people willing to teach. It also means qualification for teachers has to be somewhat different than much of the academic world. The best teachers in our field may or may not have a PhD. In fact, they may not have any diploma or certification whatsoever. If the courses were good enough, and the advantages of having such training were obvious to both students and employers, EXISTING professionals in the field would sign up for the training. Hell, I would sign up for the training.
4. Major funding. Attracting and retaining the best teachers, choosing a location (or making an on-line program available), admin costs, making a profit, etc. all need to be considered.
I believe there are many difficulties and challenges involved with putting together a meaningful training program that truly attempts to guarantee graduates would be “fit, qualified, and proficient”, but I’m also convinced it’s a worthy goal. As a hiring manager, employee, and practioner for over twenty years, I’d find it refreshing to be able at long last put the meaningless certification/diploma/training debates behind and throw my support behind something that I could really believe in. And I certainly do believe in training. I’ve been lucky enough to have some very fine teachers.
There’s been some interesting discussion on this topic lately and I’m taking note of the efforts of the AST group in this direction; there’s nothing I think is a definitive answer yet, but I find the efforts to produce talented, trained professionals heartening. All of the efforts I’ve seen thus far are starting small and will perhaps expand someday; it would be fun and exciting to see a plan that thought big and moved forward in phases. Iterations, if you will. Oops – separate blog…
Until that time, however, I remain uninterested and distinctly blasé about current degrees and certifications. The resources that possess them might be great and they might be pitiful; I don’t consider them when hiring and I don’t discuss my own when I’m interviewing. My own? Oh yes. I have enough diplomas and certifications to wallpaper my office. But those are not what gave me success in the field. Experience and the good luck to have associated with some gifted teachers gave me success in the field. My own interest and love for testing gave me success in the field. Not certifications. Those haven’t made much impact on my life.
Except, of course, for my wine-tasting certification. I learned the fine art of wine-tasting from Roger Gentile, a snob of epic proportions in this part of the country, and I can now tell a good Piesporter from a wretched Chardonnay… So if things ever get tough in this part of the US, I feel sure that piece of paper will qualify me for a sommelier position in the best Longhorn Steakhouse in town…
Thursday, August 28, 2008
THE HAPPY PATH IS EVIL
Hansel and Gretel will back me up on that one…..
In the words of Robert Frost “Two roads diverged in a wood, and I—I took the one less traveled by, And that has made all the difference.”.
Who is the Incompetent Fool that came up with “Happy Path” or “Happy Testing” and why would any testing professional actually use it in a sentence?
I do not allow my staff to use that phrase – ever. I think my reaction to it has frightened them into submission - it’s like Young Frankenstein when someone says “Bluchner”. Horses neigh and dogs howl. My head starts to spin around like the Exorcist and a priest has to be called in. And I’m not Catholic.
When I get an applicant who mentions their years of experience with happy path testing, I have to restrain myself from ripping their resume into little, tiny pieces and flinging it into the air like confetti, swearing in several languages the entire time. The minute the phrase is uttered, I am strategizing as to how quickly I can get them out of my office and back to their colleagues in Hell. It takes a week to fumigate my office – the sulphur fumes tend to linger.
Happy path testing, for those of you blissfully unaware that such a thing could even exist, is taking the most obvious, expected, valid path or paths through a given piece of software to verify the software is Perfectly Lovely and ready to move on to your lucky clients. Companies with no understanding of either software or software quality can embrace this testing policy, since it’s both cheap and unlikely to find much error. Until production, of course. But for some reason, these same companies don’t seem to “count” production errors or time lost by users in prod as part of the project expenditures.
Happy testing is little elves joyfully dancing down the garden path to Mozart, flinging little flowers around as they go.
How unfortunate that our profession is much more in line with a tattooed, leather-clad, chain-bearing gorilla that plows off the path into your garden, rips up all your daffodils and pees on your begonias, followed by blunt observations about the ugliness of your yard, your neighbors, and possibly you and your family as well.
I find it hard to believe anyone would think happy path testing is a Good Idea, but just in case, I’m going to try to change your mind.
Any programmer with even one microscopic drop of competency is going to test their own program(s) by trying the most obvious, expected, valid paths through their software. It stands to reason that the likelihood of driving out error by doing exactly the same thing is slim. Does that mean you DON’T perform those tests? No. There are programmers out there without even one microscopic drop of competency. But it means the really juicy errors lie off the happy path and where paths cross and decisions have to be made.
When you’re either examining an application or a specification, a good tester has to be curious and contrary. The #1 weapon in your arsenal should be the phrase “What if?”. When someone tells you “If A is in X state, and you do B, you will get C result.”, you should be thinking “What if A isn’t in X state? What if A is in Y state? What other states are there? What if I do B without A? What if I don’t do B at all?”, etc. If you’ve never read a spec this way, or looked at a system this way, then just TRY IT. Try it one time and see what happens.
And once you veer into the jungle, you’ll never look back. Believe me, all the fun stuff is off the path….
In the words of Robert Frost “Two roads diverged in a wood, and I—I took the one less traveled by, And that has made all the difference.”.
Who is the Incompetent Fool that came up with “Happy Path” or “Happy Testing” and why would any testing professional actually use it in a sentence?
I do not allow my staff to use that phrase – ever. I think my reaction to it has frightened them into submission - it’s like Young Frankenstein when someone says “Bluchner”. Horses neigh and dogs howl. My head starts to spin around like the Exorcist and a priest has to be called in. And I’m not Catholic.
When I get an applicant who mentions their years of experience with happy path testing, I have to restrain myself from ripping their resume into little, tiny pieces and flinging it into the air like confetti, swearing in several languages the entire time. The minute the phrase is uttered, I am strategizing as to how quickly I can get them out of my office and back to their colleagues in Hell. It takes a week to fumigate my office – the sulphur fumes tend to linger.
Happy path testing, for those of you blissfully unaware that such a thing could even exist, is taking the most obvious, expected, valid path or paths through a given piece of software to verify the software is Perfectly Lovely and ready to move on to your lucky clients. Companies with no understanding of either software or software quality can embrace this testing policy, since it’s both cheap and unlikely to find much error. Until production, of course. But for some reason, these same companies don’t seem to “count” production errors or time lost by users in prod as part of the project expenditures.
Happy testing is little elves joyfully dancing down the garden path to Mozart, flinging little flowers around as they go.
How unfortunate that our profession is much more in line with a tattooed, leather-clad, chain-bearing gorilla that plows off the path into your garden, rips up all your daffodils and pees on your begonias, followed by blunt observations about the ugliness of your yard, your neighbors, and possibly you and your family as well.
I find it hard to believe anyone would think happy path testing is a Good Idea, but just in case, I’m going to try to change your mind.
Any programmer with even one microscopic drop of competency is going to test their own program(s) by trying the most obvious, expected, valid paths through their software. It stands to reason that the likelihood of driving out error by doing exactly the same thing is slim. Does that mean you DON’T perform those tests? No. There are programmers out there without even one microscopic drop of competency. But it means the really juicy errors lie off the happy path and where paths cross and decisions have to be made.
When you’re either examining an application or a specification, a good tester has to be curious and contrary. The #1 weapon in your arsenal should be the phrase “What if?”. When someone tells you “If A is in X state, and you do B, you will get C result.”, you should be thinking “What if A isn’t in X state? What if A is in Y state? What other states are there? What if I do B without A? What if I don’t do B at all?”, etc. If you’ve never read a spec this way, or looked at a system this way, then just TRY IT. Try it one time and see what happens.
And once you veer into the jungle, you’ll never look back. Believe me, all the fun stuff is off the path….
Wednesday, August 6, 2008
I’M JUST A GIRL THAT CAIN’T SAY NO….
Are you too easy?
If someone were to ask me what I think is the number one problem facing IT today, I’d say it was the inability to say “no”. Not specifications, not offshoring, not lack of technical talent, not lack of jobs, and not any single type of project methodology.
The reason IT exists is to provide value, in the form of software and/or hardware to client or group of clients. It stands to reason that the opinion, goodwill, and often money of the client are of primary importance. We do, in fact, exist to please our clients.
Our clients communicate what they want in a variety of ways. In some companies, this is done through marketing reps, analyses, and surveys. In many companies, it is the BA (Business Analyst) that interviews, interprets, and documents what is desired by the end user. In other companies, the Project Manager (PM) works directly with the client.
In all cases, regardless of project methodology, there is a strong tendency to give the end user whatever they want, and to do it ASAP. Many of the above personnel are evaluated on how happy they make the end user.
What we end up developing for ourselves are clients that act like spoiled children. Because we have given them everything they want, whenever they want it, they expect that type of responsiveness every single time. We do not educate our end users and although we knock ourselves out to understand what they do, how they do it, and what they want and “like” about a product, we do not ever allow them to become more technically sophisticated and understand what it is WE do, how we do it, and the impact change has on a product and that product’s schedule. We do not force our clients to look at project schedules and make hard choices. They want it all, and we try to give it to them, regardless of the impact to budgets, schedules, quality, and our people. One person telling a client they can get an enhancement into a migration that is only a week away can cause 12 people to have to work 80 hour weeks for several weeks, negatively impact the work they were already doing for that migration, and make the work they were doing for the NEXT migration late. And from a QA/QC perspective, it’s likely that all of it will be buggier.
The desire to give the client whatever they want, whenever they want it, also fails to develop talented PM, marketing, and BA staff that support their own organization. They never learn to really interview the client up-front, negotiate, and in their desire to please the customer, they screw over the IT organization, which SHOULD be pretty high on their priority list. The effect of unbridled change on a project schedule is usually that the timeframes get crushed to the point where the final product has either significantly less quality or that features end up being cut. That means that the ultimate goal – to please the client – ends up being negatively impacted ANYWAY. The effect on internal personnel is that an environment where OT is a constant energy drain may become normal and that nothing ever really becomes “finished”. Those are rarely motivators to the staff and can feed dissatisfaction and staff turnover.
Often a product may become over-designed for a first deployment, offering way too many bells and whistles that don’t work quite right yet, or full of features that handle exceptions that might occur once a year for one client, rather than focusing on functionality used by a majority of clients every day.
Technically speaking, quick, klugey “bandaids” may be developed rather than “doing it the right way”, due to time constraints. Over time, this results in applications that cannot be maintained and require a complete rewrite.
While I have rarely met a PM or BA capable of either successfully negotiating schedule dates or tactfully educating a client and letting them know their latest changes cannot be accommodated, the reverse has actually been true with some areas, particularly QA. I know some QA areas that were actually DISSOLVED by upper management because they said no to everything. I train my staff to look at every option and to make every attempt to accommodate a change or request; we rarely say “no”, but when we do, our “no” actually means “no”. We do not attempt or suggest a given change NOT go into production, but if we don’t have the manpower to test it, the responsibility for testing tasks goes back to the PM and they have to find other members of the team (usually developers) to perform the testing. Is that risky? Yes. But the point I’m trying to make here is that there is a limit to what can be supported by any group, and when you hit that limit, you need to say “no”.
I believe PMs and BAs need training in negotiation; both should never commit to dates with end users until they have checked with their teams and ensured a given change/enhancement can be accommodated without negatively impacting current schedules and WITHOUT HEROICS. Heroics are a fine thing – on occasion. Constant heroics burn out your team. I believe that often these resources forget one of the most important rules of “owning” a team. The rule is “protect your team members”. The end users already have managers, etc. protecting their interests. Your job is to represent and protect the interests of your OWN team during the negotiation process. When the negotiation process is performed properly, everyone “wins”. The end user is happy with/understands the decisions, and the project team can provide a high-quality product on time, within budget, and without killing their team members.
End users need to be educated and understand that when they ask for X, it impacts Y and Z and that no, they can’t have everything they want immediately. They need to be willing and able to examine options and choose those that provide the most benefit to their own needs, recognizing they will get everything they want, but in a prioritized order over time. Overall, they need to be part of the team and understand the work of the team, rather than just function as an outside, uncontrolled impactor of the team.
I fully understand that some “emergency” changes always occur during a project. Often these changes are absolutely necessary. They need to be incorporated. Adding to that a large number of less important changes in the spirit of “cooperation”, when you know it’s going to create a huge amount of work that will be difficult or close to impossible to handle, is merely throwing your own staff under the bus so you can earn some points with a client. And ultimately, it does not benefit anyone – including your client. So why do it? Even agile projects, which are more forgiving of and actually expect user change/enhancements, normally have a start and end date, with some sort of goal. And to be run correctly, they have to constantly prioritize and shift around workloads. Good agile projects do that with the end user as an active team member. Even then, you can end up working on a project that never ends if the enhancement/change requests never stop. If you’re a consultant being paid by the hour, that’s not necessarily a bad thing. For the rest of us, it’s akin to Living Hell.
Resources have to be empowered to say “no” when something is truly outside their ability to provide in a given timeframe. Often they are afraid to do so, and will therefore produce “something” within the timeframe. That “something” will usually end up being substandard. PMs and BAs need to learn not to commit to anything without first ensuring the work can be done, and they need to be trained to both interview adequately at the onset of a project to get as many business requirements as possible up-front, and to negotiate fixes/enhancements intelligently to ensure the entire team, both IT and end user, get the maximum benefit from the resources, time, and money available.
So are you “too easy”? It’s not too late to grow a spine, Mr. Loopner. Accept that the health and well-being of your team is as important as pleasing the client and that you are responsible for negotiating workable solutions that benefit both sides of the equation.
If someone were to ask me what I think is the number one problem facing IT today, I’d say it was the inability to say “no”. Not specifications, not offshoring, not lack of technical talent, not lack of jobs, and not any single type of project methodology.
The reason IT exists is to provide value, in the form of software and/or hardware to
Our clients communicate what they want in a variety of ways. In some companies, this is done through marketing reps, analyses, and surveys. In many companies, it is the BA (Business Analyst) that interviews, interprets, and documents what is desired by the end user. In other companies, the Project Manager (PM) works directly with the client.
In all cases, regardless of project methodology, there is a strong tendency to give the end user whatever they want, and to do it ASAP. Many of the above personnel are evaluated on how happy they make the end user.
What we end up developing for ourselves are clients that act like spoiled children. Because we have given them everything they want, whenever they want it, they expect that type of responsiveness every single time. We do not educate our end users and although we knock ourselves out to understand what they do, how they do it, and what they want and “like” about a product, we do not ever allow them to become more technically sophisticated and understand what it is WE do, how we do it, and the impact change has on a product and that product’s schedule. We do not force our clients to look at project schedules and make hard choices. They want it all, and we try to give it to them, regardless of the impact to budgets, schedules, quality, and our people. One person telling a client they can get an enhancement into a migration that is only a week away can cause 12 people to have to work 80 hour weeks for several weeks, negatively impact the work they were already doing for that migration, and make the work they were doing for the NEXT migration late. And from a QA/QC perspective, it’s likely that all of it will be buggier.
The desire to give the client whatever they want, whenever they want it, also fails to develop talented PM, marketing, and BA staff that support their own organization. They never learn to really interview the client up-front, negotiate, and in their desire to please the customer, they screw over the IT organization, which SHOULD be pretty high on their priority list. The effect of unbridled change on a project schedule is usually that the timeframes get crushed to the point where the final product has either significantly less quality or that features end up being cut. That means that the ultimate goal – to please the client – ends up being negatively impacted ANYWAY. The effect on internal personnel is that an environment where OT is a constant energy drain may become normal and that nothing ever really becomes “finished”. Those are rarely motivators to the staff and can feed dissatisfaction and staff turnover.
Often a product may become over-designed for a first deployment, offering way too many bells and whistles that don’t work quite right yet, or full of features that handle exceptions that might occur once a year for one client, rather than focusing on functionality used by a majority of clients every day.
Technically speaking, quick, klugey “bandaids” may be developed rather than “doing it the right way”, due to time constraints. Over time, this results in applications that cannot be maintained and require a complete rewrite.
While I have rarely met a PM or BA capable of either successfully negotiating schedule dates or tactfully educating a client and letting them know their latest changes cannot be accommodated, the reverse has actually been true with some areas, particularly QA. I know some QA areas that were actually DISSOLVED by upper management because they said no to everything. I train my staff to look at every option and to make every attempt to accommodate a change or request; we rarely say “no”, but when we do, our “no” actually means “no”. We do not attempt or suggest a given change NOT go into production, but if we don’t have the manpower to test it, the responsibility for testing tasks goes back to the PM and they have to find other members of the team (usually developers) to perform the testing. Is that risky? Yes. But the point I’m trying to make here is that there is a limit to what can be supported by any group, and when you hit that limit, you need to say “no”.
I believe PMs and BAs need training in negotiation; both should never commit to dates with end users until they have checked with their teams and ensured a given change/enhancement can be accommodated without negatively impacting current schedules and WITHOUT HEROICS. Heroics are a fine thing – on occasion. Constant heroics burn out your team. I believe that often these resources forget one of the most important rules of “owning” a team. The rule is “protect your team members”. The end users already have managers, etc. protecting their interests. Your job is to represent and protect the interests of your OWN team during the negotiation process. When the negotiation process is performed properly, everyone “wins”. The end user is happy with/understands the decisions, and the project team can provide a high-quality product on time, within budget, and without killing their team members.
End users need to be educated and understand that when they ask for X, it impacts Y and Z and that no, they can’t have everything they want immediately. They need to be willing and able to examine options and choose those that provide the most benefit to their own needs, recognizing they will get everything they want, but in a prioritized order over time. Overall, they need to be part of the team and understand the work of the team, rather than just function as an outside, uncontrolled impactor of the team.
I fully understand that some “emergency” changes always occur during a project. Often these changes are absolutely necessary. They need to be incorporated. Adding to that a large number of less important changes in the spirit of “cooperation”, when you know it’s going to create a huge amount of work that will be difficult or close to impossible to handle, is merely throwing your own staff under the bus so you can earn some points with a client. And ultimately, it does not benefit anyone – including your client. So why do it? Even agile projects, which are more forgiving of and actually expect user change/enhancements, normally have a start and end date, with some sort of goal. And to be run correctly, they have to constantly prioritize and shift around workloads. Good agile projects do that with the end user as an active team member. Even then, you can end up working on a project that never ends if the enhancement/change requests never stop. If you’re a consultant being paid by the hour, that’s not necessarily a bad thing. For the rest of us, it’s akin to Living Hell.
Resources have to be empowered to say “no” when something is truly outside their ability to provide in a given timeframe. Often they are afraid to do so, and will therefore produce “something” within the timeframe. That “something” will usually end up being substandard. PMs and BAs need to learn not to commit to anything without first ensuring the work can be done, and they need to be trained to both interview adequately at the onset of a project to get as many business requirements as possible up-front, and to negotiate fixes/enhancements intelligently to ensure the entire team, both IT and end user, get the maximum benefit from the resources, time, and money available.
So are you “too easy”? It’s not too late to grow a spine, Mr. Loopner. Accept that the health and well-being of your team is as important as pleasing the client and that you are responsible for negotiating workable solutions that benefit both sides of the equation.
Friday, July 25, 2008
HOW LONG DOES IT TAKE TO CATCH A FISH?
- An Arsenal of Bad Answers –
I tried to not pick up my pen – really I did… I battled with it for an entire week. But I cannot resist the call any longer. I promised myself a long time ago that I would NOT NOT NOT make comments on Michael Bolton’s articles. I’ve told myself that if I start down that road, my entire existence might end up consisting of nothing but pathetic and futile counterpoints to someone else’s warped perceptions of What is Right.
If you are reading this you must, you positively MUST, go read Michael Bolton’s article on stickyminds.com called “An Arsenal of Answers”. I believe he had the balls to put it under management.
The original concept – the question to be answered – was how long it would take to test a given product or projects. To sum up 3 pages of Boltonese, the answer is “I don’t know”, with a dash of “it’s not my responsibility” thrown in.
And an eager commenter tells him he’s covered one of the hottest topics in testing in a brilliant way. And that testing never ends. It just gets transferred to the customer. Uh-huh. Maybe that’s what happens to your customers…
I think what bothered me the most about this article is that NO ONE CHALLENGED IT. Granted, it could be that some people have already had the inestimable pleasure of attempting to argue with Michael Bolton and found it to be akin to arguing with a particularly pompous piece of igneous rock, but c’mon – are you all going to allow those kinds of statements to stand on stickyminds.com?
So back to the article. Michael said the manager might REALLY be asking:
When will the testers be able to declare the product ready to ship?
When should I ship the product?
How much time would you like to have to test the product?
What can we do to speed up testing?
When will we know we’ve found the most important problems?
How long should the test phase last?
Answers to these were that the testers won’t be able to declare the product ready to ship, that the product could be shipped whenever they like, that we’d like as much time as they’ll give us for testing, that we won’t know when we’ve found the most important problems, and that there is no such thing as a test phase.
Um, maybe, just maybe, someone is asking you how long it’s going to take you to do your job. And if YOU don’t know, how in hell do you expect THEM to know? Virtually the only advantage to passing off your estimation and scheduling responsibilities off to someone who has never done your work is that you can point fingers at them later when you run out of time or do a poor job.
Most project managers or management personnel are going to find the virtual answer of “How long does it take to catch a fish?” to be both unprofessional and frustrating. They aren’t looking for philosophical dissertations. They’re looking for rough timeframes. Give them some. If you cannot at the very least give estimates based on past experience, then your best bet is to inform your clients you don't know how long it takes you, or your team, to do their work. That you can't tell when the most important problems have been found. That you don't know what a test phase is.
Look, everyone on a project feeds into the initial project plan/schedule. Developers have to give estimates. DBAs have to give estimates. Architects have to give estimates.
YOU have to give estimates. The elements of your job are no more ephemeral or difficult to pin down than any else’s. I get really tired of the whiny ridiculousness of how impossible it is to nail down the elements of our jobs. Art vs. science. Actually, a lot of the stuff going around now makes it seem more like magic. What a crock. Sure, you can't guarantee you'll find one error every 32.5 minutes. But if you're experienced, you can ESTIMATE how long it'll take you to test a new screen, feature, or system.
Overall, you're in QA/QC, dammit. Be brave.
Get over yourself. Be a grownup. Commit…..
I tried to not pick up my pen – really I did… I battled with it for an entire week. But I cannot resist the call any longer. I promised myself a long time ago that I would NOT NOT NOT make comments on Michael Bolton’s articles. I’ve told myself that if I start down that road, my entire existence might end up consisting of nothing but pathetic and futile counterpoints to someone else’s warped perceptions of What is Right.
If you are reading this you must, you positively MUST, go read Michael Bolton’s article on stickyminds.com called “An Arsenal of Answers”. I believe he had the balls to put it under management.
The original concept – the question to be answered – was how long it would take to test a given product or projects. To sum up 3 pages of Boltonese, the answer is “I don’t know”, with a dash of “it’s not my responsibility” thrown in.
And an eager commenter tells him he’s covered one of the hottest topics in testing in a brilliant way. And that testing never ends. It just gets transferred to the customer. Uh-huh. Maybe that’s what happens to your customers…
I think what bothered me the most about this article is that NO ONE CHALLENGED IT. Granted, it could be that some people have already had the inestimable pleasure of attempting to argue with Michael Bolton and found it to be akin to arguing with a particularly pompous piece of igneous rock, but c’mon – are you all going to allow those kinds of statements to stand on stickyminds.com?
So back to the article. Michael said the manager might REALLY be asking:
When will the testers be able to declare the product ready to ship?
When should I ship the product?
How much time would you like to have to test the product?
What can we do to speed up testing?
When will we know we’ve found the most important problems?
How long should the test phase last?
Answers to these were that the testers won’t be able to declare the product ready to ship, that the product could be shipped whenever they like, that we’d like as much time as they’ll give us for testing, that we won’t know when we’ve found the most important problems, and that there is no such thing as a test phase.
Um, maybe, just maybe, someone is asking you how long it’s going to take you to do your job. And if YOU don’t know, how in hell do you expect THEM to know? Virtually the only advantage to passing off your estimation and scheduling responsibilities off to someone who has never done your work is that you can point fingers at them later when you run out of time or do a poor job.
Most project managers or management personnel are going to find the virtual answer of “How long does it take to catch a fish?” to be both unprofessional and frustrating. They aren’t looking for philosophical dissertations. They’re looking for rough timeframes. Give them some. If you cannot at the very least give estimates based on past experience, then your best bet is to inform your clients you don't know how long it takes you, or your team, to do their work. That you can't tell when the most important problems have been found. That you don't know what a test phase is.
Look, everyone on a project feeds into the initial project plan/schedule. Developers have to give estimates. DBAs have to give estimates. Architects have to give estimates.
YOU have to give estimates. The elements of your job are no more ephemeral or difficult to pin down than any else’s. I get really tired of the whiny ridiculousness of how impossible it is to nail down the elements of our jobs. Art vs. science. Actually, a lot of the stuff going around now makes it seem more like magic. What a crock. Sure, you can't guarantee you'll find one error every 32.5 minutes. But if you're experienced, you can ESTIMATE how long it'll take you to test a new screen, feature, or system.
Overall, you're in QA/QC, dammit. Be brave.
Get over yourself. Be a grownup. Commit…..
Friday, July 11, 2008
LEARNING TO TEST
Enjoying the dark side of the force for fun and profit….
I’ve been surprised lately by the number of blogs/articles out there talking about learning how to test. There are SO MANY books and classes out there on basic topics like this that I really felt that I wouldn’t ever be posting on basic topics here. It was my intent to focus on QA management issues, since there’s less material available with that type of focus.
Just like the rest of you, however, whenever I read something about a topic I’m passionate about, it inspires me to put in my two cents.
I’m not going to comment much about Michael Bolton’s blog about the similarities of learning to drive and learning to test (find it on stickyminds.com). First of all, it was obvious to me the memories associated with learning to drive had some personal significance to him, which means a bit of sensitivity wouldn’t come amiss. I understood some of the points he was trying to make and agreed with them, if not, perhaps, in that context. I did disagree with his conclusion. The concluding thought was “You wouldn’t want someone new driving with someone else’s script, would you?”. Yes, I definitely would, but that’s because I equate a script more to a GPS system or map, rather than pamphlets on rules of the road or training/mentoring.
So I was thinking about how I learned to test and how I teach testing to others. Here are my thoughts. I’m not going to try to equate testing to learning to cook, astrology, quantum physics, or plumbing, although that might be fun sometime.
I started in the field in systems analysis. I caught the attention of the QA Manager when I worked in a coordinator position between development and QA on a major project. When I turned in my notice, my boss begged me to go anywhere but QA. Back then, QA reviewed code and was one of the most hated organizations in the company. They’d go back to your lead developer and most valuable resource and tell him his code was inefficient and that they could rewrite 12 lines of his code in 3. Large projects would bog down in QA for months. No wonder they were despised.
Shortly after I joined up, they went through a major change in focus. It had become obvious to executive management that the end user really didn’t care what language a system was written in, how many lines of code it took to write it, etc. So the testing became user/specification oriented, rather than code-based.
The first day I went into the office, there was stack of documentation on my new desk about a foot high. Those, I was informed, were my new projects.
I was 23 and, as I look back fondly at the beginnings of my career, can reliably report that I was pretty much unable to find my own butt with both hands.
I was assigned a mentor – a good one. The entire QA team, which was very tight and supportive of each other, pretty much “adopted” me. I haven’t seen that change much over the years, by the way. It’s a highly dysfunctional QA/QC group that doesn’t take care of its own.
The first “task” I was given was (you guessed it) running regression test cases for someone else’s project. I realize some people think that is a heinous way to start. But it wasn’t. First of all, I learned the application under test by following the guidelines set down by someone who was an expert on that system – the author of the test cases. Second, I learned how I was expected to format my own test cases. Third, I learned what kind of things an expert tester looked for by running those test cases. And fourth (and probably most important to my employers), I was immediately useful and contributing to the team.
As this was going on, I was also given instruction on testing technique and reading specifications for the first project on my stack. The first set of tests I wrote were peer-reviewed by my mentor, who, I might add, wrote all over them in bright red ink, pointing out what I had forgotten or tests I had missed. That first effort was a sea of red ink.
I was pretty bummed out that first time through. At the same time, I was told what a great job I’d done for a first effort and what a great addition I was to the team. That was the first and last time for that process, by the way. You were put through the wringer one time, and were thereafter expected to understand what was required and to do it.
That meant all the rest was up to me. I went through all of that red ink and learned to ask questions; of my mentors, BAs, and developers.
But more than that, I fell in love with testing. I was obsessed with testing. I tested EVERYTHING. During lunch time, I’d pull up the word processor and test it. I’d test the time reporting system. I spent literally weeks of my own time figuring out how to break things. I drove them all crazy; pretty soon I was finding errors in everything I touched. I was lucky enough to work for a company that believed strongly in education and fostering new talent; I believe I probably attended at least 24 classes and seminars while I was an employee there. That testing “love affair” never ended; after all this time, I still love to test. I’ve been a manager for some time now, so it’s no longer my “job”. But it’s still my avocation.
When I look back at it, I was pretty lucky. It’s fine to talk about mentors and training, but I have to say I’m in the minority, not the majority. I’ve met very few testers that have ever had any formal training, let alone a mentor. Anything they’ve learned, they’ve had to learn on their own.
So how do I teach testing? Well, my current company has highly complex, interrelated applications on a multi-tiered system and operates 24X7, with branches all over the world and staff with immediate access to some critical applications via Blackberry. We have unique security considerations. We also directly interface with a number of vendors. Our application systems are not “like” other systems, in that I can’t easily go out and find resources that have a background that is similar. So everyone pretty much “starts from scratch” in terms of knowledge base.
Our first step is an overview of our applications from a high level; we spend about 3 days on that. New resources are immediately given access to our regression test base and are expected to execute those that impact their assignments to get familiar with specifics for the application and our test case format. Low-level staff (new to testing) will be executing existing tests for a while – it provides value to the company while they’re learning.
Everyone, experienced or not, goes through a bootcamp, which takes about 3 days. The bootcamp reviews both QA and QC, with specific emphasis on how things are set up in our QA organization, trains everyone in basic test technique (both structured and agile), and reviews how automation is used in our shop. The bootcamp includes a testing “test”, which we review in order to determine who “gets” it and who needs more help. Those that need more help are given a mentor to work more closely with them.
The bootcamp ensures everyone understands our terminology, understands the basics in terms of technique, knows what is expected from them, and the overall flow of work through our group.
From there, staff move on to their individual assignments. Everyone has their work reviewed the first time they produce deliverables for us. New people who are also new to the testing field execute regression test cases for several migrations. They are then eased into small projects that are somewhat related to the test cases they’ve become familiar with, followed by projects of increasing size and complexity. New people who are experienced will start out with small projects and progress more quickly. Note: we do not normally produce test cases prior to a testing effort. We work from a structured outline – a kind of hierarchical, organized “list” of what we want to examine. Test cases are written after the testing effort and become part of our regression test case base.
We are also self-regulating in that we examine every bug found in production for several weeks after a migration and try to figure out how we missed it. We’re not a zero defect shop, so we expect some errors (right now it’s about 4%); no one is ever “punished” for missing something. If someone misses significant error repeatedly over multiple releases, however, we’re going to first try to mentor the shit out of them. If that doesn’t work, we’re going to bump back their responsibilities until we find the “sweet spot”; something that resource can handle effectively.
One thing I’ve found is that all the training in the world doesn’t give someone a passion for testing. That’s one thing they have to have on their own. We can give them the tools and the training; they’re the ones that have to take it from there.
And not everyone is good at testing. I’ve known many talented, earnest, hard-working individuals that NEVER “get” it, no matter how hard you (and they) try. So what do we do in those cases? To be honest, everyone in my group has to be competent; we “manage them out” if they can’t handle the work. We always try mentoring first; it’s expensive to find and train someone new; but everyone on the team has to pull their own weight. That said, there’s a world of difference between “competent” and “awesome”. I have some of both; most managers do. If I could instill my own love of testing in everyone, I would, but it just doesn’t work that way. I put my competent people on projects that require competence (which is the majority of small projects), and save my awesome people for projects that we know are going to require some awesome testing skills. Chances are also good that those “merely competent” people are going to be awesome at something else that needs to be done in the group – I talked about this a bit in my blog about building a team.
By the way, have you ever noticed that your awesome testing personnel are the ones that pretty much started that way out the gate? Some people just show a definite, rare instinct in regards to finding problems that training and mentoring just enhances. They grab whatever you give them and take off with it. These are the folks with the real passion for the field; I suspect that many of the testing bloggers out there fall into this category.
There are several individuals in the QA/QC field that focus specifically on figuring out what makes a great tester great – WHY are they so good? HOW do their minds work? WHAT do they do differently? I have to leave that weighty research for others; perhaps one day that type of scholarship will help us provide better training or identification of talent across the board.
I’ve been surprised lately by the number of blogs/articles out there talking about learning how to test. There are SO MANY books and classes out there on basic topics like this that I really felt that I wouldn’t ever be posting on basic topics here. It was my intent to focus on QA management issues, since there’s less material available with that type of focus.
Just like the rest of you, however, whenever I read something about a topic I’m passionate about, it inspires me to put in my two cents.
I’m not going to comment much about Michael Bolton’s blog about the similarities of learning to drive and learning to test (find it on stickyminds.com). First of all, it was obvious to me the memories associated with learning to drive had some personal significance to him, which means a bit of sensitivity wouldn’t come amiss. I understood some of the points he was trying to make and agreed with them, if not, perhaps, in that context. I did disagree with his conclusion. The concluding thought was “You wouldn’t want someone new driving with someone else’s script, would you?”. Yes, I definitely would, but that’s because I equate a script more to a GPS system or map, rather than pamphlets on rules of the road or training/mentoring.
So I was thinking about how I learned to test and how I teach testing to others. Here are my thoughts. I’m not going to try to equate testing to learning to cook, astrology, quantum physics, or plumbing, although that might be fun sometime.
I started in the field in systems analysis. I caught the attention of the QA Manager when I worked in a coordinator position between development and QA on a major project. When I turned in my notice, my boss begged me to go anywhere but QA. Back then, QA reviewed code and was one of the most hated organizations in the company. They’d go back to your lead developer and most valuable resource and tell him his code was inefficient and that they could rewrite 12 lines of his code in 3. Large projects would bog down in QA for months. No wonder they were despised.
Shortly after I joined up, they went through a major change in focus. It had become obvious to executive management that the end user really didn’t care what language a system was written in, how many lines of code it took to write it, etc. So the testing became user/specification oriented, rather than code-based.
The first day I went into the office, there was stack of documentation on my new desk about a foot high. Those, I was informed, were my new projects.
I was 23 and, as I look back fondly at the beginnings of my career, can reliably report that I was pretty much unable to find my own butt with both hands.
I was assigned a mentor – a good one. The entire QA team, which was very tight and supportive of each other, pretty much “adopted” me. I haven’t seen that change much over the years, by the way. It’s a highly dysfunctional QA/QC group that doesn’t take care of its own.
The first “task” I was given was (you guessed it) running regression test cases for someone else’s project. I realize some people think that is a heinous way to start. But it wasn’t. First of all, I learned the application under test by following the guidelines set down by someone who was an expert on that system – the author of the test cases. Second, I learned how I was expected to format my own test cases. Third, I learned what kind of things an expert tester looked for by running those test cases. And fourth (and probably most important to my employers), I was immediately useful and contributing to the team.
As this was going on, I was also given instruction on testing technique and reading specifications for the first project on my stack. The first set of tests I wrote were peer-reviewed by my mentor, who, I might add, wrote all over them in bright red ink, pointing out what I had forgotten or tests I had missed. That first effort was a sea of red ink.
I was pretty bummed out that first time through. At the same time, I was told what a great job I’d done for a first effort and what a great addition I was to the team. That was the first and last time for that process, by the way. You were put through the wringer one time, and were thereafter expected to understand what was required and to do it.
That meant all the rest was up to me. I went through all of that red ink and learned to ask questions; of my mentors, BAs, and developers.
But more than that, I fell in love with testing. I was obsessed with testing. I tested EVERYTHING. During lunch time, I’d pull up the word processor and test it. I’d test the time reporting system. I spent literally weeks of my own time figuring out how to break things. I drove them all crazy; pretty soon I was finding errors in everything I touched. I was lucky enough to work for a company that believed strongly in education and fostering new talent; I believe I probably attended at least 24 classes and seminars while I was an employee there. That testing “love affair” never ended; after all this time, I still love to test. I’ve been a manager for some time now, so it’s no longer my “job”. But it’s still my avocation.
When I look back at it, I was pretty lucky. It’s fine to talk about mentors and training, but I have to say I’m in the minority, not the majority. I’ve met very few testers that have ever had any formal training, let alone a mentor. Anything they’ve learned, they’ve had to learn on their own.
So how do I teach testing? Well, my current company has highly complex, interrelated applications on a multi-tiered system and operates 24X7, with branches all over the world and staff with immediate access to some critical applications via Blackberry. We have unique security considerations. We also directly interface with a number of vendors. Our application systems are not “like” other systems, in that I can’t easily go out and find resources that have a background that is similar. So everyone pretty much “starts from scratch” in terms of knowledge base.
Our first step is an overview of our applications from a high level; we spend about 3 days on that. New resources are immediately given access to our regression test base and are expected to execute those that impact their assignments to get familiar with specifics for the application and our test case format. Low-level staff (new to testing) will be executing existing tests for a while – it provides value to the company while they’re learning.
Everyone, experienced or not, goes through a bootcamp, which takes about 3 days. The bootcamp reviews both QA and QC, with specific emphasis on how things are set up in our QA organization, trains everyone in basic test technique (both structured and agile), and reviews how automation is used in our shop. The bootcamp includes a testing “test”, which we review in order to determine who “gets” it and who needs more help. Those that need more help are given a mentor to work more closely with them.
The bootcamp ensures everyone understands our terminology, understands the basics in terms of technique, knows what is expected from them, and the overall flow of work through our group.
From there, staff move on to their individual assignments. Everyone has their work reviewed the first time they produce deliverables for us. New people who are also new to the testing field execute regression test cases for several migrations. They are then eased into small projects that are somewhat related to the test cases they’ve become familiar with, followed by projects of increasing size and complexity. New people who are experienced will start out with small projects and progress more quickly. Note: we do not normally produce test cases prior to a testing effort. We work from a structured outline – a kind of hierarchical, organized “list” of what we want to examine. Test cases are written after the testing effort and become part of our regression test case base.
We are also self-regulating in that we examine every bug found in production for several weeks after a migration and try to figure out how we missed it. We’re not a zero defect shop, so we expect some errors (right now it’s about 4%); no one is ever “punished” for missing something. If someone misses significant error repeatedly over multiple releases, however, we’re going to first try to mentor the shit out of them. If that doesn’t work, we’re going to bump back their responsibilities until we find the “sweet spot”; something that resource can handle effectively.
One thing I’ve found is that all the training in the world doesn’t give someone a passion for testing. That’s one thing they have to have on their own. We can give them the tools and the training; they’re the ones that have to take it from there.
And not everyone is good at testing. I’ve known many talented, earnest, hard-working individuals that NEVER “get” it, no matter how hard you (and they) try. So what do we do in those cases? To be honest, everyone in my group has to be competent; we “manage them out” if they can’t handle the work. We always try mentoring first; it’s expensive to find and train someone new; but everyone on the team has to pull their own weight. That said, there’s a world of difference between “competent” and “awesome”. I have some of both; most managers do. If I could instill my own love of testing in everyone, I would, but it just doesn’t work that way. I put my competent people on projects that require competence (which is the majority of small projects), and save my awesome people for projects that we know are going to require some awesome testing skills. Chances are also good that those “merely competent” people are going to be awesome at something else that needs to be done in the group – I talked about this a bit in my blog about building a team.
By the way, have you ever noticed that your awesome testing personnel are the ones that pretty much started that way out the gate? Some people just show a definite, rare instinct in regards to finding problems that training and mentoring just enhances. They grab whatever you give them and take off with it. These are the folks with the real passion for the field; I suspect that many of the testing bloggers out there fall into this category.
There are several individuals in the QA/QC field that focus specifically on figuring out what makes a great tester great – WHY are they so good? HOW do their minds work? WHAT do they do differently? I have to leave that weighty research for others; perhaps one day that type of scholarship will help us provide better training or identification of talent across the board.
Thursday, July 3, 2008
TEN REASONS TO DRINK THE KOOLAID
So sometimes the Contextual Posse is right – I hate it when that happens….
In honor of the 4th of July, here’s a little firecracker…enjoy.
Generally, I dislike the idea of identifying with a “school of thought” as I (personally) find the concept confining. I find members of such groups tend to support their own views to the exclusion of others. They strongly defend their own views, even when those views are patently wrong and do not support the majority of the field. Often their motives involve financial gain. For themselves. They support their own leaders to the point they are incapable of seeing for themselves, because their heads are so far up their butts, clear sight is no longer possible. They are fanatics, and my own feeling is that you cannot have an enjoyable or meaningful discussion or debate with any being that froths at the mouth or is incapable of admitting they might be wrong. I dislike communications which are condescending, pompous, self-righteous, or insulting to someone who didn’t do anything to earn such a communication.
That said, I’ve been condescending, pompous, self-righteous, and insulting myself on occasion. And of course, I try to justify that by saying I usually have to be goaded to react that way. True enough, kinda. Um, most of the time…..
So let’s talk about the Contextual Posse for a few minutes. The CP is almost more like a religion than a school. I have issues with that. I believe in independent thought, which means I should be able to strongly disagree with a “leader” without being publicly stripped of my epaulets.
That said, there are times that group is just Right. What they have to say is simply true. It’s hard to argue with truth.
I’ve found myself unexpectedly in total agreement with two posts from the Buccaneer-Scholar lately, and have to confess that it makes the Koolaid look just a tad bit tastier. Since I can’t help poking at the CP now and then (they’re very prolific writers, which makes it extraordinarily easy), I thought it might be time to talk about reasons to jump on their exclusive bandwagon.
Reason One
They reject certifications or degrees as a viable measure of skill. I personally have certifications coming out my….ears. I’ve never used them. They were just a by-product of some type of learning I felt I needed to do in order to understand something that interested me or get the building blocks I needed to become proficient on something necessary for my work at the time. I’ve found that some individuals obtain certifications to “prove” they have competency at something in which they actually have no competency at all. There is no substitute for experience. Those of us who have tons of tool certifications can attest to this. When you complete a basic class, or set of classes, in X tool, does that qualify you for a job in which expertise with that tool is required? No. Every tool has its own quirks and you don’t really find out what those quirks are until you’ve actually WORKED with it. I’ve been certified on tools that I’ve never used or that have long since gone the way of the Dodo. They’re extinct.
I liked some of their comments in regards to being able to revoke someone’s certification for Abysmal Performance. I’ve wanted to award someone a “Certified Unqualified” button several times as a warning to other unsuspecting employers, but I’m afraid they wouldn’t wear it with pride. I suspect my staff would have to hold them down while I tattooed it across their forehead. Preferably next to the “666” mark…
At the same time, one cannot help but wonder how a group so vocal in regards to repudiating certfications can, with any conscience, recommend certification by any group. Oddly enough, their OWN certification is likely going to be the Greatest Thing Since Sliced Bread. Go figure. One chortles aloud.
To be perfectly fair, which isn’t as much fun, there are regions of the world where you MUST be certified in order to be competitive. Reality is reality – if you have to have one, I’d suggest you get one. Being employed trumps self-righteousness every time.
Reason Two
Open scoffing at idiots has to be Reason Two for joining the CP. Many of us are limited in our ability to indulge ourselves this way by our civilized and polite upbringing. My only issue with this is that everyone that disagrees with the CP (or a member of the CP) isn’t an idiot. That posse attacks anyone they view as either a threat or a heathen non-believer. There are times, however, when someone who truly doesn’t belong in the field is lambasted, and rightfully so. For example, attempting to convince the public-at-large that you are an expert in the field and then making statements regarding paradigm shifts to automated testing that writes itself, or how easy and “cheap” manual testing is clearly indicates a monumental lack of experience.
Reason Three
All the cool kids are contextual. The group encourages, breeds, and develops exclusivity. If you aren’t cool, well, you’re uncool. They all promote each other and dog their “enemies” as a one-minded pack. The advantages to this for you personally are obvious. The contextual posse has some of the most proliferate and interesting authors and practitioners in the field today. Their people have a stranglehold on many of the conferences, magazines, and websites out there in the field. Take a look at their blog lists. They promote each other. Take a look at the speakers at conferences and then cross-reference to the blog lists. Same names. Take a look at your testing magazine and do the same. Take a look at testingreflections.com. Ditto. While this is Good Stuff for them, it’s pretty bad stuff for everyone else. First of all, our exposure to other thoughts, opinions, and talent is limited to a relatively narrow line of thought. I don’t WANT to attend another lecture by Person X or one of their sycophants. Let’s hear some other voices; there are plenty of them out there. But if you’re a practical person and interested in your own advancement internationally, a bit of butt-kissing or a teensy-tiny loss of some of your personal integrity might not come amiss. So if you want to be cool and need the support of some Big Players in our field, the CP is the way to go. And no one would blame you.
Reason Four
Philosophical and personal issues aside, some of the best minds in our field are part of the CP. How would you like to work with the best of the best every day and call them your peeps? How do you think it would feel to have them call YOU a peep? There are times a blog, article, comment, presentation, or class is so incredibly awesome, I feel like bowing while murmuring “I’m not worthy” under my breath. There are GENIUSES out there. And nothing compares (at least to me) to picking up something new or different. If it’s not useful to me, I might toss it away, but there’s a kind of joy in intellectual discovery that I can’t really explain.
Reason Five
The CP is protecting WHAT YOU DO FOR A LIVING. They’re promoting testers as highly intelligent, sapient humans that cannot be replaced with either machines or unqualified hordes of untrained personnel. OK, now that I think about it, maybe I’ve been a tad ungrateful myself. I must remember to add a few names to my Christmas Card list….
Reason Six
Actually, I couldn’t come up with 10 reasons. Only five.
Um, but they’re a killer five, don’t you think? So what do you think? Need a straw? You first…..
In honor of the 4th of July, here’s a little firecracker…enjoy.
Generally, I dislike the idea of identifying with a “school of thought” as I (personally) find the concept confining. I find members of such groups tend to support their own views to the exclusion of others. They strongly defend their own views, even when those views are patently wrong and do not support the majority of the field. Often their motives involve financial gain. For themselves. They support their own leaders to the point they are incapable of seeing for themselves, because their heads are so far up their butts, clear sight is no longer possible. They are fanatics, and my own feeling is that you cannot have an enjoyable or meaningful discussion or debate with any being that froths at the mouth or is incapable of admitting they might be wrong. I dislike communications which are condescending, pompous, self-righteous, or insulting to someone who didn’t do anything to earn such a communication.
That said, I’ve been condescending, pompous, self-righteous, and insulting myself on occasion. And of course, I try to justify that by saying I usually have to be goaded to react that way. True enough, kinda. Um, most of the time…..
So let’s talk about the Contextual Posse for a few minutes. The CP is almost more like a religion than a school. I have issues with that. I believe in independent thought, which means I should be able to strongly disagree with a “leader” without being publicly stripped of my epaulets.
That said, there are times that group is just Right. What they have to say is simply true. It’s hard to argue with truth.
I’ve found myself unexpectedly in total agreement with two posts from the Buccaneer-Scholar lately, and have to confess that it makes the Koolaid look just a tad bit tastier. Since I can’t help poking at the CP now and then (they’re very prolific writers, which makes it extraordinarily easy), I thought it might be time to talk about reasons to jump on their exclusive bandwagon.
Reason One
They reject certifications or degrees as a viable measure of skill. I personally have certifications coming out my….ears. I’ve never used them. They were just a by-product of some type of learning I felt I needed to do in order to understand something that interested me or get the building blocks I needed to become proficient on something necessary for my work at the time. I’ve found that some individuals obtain certifications to “prove” they have competency at something in which they actually have no competency at all. There is no substitute for experience. Those of us who have tons of tool certifications can attest to this. When you complete a basic class, or set of classes, in X tool, does that qualify you for a job in which expertise with that tool is required? No. Every tool has its own quirks and you don’t really find out what those quirks are until you’ve actually WORKED with it. I’ve been certified on tools that I’ve never used or that have long since gone the way of the Dodo. They’re extinct.
I liked some of their comments in regards to being able to revoke someone’s certification for Abysmal Performance. I’ve wanted to award someone a “Certified Unqualified” button several times as a warning to other unsuspecting employers, but I’m afraid they wouldn’t wear it with pride. I suspect my staff would have to hold them down while I tattooed it across their forehead. Preferably next to the “666” mark…
At the same time, one cannot help but wonder how a group so vocal in regards to repudiating certfications can, with any conscience, recommend certification by any group. Oddly enough, their OWN certification is likely going to be the Greatest Thing Since Sliced Bread. Go figure. One chortles aloud.
To be perfectly fair, which isn’t as much fun, there are regions of the world where you MUST be certified in order to be competitive. Reality is reality – if you have to have one, I’d suggest you get one. Being employed trumps self-righteousness every time.
Reason Two
Open scoffing at idiots has to be Reason Two for joining the CP. Many of us are limited in our ability to indulge ourselves this way by our civilized and polite upbringing. My only issue with this is that everyone that disagrees with the CP (or a member of the CP) isn’t an idiot. That posse attacks anyone they view as either a threat or a heathen non-believer. There are times, however, when someone who truly doesn’t belong in the field is lambasted, and rightfully so. For example, attempting to convince the public-at-large that you are an expert in the field and then making statements regarding paradigm shifts to automated testing that writes itself, or how easy and “cheap” manual testing is clearly indicates a monumental lack of experience.
Reason Three
All the cool kids are contextual. The group encourages, breeds, and develops exclusivity. If you aren’t cool, well, you’re uncool. They all promote each other and dog their “enemies” as a one-minded pack. The advantages to this for you personally are obvious. The contextual posse has some of the most proliferate and interesting authors and practitioners in the field today. Their people have a stranglehold on many of the conferences, magazines, and websites out there in the field. Take a look at their blog lists. They promote each other. Take a look at the speakers at conferences and then cross-reference to the blog lists. Same names. Take a look at your testing magazine and do the same. Take a look at testingreflections.com. Ditto. While this is Good Stuff for them, it’s pretty bad stuff for everyone else. First of all, our exposure to other thoughts, opinions, and talent is limited to a relatively narrow line of thought. I don’t WANT to attend another lecture by Person X or one of their sycophants. Let’s hear some other voices; there are plenty of them out there. But if you’re a practical person and interested in your own advancement internationally, a bit of butt-kissing or a teensy-tiny loss of some of your personal integrity might not come amiss. So if you want to be cool and need the support of some Big Players in our field, the CP is the way to go. And no one would blame you.
Reason Four
Philosophical and personal issues aside, some of the best minds in our field are part of the CP. How would you like to work with the best of the best every day and call them your peeps? How do you think it would feel to have them call YOU a peep? There are times a blog, article, comment, presentation, or class is so incredibly awesome, I feel like bowing while murmuring “I’m not worthy” under my breath. There are GENIUSES out there. And nothing compares (at least to me) to picking up something new or different. If it’s not useful to me, I might toss it away, but there’s a kind of joy in intellectual discovery that I can’t really explain.
Reason Five
The CP is protecting WHAT YOU DO FOR A LIVING. They’re promoting testers as highly intelligent, sapient humans that cannot be replaced with either machines or unqualified hordes of untrained personnel. OK, now that I think about it, maybe I’ve been a tad ungrateful myself. I must remember to add a few names to my Christmas Card list….
Reason Six
Actually, I couldn’t come up with 10 reasons. Only five.
Um, but they’re a killer five, don’t you think? So what do you think? Need a straw? You first…..
Subscribe to:
Posts (Atom)
Posts
