I'm currently building a tool that my company intends to sell. I'm the sole developer on the project and it is being developed outside our normal code base and to a certain extent outside our normal process.

I'm trying to put together a checklist of items to check before I deem the software ready to release for testing.

These are the items that I've come up with so far:

  • Is code commented appropriately?
  • Does the code adhere to the defined Company Standards?
  • Is there error handling in place?
  • Is there appropriate security?
  • Is there appropriate logging?
  • Is localisation required?
  • Have release notes and any accompanying documentation been produced?
  • Has all testing and debugging code been removed?
  • Has sensitive data been such as passwords and licence keys been removed?
  • Has performance been checked? Any memory leaks?

Can anybody suggest items that could be added to this list and explain why you would think it would be useful? My goal is to have a template checklist that I can then customise on a project by project basis.

closed as too broad by user40980, Robert Harvey, World Engineer Apr 8 '14 at 19:15

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Does it do what it is supposed to? Are there any bugs? ;) – Oded Sep 19 '11 at 10:30

Maybe you want to consider this:

  • What security privs are required to install the software?

  • Is the installation drive independent?

  • Does the install process test for space availability?

  • Is the connection string to the database automatically built or statically coded and requires user change?

  • Does your code handle dialect specific data such as date correctly?

  • Would your security use MS Windows security? Did you test that?

  • What are the other software dependencies assumed at the target client machine (such as .NET Framework, ODBC, OLEDB, etc.) - Does your installation take care of this?

  • Does the install script have an un-install that safely removes the software?

  • If your software alters the registry during install, do you make a backup of the registry before altering it?

  • Does your software expect the certain ports to be open on the firewall so that it runs? Do you check for this?

  • If your software is browser based, do you tell the user about supported browsers?

  • If your software is windows based, do you tell the user about the windows resolution you see best (unless the application supports all resolutions)?

  • Sometimes, compliance with handicapped users may be required.

  • Do your user have means to contact you when things don't work as expected?

  • Do you have license agreement in place. Does the install process takes that in consideration

  • Have you checked all due copyrights?

  • Did you confirm that the licensing mechanism (generating userid/password) work?

  • Is there a generated change log?
  • Is everything checked into the VCS?
  • Have we added and successfully run tests for each bug discovered in the previous release?
  • Has anybody deployed it on a running system?
  • Has anybody used it to do something non-trivial?
  • Is there a working downgrade procedure?
  • Does the package update user editable files (such as configuration) gracefully?
  • +1 for encouraging tests for bugs from previous releases! – John Tobler Sep 19 '11 at 20:40

A few ones:

  • Do all the unit tests pass?
  • Has the software been tested on a preproduction environment / on all the supported OSes?
  • Has the software been tested by non-technical people? Any usability issues?

Not the answer you're looking for? Browse other questions tagged or ask your own question.