APPLICATION QUALITY ASSURANCE CHECKLIST

Purpose: The Application Quality Assurance Checklist is intended to ensure “Custom-Built” applications
adhere to development practices that promote quality solutions. It is recommended that the project team
familiarize themselves with this checklist during the Design stage to ensure the developed application meets
the quality standards when reviewed in the Execute stage. This deliverable should be listed as a requirement
in the Transition Agreement.

Project Name Project # << DTC >>

Application Name Application #

Project Manager Delivery Manager

Date Completed << YYYY-MM-DD >>

IMPORTANT NOTES FOR COMPLETING THIS DOCUMENT

Each section of the Application Quality Assurance Checklist template must be completed in full. If a particular
section is not applicable to this project, then you must write Not Applicable and provide a reason.

Important Note: No sections are to be deleted from this document. This template is not to be modified in any
manner. Text contained within << >> provides information on how to complete that section and can be deleted
once the section has been completed.

1. Development Framework
Validation Questions Yes No NA Comments
1.1 Has the application been developed with the
most recent OCIO-sanctioned version of the
framework for the chosen technology?

2. Development IDE
Applications should be developed using an OCIO-sanctioned Integrated Development Environment (IDE). This
will allow Application Services resources to build and debug source code as needed.
Validation Questions Yes No NA Comments
2.1. Has the application been developed using an
Integrated Development Environment that was
approved by the OCIO?
3. Decoupling Business Logic From The Presentation Layer
Whenever possible, developers should avoid using business logic in the presentation layer. The presentation
layer should mainly be used for navigation throughout the application and presenting data to the user. For
example, the use of Java code directly within JSP pages (i.e. Scriptlets) should be avoided. The preferred
approach would be to use Tag Libraries (JSTL/EL).

Also, the Presentation Layer of Web applications should be developed using prevailing industry standards (e.g.
using Stylesheets to position and control presentation elements, using relative positioning instead of absolute
positioning, etc.).
Validation Questions Yes No NA Comments
3.1. Is the presentation layer of the application free
from business logic?
3.2. Has the presentation layer of the application
been developed in accordance with prevailing
industry standards?

4. Record Locking / Concurrent Users

Applications should be developed in such a way that users’ changes do not clash with each other or create the
potential for data loss/corruption.
Validation Questions Yes No NA Comments
4.1. Have precautions been taken to avoid data
clashes?

5. Passwords
A password helps authenticate a user when accessing a software application. Adherence to appropriate
password management will help maintain the confidentiality, integrity, availability of the data maintained by the
software application and reduce the risk of inappropriate access and use.
Validation Questions Yes No NA Comments
5.1. Does the system have functionality to allow the
user to revise their password and force user
account expiry?
5.2. Does the system support protected storage of
passwords with privileged user access? The
system should not support passwords in clear
text embedded either in the application code,
automated scripts, or the database?
5.3. Does the system meet the standard password
requirements?
5.4. Are the passwords in the production environment
different than those in a non-production
environment?
5.5. Are all vendor supplied default passwords
revised prior to placing the application in a
5. Passwords
A password helps authenticate a user when accessing a software application. Adherence to appropriate
password management will help maintain the confidentiality, integrity, availability of the data maintained by the
software application and reduce the risk of inappropriate access and use.
Validation Questions Yes No NA Comments
production environment?
5.6. Are passwords for privileged accounts different
than passwords for non-privileged accounts?

6. Logging and Auditing

Validation Questions Yes No NA Comments

6.1. Based on the application’s Information Security
Classification, does the application meet the
logging functional control requirements?
6.2. Based on the application’s Information Security
Classification, does the application meet the
auditing functional control requirements?

7. Modularized Code With No Duplication

As much as possible, code should be organized into small, separate modules to avoid code duplication and to
make future code changes easier to implement.
Validation Questions Yes No NA Comments
7.1. Is the application modularized?
7.2. Has code duplication been avoided?

