Getting Started

A colleague asked me one morning how his friend could go about getting started in the field of Software testing.  Thanks to his astute note taking, here is the list I had apparently provided.

Take the Online courses at the Association of Software Testing:

http://www.associationforsoftwaretesting.org/training/courses/

Testing – Black Box Software testing is approximately $200 course that you can take online that will give you a good overview of the “Context-Driven School of Testing” which is the direction many companies are moving towards.

http://www.associationforsoftwaretesting.org/training/courses/bug-advocacy/

Start learning these technologies for Automation:

Selenium - http://www.seleniumhq.org/

You can use the Selenium IDE http://www.seleniumhq.org/download/ to record your actions on a web page and it will auto-generate code based off of that.  This is just to get started and familiar, then code on your own after that.

WATIR - http://watir.com/

JMeter - http://jmeter.apache.org/  Can be used for performance testing, API testing, and DB testing.

You can use BadBoy http://www.badboy.com.au/ to record your actions in java and it will auto-generate code based off of that that you can use as a base.  Note that BadBoy is Windows only and may not currently be maintained

XPath - http://www.w3schools.com/xpath/

CSS - http://www.w3schools.com/css/

For gaining testing experience:

If you want to try testing to see if you would like it, you can sign up at http://www.applause.com/ or http://www.utest.com/ or https://testlio.com/ and get real testing assignments that you can get paid for on the side.  A good way to learn testing and see if you enjoy it.

You can also play with some test puzzles at http://www.testing-challenges.org/tiki-index.php

For networking:

There is also this one: http://www.meetup.com/Austin-Software-Test-Automation-Group/

and this one: http://www.meetup.com/Austin-Selenium-Meetup/

There is also one he mentioned that is run by one of the QA leads Ben Rogers  - http://www.agileaustin.org/category/agile-austin-events/qa-sig-north/

He did suggest to talk to some people in the industry to see what it is really like and would be more than happy to share the good and the dark side of software testing so you know what it is like before you get into it.

Longer term things:

To Read

Book - Agile Testing

Book - More Agile Testing

Book - Lessons Learned in Software Testing

Book - Perfect Software (and other illusions about testing)

Book - Explore It

Join the JMeter mailing list: http://jmeter.apache.org/mail.html

Join the Selenium mailing list: https://groups.google.com/forum/#!forum/selenium-users

Long list of blogs 

For training:

Any courses along the lines of Context-Driven School of Testing are good to read

Austin Community College may offer a software testing set of courses (he’s not sure how specific or helpful these may be)

US Military veterans should try the course provided by Bridge360 - http://www.bridge360.com/v4qlanding.shtml

Happy Testing!

Don't be a Cow

In early April I was reading some various articles and blog posts when I stumbled upon this quote, “I have a very strong opinion that there is no place for manual testing in the industry whatsoever - manual being testers who are told to spend days following test scripts.”  Scott Noakes - CEO of Linewize

This is one of those quotes I think you have to carefully interpret.  If read rapidly you conclude he wants all manual testing eliminated.  If you read the quote carefully he has a specific definition for manual testers.  Manual testers are people who are "told to spend days following test scripts".

I think Scott Noakes has it right.

Testers should not follow a script, but instead challenge themselves to leverage their cognitive skills.  A scripted path through a software application will most likely land you at the same spot every time.  It is a testers job to deviate from a path to go where no one has explored before.

Chapter 12 in "More Agile Testing" by Janet Gregory and Lisa Crispin will show you a newer definition of manual testing.  The chapter focuses on an investigative style of testing.

Testers should be adventurers, explorers, and scientists.  We should not follow a common path. Are you being told to spend your days following test scripts?

I encourage you to find alternative approaches.  You should read "More Agile Testing".  You should also read more about Session-Based Test Management.

You are not a cow, but a human with a brain.

Happy Testing!

"There's a hole in my soul"

