With the new versions of all of our products coming out this month, the support department is adding some new hats to the stack that we wear. Testing is a vital part of the new product cycle. Our development team does a great job running the new software through its paces in the QA phase, but there is always another gate that the software has to get through before it makes it to customer computers. That gate is support team testing. In support team testing, we want to see what happens when the new software gets used in a more varied environment. What happens when you click run on a 10,000 line item VA01 run and then kick the network cable out of the wall? If you are downloading a query into Access from the MARA, MARC, MARD and MAKT tables with Winshuttle QUERY and have 2 different versions of Office installed on your PC, is it going to work? We want to push the limits and do the usual, just to see how solid the software is. We want to use different configurations of operating systems, MS Office and SAP system versions to make sure that there are no surprises.
We also use this as a chance to beat up the new features. When we decide to add a new feature, it has to have a use case. Why would anyone use this feature? Does it work with and hopefully complement the existing features? So we start with the use case and go from there. Where else can this feature be used and will it work in that way? If I use it outside of the use case, does it break something else? The goal is to find the limits and hidden benefits of each feature in the new products.
As we wrap up testing of these builds (and we test every single build), we want to know that we are sending out the very best product to our customers. As I always tell my team, if you can break it in testing, it will be harder to break when the customer gets it. This is good for everyone concerned.
Questions or comments about this article?
Tweet @wssupport to continue the conversation!