GDPR Architects Executive Summary Architects Plans Testing

Object Oriented Design (OOD) Testing
We have developed a Testing Framework which can be used as a template for development as well as infrastructure testing. This page presents our OOD Testing for Infrastructure teams. We also architected-designed an editor for testing as a tool.

Testing Using OO
Testing is the process of achieving error free system. There should be a test plan, which includes unit test, stage development testing and system testing. The design should include testing stages and plans. Testing teams and tools should be available.

A Data Center includes hardware, software, storage, network equipment, cooling systems, power supplies and data. We would leave the facilities and building infrastructure to their experts. Our focus is on the networks which include hardware and software. Therefore, when it comes to Data Center Building and Migration, testing will be all inclusive. We need to redefine testing as follows:

       What is Data Center's Testing?
       How critical Data Center testing?
       How critical Management to Data Centers?
       Types of Testing?
       What is Tested?
       How to Test?
       When to Test it?
       Who would be Testing?
       Testers qualification?
       After Testing?
       Recycle Testing?
       Testing Class
       Java Testing Class
       Our Testing Editor

What is Data Center's Testing?:
The following image is our attempt to put a picture of the magnitude of the effort needed to test the hardware and the software of a data center. We presented the testing hierarchy and how it is all stands on the shoulder of the management and supporting staff.

Data Center testing diagram

The Data Center's Testing - Tracking - Validation Components image represents:

       Possible Testing Objects
       The views of different teams
       Properties and methods of a testing object

Possible Testing Objects:
The images groups different hardware (Bar-Metal), software, interfaces, databases, batches, operating systems into possible testing objects. Each object can be tested separately or with other objects.

The views of different teams:
Different teams can see their testing objects which they own or run and the interfaces associated with it. For example, developers who perform the software testing can recognize the portion of the testing such as the running applications and their interfaces. The DBA can see the database, bridges, SAN, NAS and batches. OS Admin sees the fact that everything running on his working OS . As for the management and supporting staff, the entire testing is shown resting on their shoulders and their goals are the Testing Checklist Goals.

Properties and methods of a testing object:
Properties and methods are the details associated with each objects and there is from 1 to N properties listing where each object would own and work with.

How critical Data Center testing?:
Data Center testing is critical to verify the performance of its infrastructure. Regardless of the Building or Migrating Data Centers, testing is the critical part of making it all possible. The testing goal is to ensure the following:

   1. Performance 2. Security 3. Availability 4. Scalability
   5. Flexibility 6. Transparency 7. Consistency 8. Reliability
   9. Recovery         

How critical Management to Data Centers?:
Without Management we do not have Testing and without Testing we do not have a data center or we have a data center with hidden bombs waiting to be detonated and your business is the causality.

Types of Testing?:
We only list a brief definition of some of known testing:

Volume Testing:
Large amounts of data is used.

Load Testing:
Testing using Large amount of users.

Stress Testing:
Focus on running abnormal conditions as well extreme values that the system may encounter.

Structural Testing:
It takes into account the internal structure of a system or component and ensures that each program statement performs its intended function. It is usually performed by the software developers.

System Testing:
Integrating hardware and software system to verify that the system meets its specified requirements. It is conducted by the testing teams in both development and target environment.

Performance Testing:
Functional testing conducted to evaluate the compliance of a system or component with specified performance requirements.

System Integration Testing (SIT):
It is a black box testing technique that evaluates the system's compliance against specified requirements. System Integration Testing is usually performed on subset of system while system testing is performed on a complete system and is preceded by the user acceptance test (UAT).

User Acceptance Testing (UAT):
also called beta testing, application testing, and end user testing - is a phase of software development in which the software is tested in the "real world" by the intended audience.

Reliability testing is used to determine the system reliability such as Boundary , Special Case, and Build Verification test (BVT).

White-box Testing:
White-box testing (also known as clear box testing, glass box testing, transparent box testing and structural testing) tests internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing an internal perspective of the system, as well as programming skills, are used to design test cases.
While white-box testing can be applied at the unit, integration and system levels of the software testing process, it is usually done at the unit level.

Black-box testing:
Black-box testing treats the software as a "black box", examining functionality without any knowledge of internal implementation. The tester is only aware of what the software is supposed to do, not how it does it.
Black-box testing methods include:
Equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing and specification-based testing.

What is Tested?:
Data centers today are larger, faster and more complex than ever and if you asked ten networking testing gurus: what do we need to test? They will give over 20 if not 30 different answers. Therefore, the following list is our attempt to inventory what is tested?

   1. Operating system 2. Servers 3. Domains 4. Software
   5. Hardware 6. Interfaces 7. Firewalls 8. Connections
   9. Recovery 10. Databases 11. Resources pools 12. Security
   13. Batch 14. Databases pools 15. Flow 16. Network, cluster, nodes
   17. Validation 18. Dependencies 19. Processes 20. Management and Documentation

A Testing Object must created with properties and methods. It may contain one or more the listed items.

How to Test?:
Testing data centers is not an easy task and both manual and automation testing must be implemented. All test requirement such as Testing Objects, test plans, testing stages and testing teams and tools must ready to execute. We do recommend the following:

Management and documentation Testing Objects must be ready and running for both managing and documenting build or migration testing.
Change Requests Object should be also ready to address changes
"Has-to-Have" and "Nice-to-Have" should be clearly defined and "Nice-to-Have" is a low priority
Testing must be done in parallel
Validation Object must be running in parallel with testing

When to Test it?:
With the assumption that the data center facilities are running perfect, testing should be done as early as possible. We recommend the following steps:

       Once a Testing Object is created, then testing it should start separately or within a group Testing Objects
       Arrays of Dependencies and Assumptions objects should be addressed in parallel
       Validation of testing should be running in parallel
       Other miscellaneous issues should be addressed also in parallel

Who would be Testing?:
Data Centers' testing is a cooperative team work and the following are testers types or categories:

       Offshore and onshore testers
       System Admin

Based on what being tested, the test plans, processes, steps, scenarios, scripts, test cases, input values and results, ..etc, these testing material should be prepared with no overlapping or redundancies.

Test Specifications, Scripts, Constants, Hard Coding and System Parameters:
The testing specifications should include rules on no-hard-coding, constants and system parameters. They should be stored in properties file and include text files. The include text files would be included in the scripts instead of hard coding. Updating these include text files with latest constants values will have consistencies for any new changes.

Testers qualification?:
Based on what is being tested, a tester should be an expert on the subject matter that being tested. For example, an application tester should not perform any DBA testing or validation.

After Testing?:
Monitoring, test reviews and small tests should be performed on regular basis.
Lessons learned plus updating both management and documentation Testing Objects

Recycle Testing?:
Using OO, inheritance and Testing Objects would help with reusability. No throw away docs or material. Everything must be documented with a timestamp and testers and managers names for audit trial.

Testing Validation is:

       The testing performed is done according to test plans, specs, input values, results, ..etc.

The following should created and approved:

       A validation matrix with a timestamp and an audit trial (testers and managers names)
       Certification of work
       Validation Reports
       Risks and risks handling

Our Testing Editor:
Data Center Testing is all inclusive and involves other teams and literally everything that is running on the networks. Our Testing Editor is an attempt to present data center testing in more structure without overwhelming the tester. Our Editor groups Testing Objects in structured and sequential format that can be easily used and comprehended.

Data Center Testing Editor

       Facebook Facebook Facebook Facebook Facebook
About us Contact Site Map Support Privacy Terms All rights reserved