Thursday, August 17, 2006

Is there anything left for us to write in Testing?

Hi Reader,

I have often stumbled upon Cem Kaner's Articles page and it is very recently that I realized, most of the articles have been written and published.

For every problem, you encounter in testing, people like James Bach, Cem Kaner, Jack Falk, Hung Nguyen, Bret Pettichord.....( I could have missed your name too, apologies for that), have written and published articles but "What are we writing nowadays?". For everything else, there is Jerry Weinberg .

I, being naive, did get disappointed but something struck me recently, with which, I now have confidence, to write or continue writing articles about testing.


_ Is there anything left for us to write in Testing? _

Myself being in India, luckily, gave me an opportunity to become optimistic on the scope left in writing articles in testing.

You might be interested to know as to what was one of them, which pulled the trgigger in me to become optimistic about writing and here it is for you.

I graduated, as an engineer, from one of the engineering schools in India and I was able to recollect that for every subject we had to study, we usually referred to two books, one a foreign author and the other an Indian. It is not that we wanted to show patriotism but just that for things that we could not grasp from the foreign author book there was a simpler version written by an Indian author, who understood the audience/students and put things in a layman fashion. Fortunately or unfortunately, they too are a part of the testing community and there should be articles tailored to their understanding levels.

I was able to recollect this concept and this did give rise to my optimism of continuing writing. Before you conclude anything, it is my responsibility to let you know that the above situation prevailing in India or might be in other countries is not because the foreign authors write it in a way that is too complicated for students here to understand but just that there are lot of factors that influences a student to refer to a particular book. One such is psychology, if a person has come across a book authored by some foreigner and due to his own naivety, was unable to grasp then he/she brands all foreign authors book as something written in Greek or Latin, despite the book being very simple to understand.

I also need to mention that the command over the language English is very important, to understand the simplicity of the written book/document.

Did I fail, by making you think that all Indian authors are the ones who abstract work from the ones who originally published the work ?

Not all, but some, yes. There are many genuine writers and I must appreciate their work in this context. Those who write the abstract versions of the original book mostly are the ones who write for commercial or fame, provided they do not give due credits to the original authors. ( As a tester, if I write such abstracted versions of original, I would be mentioning the limitation of my work in terms of the effectiveness in conveying the topic in detail or its usefulness)

It is time for me to make you think of "What can we write?" apart from one such I have mentioned in detail above -
  1. Extensions of research work of published articles.
  2. New experiments, its results, matching or defying with published articles.
  3. Testing, itself, is a game of perspectives, hence, each one's perspective.
  4. Applying the existing research to any non software field/domain.
  5. The problems that did not exist during the days the experts wrote articles and proposed solutions.
  6. Mistakes you have committed and the learning you have had from it.
  7. A new skill that a tester needs, which was not discussed earlier by any of the experts.
  8. Case studies of a project that you have been in, which you are authorized to write and publish.
  9. The kind of change you did to testing to suit new/different business needs.
  10. Things that have baffled you as a tester.
  11. Re-writing an article in native language, giving due credits to the original author.
  12. Lots more... The only limitation is your imagination - ( sorry, I do not know who quoted this)

_ End of _ Is there anything left for us to write in Testing? _

"What can be written, itself, has turned out to be a writing"

Thanks and Regards,

Pradeep Soundararajan

Tester Tested !

Note : In this post, I am representing those upcoming testers who are experimenting, trying to come out of naivety. Seniors excuse if it had not made sense to you.

Wednesday, August 02, 2006

Testing for Accessibility

This is an article from the August edition of the EuroSTAR Newsletter - STARTester, from Ruth Loebl. You can view the complete newsletter by clicking here and don't forget to subscribe to receive future issues.

Testing software for accessibility involves little more than imagination and common sense, but you have to pick the right standards, and then get to know some users.

Disability
• Lots of disabled people use computers, even people whom you might at first assume could not possibly use one.
• Many disabled people are not "disabled". My mother simply can't see as well as she used to, and has a bit of arthritis in her hands.
• Research commissioned by Microsoft indicated that in the United States, 60% (101.4 million) of adults from 18 to 64 years old "are likely or very likely to benefit from the use of accessible technology due to difficulties and impairments that may impact computer use.

"Even excluding people who are 65 or over, that's more than half the population – this isn't a niche market. So there ought to be a demand for accessible interfaces, although it's sometimes hard to detect. I'm encouraged by the improving legal situation" – check out the Code of Practice on the Disability Equality Duty in the Disability Discrimination Act 2005, example in para 3.46.

