How is data understood through reverse engineering?

Reverse engineering forms an internal part of the whole software re- engineering process. To implement the reverse engineering properly in the re- engineering process one needs to understand the data through the reverse engineering.

In this article we have taken up the same topic i.e., “how is data understood through reverse engineering?” 

- When the reverse engineering is carried out, the main objective is always to recover the designs and specifications of the software system or application.

- With reverse engineering, the development is only understood and no changes are made to the software system or application. 

- For the reverse engineering process, the source of the software system or application is fed as the input. 

- If you go through the history of the reverse engineering, you will find some cases where the executable code is given as input for the reverse engineering process. 

- The reverse engineering though being in a great contrast with the re- engineering forms an internal part of it. 

- Reverse engineering serves the purpose of recovering system design and specifications in the software re- engineering process model. 

- These recovered designs and specifications are used by the engineers to understand the software system or application before they start re- organizing the whole structure.

- However, there have been cases in which the reverse engineering is not always followed by the re- engineering process. 

- There are three stages in reverse engineering process.

 1. System to be re- engineered is subjected to automated analysis.

 2. Then it is manually annotated.

 3. With the system information obtained, a whole set of new documentation is generated containing:

(a)  Program structure diagrams

(b)  Data structure diagrams and

(c)   Traceability matrices.

Activities in Reverse engineering

In reverse engineering the data is understood by the 3 basic activities that involved intense understanding efforts:

1. Understanding process: In order to understand the procedural abstractions as well as functionality analyze the source code on the level:

(a)  System

(b)  Program

(c)   Component

(d)  Statement and

(e)  Pattern

2. Understanding data: It analyzes the internal data structures and data base structure.

3. User interfaces: It analyzes the basic actions processed by the interface, system’s behavioral response to those actions and equivalency of the interfaces.

More about reverse engineering....

- The beginning of the reverse engineering process is marked with an analysis phase in which the analyzation is carried out with the help of automated tools in order to discover the structure of the software system or application. 

- But this stage itself does not suffice the purpose of recovering the whole structure. 

- Engineers then have to work on the program code and model and add the recovered information to this.

- The recovered information is maintained in form of a directed graph. 

- The engineers always make it a point to link the directed graph to the source code. 

- The directed graphs are compared with the code with the help of the information browser stores. 

- This graph helps in generating trace ability matrices and the data structures. 

- Tools that are used make it easy to navigate through the code. 

- After the complete generation of the design documentation, the information store is supplied with the additional information as a measure to re create the specifications systems. 

What is meant by Software Reengineering Process Model?

Software re- engineering process model is based up on the principles of the software re- engineering that was proposed by Chifosky in the year of 1990.  Before we discuss about the software re- engineering process model let us see what software re- engineering is.

What is Software Re-engineering?

- The software re- engineering is considered to be a process that alters a software system and thus reconstituting it in to a new form that is better than its previous form.

- The process of the re- engineering usually occurs after the software system or application has been reverse engineered. 

- The re- engineering is also carried out for the addition of the new functionalities or to correct the discovered faults and errors. 

- Sometimes this whole process is often collectively called as reverse engineering. 

But there is a subtle difference between the two! 

- The former process i.e., the reverse engineering is like an initial examination of the software system and the latter is like the subsequent modification. 

- Re- engineering of the software systems often comes in to play where there is an involvement of a legacy system. 

- In such cases the re- engineering can be considered to be a process that re- structures a legacy system in to a new system that is constituted of much better features and functionality and maintain the quality constraint.

Re- engineering is not a thing that can be achieved in an instant rather it takes a lot of time since there is a utilization of many information technological resources over the years. Therefore every organization requires a well defined strategy for carrying out the software re-engineering. 

Steps in Software re-engineering process model

The software engineering process model consists of the following steps:

1.Inventory analysis: Analysis of all the active applications listed in the inventory of an organization.

2.Document reconstruction: The software systems that are business critical are re- documented.