8. Consistency of Code
Code sections with similar functionality should be written in a clear, predicable, and consistent way. Using
different approaches to achieve the same basic purposes should be avoided. Project teams consisting of
multiple developers should ensure that the developers follow the same coding style and naming conventions.
Validation Questions Yes No NA Comments
8.1. Is the code written in a consistent manner
throughout the application?
8.2. Have all developers followed the same coding
style and naming conventions?
8.3. Have all developers followed the coding best
practices as set out by the organization which
owns the technology?
9. Code Comments
Code sections should be well documented with comments. At a minimum, each section of code (code unit)
should have an introductory brief and accurate description to explain the code functionality. Any potentially
confusing / non-intuitive sections of code should be commented thoroughly.
Validation Questions Yes No NA Comments
9.1. Does all application code include sufficient
comments for support personnel?
9.2. Does each code unit have its own brief and
accurate description?

10. Error Handling – End User

Error messages presented to the end user should contain only that information which will allow the user to take
corrective action (e.g. “Invalid date, please reenter in YYYY-MM-DD format”). In the case of unhandled
exceptions, messages should be generic. Avoid displaying system information in error messages such as
server names, versions, and patch information, as well as application variables, paths, and other configuration
information. Avoid messages that could potentially lead to system exploitation (e.g. “Incorrect Login” is
acceptable while the message “Incorrect Password” is not).

Error handling logic should be robust enough to gracefully and meaningfully handle all errors which could be
reasonably expected to occur from user interactions with the system. The text for error messages should be
contained in a single location within the application code or database to facilitate quick additions and
modifications by support staff.
Validation Questions Yes No NA Comments
10.1. Does the application handle all the errors that
could reasonably be expected to occur?
10.2. Do the error messages contain minimal but
meaningful information?
10.3. Does the application avoid displaying system
information in error messages?
10.4. Are the error messages kept in a single
location?
11. Error Logging
Application errors should be logged for support personnel in database tables that will be directly accessible to
Application Services personnel. SQL can then be used to aid in searches for specific errors.

Log files for individual server tiers (i.e. Web and Application tiers) should be kept in a single directory on each
server. Also, log files should be saved on a daily basis with a time-date stamp on each file.

The error messages that are logged should contain information that is useful for support personnel (absolutely
no sensitive or personal data), such as which module of code encountered the error and what the specific error
was. Meaningful and detailed error messages are particularly important when troubleshooting
unknown/unexpected errors. These should definitely be captured and logged.

Logging is also required for applications as well as batch/scheduled jobs. Logging logic within applications
should be written in a modular way to facilitate the easy addition of new error messages.
Validation Questions Yes No NA Comments
11.1. Are all errors for the application being logged?
11.2. Is logging being done on each server tier?
11.3. Are the logs kept in a single location / directory /
database?
11.4. Are the logged errors specific enough to assist
support personnel in troubleshooting production
problems?
11.5. Is the code that logs the error messages written
in a modular way?
11.6. Are the log files free of personally sensitive or
identifiable information?

12. Field Validations

Where possible, validations should be performed on both the presentation layer and the business layer. In Java,
for example, validations may be done using JavaScript within JSP pages (presentation layer), but should also be
done within Java classes on the business layer. Also, validations should be performed in such a way that they
cannot be bypassed by end-users (e.g. by disabling JavaScript). Field lengths and types within an application
should be consistent with the column lengths and types declared within the underlying database tables.
Validation Questions Yes No NA Comments
12.1. Are fields being checked for the correct type
(e.g. date, integer, etc.) and the correct range of
values (e.g. 1 – 12 for month)?
12.2. Are field values being validated with regular
expressions where possible (e.g. validating email
addresses and dates for valid formats)?
12.3. Do the validations resulting in error messages
prevent data from being written to persistent
storage (databases, files, etc.)?
12.4. Are the validations being performed within the
business logic, as well as on the presentation
12. Field Validations
Where possible, validations should be performed on both the presentation layer and the business layer. In Java,
for example, validations may be done using JavaScript within JSP pages (presentation layer), but should also be
done within Java classes on the business layer. Also, validations should be performed in such a way that they
cannot be bypassed by end-users (e.g. by disabling JavaScript). Field lengths and types within an application
should be consistent with the column lengths and types declared within the underlying database tables.
Validation Questions Yes No NA Comments
layer?
12.5. Have the validations been written so that users
cannot bypass them?
12.6. Are all of the field lengths and types within the
application consistent with the column lengths
and types declared within the underlying
database tables?
12.7. Are user inputs being sanitized (without
exceptions) according to OWASP
recommendations?

