Think back to the last technical project that you were involved with. Were there any surprises after the project finally rolled out? Right before going live, did a gut feeling tell you something may be amiss?
If the memory of a previous implementation is still clear, I’m probably preaching to the choir when I say that user testing is highly underrated. And that’s what this article is all about: a few guided user testing suggestions that you probably already know… and most of us have to re-learn from time to time.
Assuming you were diligent in gathering accurate requirements and the blessings of stake holders… assuming you have something that fulfills requirements working in your development environment… you even told the user about it and gave them access to take a look at the project before pushing it live… you are feeling the pressure to roll it to the live environment where it can finally be used for real.
Giving into the pressure would be a mistake though. You and I both know that no one but you and your team did any real testing. Why? Because you didn’t tell them to test and deep down, you know that they don’t know to do this on their own. Maybe a stake-holder briefly glanced at the project, but this really isn’t sufficient. If you roll it live now, end users will probably find bugs or features that don’t work exactly they way they envisioned. So where did you go wrong?
At the very beginning of the project, stake holders or end users should be made aware of the testing they will eventually have to do. Important information to communicate includes:
- Take testing seriously. Testing should be performed as if the application was already live. It should not be viewed as testing but rather a live trial… with a reset button. Make sure testers have this view. Did you ever hear a client say that they expected a live result that was different from the development version? There’s a reason why you’re the expert and they’re not. They need your guidance.
- Set deadlines. Let testers know what the deadlines are. Testing should last as long as it takes to eliminate critical bugs. Hold the testers to the deadlines.
- Feedback. Inform testers how to record and report feedback, reactions and findings about bugs or other items discovered during testing. For example, you can schedule meetings where you gather feedback and ask questions about this feedback in person. This will save you from having to collect disparate feedback willy-nilly from random emails and calls. It’s also helpful to share docs between you and the client where you can provide comment updates.
- Stabilize requirements. Don’t let your testers cause scope creep. They may request additional enhancements. But stay strong and stick to the immediate requirements. Let them know that additional enhancements can occur as a separate approved project after the successful completion of the current project.
- Access. Test/provide login and access credentials to all testers. Make sure they have access needed to do their job.
- Inclusion. Include all key stake-holders in communications/testing. The more a person knows about a project, the more accepting of it they will probably become.
- Responsibility. Hold testers accountable for testing. Provide guidance when necessary. In the end, you are responsible for the project, even though you are depending on the testers to do their job.
So you may have hit a few speed bumps before, or maybe you’re already perfect. Either way, it’s not too late to start or continue testing the right way. Anyway, the Human Element team is rooting for you. So good luck!
