The right balance for a QA team

I've spent a year and a half working in QA, and I've spent about another year and a half in development. This gives me a unique perspective on QA teams. I recently realized that the manager of the QA team that is responsible for testing my teams software is operating under a dangerous assumption; that all QA engineers need to think like she does. What would happen if you had a QA team that all thought alike? You'd miss a bunch of bugs! There is no silver bullet for anything, and this applies to QA engineer traits.

I'm not the only one who feels this way. I ran across this idea first in the book Effective Software Testing: 50 specific Ways to Improve Your Testing by Elfriede Dustin. Item 14 deals directly with this. It states simply that QA team members need to complement each other.

Why is this the case? I think it is because humans working in groups work best when they complement each other. People are different and have different abilities. All of these abilities are beneficial in their own way. The same goes for a QA project.

Consider working on a large project with yourself. How do you know when you examined every angle? How hard would that be? Now consider working on a similar with someone who has a different personality than you. Might they find things that you did not initially consider? Would every angle be covered quicker? I think it would.

So, my point is, that a QA team needs to be balanced in order to achieve maximum efficiency and testing coverage. I feel different personalities complement each other, and allow QA to cover more ground. I feel the following personalities are needed on an effective QA team. However, it is possible for one person to have two hats; that would be perfectly normal.

QA veteran:

Let's face it, experience testing can be quite helpful. Veteran's understand a great deal about testing and can be a mentor to the rest of the team. Veteran's usually take a lead or guiding role on the team and are capable of testing covering a lot of tests quickly.

QA Newbie:

On the flip side of the coin, we have a Newbie. This is someone who is relatively new to testing and the product being tested. This is beneficial, as the newbie can be used to test old features and, in their testing, they may find things that others have overlooked. Newbies provide a fresh perspective and can be sculpted into one of the other types of QA engineers.

Tech Guru:

The tech Guru has a great deal of technical knowledge. A Tech Guru would be comfortable talking with IT or Development on highly technical issues. The Tech Guru is responsible for gray-box testing and thus would have a great understanding of how the product works under the hood. The Tech Guru, in addition to Development can identify areas of testing that are necessary or unnecessary.

Subject Matter Expert:

A subject matter expert is someone who may have (or did) use the product in a previous job. They understand the end user, because at some point, they either were the end user, potentially the end user, or worked very closely with the end user.

User Interface Expert:

The User Interface Expert knows how to tests user interfaces. Nearly every product that a QA team will test will have a User Interface. Since the user interface is the product to the client, ensuring that the UI meets usability standards that have been set out and is very familiar with different UIs.

Now, there are other types, but I feel that this list represents the most important QA personalities. In addition to these, you could have a Database Expert, Automated Tester, or a Performance Tester. However, I think these are simply different forms of a Tech Guru, since technical tools are required for these tasks.

I hope you agree with me that diversity should be encouraged, not stifled. Our diversity can be a great strength. While I'm applying this to a very specific target of a QA team, this principle applies to humanity as a whole. Our diversity makes us different, but working together, using our strengths appropriately allows us to move forward faster.

A much desired hack for IE 7

If you're like most people, you're using a version of Internet Explorer (abbreviated as IE). You might not have made the switch to IE7, but when you do, there is one hack that I highly recommend. By default, IE7 runs without a menu, like shown below:

