has now become a tourist attraction. We natives are getting used to being asked all kinds of questions by sometimes weepy, sometimes furious camera-wielding visitors as we go about our business. We've had to pull ourselves together quickly to help our organizations survive. Based upon what we've seen and heard and tried ourselves since 9/11, here are some suggestions for QA colleagues who may have succumbed to paralyzing malaise¡Xand also for those who feel fine but may want to make a greater contribution to the cause.
In your workplace, be proactive. No matter what your official job description might be, consider the needs of your organization as a whole. If your organization is just too large, focus on your own projects. Contact colleagues in other departments. Ask questions. Offer suggestions to appropriate managers. At meetings, remain calm and professional. Create your own agenda:
- Research your project's or organization's business continuity plans. Determine the extent to which they protect people, operations, property, and data. Inquire whether the plans include a scenario describing procedures to be followed if the Internet becomes unavailable for a week or more. Develop a testing strategy to verify whether the plans actually accomplish their objectives.
- Examine the data architecture of your project or organization. Identify the most frequent points of failure and the weakest security areas. Find out who is responsible for troubleshooting outages and breaches, and how they handle different types of problems. If necessary, provide them with information on integration testing, stress testing, performance monitoring, or security audit services.
- Evaluate your project's or organization's training programs. Under the current circumstances, a major goal of training should be to establish redundancy of knowledge. For every job, there should be more than one person who knows how to do most of it¡Xand is authorized to perform the task. This is especially important for workflow software: data should never get stuck in the system because the only user who executes a certain step is suddenly unavailable. Alert the training director and project manager to any shortcomings you discover.
- Audit your project's or organization's system and test documentation. If you can't do this because of security restrictions, focus upon the documentation for your own team's assignments. The documentation should be comprehensive and enough to enable an entirely new team to take over a project, perform maintenance, and deploy enhancements within a week.
- Conduct the same type of audit for your project's or organization's process documentation. Based upon the written procedures, it should be possible within a week for new staff members to add users to the systems, assign appropriate permissions to databases and operating systems, and take whatever steps your IT group follows to roll out new versions of the software you develop.
- Review your project's or organization's practices for archiving source code. Make sure you have the current version of the production source code for every software product stored in a secure location. Encourage developers to archive their work-in-progress every day, or as often as possible, considering the work habits of multideveloper teams. The archive should include databases used for requirements gathering, change management, and bug tracking, and all project and process documentation.
- Evaluate the configuration management policies your project or organization has devised. Determine whether there is a standard desktop/laptop/wireless configuration that all users are expected to install (or a list of approved alternatives). Find out if there is a comparable standard for software developers and testers, both for in-house staff members and for external consultants. Inspect the configuration, the administrative procedures, and the audit process for security holes. Then re-evaluate the policies' effectiveness in the event