I mentioned last week that we face two major challenges in SharedBook QA. The second is testing an "open" application. Some parts of our application are based on data integration from third party sites in addition to our new open API.
When testing those parts, we are required to test unfamiliar and sometimes non-existent material. In our data integration projects, a variety of content will enter the SharedBook application that could cause miscellaneous conflicts and failures.
SharedBook's open API enables programmers from all over the Web to interface with our software, using almost any kind of programming language or environment. The development task here is to make sure SharedBook remains as tolerable, adjusted and "open" as possible. The QA task is to locate in advance all those places where the system fails to meet these requirements.
Simulating the real world in the lab is always hard, and when the real world is diversified and unpredictable it is twice as difficult. Our way of dealing with this, in the data integration projects, is to try and conduct as many integration tests as possible prior to launch. We try to test the application with many different potential content types, before we open the application to the public.
Nevertheless, as always, the best tests are done when a mass of users begin to use the system. As soon as “real” users start to encounter “real” problems, our main goal is to locate those problems and fix them as soon as we can, sometimes even before the users notice them.
I'll discuss the ways we do that in my next entry when I talk about our Tech Support.