Anyone out there have a v14 upgrade Test Plan template they'd be willing to share? We implemented in v12 and upgraded to 12.5.1 out of necessity and are still scrambling to put together documentation let alone Test Cases. Any help greatly appreciated!
Hi Mindee,
We built out what I thought was a pretty comprehensive Testing Script for v14. When I reviewed it against the fairly bare-bones checklist that RAMP wants you to fill out I think the only thing they had that I didn't was ticket printing tests. That said, there is functionality in Tessitura that we don't use, and therefore I skipped. Also, if a functional area of Tessitura has not been changed (this is more true for point upgrades) then I like to pare out what I feel confident won't be affected.
We also have well over a decade's worth of customizations and a lot of TNEW customizations that are always a priority to test against new versions, so a fairly large part of the script involves those.
The script is broken out by department/position and I create several copies of the file for different individuals or groups who will be testing where I delete the checklists that aren't relevant to their job duties. For instance a Box Office Manager would have the Managers section, the Cashiers section and the Web section (almost everyone gets that), while a cashier would only get the Cashiers section and the Web section, and so on.
I also have lots of resources to help people figure out how to test effectively: reviewing the results for this upgrade I think I need a few more, but I'm getting close.
Cal Performances Tessitura Testing Scripts v14 (1).docx
--Gawain
This is incredibly useful, thanks for sharing Gawain!
This is amazing; thank you so much for sharing! Not quite 3 years in and we owe such a debt of gratitude to this user community for all of the help. My 5 year goal is to be able to help someone else a fraction as much as we've been.
Thanks!
Mindee Waltz (Past Member) said:Not quite 3 years in and we owe such a debt of gratitude to this user community for all of the help. My 5 year goal is to be able to help someone else a fraction as much as we've been.
Ten years in here, and I'm afraid the debt only seems to increase.
P.S. I think there may be a link in there to our Google Drive instance...should have deleted that.
This is wonderful. Thank you for sharing.
I'm going to add a little bit more to this.
The testing plan is basically a long check-list, but there are two really important things that we do on top of this to make testing more effective.
First, schedule group testing sessions. In the best case scenario, if you can put together a room with stations dedicated to group testing that's the best (our IT department has a bunch of loaner laptops that we can set up in one of our meeting rooms for this purpose), but if not then a screen-sharing meeting app (we use GTM) is the next best thing. Worst case scenario, try to get a two or three people who can sit at the same desk and go over things together.
Being able to test with other people means that you can compare notes and ask questions instantly, and if testing alone, the nuisance of having to email or call and wait means those issues often just get skipped over. It also forces people to actually test. If people are just given a list and told to test on their own time, they have full time jobs, and their actual work will always be the priority, and so no testing ever gets done. Ever. I don't remember who explained how important this was to effective testing (some TLCC), but they were 100% correct.
Second, the checklist is a good minimum testing requirement, but it is no substitution to user and customer behavior testing. When users (and especially less technical users) are just running through examples of how they would actually use Tessitura, or your website, they are going to do things that you would never anticipate putting on a testing plan, and easily 90% of issues have been identified under those circumstances (unfortunately, they are typically identified during that daily use, not in testing). One goal I have to add to the testing plan are a set of "scripts", where users go through a set of more vague instructions that mimic their daily work, but also challenge them a bit to creatively interpret the script.
One of the reasons I know how important this second part is comes from an old issue we had with our Test website. We have a non-dynamic informational site that then links to our TNEW site for purchases or donations. The links go back and forth, and a typical customer, especially one making a donation, will flip back and forth between them numerous times during a purchase. However, in Test, the links from TNEW->info and from info->TNEW were both copies of pages or content from the respective Live sites, and so you couldn't just click through a standard customer path without winding up in the Live site. So we just had a list of links to each functional area of TNEW so that you could go directly to each part. The result was that our website testing was always fraught with confusion and irritation, as people would find themselves on the Live site constantly, or not realize it an report errors because suddenly their cart seemed to have vanished, or they had been logged out, or whatever. But also you just couldn't act like a real customer, and so all sorts of problems would only come to light from customer feedback. When we finally prioritized getting those links to match up (no easy task, especially on the TNEW side), the quality of our testing improved dramatically.
Agreed. I'm a 'lifer' (17 years) in, and the debt never ends, but in a good way. (thanks for your test script that I've just downloaded, Gawain!)
Thank you so much for this, you are truly appreciated! It is a great tool to have.
This is awesome. Thanks for sharing.
Even a million years later, I stumbled across this, and it is going to save me so much time as I build out my v16 test plan for my depts!