3. Reverse engineering

4. Code restructuring: It involves the analyzation of the source code and reviewed again.

5. Data restructuring: It begins with reverse engineering and ends with the review of all the data structures.

Scenario behind software re-engineering process

- Software re- engineering process serves the purpose of bringing up the poorly documented and poorly structured code to a standard that is maintainable and acceptable. 

- Let us see the scenario behind the need of re- engineering. 

- In a code that is poorly controlled and maintained, lies either a large number of files spread over a number of locations or consists of only a single file consisting of a very lengthy code.

- Observing these files, one could notice that the comments do not appear to have any relationship with the code itself and the associated documentation has become outdated or refers to the previous versions of that software system or application that has underwent many modifications since then which were left undocumented. 

- To say, an executable file does exists but many decisions have to be taken to run it. 

- At this point the identification of the actual objectives of the software re- engineering process becomes important. 

- There might be so many problems underlying those decisions that now can be easily addressed. 

- It is very important that before beginning with the re- engineering of the whole code that you check its correctness otherwise you will suffer a major set back if you would have been re- engineering the wrong code all the time. 

- At the end of the process the final code needs to be base-lined with the associated project log and the documentation.

- The re- engineered software system or application is brought to a well defined stage at which it can be considered to be ready for the release and also its future maintenance will be less arduous.

What are different design specifications while drawing a test plan?

When a development team is working on a project, how do they ensure that the functionality is being coded correctly? Design specification documentation serves this purpose.

What are Design Specifications?

- A design specification document must be free of any ambiguities and should be complete, since an incomplete design specification document full of ambiguities can have you reaching for the costly rewrites.

- A good design specification follows a pyramidal approach i.e., from the top it provides a complete and broad overview of the software system or application and its components and at the lower levels it provides a detailed overview of the primary components of the application.

- The details should be as much required by the development team.

- Most of the software developers tend to work with design specifications documents which include detailed description of every function, sample screen shots, layouts of the data base as well as reports.

- Many a times it happens so that the client does not provides sufficient detail; in such a case the developer responds in writing asking as many questions required getting a detailed overview of the project.

- These questions are supposed to enquire in depth regarding the design specifications of the application under development.

- Writing an effective and a self sufficient design specification document is an art in itself.

- If you find it difficult to write a design specification document, you can first write a basic outline and then fill it up based up on the needs of the client as well as the skills of the developers.

- Coming up with a document that fits the requirements and needs of both the client and the developer is quite a difficult and requires a lot of struggle.

- There is no need to show the entire specification document to the client or the customer since they won’t understand it.

- Some organizations even take up the extraneous effort for creating two design specifications documents.

- One contains only a broad overview of the application for the customers and clients while the other one consists of detailed description of the application and its primary components meant for the developers.

- There are some artistic developers who themselves like to fill up the details for the design specifications after knowing what functions are to be performed by the application.

- To make it easier, you can start off with a high level description of the design specifications followed by signing off by the client.

- Then you can go for writing second file with more detailed descriptions.

- Keep the design specification document updated as regularly as possible.

- IEEE has come forward to help in this regard and it has laid down “IEEE 1016- 1998 standard” for specifying a structure for the SDD or software design description.

What should a design specification include?

According to IEEE standard, the design specifications must include at least the following:

1. Introduction: It includes
(a) overview of the design and
(b) Requirements traceability matrix

2. System architectural design: It includes (a) discussion regarding the alternative designs
(b) Chosen system architecture
(c) System interface description

3. Detailed description of the application components

4. User interface design: It includes
(a) description of the interface
(b) Objects and events (actions)
(c) Screen image

5. Additional information

After completing writing down the design specifications, you should compulsorily have it signed off by the client or the customer so as to have a proof that they abide by everything that is there in the specifications document.

This also provides coverage to your bases and enforces that the customer reads the whole specifications document. The design specifications should also be reviewed by the quality assurance people since a good design specification helps in creating better test cases.

