As a Quality Assurance and Testing consulting company, we are always on top of the going rate for all levels of testing professionals. Traditionally, the QA staff has been seen as the “less technical” personnel on the project team. Often they are not invited to the same meetings or provided the same information as the rest of the project team, particularly the development staff. In turn, the QA staff is often paid less, sometimes substantially less, than other IT staff on the project team, including development, DBA’s and project and product management. They are often paid more in line with the technical support staff. Both teams of which I might add have the customer in mind and are often the key link to the customers. But, I digress.

We MAY be seeing some end in sight for equity in pay. We have seen more and more demand for testers with some development background. There is more need for testers to have scripting and/or other development experience, however minor. In the more prevalent world of agile development, testers are working side by side with the developers. They may be working in a Test Driven Development (TDD) environment, or may need to test products that are created in an environment that traditional commercial tools will not suffice. So, more scripting, automated testing, and even testing utilizing open-source test tools is becoming more necessary. Therefore, the tester is being required to gain new skills.

The good news is we are starting to see better salaries and consulting rates for testers. If you have a special skill, such as Performance and Load Testing, writing test scripts in Watir, or working directly with the developers, you may deserve an increase. Or you may want to ensure you know the current market and what your skills are worth. Don’t accept being underpaid just because of history. Challenge your situation and be paid what you are worth!

We are excited to announce that ProtoTest is a Champion Sponsor of FROSSTCON - the Front Range Open Space Software Testing Conference - to be held October 10 and 11, 2008, in Westminster, Colorado.  Participation is FREE so be sure to register today. 

FROSSTCON is an Open Space event.  In case you are not familair, the open space methodology is governed by one law and four principles.

The Law of Two Feet

If at any time you are not learning or contributing, use your two feet and move to something you like.

The Four Principles
Whoever comes is the right people.
Whatever happens is the only thing that could have.
Whenever it starts is the right time.
When it's over it's over.

If you have never experienced an Open Space-style conference, give this one a try. 

Developing software via the Waterfall method has been around for a while. Waterfall was introduced (but not named) by Winston Royce [1] in 1970 when computer systems were monolithic, number-crunching entities with rudimentary front ends (by today's standards) and users' needs were filtered through the partisan minds of the computer illuminati building the systems.

At that time user feedback was an inconvenience not an asset. The developer spec’ed out and developed the product as they thought best. As Phillip A. Laplante and Colin J. Neill of Penn State University say regarding this “In such an environment the Waterfall works. Requirements seldom change after specification because users are not involved in the development; they can't provide feedback about incorrect assumptions or missing features and needs. This era is over, though. Software systems are so much closer to the user that their voices cannot be ignored; they'll reject the system if it doesn't meet their needs.”

This isn’t really a new realization. Many smart business people realize that developing software the old fashioned way is a recipe for failure. Yet a survey conduct by Laplante and Neill [2] noted that the dominant process model reported was waterfall with more than a third claiming its use. This result raises a question: Do practicing professionals know the Waterfall when they see it? Perhaps they are confusing it with other process models. This seems unlikely, but so does its dominance. It's more likely that in many circumstances, doing the wrong thing is easier than doing the right thing—and this is not a recipe for success.

I believe that many people are going the path of least resistance. Waterfalls don’t flow up and it seems as though some are adopting this attitude when it comes to change. I believe many people are too scared or confused to change. As a result poor software is being delivered and people are getting fed up with bad software.

Do you agree or disagree? Do you think waterfall can work? I believe it should go the way of the Dodo bird (or any other of the thousands of species man has wiped off the face of the earth) and simply cease to be.

~Lawrence Nuanez

[1] Royce, W. W. Managing the development of large software systems. Proceedings of IEEE WESCON

[2] Neill, C. J., and Laplante, P. A. Requirements engineering: the state of the practice

I have been to several companies where the only test placed on a development deliverable was the unit test. Granted, these are all in-house, custom development departments whose products never see a shelf beyond the walls of their own corporation. However, several of these companies have asked me, “Could you please teach these developers how to write a better test case? We are tired of them missing defects.” The answer is hopefully obvious. Teaching the developer how to test their own work is the wrong approach. Try teaching a writer how to edit their own novel without an editor. In most cases a second, un-biased eye needs to be placed on the work in order to see the flaws.

The problem with editing one’s own work is that humans have a tendency to assume that the work they have done is correct and complete. A good tester is a third party, someone who has not completed the piece of work they are testing. A better tester is someone who enjoys testing and most importantly has the time to test the product. Expecting a developer to test their own work within the same development timeline is setting both you and your developer up for failure.

The problem here is not that testing is or is not being done. The problem is that custom, in-house development groups are not giving their in-house clientele the same respect they would a paying consumer. It is much easier to throw a defect ridden product to an internal user and ask them to live with patch after patch. No external customer would ever allow that treatment to continue because they could move on to another software company.

The question is how does an in-house group start the change? How do you begin to do the right thing by your colleagues and apply appropriate processes to custom development projects? Is starting with teaching your developers to be better testers really the answer?

-- Charity

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

In the recent past, ProtoTest has been receiving many more requirements for testers that have some development and/or scripting experience.  This is a result of companies moving to more agile-like methodologies.  This in turn, requires testers who can test software developed with newer technologies that commercial test tools may not be able to support. Additionally, more development knowledge is often request of testers so they can create and maintain scripts and more effectively utilize open source test tools. In this new world we will see more agile environments and Test Driven Development (TDD).

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

Great piece on ABC TV regarding the LENA product from our good friends at Infoture in Boulder.  If you have a baby, or plan to have one, this is must-see-TV. 

http://cosmos.bcst.yahoo.com/up/player/popup/?cl=7518708

I am very pleased to announce that this week, a new company has been launched. WatirCraft is a software company that will provide products and services in support of the popular Watir open source testing tool. Our goal is to deliver test automation that works --throughout the software lifecycle.

My partner in WatirCraft is Bret Pettichord (the Watir project lead). Bret is widely known in the testing and agile development communities as one of the original authors of Watir, as an early contributor to Selenium, and as co-author of the book Lessons Learned in Software Testing.

I'm announcing this here because many readers of this blog know that for the past ten years, I have been focused on growing ProtoTest.  ProtoTest is not going away - quite the contrary, we have an excellent team and we're enjoying tremendous success in early 2008.  But I will be splitting my time between these two exciting companies in the coming months and years.

Over the last four years Watir has achieved a critical mass in the market that suggests the need for a company like WatirCraft. More than 85,000 people have installed Watir and many have expressed an interest in seeing more resources behind the product and the availability of support services. Bret and I have formed a bond of trust between us about how this kind of company should be run (given the existing Watir project, community, and shared goals.)

WatirCraft’s business model is based on an existing open source project with a broad base of code, where there is a significant community active in software development, and where we can provide subscription-based services to help people be more efficient and effective when using Watir. 

Watircraft will sell annual subscriptions for software and services, plus training and consulting.   Stay tuned for more information.