My daily work at Fuery Solutions involves finding ways to "break" MerusCase. Sounds crazy, I know. But, let me elaborate. In a nutshell, I write code that tests the application piece by piece. This, in very general terms, is what is known as unit testing. I help test the code that runs in the server as well as test the code that runs for the client that is responsible for the graphical user interface. Some testing and troubleshooting has to be done manually, as well. After verifying that all the parts of the application work as they are expected on their own, we also need to test how well they interact with one another; this is what is known as integration testing.

Why do we need to do all this testing? Well, to put it simply, so we can find and fix any bugs that may be present in the application before it reaches our customers. We want to make sure we're delivering a " fully baked" product; nothing else will do.

"fully baked" Photo courtesy of www.thecookbookchronicals.com

But testing and finding bugs in such a complex application as MerusCase isn't always so straightforward. Sure, sometimes it's pretty obvious; if you click on a button to display a list of items and you're faced with a blank screen instead, you can be absolutely sure that something is wrong. Some bugs, however, are subtle and hard to trace. Imagine, for instance, that you are getting the end result of a very complex mathematical operation. You are seeing a result, but is it the right result? How would you know except by doing the Math yourself? That is precisely why we need to test the application as thoroughly as we do!

Sometimes, however, we may miss something and a customer may report a problem. We are usually pretty good at fixing the bugs reported by customers right away, but I've also noticed that at times some of these reports are not really bugs, but come from an expectation of how the customer thinks the product should behave or a lack of understanding on how to use the tools provided by MerusCase. The latter can be easily solved with  a little bit of training, which we also provide, or by consulting some of the help articles.  In the case where the customer has expectations for behavior that is not yet present in the application, it is possible and absolutely encouraged to submit a feature request.

I think our customers are very fortunate that we do take feature requests seriously and try our best to implement them in a timely manner. Very few companies can offer that. In fact, the larger the company, the harder it becomes for the customers to get their voice heard or have a say on what goes inside the product.  Our customers literally shape the application. And with each request that we implement, more testing will be required, not only to make sure that it works as expected, but also to verify that no new bugs were introduced to other parts of the application. Yes, testing is a never ending process, but it's worth it.