13. Dates
When testing functionality that is built around date checks, the testers should use date values that occur in the
past, on the target date, and in the future. Dates should also be validated in the context of the established
business rules of the application (e.g. given a person’s birth date, is he/she eligible to vote?). When dates are
recorded in a database or log, they should include a timestamp and not just the month, day, and year.
Timestamps will not be required in specific situations (such as a birth date field) where a timestamp does not
make sense.
Validation Questions Yes No NA Comments
13.1. Does the application validate dates in a way
that is consistent with the system design
specifications and business rules?
13.2. Do all relevant dates include a timestamp?

14. Hard-Coded Values

Hard-coding of server names, database names, domain names, IP addresses, etc. within application code
should be avoided. These values should be contained in a single configuration file or database that is not part
of the application build, so that it can be easily maintained for different server environments (development,
testing/staging, and production) and will not need to be modified when new changes are built and deployed.

Fixed values that are repeatedly used throughout application code should be declared in a single location and
referenced appropriately, as needed, within the application. As a practical guide, a change to one of these
values should occur within a single reference point.
Validation Questions Yes No NA Comments
14.1. Does the application code avoid use of hard-
coded values?
14. Hard-Coded Values
Hard-coding of server names, database names, domain names, IP addresses, etc. within application code
should be avoided. These values should be contained in a single configuration file or database that is not part
of the application build, so that it can be easily maintained for different server environments (development,
testing/staging, and production) and will not need to be modified when new changes are built and deployed.

Fixed values that are repeatedly used throughout application code should be declared in a single location and
referenced appropriately, as needed, within the application. As a practical guide, a change to one of these
values should occur within a single reference point.
Validation Questions Yes No NA Comments
14.2. Do all hard-coded values reside exclusively
within configuration and constant, centralized
locations? (Central Locations that enable
changes without recompiling source code)

15. System Testing

System testing should consist of negative testing, as well as positive testing. During positive testing (“Testing
to Pass”), the testers will ensure that a program behaves as it should (in terms of navigation, processing,
reading and writing records, etc.). During negative testing (“Testing to Fail”), the testers will ensure that a
program does not behave in a way that it shouldn’t (e.g. allowing a past date to be entered into a future date
field).
Validation Questions Yes No Comments

15.1. Did the application pass all positive tests?

15.2. Did the application pass all negative tests?

15.3. Have client testers completed the formal test
plan in its entirety?
15.4. Did the application pass all tests included in the
formal test plan?
15.5. Have all positive / negative test cases and test
case results been documented?

16. Regression Testing

Regression Testing is any type of software testing that seeks to uncover new errors or regressions in existing
functionality after changes have been made to the software, such as functional enhancements, patches or
configuration changes. Regression testing ensures functionality that was working yesterday is still working
today. New functionality should be added to a system without impairing existing functionality or introducing
bugs.
Validation Questions Yes No NA Comments
16.1. As new capability is introduced, is the new
capability tested?
16.2. Have all previous tests been reconducted with
the results compared against expected results?
16. Regression Testing
Regression Testing is any type of software testing that seeks to uncover new errors or regressions in existing
functionality after changes have been made to the software, such as functional enhancements, patches or
configuration changes. Regression testing ensures functionality that was working yesterday is still working
today. New functionality should be added to a system without impairing existing functionality or introducing
bugs.
Validation Questions Yes No NA Comments
16.3. Is every capability of the software supported
with a test case and is the test case added to the
test case library to support final and future
system testing?
16.4. As bugs are detected and fixed, is the test that
exposed the bug recorded and regularly re-tested
after subsequent changes are applied to the
application?

17. Load Testing/Volume Testing

