The software testing ability of people with ASD

I've seen this news release a few times in various forms and it continues to impress me. This is the first time that I've noticed that big companies are using the services of Autistic software testers. A great achievement for the company, Soecialisterne, and the man behind it, Thorkill Sonne.

Microsoft and Computer Science Corporation are among a number of companies that are using the skills of people diagnosed with autism within their software testing processes. The companies found that people with Autistic Spectrum Disorders have a greater attention to detail than average, making them suitable for software testing.

Both companies hired staff and testing services from Specialisterne, a Danish consultant, which employs and trains people diagnosed with ASD, to provide software testing services.
Microsoft outsourced testing on its Windows Media Centre product and some of the testing of its business software to Specialisterne. IT consultants with ASD work on software testing tasks where other people would lose concentration. "This is not corporate social responsibility. We are using the service because it is comparable to other commercial testing services," said Microsoft.

CSC has hired staff with ASD to work on-site on projects including checking documentation and exploration testing. Peter Forsting, business manager at CSC, said, "{People diagnosed with ASD] have a photographic memory and notice things that we do not normally see."
In spite of having an aptitude towards working where focus and precision are beneficial skills, people diagnosed with the condition often struggle in a work environment, said Carol Evans, director of the National Autistic Society Scotland.

Thorkill Sonne, founder and chief executive officer of Specialisterne, said, "People with ASD are able to take in tasks most people hate."

He said the symptoms associated with autism, such as motivation, focus, persistence, attention to detail and a high learning ability, make them good candidates for work in software testing such as test verification, configuration management and function point counting.

Software testing FAQ - No. 25

Is there any evidence that convergence in the Telecoms sector had any impact on testing tools?

That question was sent in by Harbhajan Singh.

Well, that is an easy question to answer. The short answer is Yes. The longer answer is:

The convergence going on in the Telecoms sector that has led to triple-play (a marketing term for the provisioning of the two broadband services, high-speed Internet access and television, and one narrowband service, telephone, over a single broadband connection: Wikipedia) and quadruple-play (throw in wireless services as well) has already had an impact on testing tool. Incidentally, I wonder why the marketers chose triple and quadruple rather than the simpler three and four. No matter.

The tool I am thinking of is the Sunset(R) Modular Test Toolkit (MTT) from Sunrise Telecom, which for the first time lets technicians validate IPTV and VoIP over DSL service. Now if that is not converged triple play impact I am a monkey's uncle. Probably not the right metaphor, all things considered. But I think it provides the emphasis I wanted.

Software testing in the Telecoms sector

Continuous Integration an Load Performance Testing

Interesting post on Dr Dobbs about Continuous Integration and Performance Testing. Worth checking it out but here's a taster:

A continuous integration process requires (paraphrased from Fowler's paper):

• A single code repository. (I use Subversion, but you could use others like CVS, Perforce, and so on.)
• Automated build process with self-testing. (I use Apache Ant, you could use Maven.)
• Daily code commits.
• Continuous integration server that can build, integrate, and test the entire application quickly.
• Ability to test in a clone of production environment.
• Ability to broadcast overall build status.
• Ability to automatically deploy and broadcast availability of builds.

Continuous integration processes go beyond simply ensuring that the automating build compiles cleanly. To declare a build to be successful, it must pass basic functional tests. So we do need a somewhat mature development process, where teams all work from the same code repository, write a test case for the functionality they develop, build and test their functionality locally, refactor, and verify—only then committing their changes (frequently, at least daily) to the source code repository.

The continuous integration server includes functionality that detects that code has changed, checks out the code, and then builds and tests the entire application in a clean environment, eliminating the vagaries of individual developer's environments. If the build or tests fail, developers are notified immediately, when they are most able to easily and quickly fix the problem they introduced.

load and stress testing

Testing Peoplesoft

I found an interesting paper here about a tool for creating automated testing for Peoplesoft. The tool is called Newmerix Automate!Test™. It's principle benefits are saving time, not just in testing Peoplesoft but also in creating documentation, procedure narrative and policy language.

Even though BPD (Business Process Documentation) significantly reduces the development time, you still have to manually execute the test script which is time-consuming and labor-intensive. For instance, some years you may have six to seven tax updates that effect HR Management Systems (HRMS). The payroll process is lengthy – involving more than 80 tasks and input fields. A conservative estimate of the testing phase would require 10 users to spend two hours each testing the payroll process each time a tax update is implemented, resulting in 140 hours of testing annually. This estimate assumes that all users complete the process without a hitch. What happens, if just one user discovers a problem 10 minutes into the test? The PeopleSoft developer has to fix the problem and the user starts testing over again from square one, increasing the time it takes to rollout the update to production. Not to mention that application users are pulled away from their core job responsibilities each time a change is made to the application.
In addition to the long hours associated with manual testing, thoroughness is another concern. Do you know for certain, if end users are testing all permutations of payroll data? Most users focus on their areas of concern and test accordingly, leaving some sections unconfirmed upon rollout.
To guarantee best business practices, testing must be thorough while making the best use of resources and time. Automated testing is required to make this happen.