• Distribute lists of usability problems and unsuccessful design decisions among the interested persons. These lists should also become the topic of regular meetings, and it is necessary to pay attention to them as early as possible so that by the time of the user interface freezing all key changes have already been made.

Once you have the drafts of the user manual in hand, start working with them without delay. Since the manual is already written in the beta stage, try to work it out before the beta version is completed. Beta Software is seen as pilot and is a good way to allow the public to take part in software development.

Be aware of the most important steps documentation testing involves.

• It is most likely that you are more aware of the latest changes made to the program than the author of the documentation therefore check its validity.
• Warn the technical writer about any changes in the program.
• Check if the program has functions that are not described in the documentation or described with insufficient detail.
• Please, be advised that the staff of performance testing company would very much like to make you happy by leading your app towards success.
• When a new tester is thrown in the project, above all, instruct this person to test the program against the latest version of the user’s manual. In most cases, new testers involved in medium-scale projects, are somewhere between the alpha stage and the user interface freezing phase.
• Constantly monitor the progress in implementing the project, checking its results against expectations as well as feasibility and time. Project progress reviews need to be conducted weekly. What new tasks do you have ahead, which ones have already been solved? How do they affect the execution of project plan, how long do they take? Are you satisfied with the time frame? If not, what measures can be taken? Perhaps, it is necessary to reduce the scope of the project or to exclude certain project activities completely? Will the increased number of testers help the case? And maybe the programmers are so far behind the schedule that your slippage does not matter. However, the last consideration cannot be an excuse, and that’s why.
  • If you work too slowly, you will find errors later than would be done according to the plan. So the old part of the program is not ready on time because you failed to find an error in it within the specified time frame.
  • Trying to catch up, you start to work faster, making crumpled and illegible reports, they become less useful for reproducing errors, and, as a result, the overall work is delayed even more and its quality suffers.