discuss document export feedback print share

Testing and Documentation


  • Experiences must be delivered to the Museum at least six weeks in advance of when they launch in the gallery, exact timing will be agreed upon during the contract phase.
  • Digital experiences must be thoroughly tested on the same hardware that they will be running on in-gallery before delivery by the vendor. Refer to Hardware, Software, Web Infrastructure for more details.
  • Analytics capture also requires testing before final delivery to confirm that all events are being recorded accurately. Refer to Analytics for more details. 
  • We will aim to replicate the Digital Experience as closely as possible at AM also so we can test accurately and early. If this is not possible, we will discuss suitable alternatives to be able to test at scale. 
  • Auckland Museum’s digital experiences undergo user testing which the internal Visitor Market Research team lead. Most experiences include 1-2 testing sessions with visitors, after which a report is prepared informing improvements and updates to the user experience. This testing is worked into the timeline and allows all parties to produce the best possible experience for visitors. See Visitor Market Research Testing Process for details.
  • Throughout the project, the experience will be sent to AM to review and test. These review periods will be agreed on at the start of the project. The vendor must set clear expectations of what each delivery will and will not include. 
  • AM will set up a touchscreen for testing in our Digital Lab for updates to the experience post launch. Each new item or bug fix must be in its own version/release so that we can deploy each element individually once tested. Each item to be deployed must be requested by an AM ICT or DX staff member via a Request for Change form (RFC form) and the correct approvers must sign off before deployment. All deployments once the gallery is live must be done outside of Museum opening hours. 
  • Soak testing will occur for at least 1 week, whilst experiences are still under vendor warranty, any errors and changes will be reported promptly as required.
  • Any items discovered outside of the warranty period will be billable. Items discovered within the warranty period but not completed within the warranty period are covered within the contract. 



  • Full documentation for the experience is required to be handed over the Auckland Museum. Details of what this will include will be discussed with the project team and agreed on. This must outline how elements can be changed without needing to go back to the vendor. 
  • Raw video and source images must be delivered to AM and copyright and ownship of such files should be with AM unless an alternative arrangement has been agreed in the contract.
  • All final code will be placed into the  Museum’s Github repository. The source of truth should always be the AM Github repository. Any future updates or patches need to be updated in the Github repository also. Any deployment of code needs to involve AM ICT and AM DX for the best way to provision equipment.
  • All code created must be owned by the Museum. Full source code must be provided – this includes the ability to compile any experience be it online or in-gallery. As an example, a single binary export from Unreal Engine would not be sufficient,  instead all required code to build the binary including any licenses for any third party libraries or other assets included. Instructions must be provided for compiling any content.
  • Where a CMS is required, where possible we will leverage the Museum’s existing technology e.g. using our existing Kentico CMS if possible. If not possible, the CMS should be able to be hosted by the Museum directly.