To enable menus, simply go to tools (it's just a little bit underneath the 'X' in the upper right hand corner), and there will be an option near the bottom called 'Menu bar'. Click on this and the menu bar will appear, but not where you would expect:

(Do you see it?)

Ok, we can fix this. Fire up the old trusty 'Regedit' tool (** Disclaimer: only modify the registry if you are comfortable doing so. Failure to be cautious can cause you to be the owner of a $500 paper weight). Navigate to 'HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/Toolbar/WebBrowser/'. Now, left click below the current keys in this folder and select “New > Dword (32 bit) value”. Name the new value 'ITBar7Position'. Once created, modify the value and change it to be 1. Exit the registry and restart IE7. If successful, you should see something like this:

That's much better.

What I will do in the next 6 months to become a better developer

I've been on a quest in the last couple of weeks to discover tips on becoming a better developer when I ran across this podcast by Scott Hanselman which suggests a few ideas but largely states that whatever it is you decide on, that you write it down and you make it public. So this is my first blog post as part of my attempts to become a better developer in 6 months.

Instead of picking just one item, I've picked 5 items to work on and complete by October 11^th, 2008.

1. Post 26 blog entries, approximately one blog post a week.

2. Read the source code for 2 open source projects.

3. Read 2 books on development

4. Start a local pub club for software development

5. Publish 2 software applications

I think the first item is self explanatory. The second item is also courtesy of Scott Hanselman on this blog post. I've decided I'm going to tackle two related projects, NAnt and CruiseControl.Net. I've already glanced at the code for CruiseControl.Net for reasons that I'll explain in a couple weeks.

The idea for reading development books came from the original source for this idea, a blogger named Justice Gray. While I won't go to the extent that he planned (I say planned, because he never reported on his success or failure), I do plan to read two books. The first is a book my wife picked up for me because it had the word “Code” in the title, Dreaming in Code. I've read the first two chapters of the book and so far, it's better than I expected. The second book is more technical, Web Technologies: A Computer Science Perspective. I read a sample chapter of the book courtesy of TechRepublic, and I enjoyed the nature that the material was presented in.

The idea for a pub club comes from Scott Hanselman's podcast I mentioned earlier. I think it will entail only other developers that work at my company, but I hope to add other people as I get acquainted with other developers in the area.

Finally, I plan to release two software applications. I have several ideas for software projects floating around in my head, and I hope that giving myself a deadline is what I need to ensure these projects get accomplished. More on what these software applications are in a couple of months.

Now that I've laid down my 6 month plan, do you have a long-term plan to be a better developer?

Learning and Fixing our Bugs

I had a particularly nasty issue assigned to me a week or two ago. It's one of those bugs that I spent so much time and effort on that it was difficult to enjoy my evenings and weekend. It was nasty for a variety of reasons.

First, it involved a program component which was originally written by a developer who had already decided he would no longer work for the company, but decided he'd finish this component. As you can imagine the code is in horrible shape. Few people have any knowledge of this component, and none of those who do understand the entire system.

Second, this component could be considered an entire software solution in its own right. The size of the project is large enough that it is often installed on its own machine in production.

Third, this component was installed in an environment in the testing environment which had taken 6 weeks to setup (normally, just a few days is required).

Fourth, the error message was one that had occurred before, and in most cases, pointed to some particular setting being incorrect. Thus, it made it very difficult to rule out environmental issues.

Finally, this component is not used by one software team, but three. Since all three teams use the same component, no one “owns” the component. However, there are “satellite” assemblies of this component which each of the three teams provide on their own.

Because of the third and fourth reasons (similar errors pointing to environment issues), I spent a good amount of time traveling down that path. In the end, it proved to be a very complicated issue. There were multiple reasons for the errors. Most of the errors could be tracked down to the final reason, no one owning the software component. Due to this fact, code for this component was not delivered correctly, because of the satellite assemblies.

I learned a couple valuable lessons from this error though. First, I had great difficulty recreating the error due to a poor setup on my development machine and I can never let that happen. While I normally detest debugging, debugging this component is absolutely essential, for the size of the project and the poor state of the code is to much for one developer to grasp at one time.

Second, and more importantly, I learned it is a VERY bad idea to have a large internal component which is used by several teams, but no one team is responsible for maintaining. In hindsight, this is obvious, and probably rarely happens in other companies (if does in yours, I'd like to know).

While I could have done a much better job in handling this error and I could have solved it in a much quicker fashion, I have at least taken a couple things away from my mistakes, and my boss has recognized that this component needs to be developed by one team, and one team only.

So, recognize that mistakes will happen, but always learn from them, especially in the field of Development.