Testing is an important concept and practice when it comes to technology, regardless of what industry you’re in. When it comes to Higher Education, it defines the collaboration between IT and the various functional teams with whom they work. The aim is to maintain the consistency and longevity of the technology tools used across an organization.

Kinza Yasar, Technical Writer at TechTarget.com, defines system testing as “the process in which a quality assurance (QA) team evaluates how the various components of an application interact together in the full, integrated system or application… [it] verifies that an application performs tasks as designed.”

In this blog, I will take you through my own personal experience gaining exposure to testing, relaying a couple of lessons that taught me how important User Acceptance Testing is to daily operations.

Getting Started

I started at Teachers College as a student employment manager in 2011. It was my first time learning about Ellucian Banner Financial Aid, which was our system of record. A few years later, I was placed in charge of the maintenance of this relational database from the functional side. It was then that I learned of our test instances – copies of the database duplicated for the very purpose of running tests.

Since that time, our test environments have only grown. The data is refreshed at various points in time so that end users can perform tests following changes to the system itself (i.e., new upgrades/releases) or due to internal policy/procedure updates.

Lesson #1

As the systems coordinator in our Office of Financial Aid, I am the go-to person for any in-house Banner Financial Aid questions. One day, someone asked the rather simple question, “How are you testing?”

I was doing a few of my day-to-day tasks in the test environments and, if everything looked normal, I would give it the green light. Turns out, that wasn’t the right approach. While I was leaning in the right direction, I was not doing everything needed to successfully complete the test. That was the first time I heard about a test plan.

User Acceptance Testing

System testing must be a comprehensive process. There are layers of testing that IT folks do to ensure the database is performing normally and handling data accurately. We, as end users, also have an important role here: User Acceptance Testing (UAT).

UAT requires a full test plan that tackles every role and task across the office to ensure all bases are covered. This is where I learned I couldn’t just test for my role(s) alone, but that every single role in the office needed to be tested!

With this in mind, we put our heads together to figure out and document all that we do day-to-day, week-to-week, month-to-month, and even year-to-year. We created a starting template of the pages/tasks that are managed by each person, removing any duplications, to ensure that everything that needs to get tested does.

Lesson #2

Just as we started improving our testing practices, we hit another pothole: staff turnover. (An all-too-real reality of our industry today!) While we listed all the tasks, we never listed the actual steps that comprise each task. Nor did we identify ownership of the tasks. This left us blind to what actually needed to be done and what to expect as the end result.

So, we went back to the drawing board on our test plan. It needed even more details! By adding these details, we created a plan that not only listed the Banner job to run, but also the parameters to use, and what output to expect. We consolidated all the information into JIRA, where it can be accessed by current and future team members. This enables me, and others in the office, to conduct proper testing even if someone is out or if a role is unfilled.

Evisions Argos Testing

While the major lessons I learned came from UAT for Banner Financial Aid, I am also responsible for UAT regarding Evisions Argos. Fortunately, I was able to take those lessons learned and apply them in a rather straightforward fashion:

1. Create a new, simple DataBlock and test it
2. Run an existing DataBlock to review results and ensure it is as expected
3. Create a new, simple report and test it
4. Run an existing report to review results and ensure it is as expected

I typically deactivate schedules during tests. Sometimes, though, I’ll a schedule test manually to my email to see if it works as expected.

Conclusion

Through this experience, I learned the importance of User Acceptance Testing. From understanding the need for a test plan to realizing the significance of detailing tasks and ownership, I gained first-hand knowledge of what it takes to successfully test the technology we use every day.

Maybe you’ve had similar experiences or learned these lessons in a completely different way. Regardless, I hope that my story can help you when it comes to testing and, with it, strengthen your relationship with your IT staff while maintaining the consistency and longevity of the technology you rely on to be successful.