What are different functional specifications while drawing a test plan?

The successful completion of the software testing cycle depends entirely up on the quality of its test plan. Any test plan is composed of certain specifications which are not to be missed if you want your plan to be effective. Specifications are of two types namely:

1. Functional specifications and
2. Design specifications.

What are functional specifications?

- Functional specifications which are nothing but a formal document that is created for the purpose of describing a detailed overview of the software system’s or application’s intended functions and capabilities.

- It describes in detail the appearance of the software application as well as how it is to interact with the users.

- The functional specifications can be thought of as guidelines or references by the program developers and programmers while the development of the software is in progress.

- The functional specifications for the software system or application that are equipped with some windows and dialogs are aimed at showing the visual appearance of its user interface and also to give a detailed description of all the possible inputs from the users and the reactions of the application to them.

- A functional specification may or may not include a formal description of the dependency of the application on other programs or applications, usability criteria and user tasks.

- To define a functional specification formally we can say that it is to describe the solution technically and is also used as a representation of the contract between a client and project development team.

- It forms the basis for building any application.

What are different functional specifications while drawing a test plan?

- While drawing the test plan, the program manager baselines the functional specifications which are placed under the change control since it sustains all the information that is needed to design the solution.

- Functional specifications seek to incorporate logical, physical and conceptual designs in to the solution for making it more efficient.

- All the high level design decisions regarding the network configurations and server management should also be included under the functional specifications.

What aspects should a functional specification include?

A typical functional specification describes the following aspects:

1. Summary of the project scope (as agreed up on the by both parties in a business context).

2. Any additional requirements

3. The design of the solution

4. Specifications of the components that form a part of the solution

5. Features:
Documentation of all the planned features along with their quantitative specifications such as performance metrics, concurrent user capacity, and data base capacity and so on.

6. Security requirements:
Specifications regarding the strength of security concerning the functions that involve working with sensitive data like transactions. The encryption standards that have been implemented in the security mechanism should also be mentioned along with the location and type of the security mechanisms.

7. Legal requirements:
These must be clearly stated along with the custom codes to me business policy, custom user scenario or a governmental requirement etc.

8. Risk assessment:
This documentation must include the descriptive details about:
- potential vulnerabilities,
- mitigation strategies and
- the impact of the above strategies and vulnerabilities on the application.

There should be no ambiguity in the description of the above stated aspects and the quantitative measurements should be used wherever possible.

What aspects should a functional specification should not include?

Now we list the aspects that should not be included in the functional specifications:
1. Detailed data base schema
2. Details of the software architecture
3. Details about the programming language

Data base details suffice the purpose of the functional specifications and save the development team from extraneous efforts.
The functional specifications are changed only with the due permission of the client. Functional specifications are the living documents i.e., they are continuously updated throughout the development cycle and show how a solution can be deployed in a timely and cost effective manner.

What is meant by entry and exit criterion in software testing?

There is always a certain reason, condition, or basis for doing something. One cannot perform a function just like that. The action or the task performed has to have some justification that why it was done. Certain type of criterion is employed in every phase of testing. Mostly they are employed in dynamic and static testing.

WHAT ARE TESTING CRITERION?
The testing criteria have been defined in to 4 types based on the testing phases in which they are employed. These 4 types of criteria have been discussed below:

- Entry criteria
We all know that this is the initial and starting phase of any testing methodology.
- Suspension criteria
Suspension criteria comes in to the play when in a phase the testing is halted so as to get the documentation is send to the development team for verification.

- Re- suspension criteria
Re- suspension criteria are employed when there changes to be made in the documentation as indicated by the development team after the verification.

- Exit criteria
This is the last phase of any testing methodology. The testing is declared complete when these criteria are met.