Late last year our family went to see Bastille at the Cedar Park Event center.  As I started thinking about this post, I thought of their song "Flaws".  The title of this post is one of the lyrics.  I am finding recently that there is a hole in the soul of software testing.

I have conducted numerous job interviews for software testing candidates.  One of my common questions is "What testing books have you read?" or "What testing blogs do you follow?".  It pains me to say, but very few of the candidates have an answer.

"Are you familiar with Context-Driven School of software testing or Session Based Test Management?"  I am constantly surprised that the answer is NO.

"I see you have listed Selenium and Cucumber on your resume, please tell me about those tools."  And I get extremely vague answers, "my team uses those tools".

So the moral of this story is quite simple.  If you want to be a great Software Tester, Quality Engineer, QA Engineer, SDET, or  another career title in the field of software testing, you had better start paying attention to your craft.

There are tons of brilliant people out in the Software industry fighting to move testing forward through innovation and conversation.  Please join the conversation.

If you are going to put a term on your resume, you had better damn well know something about the term.

Please read a book or two on you craft.  There are plenty of great books available.

I participated in a discussion lead by Matt Heusser in Dallas a few years back at Software Professionals conference.  The debate was centered around, "Is Software Testing a Career".

"Hell yes!", Software testing is a career so help foster your career by participating in the industry.

Software testing rocks; however, "There's a hole in my soul, Can you fill it? Can you fill it?"  

Experiments

Last week Teslio posted on Twitter this link, "How to Become and Efficient Tester".  Here is the list of primary points.

• Organize everything
• Write detailed bug reports
• Write clear test cases  
• Take part and communicate
• Ask yourself questions
• Be positive.
• Don’t test

In general I agree with these points; however, I would like to explore the third bullet point in a bit more detail.

For me the term "Test Case' has become somewhat poisonous.  It flashes me back to the days of using Rational Unified Process, RUP and Word documents full of word density.  Today I find myself trying to avoid the words "Test Case". 

Right, wrong, or otherwise I prefer Test Idea or Charter. Both of these terms come from Session Based Test Management articles I have read over the years. Unfortunately the term Test Case is probably here to stay, so let me attempt to redefine the term from my point of view.

Test Case - an idea worth an experiment

So what is needed to conduct an experiment?  We need a hypothesis (Mission).  We need some contextual idea of the variables or inputs.  We need a control (Oracle).  We may need some mental tools (heuristics). We may need some physical tools too.  Then after conducting the actions we need observations and results.

I do not believe we need a list of detailed steps as described in Willie Tran's article.  Based on our observations and results we may have to repeat the experiment, so it is important that in your results you describe your journey and decisions you made along the journey.  I encourage testers to not write a detailed list of steps, because they may cloud the experiment.

Happy Testing!

Wearing Multiple Hats

This week there was an interesting exchange of thought on Twitter.  Here is a subset:

1. Michael Bolton ‏@michaelbolton  Apr 10

   Once again, testers: WE DO NOT PREVENT DEFECTS. We provide insight and information that can help other people to prevent them. #testing

   55 retweets40 favorites
2. Michael Bolton ‏@michaelbolton  22h22 hours ago

   @mheusser Did you change the code yourself? The design? Or did you help the person(s) who did? @Squidish_QA

   0 retweets0 favorites
3. mheusser ‏@mheusser  22h22 hours ago

   @michaelbolton @Squidish_QA ... In some cases. In others I did not. Is writing code the only way to prevent defects?

   0 retweets0 favorites
4. Michael Bolton ‏@michaelbolton  21h21 hours ago

   @mheusser Of course not. But let's be clear on who has responsibility and authority, and let's be appropriately humble. @Squidish_QA

I definitely like the aspect that testers provide insight and information.  Where this exchange sparked my brain cells was with respect to responsibility and authority.  Unfortunately I think there is a tweet missing where Matt Heusser talks about preventing a defect by fixing some code himself and committing the fix.  I think this is where Michael Bolton injects responsibility and authority by stating Matt was in the developer role and not the tester role.

