Open standards and the cloud

With every client I work for, I start to look for interesting subjects that client is involved with.
As a software testconsultant I had a lot of different clients the last six years, so you can imagine the diversity of areas I've seen.

For me one of the most interesting areas is the financial services area. Not because of the arithmetics (still not my cup of tea), but because of the innovative way these services try to adapt to the changing financial environment.
I started to see this in the beginning of internet banking and at the moment I see financial services woven into social networks like Hyves, web 2.0 as you may call it.

Very interesting for a tester, because these financial services and social networks will form an 'in silico' ecosystem (I'm still a biologist :-)), and like a living ecosystem very intricate and therefore very susceptible to errors.
To minimize this error-proneness (Open) Standards (like XBRL) were developed to make interoperability between the systems possible and to prevent also vendor-lockin.
But even standardization does not fully minimize the errors, because using standardization in design and development is still a human job, resulting in possible errors.
And what I've seen in online financial services, things can get very messy if an XML-tag of a webservice is not well tagged.

Standardization increases interoperability, but does not mean errors can't be made.

Cloud computing: a secure thing?

Financial services are very interested in cloud computing.
But one of their main worrries, as Phil Wainewright says in his blog is the risk of data being exposed to third parties in a multi-tenant environment.
Secure authentication by SSO or PKI is one way to avoid this.
But what happens when you have a man-in-the-browser-attack?
An MitB is a trojan, infecting a web browser and capable to modify pages, modify transaction content or insert additional transactions,invisible to both user and host application. Mechanisms such as SSL/PKI and/or Two/Three Factor Authentication are useless against it, because it works on transaction level, not authentication level!
Solution? Simple, think out of the browser, by using another channel to verify the transaction process: an automated telephone call.
So, now you have a “three-factor” defense against criminal activities exploiting your SaaS-application.
All three 'factors' have to be tested individually and also as an end-to-end-process/chain to minimize possible defects and risks.

Just a (simplified) scene in which a security tester can find himself while testing a SaaS-application for an online bank for example.

European e-identities

Writing a blog about your favorite testobjects has its advantages.
Roger Dean, executive Director of EEMA, read my blog about testing OpenID and invited me for the EEMA-congress eID interoperability near Brussels, Belgium.
There was only 1 catch , I had to give a presentation to the attendees about the risks of OpenID.
I said to mr. Dean: 'No worries Roger, I will come to Belgium and give you the presentation'.
And so I was in Belgium for 2 days, listening to experts on e-identity, learning a lot from them, and even holding a presentation myself about my favorite subject: testing e-identities.
The European Union wants to become more united, not only physical, but also digital.
This is a challenge: country-centric computersystems have to be interoperable with each other in a secure way. That's not easy, considering the differing European languages and legislations etc.
Perhaps, OpenID will play a big role in securing the digital connections in the European Union. As long as you minimize the risks involved!
EEMA, thank you for this opportunity!

Testing SaaS, all parties included?

This week I was at a meeting in The Hague where a SaaS-solution in e-government (GovUnited) was discussed by people from science, companies and the Dutch government.
The idea is to develop and maintain a standardized website for Dutch cities, which can be customized per city for its particular needs. The maintenance will be done from a central place in the Netherlands and the cooperating cities (the customers) will pay the service-provider GovUnited a yearly fee for development and maintenance of their website.
Next to this, GovUnited can act as a intermediate between the cities and other parties, like e-payment services (eg.Ogone) or other government services and facilitate the connection between both e-services.

This makes it for me as a testprofessional interesting, because with all these different parties involved, who is solely responsible for the quality of the SaaS-product?
If the website is running, but one of the links to another party (like Ogone) is malfunctioning, who is responisble for this, Ogone or GovUnited? Or perhaps even the party hired to develop the website?
Each party can develop and test their component of the SaaS-product, but who is responsible for testing the SaaS-product as a whole. This multisystem integration test must be considered in the development + maintenance and can't be just be planned and executed at the end of development because if things get wrong then (and most times it will) it gets nasty and dirty for all parties involved.

So, a careful planning of development and test should be made between all stakeholders to ensure the deadline can be made with possible risks taken care for.

Einstein 2.0 and BC, a SaaS vendor and its client

In an earlier blog I said I am going to illustrate model based testing of a SaaS-application.
I invented a company named Einstein 2.0 which develops ERP-SaaS applications for companies.
This blog-item will give more information about a client of Einstein 2.0: Beta Computing Inc. (BC).
BC is a global commercial enterprise specialized in selling computer hardware. Its main reason for choosing Einstein 2.0, BC wanted to outsource the development and maintenance of her ERP-software to a specialized company which also could develop it web-based, a disciplin not present in BC.
The agreement between Einstein 2.0 and BC is recorded in an SLA which describes agreements on different levels (eg. performance, payment, warranties etc.)between both parties. This SLA is very important for testing because it outlines the boundaries of the scope of the test.

As already said BC is globally present (Europe, Asia and USA).
Einstein 2.0 on the other hand is Dutch and based in The Netherlands.This is no problem, because Einstein 2.0 can develop and maintain it SaaS-product locally, but distribute it throughout the Web world wide. No local installation of 'ERP On Demand' is necessary.

This was just a short description of the fictional world of Einstein 2.0 and its client BC.
The next blog-entry will discuss one of the most important characteristics of 'ERP on Demand!', the way BC can access the software(security issue!) and to test this in a model based manner.