As more and more companies make the shift to Agile we see more QA teams stuck in the middle.  Companies decide to take the first steps to moving to Agile methodology, typically selecting a trial project or product before rolling it out company wide.  But who decides what Agile principles to implement?  What we often is see is grab bag of what is the easiest to implement or most convenient to the current company culture. This creates the “Agile-lite” environment where many teams get stuck.  We see some Agile best practices mixed in with old waterfall habits that are hard to kick.  More often than not this means that all Agile principles do not get used.  In any environment, changing methodologies presents many challenges. One of the first steps often over looked is training your team in what Agile looks like when implemented correctly (see: more than just “no documentation”).  It can be threatening to your team to switch their roles and responsibilities so make sure that they understand what they are and why they are important.  It may be helpful to draw parallels to old practices where they are replaced or improved by the new processes.  But most importantly, jump in with both feet and fully immerse your day-to-day activities in the methodology you have chosen.  You will be more successful in your implementation when you take ALL of Agile.   

Have you already migrated to Agile or are you in the process of doing so?  What have been the hardest old habits to break?  What is holding you back from implementing other parts of Agile best practices?

- Colleen Voelschow

For many years it has been a generally accepted rule that software testing and development report to different managers and have an autonomy that allows each to counter balance the other. The thought was the only way to have truly objective testing done was to have the testers report to someone other than the development manager. They would report to someone who has equal clout as the development manager and could thus duke it out with the development manager if there was is issue.

This model has worked well for many companies and most software testing ‘leaders’ still subscribe to this method. However is it really the best way to run things? Are separate development and testing departments needed or is a single software development group with different areas of focus more practical?

Over the last few years black box testers are rarely needed. Most companies do not want someone who has limited technical skills and can only run tests against a UI. Even grey/white box testers are being asked to expand their skill set to be more technically savvy. More and more companies want software testers with development skills. Microsoft is recognizing this with Visual Studio 2008. Their Team System architecture has a specific Test Edition. For years Visual Studio has only been used by developers. And in all fairness it was designed and implemented for developers. However, total lifecycle development is increasing in scope. Testing is being recognized as a part of the development process not a separate activity. The Agile software development life cycle recognizes this and testing is built in from the very beginning. Does it make sense to have a separate testing department when in reality they are working on development with development tools?

Is the future of software testing the future of development? Is testing as a separate department a thing of the past? Does it make more sense to have development teams (including those who are testing) using the same tools working on the same product reporting to the same manager?

What are your thoughts? Is anyone implementing Microsoft Team Foundation Server and integrating the Testing Edition?

~ Lawrence Nuanez

Improving metrics is one of the most frequently requested needs of our customers.  Management and project stakeholders need to have a clear picture of a projects health and any given time during its lifecycle and metrics provide that window.  These metrics however, mean very little to those attempting to interpret them if they are different for every project.  It sounds simple enough, right?  You would think so, but often projects within one organization end up capturing and evaluating different sets of data.  I encourage many of the QA teams that I work with standardize and simplify their metrics so that teams outside of QA know what to expect and how to interpret them.  Start with the basics- decide what you want to measure (are you evaluating the product or the process?) and determine how to quantify it.  Use this as a baseline for data collection for all of your projects. You will be setting company wide expectations for how quality is measured and eliminating any personal subjectivity. Standardized metrics will prove to be a valuable tool to compare projects against one another as well. 

What metrics do you collect?  Are they the same for all projects?  Do stakeholders know what them mean?

 -Colleen Voelschow

We talk a lot about the skill set that all testers must have, such as being detail-oriented, having good written and verbal communication skills and the ability to work in fast-paced environments. But, we know that most companies only take a cursory glance at your skills and then want to see what your personality is like. So, what personality traits make a great tester?

Enthusiastic – If you are not enthusiastic about testing most QA managers will not be interested in you. Enjoying sitting down and breaking software is almost as important as “detail-oriented”.