WHAT IS MEANT BY ENTRY CRITERION?
- Entry criteria as we mentioned above is encountered at the starting phase of any testing methodology.
- It is a kind of document that is needed for starting the testing process.
- It contains all the necessary conditions that have to be met before a testing is commenced.
- Usually the entry criteria are placed in the “approach to test” section of the test plan.
- For every step in the testing strategy some criteria are stated so there is no wasting of time and testing takes place efficiently.
- There are so many factors to be considered while deciding the criteria.

ASPECTS OF ENTRY CRITERION
There are 3 main aspects of entry criteria that have to be considered:

1. Approved Test Plan
- The test plan has to be developed long back before the testing starts.
- Before you commence the testing, you need to get your test plan approved by all the stake holders.
- All the possible risks are identified at this stage.

2. Availability of Resources
- The testing is carried out in a proper testing environment rather than a normal user environment.
- Resources like trained professionals with good testing skills, testing environment, test input data and paper work set up should be available before the testing starts.

3. Developed Tests
- All the test cases and scripts need to be developed before the commencement of the testing and must be verified by the stake holders.

WHAT IS MEANT BY EXIT CRITERION?
Now coming to the exit criteria, it is the criteria which are required to end a test cycle. Exit criteria include:

1. Deadlines for the completion of the testing.
2. Completion of test cases with some minimum passing percentage.
3. Depletion of the test budget.
4. Specific level to be attained by the code coverage, functionality coverage and requirements coverage.
5. Reduction in the number of bugs below a certain level.
6. The end of the testing period of alpha and beta testing.

IMPORTANCE OF ENTRY & EXIT CRITERION
- Entry and exit criteria hold a great importance in the whole testing process.
- Without any entry or exit criteria you will not know when to start or end the testing or when the testing is complete.
- Entry and exit criteria save much of our efforts.
- Apart from this, the entry and exit criteria also increase the knowledge of the tester about the application.
- With the help of these criteria you can quickly move up to the different phases of the test cycle without unnecessarily wasting your time and efforts on one thing.

Why is documentation so important for software testing?

IMPORTANCE OF DOCUMENTATION

- Software documentation like other kinds of documentation is just a piece of plane text.
- Though just being plain text, its importance in the field cannot be neglected.
- You must have observed that whenever you purchase some software or application it comes with a documentation which contains user’s manual also.
- It is obvious that you must be using this user’s manual to understand and use the software better.
- The manual might have always helped you in diagnosis of your system whenever it might have had a break down, crash or hang.
- Documentation is a great help as it helps us in operating the software system or application.
- Documentation helps different people in different ways.
- Documentation has a very important role to play in the field of software engineering.

TYPES OF DOCUMENTATION

1.Requirements Documentation
- This documentation states all the requirements of a software system or application be it functional requirements or non functional requirements.
- Apart from the requirements it also states the features, functionalities, capabilities, attributes and characteristics of a software system or application. - This type of documentation serves as a foundation for the other documentations.

2. Technical Documentation
- This documentation contains the written code of the program and algorithm implemented.
- It also provides knowledge about the user interface of the software system or application.
- It also gives information about the APIs.

3. Marketing Documentation
- This documentation gives tip and information for marketing the software product.

4. Architectural Documentation
- This documentation is all about the internal structure of the software system or application.
- It explains how a particular software system or application is related to the environment and on what principles the construction of the program is based.

5. End user Documentation or User’s Manual
- This document is popularly known as user’s manual.
- It contains all type of knowledge that a user might need to operate the software system or for trouble shooting.

SOME FACTS ABOUT DOCUMENTATION
- Documentation introduces the software system or application to the user.
- It contains details about the software.
- Documentation can be thought of as a verified and validated agreement between the product developer and the buyer i.e., client.
- Documentation is modular in nature.
- It serves as road map for the user.
- It is said that if something is not present in the writing, it actually never happened.
- Documentation serves as a proof.
- If you don’t make a write up about the software, the client or the users will think that you are just making up the facts and if the things are there, they might have been done by some body else.
- You need to document every aspect of your software so that if later any dispute arises, none will be able to testify your work and decisions.
- Information contained in the documentation is very crucial and important.
- The software engineering industry is so documentation intensive.

