- essential and what it involves. Lots of meetings and one-on-one encounters are needed to get everyone on board and to establish priorities.
- Support Information Systems, the group that administers the production site. These people will benefit from not having their pager go off so much when applications are tested before being launched to production. The Vice President of Technology and the IS director fully supported me and refused to launch any update that had not been fully tested. This kept the rest of the organization from steamrolling over me, giving me a chance to prove the value of testing. I don't bug IS for the things I can do myself, but I let them do their job. For example, I installed Y2K patches on the test machines, but IS controlled all the UNIX and NT account management.
- Understand the developers' point of view. You may have young, brilliant developers who don't communicate in ways you are accustomed to. Our original developers were mostly very young and inexperienced. Some had not finished high school!. Others weren't old enough to drink! The culture was anti-corporate, and they said what was on their minds. I found that if I listened, I learned, and they in turn were willing to listen to my ideas. I learned everything I now know about Web applications from the developers themselves. I presented a "Quality Hero" award each month to a developer who took exceptional measures to prevent defects and improve quality. The prize was just a Nerf gun and the developer's name appeared on the Quality Hero Award plaque, but it raised the visibility of high quality process and techniques.
- Brainstorm with developers and others about problems that may not come out in testing. For example, I didn't know that if you change a URL, search engines may not be able to find your site. When we implemented a content management tool that required changing every URL, this was important information!
I. Work Smart
Here's my advice for making the testing organization lean and mean:
These tools won't necessarily meet your needs–just be open and creative when evaluating tools. Investigate alternatives–for example, if you create unit tests to reproduce each bug you find in testing, you may not even need a defect tracking system!
Software QA and Testing Resource Center: Everything from basic definition and articles on how to test Web applications to comprehensive lists of Web tools to links to other informative sites.
Articles by Cem Kaner
Of course, user conferences are invaluable for both information-gathering and networking
In short: Dig your heels in and refuse to launch until some semblance of a test environment is established. Remember, it is harder to get the test environment once the new application is in production. Make it a requirement of release.
- Evaluate tools. Put as much time as you can into tool evaluation, such as those for automated testing, defect tracking, and configuration management. Identify the vendors who can help you the most, and get as much information from them as you can. Ask fellow testers for their recommendations and experiences. Install new tools and try them out. Select tools that are appropriate for you and your company. It doesn't do any good to buy a tool you don't have time to learn how to use, especially if your testing team is small. I ended up choosing tools that are lesser known but stil meet our needs. For example:
- automated testing at TRIP.com (we use this at tensegrent as well), we used WebART, an incredibly inexpensive, easy-to-learn, but powerful tool sold by OCLC Inc. (a non-profit company). They