Thick Skinned – You have to be able to stand up for yourself and not lose a step when you get shot down. Plus, if someone challenges your work or your approach you must be able to take it as constructive criticism and not as an attack on your integrity.

Even Tempered – Losing your cool is never a good thing when you are on the job, but if you are someone who easily gets riled up, then testing is not the job for you. Daily stresses and constant pressure make it difficult to stay calm.

Organized – Being able to organize complex programs into smaller systems is not just a skill; I do believe it is also a personality trait. If you are not inherently able to organize your thoughts it can be learned but it is much harder to that way. (Author’s note: Organized does not necessarily mean clean… I know plenty of organized individuals with messy desks (including myself)!)

Good Sense of Humor – This one is almost more important than the first one, in my experience. Testing can be funny! And if you can make it fun then it is even better. I know testers who love the tedious parts of testing only because they incorporate some humor into it. Also, knowing how to take a joke is very important in team environments.

What other personality traits can you think of that you have found helpful in your testers?

-- Charity

Recently I was speaking with the VP of Engineering of a software company in Denver, CO. Since his company deals with many cellular phone companies, I asked him his thoughts on the recent report that listed cell phone companies near the bottom of most customer satisfaction surveys. He said he wasn’t shocked. I asked if that would ever change. He said he didn’t think it would. He said it would not change as long as customers tolerated poor cell service and dropped calls. But don’t all cell phone companies drop calls and have poor cell service? In the opinion of most the answer is yes. If there was one cell phone company that could actually provide consistently good quality cell phone service and keep those calls connected, customers would flock to them in record numbers. So why hasn’t it happened yet? Honestly it is because the vast majority of us just deal with it. We know it is unacceptable yet we accept it! Why??!!

Poor quality also infects software development. How many of us have just gotten used to programs freezing and not responding? Or operating systems ‘just dying’ and having to reboot the machine? A sad but true fact is that the majority of people tolerate poor quality because they feel they have no choice. If you change to a different program that one will just freeze or die in a different way.

It reminds me of the automotive industry in the United States about 40 years ago. At the time you could buy a car from one of the ‘Big Three’ auto makers or from small foreign car makers. There wasn’t a huge difference in quality at the time. However, at about that time several foreign car makers made a concerted effort to improve quality. The ‘Big Three’ laughed and thought there was no way the foreign car makers would ever make a serious dent in their bottom line. This was America and Americans buy American. But that did not prove to be the case. Americans proved to be like everyone else in the world – they wanted good value for their money and they wanted quality. It turned out that where it came form didn’t mean as much as was thought. By the time the American auto makers realized they were in trouble, it was too late. They had suffered a loss that they may never recover from. Sure, they continue to sell cars but their reputation is forever tarnished.

A s you look at the software landscape, are there companies out there that are going to put quality first and force people to take a stand? Is it possible to achieve with software what some auto makers have achieved in the auto industry? There are behemoths in the software industry that seem indestructible – can they be toppled by the little guy who actually makes a better product? At what point will we stand up and say we are not to going to accept the unacceptable?

(For the record – while I was writing this blog my browser inexplicably just shut down and the word processing software I was using stopped recognizing lower case letters for no known reason and had to be restarted.)

 

~ Lawrence Nuanez

The improper use of terminology in the Quality Assurance industry is rampant. I was recently asked when QA terms would be standardized across all companies. The truth is that the standardization is already out there just waiting for companies and individuals to learn and adopt the proper words and definitions. The largest group of offenders is Quality Assurance professionals who have been in the business for a long time. Many feel like they have been using the proper terminology for years and they may not even realize that they learned it wrong in the beginning. No matter what “modified” software development lifecycle you adopted the terminology stays the same. Companies allow the use of terms like “use cases” to be used incorrectly with the reasoning, “The team knows what that means here in our environment.”

The problem with allowing this to continue is that it degrades the organization’s ability to speak intelligently about their quality practices to other QA professionals. Anytime your QA team speaks to outside representatives, be that other test teams or even new employees, the words they use must be industry standard or you risk loosing respect in your quality as an organization.