So how do all these disabled people use computers? For most, the answer is: in the same way that non-disabled people use computers, with a standard keyboard, mouse and screen.
As an example, one of the most important features of Windows is the ability to change the colour scheme and system fonts. While some of us just like a bit of variety in the colours we look at on the screen all day, for quite a few people choosing the right font and colour scheme is what enables them to read the screen at all. A few pre-set font and colour schemes are offered through the Accessibility Wizard (Programs, Accessories, Accessibility). More can be achieved through the Control Panel (Display, Appearance tab, Advanced button).

Accessibility testing should highlight when systems interfere with or disable these features that are provided through the operating system. It would be most annoying if your choice of colour scheme were ignored by a system that you have to use. All too often, oh dear, it is.

Access technology
Access technology is used where the effect of an impairment is such that an intermediary tool is needed to enable someone to use a computer.

• Partially sighted people who can't get by with an alternative font or colour scheme often use screen magnification software, which enlarges some or all of the screen contents, and provides other powerful features such as image smoothing and colour manipulation.
• People who have a reading impairment, poor literacy or dyslexia can use 'text-to-speech' software, where text highlighted with the mouse is spoken out loud. Sometimes, voice input is useful too.
• People who have a problem with their hands or arms will need adjustments or alternatives to the standard keyboard and mouse. This might simply be different hardware (a one-handed keyboard, a trackball, joystick or mouse pad) or a full speech recognition system.
• People who are blind use a standard keyboard but cannot operate a mouse. Speech output software conveys the contents of the screen, sometimes complemented by electronic braille output on hardware called a braille display. A full keyboard interface without reliance on the mouse is essential for effective access.
These access technologies are very powerful, but are often helpless when faced with really poorly designed software.

Software testing
As testers, you may want to know more about disability and access technology, and to meet some disabled people – I would certainly encourage this. For effective accessibility testing, it is important to involve as many different types of real users as possible, with different abilities, background, experience and so on. We often criticise software and web designers who don’t include people with disabilities in their testing processes.
Real user testing does demand a functional interface, but at this late stage it may be too late to change some aspects of the underlying design without compromising the viability of the whole software development project.

So as well as getting to know your users, we advocate the use of 'inclusive design' standards and guidelines at the earliest stages of interface design. The testable statements focus on the software itself, in isolation, independent of any particular user. They are intended to minimise barriers to both accessibility and usability, and to address many of the requirements of disabled users.

Standards and guidelines
Which standards and guidelines are most applicable for testing software? Three suggestions are below, and for our latest thinking on software and web accessibility, visit the RNIB technology site and follow the link to Software Accessibility. This information is due to be refreshed in early August.

ISO 9241-171 (formerly ISO/TS 16071)
The full title is "Ergonomics of human-system interaction – Guidance on software accessibility". It is in final draft, but as an internationally recognised standard written by professional standards-makers, we hope it will become a reference point alongside the guidelines and checklists that exist.
Within RNIB, we have adopted ISO 9241-171 as the basis for our software acceptance procedures, but it is actually too wide-ranging to implement in its entirety! For each software development project so far, we have had to extract a more workable subset of the full range of standards, tailored to the particular development and delivery platforms for that project.

IBM software accessibility checklist
The IBM Checklists are available for various technologies, including software in general as well as Web, Java and hardware. Each key point is explained clearly, and some information about implementation and testing is also given. They are much more usable and user-friendly than ISO, and free, but less comprehensive.

Section 508
Section 508 is US legislation to ensure that “electronic and information technologies” which Federal agencies develop, procure, maintain, or use, conform to standards designed to provide comparable access for people with and without disabilities. If you want to sell to Federal government in the US, these are the standards to apply. They don't include enough to make your system fully accessible, though.

Some messages to end with
• Accessibility is ultimately subjective, like usability. Effective testing depends on having a wide variety of users to test products in the later stages of the design process.
• Inclusive design is more objective, and applies to the software itself, independent of users. It can be tested from the earliest stages of a software design project.
• Inclusive design does not stifle creativity: good design for people with disabilities results in good design for all.

In my presentation at EuroSTAR 2006, you'll have the chance to see access technology in action, and some examples of accessibility standards and testing in the real world. See you there!


Biography
"Ruth Loebl has been with the Royal National Institute of the Blind (RNIB) for 13 years, working in the area of sight loss and technology."

Emotional Testing - Testing From the Heart of the Business

This is an article from the August edition of the EuroSTAR Newsletter - STARTester, from Ian Londesbrough. You can view the complete newsletter by clicking here and don't forget to subscribe to receive future issues.