Let us say that you have a program that got some problem like it crashed or hanged and the person in charge of the software is not available. Neither you know the structure and design of the program nor do you have any idea of how to mend the fault in the program. So what you will do in such a case?

Here documentation comes to your rescue.
- You have all the necessary details and tips on how to fix a fault and also the design of the program.
- It is important that the proper documentation is made available to each and every personnel of the software development team.

The Risk Mitigation, Monitoring and Management (RMMM) Plan

The Risk Mitigation, Monitoring and Management, RMMM, plan documents all work performed as part of risk analysis and is used by the project manager as part of overall project plan.
The goal of the risk mitigation, monitoring and management plan is to identify as
many potential risks as possible.It is the organization’s responsibility to perform risk mitigation, monitoring, and management in order to produce a quality product.
Every phase of this plan is of equal importance. More focus is maintained in the initial phases i.e. the identification and assessment of possible risks.
Once RMMM has been documented and project has begun, risk mitigation and monitoring steps commence.
Once RMMM has been documented and the project has begun, risk mitigation and monitoring steps commence.
The measurement of effectiveness of these mitigation / contingency plans should be well carried. It must ensure that after the execution of such plans the risk exposure is reduced or preferably eliminated.

- Risk Mitigation covers efforts taken to reduce either the probability or consequences of a threat.
- Risk monitoring and control is the process of identifying, analyzing, and planning for newly discovered risks and managing identified risks.
- Risk management is the identification, assessment, and prioritization of risks.

What comprises Test Ware Development : Test Strategy

Test ware development is the key role of the testing team. Test ware comprises of:

Test Strategy

Before starting any testing activities, the team lead will have to think a lot and arrive at a strategy. This will describe the approach, which is to be adopted for carrying out test activities including the planning activities. This is a formal document and the very first document regarding the testing area and is prepared at a very early stage in software development life cycle. This document must provide generic test approach as well as specific details regarding the project.

The following areas are addressed in the test strategy document:
- Test Levels: The test strategy must talk about what are the test levels that will be carried out for that particular project. Unit, Integration and system testing will be carried out in all projects. But many times, integration and system testing may be combined.

- Roles and Responsibilities: The roles and responsibilities of test leader, individual testers, project manager are to be clearly defined at a project level. the review and approval mechanism must be stated here for test plans and other test documents. Also, we have to state who reviews the test cases, test records and who approved them.The documents may go through a series of reviews or multiple approvals and all these are mentioned in this section.

- Testing tools: Any testing tools which are to be used in different test levels must be clearly identified. This includes justifications for the tools being used in that particular level also.

- Risks and Mitigation: Any risks that will affect the testing process must be listed along with the mitigation. By documenting the risks in this document, we can anticipate the occurrence of it well ahead of time and then we can proactively prevent it from occurring. Sample risks are dependency of completion of coding, which is done by sub-contractors, capability of testing tools etc.

- Regression Test Approach: When a particular problem is identified, the programs will be debugged and the fix will be done to the program. To make sure that the fix works, the program will be tested again for that criteria. Regression test will make sure that one fix does not create some other problems in that program or in any other interface. So, a set of related test cases may have to be repeated again, to make sure that nothing else is affected by a particular fix. how this is going to be carried out is elaborated in this section.

Different Testing activities in Design phase

The design document aids in programming, communication, and error analysis and test data generation. The requirements statement and the design document should together give the problem and the organization of the solution i.e.what the program will do and how it will be done.
The design document should contain:
- Principal data structures.
- Functions, algorithms, heuristics or special techniques used for processing.
- The program organization, how it will be modularized and categorized into external and internal interfaces.
- Any additional information.

The testing activities should consist of:
- Analysis of design to check its completeness and consistency
The total process should be analysed to determine that no steps or special cases have been overlooked. Internal interfaces, I/O handling and data structures should specially be checked for inconsistencies.

