Some best practices that contribute to improved software testing Part II

There is always a search for best practices going on. Some are well known and some hidden. Testing does not stand alone. It is intimately dependant on the development practices. These practices have come from many sources. These practices can be divided in three parts:
- Basic Practices
- Foundation Practices
- Incremental Practices

The foundational practices include:
- User Scenarios
User scenarios are developed to test the functionality of applications when multiple software products are integrated. User scenarios test the product in a way that it reflects customer usage. It also reduces complexity of writing test cases. This practice should capture methods of recording user scenarios and developing test cases based on them.

- Usability Testing
Usability testing not only tests how usable a product is but also provide feedback on methods to improve user experience. A good user experience is very necessary. The best practice for usability testing is that it should have knowledge in area of human computer interface.

- In-process ODC feedback loops
Orthogonal defect classification or ODC uses deect stream for precise measurability into product and process. The advantage of ODC is that it has the ability to close feedback loops which has proved to be cost effective and process improvement.

- Multi release ODC/Butterfly profiles
This technology or practice allows to make strategic decisions to optimize development costs, time and quality issues by recognizing customer trends, patterns and performance of the product.

- Test Planning Requirements
Requirements management and preparing test plans out of it is an important step to check whether they are meeting the customer needs or not. This practice is understood and executed with a holistic view.

- Automated test generation
There are many automated tools to generate test cases which help in software testing.this practice needs to understand which of the methods are successful and in what environments they are viable. A good amount of learning is needed to learn these tools.

Component Level Design - Designing Class based Components - Basic Design Principles

Component level design in object oriented approach focuses on elaboration of analysis classes and the definition and refinement of infrastructure classes.

BASIC DESIGN PRINCIPLES

There are four basic design principles that are adopted to component level design.
Open-Closed Principle
A component or module should be open for extension and closed for modification. It means that the component should be allowed to extend without the need to make any internal changes. Abstractions are created that serve as a buffer between functionality that is expected to be extended and the design class itself.

Liskov Substitution Principle(LSP)

This principle suggests that a component that uses a base class should continue to function properly if a class derived from the base class is passed to the component instead. When a derived class is created, it also conforms to the pre- and post- conditions.

Dependency Inversion Principle(DIP)

This principle depends on abstractions. It does not depend on concretions. The more a component depends on other concrete components, the more difficult it will be to extend.

Interface Segregation Principle(ISP)

This principle suggests that a specialized interface should be designed to serve each major category of clients. Operations relevant to that category of clients should be described in interface. If multiple clients require same operations, they should be specified in each of the specialized interfaces.

Release Reuse Equivalence Principle(REP)

This principle suggests that when classes and components are designed for reuse, an implicit contract is established between the developer and the people who are using it. Older versions of entity are maintained by the developer who establishes a release control system.

Common Closure Principle(CCP)

This principle suggests that classes should address the same functional or behavioral area when they are packaged as part of a design.

Common Reuse Principle(CRP)

This principle suggests that release number of the package changes when one or more classes with a package changes. All other classes or packages that rely on the package that has been changed must now update to the most recent release of the package and be tested to ensure that new release operates without incident.