Testing Procedures

We see it all the time here in the IT field…people floating around aimlessly during a maintenance doing nothing while others seem to be working harder than others. Why is this? For the most part I don’t believe we should be blaming them directly; rather, I think we need to blame management for not delegating responsibilities properly and efficiently…

I find that some people are forced to sit around aimlessly because they are stuck in the maintenance with nothing to do. This is due to lack of planning on the part of those in charge of delegating tasks so the said “lazy” person may not want to interfere with others and their duties but always winds up blamed for doing nothing. This is where you learn about ordinal test procedures.

Call it whatever you want actually because ordinal just means sequential and in most cases you want your ordinal list to be sorted by order of mission critical operations. For example, you don’t want something like a sandbox test environment that is rarely used and doesn’t make money at the top of the list over your production SaaS network that is customer facing. Prioritizing your ordinal lists ensures that you can isolate problems quickly and effectively.

This also comes down to providing enough time in a maintenance window to get things done. In the past I have worked for companies that gave 2 hour windows; however, that window wasn’t strictly for me to perform all my work it also included others to shut down their stuff. Thus, it would take 30 minutes to bring down and 15 minutes to come back up taking away 45 minutes of my 2 hour window. This leads to another aspect of testing, prototyping, piloting and lab networks. If you expect someone to build a config based purely on text and have no other means to verify their logic then you should expect it to fail and fail miserably. In the past I have dealt with such behavior and it wouldn’t click with some people that you NEED a lab of some sorts (either a subset or an entire prototype network that has similar services and systems running on it). If you want a successful maintenance I always recommend having spare equipment that has all the same basic core functions as your current infrastructure to test new ideas, new hardware and new configuration. “Winging” it is just setting yourself up for failure.