Think about it: How does your company define “use cases” or “test plan”? Ask a friend or co-worker the same question. Do they match? Now download the latest glossary from the American Software Testing Qualifications Board and check your answers. What did you find?

Job seekers please note: Many companies are beginning to test professionals on their industry knowledge prior to hiring for quality assurance positions. Not knowing the standardized definition for a specific test term can potentially lose you a great job.  Taking a certification course can help you discover what you have been missing and give you an edge in your next interview.

Any time you attempt to set off on a new path, take a suggestion from your childhood and find a buddy. Even in the corporate world it is a good idea to find someone who can agree with you and back the changes you are hoping to make before you set off down the path. Making the right choice in partners can make all the difference. For a quality assurance professional getting ready to make a change to the overall project or development process usually the best person to get on your side is the project manager. With the PM’s support you can make a lot of change happen fairly quickly on a project by project basis.

Depending on what development model your company uses some form of QA process may already be built in. But, if you find yourself or your team struggling to get what you need to efficiently complete your work on a project then have a heart to heart with the project manager. Find out what the project manager expects from each role, how they envisioned things occurring and then make suggestions that might help the communication or work flow within the project improve.

What changes could your project team as a whole make to improve communication? Do you meet too often or not often enough? Are project meetings open forums where members are allowed to discuss current status and problems or are they just task reminder meetings for the work ahead? As a Quality Assurance professional do you see changes that could be made to facilitate the right people getting the right information at the right time?

- Charity

Today’s software companies and corporate IT departments need testers with more than just a keen eye and excellent verbal and written communication skills that we read about in every QA/Test job posting. Communication and the power of observation should be requirements for any job. Testers need to extend their skills into development, process and product domain knowledge. In current times software cycles move very fast. Testers need to do more than just point out a potential defect; we need to identify its source, better the procedures, and truly understand the business needs. This is not possible without intimate knowledge of the underlying working of your product and environment.

Test Managers, what type of skill sets do you expect from your staff?

Test Professionals, do you continue to expand you skills outside of testing techniques?

Conferences have been around for as long there have been companies. People have an intrinsic need to gather in groups to talk about what they do. Quality Assurance and Software Test people are no different. Conferences have popped up all over the world for such topics as automation, load and performance testing, vendor specific conferences, and just general QA conferences. Some of these are quite large and are attended by thousands of professionals. Some of these larger conferences invite well known speakers and vendors and have workshops that can cover many topics.

Some conferences also can take on the feeling of an extended sales call. You can be inundated with new product news and session after session on why certain products are needed by your company. Does it make a difference if a conference is vendor specific?

The price can also range from free to thousands of dollars. It is worth it to attend these conferences? If you have attended one and benefited from it, why was it beneficial? Is it possible to attend a lower priced conference and still learn a great deal? Or are conferences just a way for an employee or two to get out of town for a few days, stay in hotel, and eat out while making a token appearance at some of the sessions?

-- Lawrence Nuanez

Many of the clients I’ve worked with come to ProtoTest looking for some direction for their test documentation to take. Some clients have very little documentation and are looking for standardization in templates and test deliverables. Other clients have a heavy documentation process but the documentation is produced and often not referred to or used again. Even in an Agile environment, documentation is an inevitable part of software testing but one solution cannot be applied to every situation.

When evaluating your documentation needs it is important to remember the end goal of the documents being produced: COMMUNICATION. You need to look at your audience and their needs to determine what is the best method, content and format of the information required. Documentation for the sake of documentation is waste of time for everyone involved, so spend the time upfront to identify the goals for written deliverables. If you are working from templates that are not fostering valuable discussions and actions, it may be a good time to revisit the content of your templates. And don’t forget that words on paper will be of little value if no one reads them, so take the time to hold walkthroughs and collaborative reviews to get your audience involved in the process.

What changes could you make to your documentation to make it more beneficial to its audience?

~Colleen Voelschow