If you don't have any experience of carrying out software testing, it can be quite a daunting task - especially if your diary is already pretty full.
To help you get the most out of this phase of your Implementation, here are some useful hints and tips.
Focus your time and energy where it needs to be
When you're planning your testing activities, remember which areas of the system need to be tested.
You don't need to test the system as a whole. Looking at the fundamental functionality of the system (e.g. the Pipeline View, Queries and Filters within the Core System) is not a good use of your time - these things don't need to be tested.
You need to test those aspects of the system which have been customised to your needs, or which you have customised yourself. These areas include, but are not limited to, your Recruitment Workflow settings, email notifications, integrations and exports.
You're not trying to break the system
Contrary to popular belief, Customer Testing (or User Acceptance Testing/UAT) is not about trying to break your system.
The whole point of the testing phase of your project is to ensure that anything which has been configured and made specific to your organisation and processes is fit for purpose.
Your tests should give you confidence that your implementation of Eploy does everything you want it to do, but also what you need it to do.
Not an opportunity to add new functionality
This one doesn't come up all that often, but it's always good to note.
When you carry out your Customer Testing, you'll be testing all of the features and functionality that you told us you wanted as part of your Scope and which were therefore included within the Services Order Form you signed at the beginning of your project. These were then refined and agreed upon during Phase 1 of your Project, with the final setup of your system confirmed in the Customer Readiness Requirements Sign-off document.
Testing is not to be used as an opportunity to add any new features to the system, or to fundamentally change how the system works.
We have had examples in the past where certain assumptions had been made (e.g. We thought Video Interviewing was included for free as it's in our Demo System? or We just assumed it'd automatically integrate with our HR system) and it's not until testing where these assumptions turned out to be incorrect.
Once you've reached the testing phase of your project it's too late to add these sorts of features in to your system and still hit your go-live deadlines. Of course, we'd be happy to discuss adding these features in, but in all likelihood the changes would have to be made after your system has gone live, and would almost certainly have to be dealt with using our Change Control process.
Plan, plan, plan
As mentioned above, the whole point of the Customer Testing phase of your implementation project is to test all aspects of the system which have been configured either for you or by you.
As a result it's vital that you spend adequate time planning for your testing, ensuring that you've captured a list of everything that you need to test, which you can then turn in to a series of testing scenarios and scripts which your testers will be able to follow - randomly clicking around the system to see what happens, or spending an hour putting 15 vacancies through the same Authorisation Workflow, is not a good use of your testers' time and doesn't really achieve anything.
Planning is so important that we get you thinking about it within Phase 2 - if you've attended our Customer Configuration webinars, you'll have heard your trainer talk about adding things to a scenario list as you make the changes.
To help you get started, within the Files tab in your Teamwork project, you'll find an example scenarios document. This lists all the most common testing scenarios we see, but it shouldn't be treated as an exhaustive list - you should add your own scenarios to the list as you're making changes during Phase 3.
Who needs to do the testing
Typically, the Customer Testing phase is carried out over three weeks.
During the first week you and your project team will carry out the majority of your testing, identifying and resolving as many issues as you can along the way. Anything that you can't fix, you'll feed back to Eploy at the end of Week 1.
During week 2, your Implementation Manager will review the feedback and resolve any issues.
Week 3 is the final week of testing and is your opportunity to confirm that the issues have been resolved.
Week 3 is also a fantastic opportunity to get people from outside your project team involved - after all, they'll be the ones using the Hiring Manager Portal and potentially any of them might become a Candidate, meaning they'll be using the Vacancy pages and Candidate Portal. By getting them involved at this stage you'll be able to get actual user feedback, which might result in some subtle changes being made prior to go-live, but it will also help you to start building some buzz and excitement within your organisation about your new system.