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.

Sometimes requirements change very quickly, what can be done in those cases?

There is an expectation that the requirements should be determined early and should remain stable. Some approaches can be followed if these expectations are reasonable:

- Understanding how the requirements might change early in the stage can be done by working with project stakeholders early.
- The application should allow some adaptability to the changes that can occur in the requirments later.
- The code should be well documented and wriiten and commented. It makes notification of changes much easier.
- Rapid prototyping can be used to minimize changes.
- Some extra time should be taken into consideration in the case of changes.
- The new requirements should be moved to different phase while the original requirements should be in the original phase.
- The requiremnts that can be implemented more easily should be incorporated in the project first keeping the difficult requirements for future versions.
- The management and customer should keep in mind the effects that the changes in the requirements can incorporate.
- Automated test scripts should be made flexible.
- Test cases should be designed to be flexible.
- Ad hoc testing should be in focus more instead of detailed test plans and test cases.
- Minimize regression testing methods.

If the application has the functionality that was not in the requirements and if the functionality is not necessary, then it should be removed because it can have some unknown impacts and dependencies in the application which were not taken into account
by designer or customer. The management should be aware of the added risks as a result of unexpected functionality.

What is Requirement Metrics? What is Requirement Profile Test?

Requirements measurement focuses on three areas: process, product and resources.
- Requirement size can be a good input for estimating software development effort.
- As software development progresses, the requirement size can be tracked down.
- As design and development occur, we would have a deeper understanding of the problem and solution.
- A large number of changes indicates some instability and uncertainty in our understanding of what the system should do or how it should behave.

Requirements can be used to determine if the requirements are ready to be turned over to them by designers and testers. Requirement Profile test is a technique employed to determine the readiness to turn over requirements to the designers or testers.
For Designers
- System Designer Rate 1: It means the designer understands the requirements completely.
- System Designer Rate 2: It means that there are aspects of the requirement that are new to designer, however, they are not radically different from requirements that he has defined.
- System Designer Rate 3: It means that there are aspects of the requirement that are very different from requirement that the designer has designed before, however he understands it and is confident that he can develop a good design.
- System Designer Rate 4: It means that there are parts of this requirement that he does not understand, not confident that he can develop a good design.
- System Designer Rate 5: It means that he does not understand the requirement at all and a design cannot be developed.

For Testers:
- System Tester Rate 1: It means that he understands the requirements completely and that he has tested similar requirements previously.
- System Tester Rate 2: It means that there are aspects of the requirement that are new to tester however, they are not radically different from requirements that he has tested before.
- System Tester Rate 3: It means that there are aspects of the requirement that are very different from requirement that the tester has tested before, however he understands it and is confident that he can test it.
- System Tester Rate 4: It means that there are parts of this requirement that he does not understand, not confident that he can devise a test to address this requirement.
- System Tester Rate 5: It means that he does not understand the requirement at all and he cannot develop a test to address it.

Categories of Heuristics of Software Testing

There is a set of characteristics that lead to a testable software.
- Operability: The better it works, more efficiently it can be tested.The system should have few bugs or no bugs that should block the execution of tests and the product should evolve in functional stages.

- Observability: What we see is what we test. It includes a distinct output should be generated for each input, the current and past system states and variables should be visible during testing, all factors affecting the output should be visible, incorrect output should be easily identified, source code should be easily accessible and internal errors should be automatically detected and reported.

- Controllability: The better we control the software, the more the testing process can be automated and optimized. Check that all outputs can be generated and code can be executed through some combination of input. Check that the software and hardware states can be controlled directly by the test engineer. Check that inputs and outputs formats are consistent and structured. Check that the test can be conveniently specified, automated and reproduced.

- Decomposability: By controlling the scope of testing, we can quickly isolate problems and perform effective and efficient testing. The software system should be built from independent modules which can be tested independently.

- Simplicity: The less there is to test, the more quickly we can test it. the points to consider in this regard are functional, structural and code simplicity.

- Stability: The fewer the changes, the fewer are the disruptions to testing. The changes to software should be infrequent, controlled and not invalidating existing tests. The software should be able to recover well from failures.

- Understandability: The more information we will have, the smarter we will test. The testers should be able to understand well the design, changes to the design and the dependencies between internal, external and shared components.

- Suitability: The more we know about the intended use of the software, the better we can organize our testing to find important bugs.

The above heuristics can be used by a software engineer to develop a software configuration which is convenient to test and verify.