This distinction caused me to think about what role might I want to play.  I think I want to be a "Team member".  Sure I think the skills I bring to the table is that of a tester's mind, but I also have other skills. I want to always apply each of those skills in the context of a Team.

I think Michael's point is that the actions taken can be bucketed into roles and that point is fine.  What I want to see happen is we reduce the dependency on roles and focus more on creating great teams with a diverse set of skills.  At Agile Testing Days 2014 Janet Gregory and Lisa Crispin talked about the T-Shaped tester.  A diverse set of skills with depth and breadth help form great teams in my opinion. Everyone can contribute in a spontaneous manner to build great software.

One of the battles I have seen over the years is the siloing or segregation of roles.  I would rather see the lines blurred.  This morning I read several articles in the April addition of Testing Trapeze.  I felt this quote in an article by Michael Trengrove resonated more closely to my point of view,   "Testers writing code, and programmers further developing a tester’s mindset.”

The quote itself implies a set of roles; however, I think the roles should be merging and applied.

In the Trengrove article I think there is another quote that also describes my point of view.  The development Director fo Orion Health, Jan Behrens states, “Today the biggest benefit of having test professionals embedded in cross-functional development teams is not that they are the ones doing all the testing but, similar to an architect or a business analyst or a UX designer, they have a particular set of skills that they help the whole team to apply.”  

My position is we should continue to blurr the lines by sharpening all skills and knowledge of all roles.  I greatly appreciate the acuteness of which Michael Bolton makes distinctions and those distinctions are important.  I prefer to wear multiple hats; however, relative to the context of the situation it is important to know which hat you have on!

Happy Testing!

Working as Designed, Really?

I recently saw a Facebook post from a family member.  At first I thought it was a really good April Fools joke, but honestly I am not sure.  The post was showing off a new tattoo.  I did a double take. Is that word spelled correctly? After several sanity checks or explorative tests I realized for sure that there was a typo on a tattoo.  This is a permanent defect or at a minimum will take an extremely complex and perhaps painful solution.

I think the same thing happens in software.  The unfortunately side of this happening in software is we simply mark the defect as "working as designed" or "will not fix".  What if the defect does permanent damage to the customer?  Certainly it will be expensive to redesign the system, but perhaps that is the right thing to do.  Marking something as "working as designed" with out carefully consider the potential for a design flaw in my opinion is a mistake.

Often the resolution working as designed puts a tester in an awkward position.  The tester either advocates for the right action to take place or has to carefully craft an excuse to deliver to the customer.  I have experienced situations where the proper resolution is a complete system redesign and could take a very long time to resolve.

I think the worst part for me is that sometimes someone will set a resolution to "working as designed" when they know deep down it is simply an excuse, stating  "I will let someone else sort this one out".  The burden typically falls upon the tester to put on their advocate cape on and begin the battle for the proper resolution.

In the case of the tattoo spelling error, I do not have the guts to report that to the tattoo owner.  I guess I also fell into the trap of "working as designed" and not advocating for the proper solution.

Let's build software right!  We should spend some time evaluating the defects in our system that were marked as "working as designed" or "will not fix".  We might just find a misspelled tattoo.

Happy Testing!

What should testers do differently?

I had the awesome pleasure of hanging out some with Peter Walen at Agile Testing Days.  Peter is a tester that really seems to enjoy life and is always willing to share experiences.  I learned that he has many experiences outside of testing that are wonderful to hear and ponder.  You can enjoy his work by reading his blog - "Rhythm of Testing".  Every tester should have a pint of beer with Mr. Walen, so if you get a chance introduce yourself.

At some point in the conference Peter asked me a question - "What is the one thing testers should do differently in the future?"  I almost spit out the first thing that came to mind; however, I suspected a trap.  If you get a chance ask Peter about the Super Ball test.  For some reason I asked for more time to think about the question.

