My expert formally educated (in training, instructional design, eLearning, teaching, and curriculum development) software training teams are usually an additional extension to software development teams.
Why?
We note any functional software issues that could negatively affect end users perception of the change initiative
We search for technological or change management areas that could fail. A failure could cause employee job or behavioral performance problems during go-live software enterprise implementations. We stumble upon these issues notably during training assessments / design / and development.
Since we are hired to provide knowledge transfer to end users, we have spent a considerable amount of time with end users discovering how employees work on their jobs, what they do, and what they need. Therefore, we provide another line of defense for software developers when we function as their preliminary end user testers. Sometimes, we are even contracted to develop technology training WHILE the software team is still building the unfinished technology. This usually occurs because of program time constraints.
As testers, we conduct informed foreshadowing and provide evidence of failure, first, to the software development team (so that they have the chance to fix it) and then to program leadership (especially when external constraints causing the failure are not the software development team’s fault or if the failure is consistently not addressed). The purpose is to preventively reveal how the current technology performance and processes could fail later DURING go-Live, if the issue is not addressed. This is especially important for high-profile and high-risk businesses whose reputation is at stake during go-live.
Used As Fresh Eyes for Software Development Teams
Usually, software teams are working so hard to develop the software that they appreciate additional fresh eyes to help test software in a contextual manner (as it would actually be used by an end-user).
In the past during actual training for businesses, we noticed software errors or, by contrast, excellently developed software features during two specific occasions:
1) Before training commences (during the training design and development phases)
And
2) While we are training actual end users. If it occurs during live training with actual end users, we find errors and improvise (or even scramble) to create a quick workaround because of a software or hardware failure. This helps to keep end users who are averse to change (because of negative experiences with past changes) from complaining about leadership whom they believe are imposing onto them a(nother) change failure. In this moment, we in the training industry become liaisons between leadership and end users, although most of the time we aren't recognized for doing so. If we are really good at our jobs, we will improvise in such a manner that the end user barely realizes, remembers, or leaves with a negative system review that the failure occurred during the training time. It is significant, because many end users assume the live system will fail while they are doing their jobs if the system provided for training failed as well. This places high pressure on us -- adrenaline-rushing, sometimes potentially ulcer-causing pressure, so please don’t forget to appreciate the training industry's efforts.