You may have heard of Crowdtesting, a practice that generates a lot of ‘buzz’ currently and that consists in having a community of testers outside the company testing an aplication in order to check its robustness.

With the previous post last week, I was thinking if the situation encountered on this occasion could justify using this technique.

An IT department that faces the strong growth of an online sales website, managing tens of thousands of daily visits and thousands of products from over 1 500 different suppliers. A portfolio of aging applications integrated with ERPs, and a large number of customizations to take into account the regulations of each country.

The pressure of time-to-market and the low priority given to the QA lead to bugs that even a single user can detect following a normal purchase. If any user can do so, any ‘Crowdtester’ could achieve good results very easily.

Would this not be an ideal case for incorporating ‘Crowdtesting in the QA strategy of this site? What would be the benefits?

• Costs: perform more tests at a lower cost. This IT department has clearly not a QA budget to match its mission. More with less.
• Flexibility: perform more tests in a shorter time. The use case we met – an exception to the default delivery process – probably requires one or more iterations of QA in a few hours, certainly within a week. Impossible with an internal team not large enough. Possible with crowdtesters. Sooner with less.
• Infrastructure: since this is a commercial online site, such tests can be conducted on a (private) image of the site, without requiring significant effort to manage the infrastructure of testing or mess with deployment of different releases. In addition, Crowdtesting is justified when tests need to be replicated on different configurations of browsers and of client machines (computers, tablets, phones, OS, …).
• Security. This application has little or no personal data. The only process a little bit delicate is the identification system of the user and the payment, but this can easily managed. Not as if we were speaking of the medical records of a patient or your bank accounts.
• Criticality and diversity. Crowdtesting does not really apply when it comes to test sophisticated and complex features that require advanced business knowledge. In the case of an online sales process, this does not apply. Instead, the large number of testers ensures a diversity of shopping behaviors that can only be beneficial.

I think it is a situation in which it is possible to imagine a synergy between:

• A small team of professionals in charge of verifying a correct implementation of the business requirements.
• Crowdtesting to optimize time-to-market, flexibility and costs.

The post last week was too long to share these thoughts, and I also wanted to move on to other subjects, especially around Sonar. But an article in ‘El Pais’ yesterday gave me the opportunity to think about something else: Crowdsourcing.

Crowdsourcing is a practice that emerged with the Web 2.0, which is to use the collective potential of Internet users to develop new applications. I was thus thinking if we could, as in our case above, mix internal developers and ‘CrowdDevelopers’.

The main argument against such an idea is that, again, we can not ask for outside developers to manage the functional complexity of an application. No? Really?

But is this not what happens when a company outsources its applications? This implies an effort to transfer this functional knowledge, which further justifies to avoid the outsourcing of applications functionally complex and critical.

And then there are already examples of ‘CrowdDev’ which prove that this model is feasible. The Open Source world has shown us that communities of developers could be built around a software product that they contribute to extend. You will generally find a small team, very expert, dedicated to the management of a core of Open-Source code around which the community of ‘CrowdSourcers’ will develop external components.

Another possible point: this model is not applicable outside the Open Source world, for business projects. And why not? Most current development projects are based on open source frameworks. And they are less and less technical but more and more functional ERPs. I also know clients open-sourcing some of their developments. For example, the IT department of an administrative region, in charge of all applications open to the public, which puts its developments available to other regions in order to share maintenance costs. An editor of an ERP of management of an university that requires a lot of adaptations from each university. These customizations are ‘open-sourced’ to enable each university to benefit from developments of other teams, and incorporated by the software editor to enrich the basic version.

One can imagine teams of Crowdsourcing and CrowdTesting, working in a world more and more virtualized with IT departments and business teams small and highly specialized that focus on quality.
In the example of this website, as we have seen that they plan to offer their site online in a SaaS platform, some features could be ‘crowdsourced’, as the localization of the site in different languages, the customizations of the differents shops based on products sold, or the personalization of the user interface and the usability on different hardwares (PC, tablet, etc.).

Contrary to what some do believe, I don’t think that professionals of QA or development are threatened by these market changes. As discussed above, a good architect or a good tester will always be necessary for a complex application, functionally sharp, or security risky .

However, I also think the time has gone when anyone could spend his entire professional life as an employee in one or more companies, but that it will be increasingly necessary in the future to create his own job. In this sense, Crowdsourcing and Crowdtesting will facilitate the use of outside expertise by IT departments.

So much the better. In my last job, I had four different bosses in five years, and I have not chosen them. My customers I did.