Seriously I knew Peter was not setting me up.  He was asking me a genuine question.  In hind sight the conference was about the future of testing so the question really makes sense.  So I have had quite a bit of time to think about this topic.  I honestly have gone all over the place with my thoughts.

I think I have boiled my answer down to this.  Testers must earn the respect of their peers.  My definition of peers would be anyone you encounter in the field of software testing or in life.

Earning respect can take on many forms such as being a team player, learning to code, better yet always be willing to learn, or demonstrate your skills.  I believe once you have earned the respect of your peers you have gained trust and trust is the key to doing some great things.  If you get a chance read the works of Christopher Avery.

Respect and trust are hard to earn.  Once earned they are hard to keep. The rewards of earning respect are plentiful.  We learn from our mistakes.  Making mistakes together as a group and learning from those mistakes can be even more powerful.

I will conclude this post by saying "Thank you Mr. Peter Walen" for asking the question.  I cannot wait to here his thoughts around the question.  I also want to thank him for reminding me that we should have fun in what we do and it is really important to have fun together.

Anyone have a different answer?

Happy Thanksgiving testers!

Buccaneer Scholar to King

Well I have not written in a while, so I will try to articulate some recent thoughts.  I am certainly not the best wordsmith or most articulate speaker, but I do have an opinion.

Some people you meet in life are inspirational.  They advocate for innovation, instilling drive and passion.  You read a great book about being a buccaneer scholar, pulling yourself up by your suspenders and achieving great things in life.  You attend a presentation at the 2009 STP Conference in Las Vegas and you come away thinking man that person is brilliant. You follow their blog posts and Twitter feeds that lead to inspiration. They teach you to enjoy games and attack challenges.  Today these pioneers seem to be taking a position of my way or the highway.  We are right and everyone else is wrong.

I am not sure that is the intent of the rhetoric or dogma as one colleague stated, but that has become my perception.

These pioneers have been extremely polarizing in their thoughts and critiques of others lately.  I am certainly OK with criticism and the elevation of thought.  I guess I think it should be done in a kind, professional, and collaborative nature.  What happened to politely learning to agree to disagree.

Word choice is an important attribute when debating or collaborating.  I am not great on my feet when it comes to word choice when debating on the fly.  When someone says I am wrong I can take it and I can listen to the point of view.  But when someone continuously attacks and says your idea is wrong it does not foster a learning environment.  I think we have missed the human side of a debate.

There are many people I respect and learn from in the industry of software testing.  Ideas should be challenged, but challenged in a human compassionate way.  We should push each other to be creative thinkers, but not at the expense of destroying relationships.

Although some people are more skilled than others we should not put ourselves on a mountain top and declare I am right; therefore, everyone else is wrong.  It is certainly Ok to think that way, but not belittle the thoughts of others along the way.

I hope the attitudes temper and we can get back to collectively improving our craft of software testing.

I will end with a humorous quote from a colleague - " I am Polish so I know all about Czech's!"

Keep on Testing!

ISO 29119 - What not to do!

This post is inspired by Michael Bolton's post here.

I am a software tester.  I am an advocate for rapid and creative testing.  Think and do not follow!

I am formally a chemist where I managed an Ambient Air Analysis laboratory.  Our laboratory had many other divisions analyzing water, soil, and other tests that had to comply to EPA protocols.  All of these protocols were based on a documented government standard.  The irony of analyzing environmental standards relative to protocols was that if you found a better way to test for something, you were WRONG!  You could get the governing body to draft an amendment to the protocol or actually convert it to a new standard, but it most likely would take years.

Because some of us do things differently in testing software are we WRONG?

One funny story is that to do environmental analysis you had to have "certified" reference standards.  I discovered on a audit/tour of a gas standards company that the standards they were selling were certified against an expired standard.  The further irony was that the some gas standard companies certify their newly generated standards against standards they themselves had prepared.  I created the certification standard and I sell "certified" standards to the public.  Sure seems like a wolf in the hen house.

