One of the challenges facing software testers has been the availability of an agreed set of document standards and templates for testing. The IEEE 829 provides an internationally recognised set of standards for test planning documentation.

IEEE 829 2008, also known as the IEEE 829 Standard for Software Test Documentation, is an IEEE standard that specifies the form of a set of documents for use in eight defined stages of software testing, each stage potentially producing its own separate type of document.

We all know that Cloud Computing is one of the hot topics and lots of big companies adopted it already. Every week you can read an article on the internet or in one of the IT magazines. One year ago I started thinking on this subject after reading a number of articles on the activities of Google and IBM. The question that occur to me, can we introduce this also within the testing industry?

To understand the effect of Cloud computing on the delivery model in the testing industry, you need first to know what’s the IT or testing market currently asking and what can cloud computing offer. Let’s  first start with why already for a number of years companies see the importance of testing. The current keywords in the business are:

1. 1. Business is demanding earlier Time to Market (TTM).
2. 2. Traceability of the quality through the full process of software development.
3. 3. Complexity of the business chain.
4. 4. New non-functional requirements (compliancy, usability, performance etc.).
5. 5. More efficient ways to buy and deploy technology.

These drivers in the business are speeding up the process and make IT & end to end testing to become a standard utility of everyday business.

The term “Cloud computing” has grown too big to explain in a couple of keywords. In the next paragraph I will explain a little more on the term and background, service offerings, risks and trends for the near future. In the second paragraph I will continue on the impact and possibilities for the testing industry, embrace the use of Cloud computing in it’s full appearance.  

On January 28, we visited the Test Management Summit in London with a number of people from the our project. As our project is based in the UK we were able to combine these activities and visit a test gathering outside the Netherlands.

The summit is organized yearly by Paul Gerrard, the owner of Gerrard Consulting. Many of you will know Paul from the Eurostar event where he conveyed his extraordinary view on testing. The day consisted of four blocks of free-of-choice sessions. In between there was time for the attendees to expand their business network, and the day was closed by a central presentation. When the sessions started the Ricoh group separated to join different sessions.

The kickoff was centered on Pragmatic Testing in Agile Projects, a hot topic in testing at the moment. Agile, and scrum as its management approach, are popular choices in today’s projects. Stuart Reid lined out how cross functional sprint teams could ideally fulfill any role, which is a major challenge for testers in such projects.   

I'm not the biggest fan of IBM’s Rational Quality Manager (sorry IBM). To many people think that introducing a tool within their organisation will solve the Quality Management problem. Good Quality Management start with organizing your own organisation and process. If you are able to introduce simple, effective checks on the deliverables within you process, overall Quality Management will be improved and still be controlled with low cost.

For you all out there that have a new job or you want to know what you can achieve with RQM, check out the weblog of Mike Kelly .

1. Getting started with IBM Rational Quality Manager
2. Managing your first project with IBM Rational Quality Manager
3. Test planning using IBM Rational Quality Manager
4. Test analysis and reporting using IBM Rational Quality Manager
5. Lab Management using IBM Rational Test Lab Manager
6. Integrating IBM Rational Functional Tester and IBM Rational Performance Tester with IBM Rational Quality Manager

Today I found a real nice website about "Software failures in the wild"
Modern life and business runs on software. Sometimes software fails. Sometimes these failures are obvious catastrophic failures. Other times software fails in ways that aren't necessarily clear technical failures. Some of these failures frustrate, confuse, or otherwise discombobulate users. Sometimes people may disagree as to whether behavior is a failure. These are failures that leave us asking "Is there a problem here?"

The author has collected a number of examples of software failures in the and ceated a blog for sharing these software failures. The list will be updated regualar with new ones as they are discovered, with hope that software designers, developers, and testers can discuss and learn from them.

Have fun and the check this website