Documentation

At this moment, a real opposition is being formed to prevent ISO29119 becoming the standard for the test community. One of the main reasons is the excessive generation of documentation. All these documents are needed, required to set up your test process. That is what this standard proclaims. If you look at standard 29119-3, the following documents are determined

  • Organizational test documentation
    • Test Policy
    • Test Strategy
  • Test Management documentation
    • Test Plan
    • Test Completion Report
  • Dynamic Test documentation
    • Test Status Report
    • Test Design Specification
    • Test Case Specification
    • Test Procedure Specification
    • Test Data Requirements
    • Test Environment Requirements
    • Test Data Readiness Report
    • Test Environment Readiness Report
    • Test Execution Log
    • Incident Report

A lot of documentation for the sake of the standards. I call them test process documents.

As a tester you ask yourself, When am I allowed to execute my first test? Perhaps one document has serious importance for the tester, the “Test Execution Log” document. As a proponent of the Session Based Test approach, I call this document a session report. A session report is a document where you write down your observations during your test execution. And I must admit. I write a lot of them. But with a goal. To inform my stakeholders. They can read them, or not. But one thing I can tell, these are documents for the sake of your test execution.

I dare to say that all these ISO29119 documents are not relevant for your test execution. As a tester, start with test execution based on the information you have. This can be some requirements, test ideas or areas to test depicted in a mind map. You start to execute some tests and document your observations. With this new information, you can update your test scope and improve/adjust your test ideas. This type of documentation supports him to become a skillful tester, a craftsman. Test management can use the session reports to create their management reports. Let the tester do what he does best. Execute tests, working on the risk issues, so he can answer the most important question of every project. Can it be shipped?

Advertisements

3 Comments Add yours

  1. jlottosen says:

    I wonder if 29119-3 takes into consideration that many of these documents can be replaced by tools: Mindmaps for sure, tracking systems, sharepoints and even good old HPQC.

    I wonder if 29119-3 takes into consideration that logs can be of other forms than written: pictures, voice recordings – and even video evidence.

    It’s so 1999 to type-cast it all into (Dynamic) documents

  2. Radek says:

    Keep in mind that mentioned documents are part of predecessor of 29119 – IEEE 829. I don’t remeber many comments on that norm from the past. Those documents are OPTIONAL. None is mandatory

    @jlottosen
    There is no need to keep this document written. According to standard it can take any form.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s