Posts fromJanuary 2009

Data Validation Alongside Agile Development

I would like to discuss an issue one can likely experience with agile development processes and systems which data needs to be maintened during upgrades:

A customer care application for a PC retailer was developed so far and the software is running pretty well. Because warranty fraud is increasing, management decides to put in a check with the hardware supplier to check the validity of the serial number. But when checking the numbers against the webservice of the supplier almost all existing data gets rejected, because the serial numbers were not at all or incorrectlly entered so far. The supplier provides a validation algorithm which is added to the application. But after the next release of the software many employees complain about the system rejecting changes or updates of existing customer data. Also a third party financial system no longer is able to update the payment status.

This scenario describes that existing data is very likely to cause trouble when adding further validation rules. One could limit the data validation to the user interface, which would help the financial system, but still call center agents would no longer be able to update the invalid data.

Automatic data upgrade/conversion/fixing procedures are no promising candidates, because often the information is just missing and need to be obtained manually (e.g. from the customer).

Here some ideas to limit the effect of this problem:

  1. Before adding new rules, generate a list of existing data which will be affected and let them be fixed on beforehand
  2. Show rules for a given time only as warning, not as error
  3. Use additional information to limit validation rules to new data only
  4. When adding new data fields, think about at least a basic validation

Have you made similar experience? Do you have any better ideas to fight this issues? Or even a procedure to avoid them?

Fabian Lange

 

From a Mathematician’s Point of View – Career Changers

Nearly all of my colleagues at codecentric are either IT scientists or trained IT specialists. Despite the still severe shortage of skilled IT people in general, as a mathematician and career changer I remain an exception in our company. I am an exception at codecentric as a specialized tester, too. As is fitting for a performance-specialist like codecentric GmbH, my emphasis is on the exciting area of load and performance testing, a branch of non-functional testing.

For me it was fascinating to realize that actually quite a lot of career changers can be found in IT testing. This is true already for functional testing. Naturally there are a lot of the usual IT people and department personnel at functional testing, but you can already find quite a few exotic professions, too, e.g. jurists. At a training course for load and performance testing in early spring 2008 in Cologne, a real zoo of professions was gathered: Besides me – a mathematician – there were a specialist in German studies, an agricultural scientist and the lecturer was a meteorologist. All women, by the way, and many had a PhD.

In my eyes, IT testing is ideally suited for career changers. Certainly, specialized IT knowledge is desired and useful, but it is not necessary to have so deep and thorough a grasp of it as e.g. software developers. On the contrary, being sunk too deeply within the technologies can make one blind for other concerns. The main goal for any tester is to guarantee high quality. Now the adequate benchmark for high quality is not the blurred view of a software developer smitten with technology but the usefulness of the product for the user or the customer. To assess this usefulness, a certain distance to IT can be helpful. At least, one must be able to distance oneself mentally to look at and evaluate the product – the test object, as the tester says – from another point of view.

At this point the qualities of the career changer come into play. I am convinced that these qualities more than compensate for the higher need for trainings and the initially slightly lower productivity of a career changer. As non-IT-insider it is easier for him to view the application or IT system not as an end in itself but in light of the task it is designed to fulfill. The career changer can draw on his experiences from other roles in other sectors. Because of that, he not only has another point of view and can think along other and broader lines, but he may even be able to create an extra value for a project out of the synthesis of his experiences. These capabilities are especially valuable for load and performance testing, as for the conception of such tests requirements and information from very different areas have to be collected, analyzed and connected. In this process, the load tester has to deal with the concerned departments, IT development and IT infrastructure, but quite often with marketing, sales, management and even external service providers, too. Here the career changer with his broad and diverse background clearly has an advantage.

My studies of economathematics at the University of Augsburg were also a synthesis of different fields – mathematics, computer sciences and economics. And already in my first larger load testing project for an automobile insurance company I could make good use of exactly this same cross section of different fields. For my post graduate studies I went to the universities in Berkeley and Jena for further research in (combinatorial) game theory, optimization and operations research and the application of these sciences to real world problems.

This is the background on which I want to write about and examine different aspects and topics of IT within this column. I plan to evaluate current developments or simply pick up what I observe in the day-to-day business here at codecentric. One large focus will surely be on the area of load and performance testing. But above all, I want to write from the outside – from the point of view of a career changer and mathematician.

Dr. Raymond Georg Snatzke