There is a term “Unit Test” in software development. That’s a special piece of test code, which checks that a particular part of the main code works as expected. A complex set of unit tests verifies behavior in Security, Data, Authorization, and many other domains.
Would we use such approach when it comes to IT? How do you judge the performance and state of your department or a function?
- Is particular IT request indeed takes X amount of time to implement?
- Is your Ops team indeed gets alarm when unauthorized device is attached to the network?
- Is your IT environment indeed follows the best practices? How would you know it?
- Is developing your Enterprise and IT architecture a smooth repetitive process that can run by itself?
- How efficient is the process of identifying new customer needs and provisioning them from IT side?
How do you “test” these things now? In my experience we often use our own subjective judgement instead of defining a set of repetitive, measurable procedures.
The approach that teaches to firstly define the desired behavior as part of the test procedure and only then implement the function that delivers this outcome is called Behavior Driven Development. What may sound a bit counter-intuitive, but is in fact an excellent way to keep focused on the main goal and cut the noise that does not contribute to the desired results.
As a result, when judging the outcome, instead of vague “I think it’s good” opinion you will get a SLA-like enforced delivery.
Alex Mavrin, CCIE #7846
Visit https://www.apteriks.com and use FREE ONLINE tools for network professionals.