- Analysis of design to check whether it satisfies the requirements
Check whether both requirements and design documents contain the same form, format, units used for input and output and also that all the functions listed in the requirement document have been included in the design document. Selected test data which is generated during the requirement analysis phase should be manually simulated to determine whether the design will yield the expected values.

- Generation of test data based on the design
The tests generated should cover the structure as well as the internal functions of the design like the data structures, algorithm, functions, heuristics and general program structure etc. Standard extreme and special values should be included and expected output should be recorded in the test data.

- Re-examination and refinement of the test data set generated at the requirements analysis phase.

The first two steps should also be performed by some colleague and not only by the designer or developer.

What's the role of documentation in QA?

Sometimes, for people who are new to the software line (and specifically new to the testing business), there are questions about how important documentation would be to regular Quality work. After all, the major work is about testing some software and getting the bugs resolved, how important could testing be ? Well, the role of documentation in enabling the success of QA activities is critical. Note that documentation can be in electronic form as well, no necessity that it should be only paper, and in fact, recent trends are more towards having electronic forms that can be placed in source control areas in their specific directory locations.
QA practices should be documented such that they are repeatable, and are not dependent on individual people. Software artifacts and processes such as requirement and design specifications, design documents such as architecture, HLD, LLD, business rules, inspection reports, configuration control design and operational documents, code changes, software test plans, test cases, bug reports and decision making on important bugs, user manuals, etc. should all be documented such that these can be referred later (and prove very useful in case the project personnel are changed or should be transitioned to other teams).
As a part of documentation, there needs to be a system for easily finding and obtaining documents and determining what documentation will have a particular piece of information. Change management for documentation should be used in all cases, else you will find later that it is hard to figure out why something changed and what were the reasons behind it.
One of the most common reasons for failures or overruns / delays in a complex software project is to have poorly documented requirements specifications. Requirement specifications are the details describing an application's externally-perceived functionality and properties. The condition for requirements should be clear, complete, reasonably detailed, cohesive, attainable, and testable. A non-testable requirement would be, for example, 'user-friendly' (too subjective). A testable requirement would be something like 'user needs to enter their date of birth while creating their profile'. Determining and organizing requirements details in a useful and efficient way can be a difficult effort; different methods are available depending on the particular project.
Care should be taken to involve ALL of a project's significant 'customers' and important stakeholders in the requirements process. 'Customers' could be in-house personnel or out, and could include end-users, customer acceptance testers, customer contract officers, customer management, future software maintenance engineers, salespeople, etc. Anyone who could later derail the project if their expectations aren't met should be included if possible. This also helps in ensuring that changes later are minimized (can never be eliminated).
Organizations vary considerably in their handling of requirements specifications. Ideally, the requirements are spelled out in a document with statements such as 'The product shall.....'. 'Design' specifications should not be confused with 'requirements'; design specifications should be traceable back to the requirements.
In some organizations requirements may end up in high level project plans, functional specification documents, in design documents, or in other documents at various levels of detail. No matter what they are called, some type of documentation with detailed requirements will be needed by testers in order to properly plan and execute tests. Without such documentation, there will be no clear-cut way to determine if a software application is performing correctly.
Test plans need to be documented properly with good change control, since a test plan forms the basis of determining the areas of testing, scope, responsibilities, etc. A test plan forms the first level of generation of confidence in the test strategy for the project.

Details (sub-parts) of a test plan !!