One of the most frustrating things about working in the environmental laboratory were the government audits.  If you did not follow protocol to the letter you risk large fines and even loss of business.  Something as simple as failing to put your initials in a laboratory logbook or an expired training record could result in a fine.

I believe I was a good chemist solving real world environmental problems.  When the lab got bought and I was told to only run samples of this kind in compliance with this standard to maximize profit.  I changed careers!  I was no longer permitted to innovate and solve environmental challenges.

When I hear debates like the one on ISO 29119, all of those laboratory frustrations resurface.  Today I lead a fantastic team that test a family of web sites designed to help create fun vacations for families and groups of friends.  Does an ever changing website really need to comply with some standard?  I think not.  Do we want a quality product that delights our customers.  Absolutely!

Now there may be software that requires a high degree of rigor and I get that. Just because you follow some guidance does not mean the software complies with a standard.

In the business of analyzing gas samples the oracle was a certified reference standard.  What is the oracle for "Perfect Software"?

I also worked for a software company that was attempting to achieve a high level of CMMI certification. The work became sit in review meetings 8 hours a day, then find time to actually test the software.    This routine involved test plans in word documents, test matrices, change control on test cases, and so on.  I do not want to go back to that routine.

My vote is test software with a high degree of technical creativity, find the bugs, and never follow any mandated guidance.

Honestly if I get a copy of ISO 29119, I will probably read it as a reference of what not to do!

Happy Testing!

Reply to the Two Hour Challenge

Finally getting around to my answer to the two hour challenge.  I appreciated the two people who attempted to tackle the two hour challenge.

Here would have been my approach:

• 25 minutes exploring the site/application gathering context and testing ideas in a mind map
• 5 minutes organizing the test ideas in order of importance or likelyhood to uncover bugs
• 60 minutes executed the test ideas in order of importance and during execution taking notes.  The notes would be tagged - bug, question, observation, enhancement, issue, and action
• 30 minutes summarizing my findings in a report where the report includes a list of bugs, questions, observations, enhancement suggestions, issues, and future action items.  The list of action items would include recommendations on additional test ideas I would recommend the team execute.

Hopefully based on these findings, I would be contracted to do additional testing.

Targeted and time-based sessions work!  Try it!

Two Hour Challenge

It is very safe to say that I have completely blown my objective of writing a weekly blog post in 2014.  I could analyze the plethora of reasons, but that is really not important.  What is important is that I have been inspired to challenge the testing community?

In my opinion testing has been reframed from the POV of what testing does it require to generate a great product to what great testing can be accomplished in a given timeframe and make the product great.

The reframing could be worded better, but hopefully you get my point.

So here is the two hour challenge:

You are being hired to test a website.  You will be provided only a URL.  And you only have 2 hours to test.

How would you structure those two hours and what would you deliver?

Please post your testing approach as a comment.  Don't be shy because I am sure there are no wrong answers!

I will try my best to share my answer next week.

And what is your excuse?

I finally made my way through about 70 blogs.  Many educated me and a few were easily skipped.  It was this one that I found interesting - Top 5 Excuses for not having enough Testers Testing.

My Product is not finished yet:  I agree with the article that this excuse is silly.  The best and perhaps the most important testing happens at the beginning of SDLC.

Quality is everyone's responsibility; No dedicated testers needed:  I very much believe quality is everyone's responsibility and quality is enhanced by having a dedicated tester leading the charge.

We have budget/time constraints:  Oh!  This excuse is so very true.  This is where experienced testers add a tremendous amount of value by executing risk based and Session Based Test Management, SBTM.  In the world of continuous delivery time constraint certainly is playing a more important role in the land of excuses, so creativity and automation are highly valued.

My product is perfect.  It does not need testing:  This one is just laughable.  Hand the team a copy of Perfect Software by Gerald Weinberg.  Honestly it does not take much effort to find flaws in almost every software product today.

