Ownership and support for the test of PL/SQL Libraries

This is the second article on the method to test and is about “Ownership and support”.

During the installation of the library or just after, when you starts to use it, you need some support. Because when you are using the creation of another people, you need to understand the structure, the goals and the ways of creating the code. In one word to take ownership of the code.

The better code can be unusable without explanations. We will consider the different ways to offer support to users, on line with bugs trackers and forums and off line with the usual electronic documentation.

Ownership and support

Notation

• On line help :

  • 1 point for each communication channel

  • 1 more point if a question is answered in less than 5 working days

• Off line help : documentation

  • 0 if it is not available or does not bring nothing to the library

  • 1 point for existing in English

  • 1 point for free format (text, OpenOffice, PDF...)

  • 1 point if the main subject is detailed in more than 3 pages

  • 1 point for examples

  • 1 point for schema.

Features to evaluate

The choice has been done to evaluate the documentation in another category. The only exception will be the Quick Start guide, only noted here.

• On line help :

  • Forum help : to discuss with the others users and the development team about the problem you have

  • Bug Tracker : to register a bug you encountered

• Off line help :

  • Quick start guide : how to start with the library and use it as quick as possible.

This article is quite short and allows us to take a rest before the main piece of the methodology : the development feature that we will evaluate next week.

I am waiting for your opinions and feedback about that post.

Have a nice week-end and see you next week.

Introduction to the test methodology for PL/SQL libraries

Presentation of the articles series

Discussing about a methodology to test PL/SQL frameworks and libraries seems too long and technical to be done in one article. So I decided to split the article in seven parts (one by category to evaluate) to give you something more digest and let you give your feedback on a limited number of subjects. You will have a weekly “pill to take” and talk about the effects.

We start the series with this article.

Introduction

Testing PL/SQL frameworks and libraries demands a lot of work and a method is necessary to evaluate multiple tools with different features and different approach of the development.

As developers, we all have different sensibilities and each people has to find his own comfortable path to develop. With these tests, I just want to highlight the strengths and weaknesses of the tools to let you choose which one better fits your needs with a maximum of information.

That is why I publish the methodology and ask you to help me to build the most "objective" one.

Information on frameworks and libraries

In this article I define a library as a collection of functions and procedures on a specific topic and a framework like a collection of libraries. And of course, one of the greatest interests of a framework is the compatibility between its libraries.

I will use here the word of library to indicate a library or a framework.

To have an overview of each library, I will provide the following information on each one :

• Type (framework or library)

• Type of release (alpha, beta, production...)

• Version of the release

• Start date of the project

• Date of the last version

• Translations available

• Number of developers

• Web site

when they are known.

General principles of the notation

As it is difficult to compare numerous libraries that does have not the same features and documentation, I will note all the features or documentation present in each one.

The features and documentation will be group in categories.

The note for each feature or documentation will be summed to give a note to their category.

If a feature or documentation only exists in a library, only this one will be noted. Others libraries will have 0 for that feature or documentation.

It means that the notes of the categories are not limited, it is an open notation.

Moreover some extra points can be given in some conditions (if no DBA action required for example).

Anyway, a notation reference is detailed before the each evaluation of a category.

The main categories to evaluate

I have identified seven categories than should be evaluated :

1. Install/uninstall and upgrade

2. Ownership and support

3. Development features

4. Documentation

5. Interoperability

6. Code quality & architecture

7. Performances

Install/Uninstall and upgrade

Notation

Prerequisites :

• 0 point if several prerequisites

• 1 point if one prerequisite

• 2 points if no prerequisite

Scripts :

• 0 if it does not work (>15 min to use it) or it is not present or if the results are not reproducible

• 1 point for >10 min to use it

• 2 points for >5 min and <10>

• 3 points for <5>

Bonus :

• 1 more point if no DBA action is required.

• 1 more point if the number of objects created by library is less or equal to 10

Features to evaluate

• Installation or upgrade :

• Install script : from scratch

• Upgrade script : from a previous version of the library

• Example : a script or package is given as example to verify immediately that the library works correctly.

• Prerequisites : dedicated schema, administrator rights, others.

• Number of objects installed : Packages, tables, views, sequence...

• Uninstall :

  • Uninstall script : from the last version of the library

  • Cleaning of the installed objects.

This is the end of the first article of our serial. I am waiting for your feedback, ideas and contributions. It is up to you now !

And see you next week for the second article...