A software test plan is a document that is critical to any software project. This is the document that is the proper reference to the process that QE follows during the testing process. Having a software test plan is a critical requirement of quality processes, and the document by itself takes some time to prepare (given the importance of the document for the overall process). So let us talk in some more detail of what a test plan should be like:
The software project test plan document describes properties of the testing effort such as the objectives, scope, approach, and focus. One advantage of the process of preparing a test plan is that it provides a useful way to think through the efforts needed to validate the acceptability of a software product, and the consequence of this effort is that such a completed document helps people outside the test group understand the 'why' and 'how' of product validation. One major need for such a document is that it should be thorough enough to be useful, and succinct enough at the same time so that no one outside the test group will read it. The following are some of the items that might be included in a test plan, depending on the particular project:
• Title
• Identification of software including version/release numbers: Which is the software for which this document captures the test process
• Revision history of document including authors, dates, approvals: A document could go through many versions, so this field captures the current version number
• Table of Contents: Very useful, and needed for most documents
• Purpose of document, intended audience
• Objective of testing effort: What should be the goal of the testing effort
• Software product overview
• Relevant related document list, such as requirements, design documents, other test plans, etc.: A test plan by itself is not complete, since a project has different areas covered by different documents
• Relevant standards or legal requirements
• Traceability requirements: Traceability determines how the various requirements are mapped to the different test plans
• Relevant naming conventions and identifier conventions: Very useful for people not involved in the preparation of this test plan
• Overall software project organization and personnel/contact-info/responsibilties: Such a section provides contact details of the key people in the group
• Test organization and personnel/contact-info/responsibilities: The same as above, but covers people in the testing organization
• Assumptions and dependencies: Assumptions can make a lot of difference to the success and failure of a project (and its test plan) and need to be carefully validated
• Project risk analysis: Risk analysis provides a good list of items that could cause risk to the project
• Testing priorities and focus: Any testing process has certain areas of focus (high risk areas, high impact areas, high change areas), and these need to be highlighted
• Scope and limitations of testing: There are some parts of the testing that may not be able to be covered, and this section attempts to cover this part
• Test outline - a breakdown of the test approach by test type, feature, functionality, process, system, module, etc. as applicable
• Data structures - Outline of data input, equivalence classes, boundary value analysis, error classes
• Details of the Test environment - hardware, operating systems, other required software, data configurations, interfaces to other systems; all these items should be detailed so that anybody picking up the test plan will have enough information
• Test environment validity analysis - differences between the test and production systems and their impact on test validity.
• Test environment setup and configuration issues
• Software migration processes
• Software CM processes: CM stands for Configuration Management
• Test data setup requirements
• Database setup requirements: If the software requires a database, then these instructions will be needed
• Outline of system-logging/error-logging/other capabilities, and tools such as screen capture software, that will be used to help describe and report bugs
• Discussion of any specialized software or hardware tools that will be used by testers to help track the cause or source of bugs
• Test automation - justification and overview
• Test tools to be used, including versions, patches, etc.
• Test script/test code maintenance processes and version control
• Problem tracking and resolution - tools and processes
• Project test metrics to be used
• Reporting requirements and testing deliverables
• Software entrance and exit criteria
• Initial sanity testing period and criteria
• Test suspension and restart criteria
• Personnel allocation
• Personnel pre-training needs: For some cases, people doing the testing may need some special training
• Test site/location: Where will the testing be done. For some specialized equipment, the testing would need to be done at the location where the equipment is based.
• Outside test organizations to be utilized and their purpose, responsibilties, deliverables, contact persons, and coordination issues
• Relevant proprietary, classified, security, and licensing issues - These are very important from a legal point of view
• Open issues
• Appendix - glossary, acronyms, etc.
All of these sections, when completed, will provide a test plan that should be the single document that will guide the testing process

Resources for usability testing

Previous articles covered some details about usability testing. I hope by now I have been able to cover some details of what usability testing is, why it is important, and some tips / issues that one needs to cover. However, there is always more that you can explore, read about, and hence you should have an idea of some of the secrets to having a good usability testing program.
Infodesign.com.au (link)
Accessibility forum (link)
Userfocus.co.uk (link)
Web Site Usability (link)
Web usability (link)
Usability.gov (link)
Doug Ward's website (link)
Usability testing (link)
deyalexander.com (link)
Column by Jakob Nielsen (link)