A separate QA team can build an 'Us vs Them mentality', which is not Healthy:  I have to admit that I have heard this one too.  And I agree with the article that this sentiment boils down to culture and style.  Agile software teams today should have a set of roles responsible for building great software regardless of the management structure.

I think there may be a couple more excuses floating around.

Our customers will let us know if we have bugs in our product:  This one is very sad, but I think it is true for some web applications.

Revenue is more important than product quality, just deliver it on time:  I think this may be a true excuse for young entrepreneurial companies.

The developers are doing enough testing:  In my opinion you add a great tester to this team it may just be humbling.

I set out to think of 5 additional excuses, but I am afraid I am going to fall two short.  

I think we should all focus on making great software and a little less on excuses.  We are human and yes we all do make mistakes.  I would rather a colleague catch my mistake than a customer.

Happy Testing!

Testing versus Winning the Lottery

I just returned from a wonderful vacation at Seagrove Beach Florida.  I really did not have a clue what to blog about until I reflected on the vacation.  On our road trip we stopped at a Subway/Gas station.  I observed many interactions at this place, but the one that peaked my curiosity was the two ladies who spent $32 each on Power ball tickets and the family who sat at a table rapidly scratching their pile of scratch off lottery tickets.  I guess I was amazed at how they could spend their time and hard earned money on such long shot purchases.

As related to testing is seems like testers may spend most of their time rapidly looking for long shots.
Great testers typically do not rely on random luck, but I feel like there are some similarities.

Sometimes we testers throw money at the problem like the two ladies.

Sometimes we collaborate like the family all doing the scratch off tickets.

I did not observe the diversity of the scratch off tickets, but I could assume that the family strategically selected the tickets they suspected might pay off.  We testers do the same thing using a risk based approach to testing.

I believe the two ladies relied on the random generation of power ball numbers.  We testers use random inputs all the time hoping to hit the defect jackpot.

My conclusion is that testers gamble often.  Our jackpot just happens to be bugs!

A/B Testing Experience Report

First I must start out with a huge apology to Lisa Crispin.  I had promised her a brief experience report on A/B testing a few weeks ago and I failed to deliver.

I thought it would be a good topic for a blog post.

First I would like to explain some potential confusion.  Recently I have heard people mention A/B testing as Test Driven Development.  Although I think the phrase is applicable it confused me because I think of Test Driven Development, TDD, as write your tests then your code.

So in the spirit of A/B Testing you write your experimental design and then execute against that design.  They certainly seem analogous, but I get confused in conversation and thought perhaps others might.

I first learned about A/B testing in 2002.  I was with a small start up and we were trying to follow XP patterns at the time.  I recall doing a couple of successful A/B tests on new features, but I really do not recall the actual mechanics.  We did leverage a Big Lever software product called Gears to rapidly establish feature sets, but I was not privy to the server mechanics or I simply do not recall.  The tool set did allow us to expose a customer base to feature A in a control fashion.

Today it is my opinion that A/B tests take on a way more sophisticated approach of scientific design.  You will also hear this technique referred to Multi-variant Testing, MVT.  I am amazed at how much design takes place today in order to have a successful A/B test.  The key piece in my opinion is having robust mechanics for measurement.  Sometimes a small statistical measure of variance can make a huge difference in the success of a business.

Here are the key components to a successful A/B test:

• Hypothesis
• Tools for Measurement
• Mechanism for Traffic Control of the User experience

A/B tests can be extremely simple or extremely complex.  Most of the time the experiment is designed to evaluate user behavior with the hope of directing that behavior to improve a business result.  I think a guiding principle is to only adjust one variable at a time.

A hypothesis can come from anywhere in an organization, but in my opinion it takes a diverse team to evaluate the data and draw a meaningful conclusion that might improve the business.

Example hypotheses:

• What if we increase the button size so more people will click it?
• What if we change the checkout flow from Vertical to horizontal will the experience be better and sales increase?
• What if we change the color from blue to green will we have more customer retention on the web page ?
• What if we used a larger image size will more people buy the product?
• What if we moved widget A above the fold would customers be more likely to use the widget?

Example Tools for measurement:

Google Analytics

New Relic

Splunk

Mechanics to control traffic flow:

Load Balancer

Varnish

There are many more tools and even companies who's business model is based on multi-variant testing.  However, these are the tools I am familiar with today.

The ability to conduct A/B tests is dependent on many variables, but here is the basic approach.  

You know that X number of clicks on Image A happen per day using Google Analytics.  You would like to increase the number of clicks by 10%.  Your hypothesis is that image size will make a difference.  So you design a web page that has a 200 x 400 image and you also design a web page with a 400 x 800 image.  You deploy each of these web pages to separate web servers.  In order to get a statistically significant sample you divert 10% of the web traffic to web server B that has the design with the larger image.  You believe one weeks worth of data will be statistically significant.  You measure the clicks per day over the course of that week in order to determine if you increased the number of clicks with the larger image.

Unfortunately I am not able to share specific experimental designs or results,  but I think Multi-variant is an important aspect of modern rapid software development.  If you get the desired result from your experimental design it is just a matter of adjusting a switch and your customers are on the new design.

Another cool aspect that I forgot to mention that part of your traffic is the control seeing the normal experiment.  There is a ton of literature on the topic and I will never claim to be an expert.  But I do believe that well thought out tests coupled with accurate measurement can improve your business and customer experience.

Are QA Managers necessary?

Unfortunately I did not attend the Agile Austin QA Special Interest group meeting last Wednesday, but they did explore an interesting topic.  A couple of my colleagues did attend so I got a little bit of an overview.  Since the topic is somewhat hot of the press, I am going to explore the issue.

Are QA managers required in an Agile development world?  Since I am a Director of QA of course my first inclination is to say, “Yes”. 

Is it necessary for the team to include a QA Manager to create great software?  I would conclude, “No”.

Who makes the tough decisions?  I would like to think this is a role of a QA Manager, but a team could certainly make the decision.

Who looks out for the best interests of the testers?  Perhaps we need a union, but I would think this is a role of a QA manager.

Who provides mentorship?  Could be the QA manager, but I think anyone with an experience to share can be a mentor.

Who puts together the budget?  I think this could be the role of a QA Manager.

Who does the hiring?  Entire team should be involved, but I think the decision boils done to the QA Manager.

Who does the people management such as career growth or disciplinary actions?  I would conclude the QA Manager, but it could be any people manager.

Do QA managers get in the way of Agility?  They could, but I think a good QA manager would not get in the way and would be an advocate for innovation and change.

Why was this topic even pondered at a QA SIG?  For this answer I wish I had attended.  I suspect as companies grow, layers of bureaucracy cause frustration and a reduction in speed.

Without QA Manager role what would be a logical career path for testers?  Oh yes, I believe testing is a career, but a tester could be perfectly satisfied focusing on a technical growth path and not in management.  I do like the fact that over time testers have a choice.

I have pondered several questions in this exercise, but I do not think I have scratched the surface on this topic.  I am leaning toward the cop out answer of “it depends”.

If every tester was self motivated, self correcting, self reflecting, and great at their craft, then I would have to say QA Managers are not needed.  However, with the inherent complexities with in a company and various degrees of learning, I think QA Managers can serve a very important role.

I have been managing projects and people for almost 30 years, so believe it is an important role.

Some of the software purists believe that there is no need for QA at all and that code can be so perfectly created that it encapsulates the requirements and essence of the product being delivered.

Many of the “Great” testers that I know are either managers or corporate consultants, so I would conclude leadership is vital from a quality perspective.

It is a delicate dance that probably depends on the size of the company, the structure of the company, and the complexities of the application under test.

Do you have an opinion?