The load/volume testing that is performed on an application should be reflective of the demands that could
reasonably be expected to occur when the application goes into production. The testing should try to anticipate
future system growth, data growth, and an increase in the number of active users.
Validation Questions Yes No NA Comments
17.1. Has the application been tested with a large
number of concurrent users (i.e. a number of
users that is representative of peak system
usage)?
17.2. Has the application been tested with large
numbers of concurrent transactions (i.e. a
number of transactions that is representative of
peak system usage)?
17.3. Did the system perform well with a large
number of concurrent users?
17.4. Did the system perform well with a large
number of concurrent transactions?
17.5. Are end-users satisfied with the application’s
performance and responsiveness during
everyday use?

18. Certificates / Environment Software

Any certificates or special software that needs to be installed on a server stack for an application to function
(e.g. virus scanning software, SSL Certificates, etc.) should be documented in the Operations Procedure
Manual. Documentation should include the relevant expiration dates and the processes that must be followed
for renewal. Also, application deployments in production environments should not be comprised of any trial
versions of software. All proprietary and copyrighted software should be properly licensed for Government use.
 Validation Questions Yes No NA Comments
18.1. Has all proprietary and copyrighted software
been properly licensed for government use?
18.2. Have special software/certificate requirements
been documented?
18.3. Does the documentation provide expiration
dates and instructions for renewal?
18.4. Is the system / application free from trial
versions of software?

19. Business Requirements - Traceability

All of the business requirements that have been captured and agreed upon by the project stakeholders should
be fully met in the final version of the application that is transitioned over to Application Services. All required
system functionality should also be fully satisfied by this final version.
Validation Questions Yes No NA Comments
19.1. Have all of the business requirements been met
by the finished application?
19.2. Has all of the required functionality been met by
the finished application?

20. Source Code

Validation Questions Yes No NA Comments
20.1. Has the final approved version of the
Application Code been provided to Application
Services for use and maintenance during the
Transition Period?
20.2. Has a test build been completed by Application
Services using the code that has been handed
over?
20.3. Has a copy of the version of Open Source Code
used by the application been provided to
Application Services for retention? (Links are not
recommended)
20.4. Have the 3rd party developer code / plug-ins
(e.g. Axis2, Eclipse) been identified and provided
to Application Services for the continued
maintenance of the application? (Links to the
utility not satisfactory, 3rd party products need to
be provided)
21. Database Design

Industry best practices should be followed in the design of databases for production applications: tables
normalized, exceptions documented, constraints enforced, and required fields completed (nulls not permitted).
Also, if table keys are based on sequence numbers, each table should have its own sequence.
Validation Questions Yes No NA Comments

21.1. Have the database tables been normalized?

21.2. Keys based on sequence numbers have unique

sequences.
21.3. Are all keys and required fields set to ‘not null’
in all tables of the database?
21.4. Have triggers, stored procedures, sequences,
and constraints been properly utilized?

22. Transition To Support Personnel

The necessary server environments to support an application (development, test/staging, and production)
should be fully constructed prior to transition and should be entirely consistent with each other with respect to
Operating Systems, software versions, database versions, environment hardening, configuration, etc.

The Application Services resources supporting an application should be granted access to development,
test/staging, and production environments (as appropriate) prior to transition.
Validation Questions Yes No NA Comments
22.1. Have accounts been created on all servers for
the appropriate support personnel?
22.2. Have the necessary firewall rules been added
to allow Application Services support personnel
to access the relevant servers (i.e. via the Jump
Box)?
22.3. Have all server environments (development,
test/staging, and production) been fully created?
22.4. Are all of the server environments entirely
consistent with each other?

23. Checklist Exceptions

If the answer was ‘no’ for any of the checklist items above, please explain why in this section.
<< Please explain any exceptions using specific reference numbers from above. >>
PREPARED BY

PROJECT MANAGER
Print name Signature Date (YYYY-MM-DD)

REVIEWED BY

APPLICATION SERVICES
TEAM LEAD
Print name Signature Date (YYYY-MM-DD)