Some problems inherent in creating a software test plan - Part 1

Creating an effective software test plan & test cases is critical for the success of a software project. Sometimes, when teams are in a big hurry in terms of the time available for the project, there is a tendency to see whether some of this time can be compromised in terms of creating the test plans and test cases. Such compromises sometimes pay off (I will not say that teams get into trouble every time), but taking such short cuts means that you are indeed compromising on the quality of the end project, and dramatically increasing the risks that the project will run into serious problems.
So what are some of the problems that happen in creating a test plan:
- The test plan and test cases are not created by the people who have analysed the design. Typically, test plans and test cases should be created well in advance of the actual testing process; the test engineers should study the requirements and design, ensure that all their doubts are answered, and then start work on the testing documents. They should have access to the people who have created the requirements and the design documents, and be able to have a discussion where required. One big problem that occurs is when the test documents are prepared long after the requirements have been created (with the test engineers not being involved in the process). When such a situation happens, any doubts that the test engineers have in terms of the requirements or the design process are left unanswered and carry over to the actual test documents. If the discrepancy is minor, then such problems can go through to the actual product without much of an impact, but where this is a questions of requirements (consider cases such as weapons engineering, aerospace, financial, etc), such errors can be very significant, and yet not easily caught. End user testing does not really cover all the requirements of the users (especially in the case of complex requirements) and such errors can go all the way through to the actual finished product.

More details in part 2 ..

What are Construction Practices in Software Engineering Practice? - Part 2 : Testing Principles

In software engineering practice, construction practice includes coding and testing tasks and principles. Testing is a process of finding out an error. A good testing technique is one which gives the maximum probability of finding out an error. The main objective of testers is to design tests that uncover different classes of errors with minimum amount of effort and time.

Some testing principles include:
- From a customer point of view, severe defects are one that cause failure of the program so all the tests that are defined should meet the requirements of the customer.
- Planning of tests should be done long before testing begins. When the design model is made, test cases cab be defined at that very point. Tests can be planned before any code has been generated.
- Generally, individual components are tested first and then the focus is shifted to integrated components and finally the entire system.
- It is not possible to execute different combination of paths during testing. This means that exhaustive testing is not possible.

In a broader software design context, we begin "in the large" by focusing on software architecture and end "in the small" focusing on components. In testing, the focus is reversed.

What are Construction Practices in Software Engineering Practice? - Part 1

In software engineering practice, construction practice includes coding and testing tasks and principles. Coding involves direct creation of source code, automatic generation of source code and automatic generation of executable code using fourth generation programming languages.

CODING PRINCIPLES

Coding principles include preparation principles, coding principles, validation principles.
Preparation principles include:
- good understanding of the problem is necessary.
- good understanding of design principles and concepts.
- choose the right programming language and environment.
- unit tests that are applied once the component you code is completed.

Coding principles include:
- choose data structures.
- constrain algorithms.
- choose software architecture and interfaces.
- nested loops should be simple and easily testable.
- conditional logic should be simple.
- variable names should be meaningful.
- code should be self documenting.

Validation principles include:
- a code walk-through is conducted.
- unit tests are performed.
- code re-factoring is done.