Motivating QA Team

Job satisfaction among QA professionals has been traditionally low when compared with their development peers and with those in other departments. Why? External misconceptions that are out there such as “anybody can do QA”, “hire some out of school kids to test our applications”, or “QA folks are in reality ‘developer wannabees’, can really have an impact on your team’s morale.

We will take a closer look at some common QA miss-perceptions, reason why they are wrong, and gives you some specific follow-up action items that you could act upon to keep and maintain a motivated staff.

Myth #1: Anybody can do QA

Wrong. Testing is a skilled activity that requires the ability to think, explore and follow logic while questioning and reasoning at the same time. It is based on the philosophy of performing a technical investigation of a product, to provide information and report back to various stakeholders throughout the organization. And to achieve

the end result of communicating back your findings, you will need to use various types of infrastructure and experimentation, logic, models, mathematical probabilities and supporting tools to build the appropriate Test Case scenarios. And don’t forget that QA teams usually have very limited product documentation (if any), and have to work in a very time-constrained schedule.

Myth #2: Any out of school kid can test our applications

Wrong. Your applications are a critical company asset. Depending on the nature of your business, direct profit and revenue can be impacted if an application goes down or performs poorly. And of course, a company’s reputation can also be seriously damaged when things don’t “work” right. Think about it. Will you hire an inexperienced, out of college kid to take care of your critical investments and financial assets? Those who looks for a Quality delivered product, they will surely look for skilled QA Engineers.

Myth #3: A QA Engineer is a “Developer wannabe”

Wrong. While it is true that some QA engineers like to get into the code, and enjoy using automated scripts, there are other folks that prefer a “thinking & building test cases while executing manual tests” type of approach. Probably within your team you will even have a mixture of skill-sets and different personality types. Similarly you will have folks that started in QA, landed in QA from a different career, are considering a career change, or want to remain in QA for the long term. What is important to remember is this - QA is a valuable professional field that requires intellectual efforts similar to those required to develop a product. Think about it. A QA Engineer is developing the plan that will ensure the success of a company’s product in the marketplace.

Myth #4: QA doesn’t provide much value to the organization

Wrong. QA represents the heterogeneous users of the products that your company produces, so they are there to improve product quality, ensure a better user experience and reduce support costs. Let’s take a quick look at some of the responsibilities that QA has within an organization. QA engineers are in charge of finding and reporting bugs (from critical problems to minor enhancements or documentation changes), and verify that bugs are fixed (and that nothing else broke because of code changes). In addition they typically work very closely with development, product management, customers and other internal folks to understand product functionality and use cases, as well as build appropriate test plans. They are the ones you want to vouch for the adequacy of your user documentation while it is being finalized. To top it all, QA teams assess product conformance to specifications and standards, while checking interoperability with infrastructure, complementary products and/or third party vendor products. Lastly, they have the final saying of when a Beta and/or GA product can be shipped to customers, so they can block or veto a premature product release. Very impressive, right? To say QA doesn’t provide much value would be gross misrepresentation of the truth.

Myth #5: QA is a boring, repetitive job with no creativeness involved

Well, this one could be partially true, depending on the internal processes that you have in place. For example, if QA is not involved with a project from the beginning, there is not much room to bring new ideas or feedback to product’s requirements. And this could translate into lack of empowerment, and not feeling appreciated. Another scenario could be if you have no automation in place, and there are truly repetitive tasks and regression testing steps that could in fact be automated in your environment.

So, What Next? How do you motivate.

Let’s look some point which makes QA to work better and motivate in several aspects

· Evaluate internal atmosphere.

Are the development team gives respects to QA? Whether QA team is involved in all project related meetings? If there’s appreciation given for a team, then QA person efforts should also be considered and rewarded.

Communicate, communicate and communicate. A good idea could be to come up with a list of periodic achievements from your team, and get in the habit of talking about them whenever you are interacting with your peers.

· Improve QA-development relations. If you have noticed that this relationship is not that great, think of ways to improve it. For example, if a development manager and a QA manager that are not communicating well are reporting to the same layer, escalating discrepancies to the top (which might work in other environments when both teams are independent) is not the right approach here. In this case you could try building a personal relationship first with your counterpart, and try to understand the other person point of view when discussing issues. In addition, you could think about having team building exercises for QA and development teams together, or having daily cross-functional meetings in your department.

· Enhance your QA job descriptions

Modify the job description of your postings to first attract better candidates, and secondly send a positive message to your QA department. What would you rather see and apply to? “We are looking for a QA Engineer to perform hands-on testing of our SDK. The QA Engineer will provide functional and boundary testing and timely feedback. They are also responsible for the project bug database and associated maintenance tasks, etc” or “We are looking for an innovative and resourceful QA Engineer – aka problem solver—who is able to conduct software testing, and bug report assessments with integrity and honesty; ability to manage own projects; good interpersonal skills, etc”. Taking the time to put together a more enticing job description, sends a strong message that your company values and appreciates their QA resources

· Involve QA in your development cycles from the beginning

This is critical to ensure that QA Engineers fully understand the product, user personas and testing scenarios, enabling them to bring valuable questions to cross-functional meetings, and have an impact on design and architectural decisions right from the beginning. If possible you could start exploring Agile and Scrum technologies as a way to change your development processes. In case you are not too familiar, Agile methods are built on the philosophy of minimizing risk by developing software in shorter timeframes, which usually last one to four weeks.

· Be a “good” manager.

As referenced in the opening, employees leave many times because of their managers, and not because the actual job on itself. The inverse is true also – employees will stay with an organization because of their manager. So the bottom-line here is: try to keep the working environment fun and challenging; show appreciation to your team members, and consider allowing working from home some times, telecommuting or flexible schedules. After all, as long as tasks are done in time, do you really care at what time of the day are done or from which location