Brandon Holloway is a Quality Assurance Engineer at ThreeWill. He has over 10 years of QA experience in requirements gathering, risk analysis, project planning, project sizing, scheduling, testing, defect/bug tracking, management, and reporting.
Testing Out of The Box SharePoint Features
In the last couple years, I’ve done a decent amount of QA testing that either fully or partially involved SharePoint. One thing that is almost always utilized, regardless of the size of the project, is the use (at least to some degree) of out of the Box (OOTB) features. These are features that “come with” SharePoint, ready to use immediately without using custom code. When testing OOTB features, here are 3 things to consider:
While OOTB features are pretty reliable when used as originally intended, it is very common for some of them to be integrated with custom code which furthers their capabilities. It is important in these situations not to focus solely on testing the new code, but to test the full integration with the OOTB features. Also, what if the original OOTB features are not totally dependent on the new code, meaning not only can you use them for their newly expanded capabilities, but you can still use them as they were originally intended, as well? In this situation, you may think testing it as it was before would be a waste of time since without the new pieces, it is still OOTB functionality. This isn’t necessarily true. You never know what the new code could be touching in the back end, so some regression testing should be in order.
While it seems straightforward, usability can easily be overlooked. Sometimes customers will decide to go with an OOTB feature for something they need. This could be to save costs or because exactly what they need just happens to be there already. Regardless of the reason, the OOTB feature in question should always be tested for usability. Just because they want to use a particular “tried and true” feature that comes ready to use doesn’t mean that it will 100% fit their needs. You need some good, solid use cases (both positive and negative) in these situations. Many OOTB features have multiple possible configurations, whether we are talking about workflows, alerts, forms, or simple views. Do your due diligence and make sure that the customer will get all that they need with this feature and its “as-is” functionality and configurability.
3. You Never Know
OOTB functionality always works like it’s supposed to, right? Well, mostly. I have seen some funky things in some OOTB features that made me scratch my head a little. Maybe something is sort of misleading; maybe it’s counterintuitive. Googling such things almost always turns up something like, “that’s just how it works.” The point is, no matter how simple the OOTB functionality in question may seem, if it is a part of what the customer will be using on a regular basis, test it anyway. Will you find anything that hasn’t already been found and discussed a hundred times in QA and/or Dev forums across the internet and eventually deemed “acceptable”? Probably not… but running at least a handful of high-level test cases can’t hurt. You never know.
What Would You Add to This List?
Leave a comment below…