In the last few years, testing and quality assurance have started to shake off the preconceptions of geekiness and started to carry more gravitas within organisations. Seemingly always the poor relation to development in the IS profession, testing is finally making it onto the agenda for board rooms, businesses and IS communities. But to claim that testing is "sexy" or "cutting edge" would be to overstate its appeal - if this is the case, how can the technology industry demonstrate its importance to the business decision makers?

Testing, like many other practices in the IT industry, has long been the preserve of logical, structured, “left brain” thinkers - the tech heads. In truth, many of the people who drive business are the creative forces, people who are more “right brain” in their thought processes. Therefore if testing is going to take up its rightful place in driving the development of projects that actually deliver the expected results, then something has to change – it has to be made more appealing to the creative forces within business.



Consider for a moment the difference between left brain and right brain thinking and the types of thought processes they engage in:

Left Brain
Logical
Sequential
Rational
Analytical
Objective
Looks at parts


Right Brain
Random
Intuitive
Holistic
Synthesizing
Subjective
Looks at wholes


There is no doubt that testing professionals need all the “left brain” attributes, but in addition to those, they need to move beyond the robotic, structured motions of traditional testing - both the left and the right side of the brain need to be utilised. This would enable testing professionals to start thinking about business from the more strategic and creative perspectives. It would also help them to gain a firmer foothold in the boardroom, allowing them to communicate the importance and criticality of testing to the right audience.

As we know, testing is required for a very diverse range of products and systems. For example, to test a console game which is designed to stimulate emotion requires both emotional and subjective decisions, as well as random and intuitive assessment of risk. These elements require a mental attitude different to that of the traditional testing professional.

The testing industry not only needs to adopt a “whole brain” approach when testing, it needs to utilise the right side in order to engage with the board and demonstrate the added value and business benefits of testing. Jargon such as “stakeholder buy-in”, “board level sponsorship”, “grass roots support”, is forever being bandied about, but how can the testing and technology industries really engage directors, business users, and staff and make a connection which delivers the value and benefit they expect?

To engage with any of their audiences, senior decision makers in particular, testing professionals need to have a firm understanding of the business requirements. The job of a professional tester is to fulfil the requirements of all stakeholders: from the client and their board through to partners and the tester’s own employer. By fulfilling the requirements, testing is not only seen in a favourable light, but it becomes a “must have” for any project.

In order to engage with their audiences effectively, professional testers need to be connected, from an emotional standpoint, to the business and understand on a cerebral level what the business is trying to achieve. When responding to situations the right side of the brain is the reactive, emotional side – think adrenaline rushes, increasing heart rates – the left side of the brain has a more considered, logical approach. Therefore testers can harness this cognitive process to ensure they immerse themselves in the business, the requirements and the risks and dangers it faces and then use their logical, analytical abilities to come up with testing and quality assurance strategies to meet the business’s requirements.

Traditionally, testers are not always vocal about their work and the positive benefits they are bringing to the business. Using this more emotional approach, throughout delivery of the project, testers need to constantly re-engage and maintain a positive relationship with their customers by communicating and demonstrating how testing has removed the risk from the project and produced success and profit.

The connection between an emotive approach and business and technology issues in a testing environment becomes clear when assessing the success that testing professionals achieve in delivering positive outcomes for the business. Testers who are trapped in the old school thought process of testing for testing’s sake and approaching it from a box-ticking, operational perspective, fail to engage effectively with the business and thus achieve a lesser degree of success. For example they may not understand the importance of capturing information that demonstrates the value testing is bringing to the business.

Using an emotive approach to testing will also enable professional testers to bring the discipline to life – using real life examples of projects that have failed due to shortfalls in the testing and quality assurance procedures will be much more effective than the traditional “death by powerpoint” approach.
If testers can engage the business and technology industry on an emotional level, about the added value and business benefits of testing, then testing will be able to move forward. Once the testing industry embraces the “whole brain” approach, they can assume a leadership role, guiding clients through projects safely eliminating the risk and enjoying much more success than you could possibly have from a traditional, logical and structured approach.

For all professional testers convinced of how critical their role is to the success or failure of IT projects, they need to engage the business at the ideas stage, drill down effectively to determine the requirements from the project and really get to the nub of what organisations and IS communities want. In doing this, disaster can be averted and businesses will start to realise the true benefits of successful projects.


Biography
Graduating from Warwick University in 1988, Ian started his career in IT as a Junior Programmer with Barclays Bank. Ian then moved to ICI, which became Zeneca and then Astra Zeneca. Ian has also worked for PA Consulting and prior to joining IS Integration he was the Testing & Release Manager for RWE Shared Services IS (serving npower and Thames Water).