Useful checklists for GA day?

[SkyeHa]

Does anyone have a battery of tests that they run through on GA day (also known as "day of a thousand bugs") that they would be willing to share? Or do y'all just sit back and wait for the bug reports to roll in?

[DavidCo3]

I mainly just review the release notes and test (in the sandbox prior to GA) the new/changed features which I know that we will use. Whilst there have been quite a number of UI bugs introduced recently, I've not (yet) been smashed with them on the day of a GA so at this point don't do any system-wide testing at that point. Interested to hear what others do as this might be worthwhile.....

[DavidCo3]

I'm not sure if the GA has been applied today or not. We have had lots of users complaining this morning about new issues, but the main issue I was looking forward to being fixed hasn't been. How is everyone else going?

[SkyeHa]

it has been a quiet GA day for me. I only reported one new issue to the helpdesk--not sure if it is a bug or a feature, but the majority of my proof comments are not being listed on the updates tab of the document. We use proofHQ and you usually see all comments listed on the updates tab of the document prefaced by "PROOF COMMENT" and that currently isn't happening. Is it a bug? Is it a feature? Only time (and the helpdesk) will tell. In the past week (between 6/22 and 6/29) I have reported a bunch of issues, many seemingly revolving around performance issues (only happens in the afternoons), and documents not generating proofs. This week (Monday and Tuesday) I also had two new users tell me they were getting a login screen, which is pretty worrying because I didn't give them a /login URL, and we're on SSO.

[DavidCo3]

The update now seems to have been applied to our production system around 12pm today. Our main browser freezing issue now seems resolved at last, which is a good step forwards. We're still having several existing issues, plus some new ones: Pages don't remember the tab you were previously on Pages don't remember how many results you were viewing when reloaded Grouping collapse button at the top of a list doesn't work.

[DavidCo3]

Quick update on the above issues....these affected many, but not all users. For the affected users, we found that clearing their browser cache and cookies resolved it.

[DavidCo3]

Overall, we seem to be going much better now. This morning (9AM East Coast Australian time) was chaos as it seemed that the software had only been partially updated. Lots of complaints from users with all sorts of error messages. Around 12pm it seems like the rest of the update was loaded and things started to settle down. Not sure what the reason is behind this, but the timing of the update was really bad for us being both end-of-month and also end-of-financial-year in Australia. For any Workfront QA people reading this, can you please schedule updates for closer to the middle of the month in the future so that there is more time to resolve issues before month-end. Thanks

[tadams-1146613]

My Workfront champions know when GA dates are and field any changes and issues to quickly address and submit them for correction to WF. -- Scott Adams Work together. Work smarter. Workfront. Business System Analyst Lead Global Creative Studio | Starbucks Coffee Company | 2401 Utah Ave S, Ste. 800 |Seattle, WA 98134

[AmandaBa3]

Our GA days aren't just development releases. Most of our products offer managed services as well so we have to make sure we can provide the services being offered. Every product release must include a Service Design Package prior to launch and sign off on an Operational Readiness Checklist by all affected parties: Test/QA (who tests the Dev work), Product, Service Transition, and Service Operations. This way everyone has given their stamp of approval.

[ScottSa1]

We try and set the expectations ahead of time that there may be issues and then how to treat them. We also have a weekly change management meeting and any big release goes through the formal change process so that everyone is aware and depending on the release, high alert. We inform our help center as well as other support team members. In some cases we'll also release a list of known issues to let people know whats been discovered already but also to send the message that things won't be perfect. There will always be people that are unhappy and will complain no matter what, the question is do you want them to complain about not knowing also.....so managing those expectations are key. Hope that helps!

[katiegeorgeatl]

I try to build hype by sending out an email to (relevant) associates letting them know that a cool new feature is rolling out. I always make sure to explain that it could lead to functionality issues, but that once the kinks are ironed it, it will be an indispensable tool. (Unless it's not... Then I just cross my fingers and hope no one minds the update.)

[SkyeHa]

thanks everyone for your kind responses! I think what's going to work best for us is to use a combination of everyone else's good ideas. I'll be preparing a quick checklist of more subtle ways that our most commonly used features in Workfront could fail, and distributing it to our Workfront champions and power users. e.g. proofHQ checklist: doc-upload errors are pretty visible so I can leave this off the list. "Error generating proof" or "long proof generation times" are both errors that have happened in the past. As well, in our workflow they are something that would get missed until it gets to the reviewer, so maybe the person generating the proof could stick around for a few minutes and make sure that everything is going well. The people who frequently use the features should have always been the ones who warn me that there's unexpected behavior around the issue, but you would be surprised at how many times they think "oh, this is only my computer acting up" (we're not used to thinking in terms of cloud-based apps) or some variation of "someone upstream is failing to complete/approve their task" (instead of "someone cannot see their task").