AJE Software Technology Specialists
Follow us on ... Indigo DQM on FacebookIndigo DQM on TwitterIndigo DQM on LinkedIn
Tel: 056 0364 1958
Global Software Specialists
And Technology Consultants
 
 
IT Software Experts and Data Specialists
Data Management, Query and Reporting
Data Analysis, Data Mining, Processing, ETL
FinTech, Financial Software and Reporting

Data Artificial Intelligence / Machine Learning

Web Scraping / Data Extraction and Harvesting

Data Analysis, Migration and Consolidation

Business and Data Intelligence Software
Software Components and Development Tools
 
     
     
 

AJE Consulting Standards

AJE Consulting Enquiry Form

All our products have been developed and tested to the highest standards. As a rule all our products undergo rigorous design and testing methods to ensure the highest level of quality, functionality and reliability. An overview of our design process is detailed below.

AJE Software is always looking to improve the quality of our software products and would welcome any feedback or suggestions on how any product may be improved.

Design Process

VERIFICATION AND VALIDATION

Verification involves checking that the product conforms to its specification. Validation involves checking that the product meets the expectations of the customer.

Requirements validation techniques, such as prototyping are useful here. However, flaws and deficiencies in the requirements can sometimes only be discovered when the system implementation is complete.

To satisfy the objectives of the Verification and Validation process, both static and dynamic techniques of component checking and analysis are used. Static techniques are concerned with the analysis and checking of product representations such as the requirements document, design diagrams and the source code and may be applied at all stages of the process. Dynamic tests involve exercising an implementation and can only be used when a prototype is available.

Static tests include product inspections, analysis and formal verification. Static techniques can only check the correspondence between a product and its specification. They cannot demonstrate that the product is operationally useful.

Product testing is still a good way of testing and involves exercising the product using data like the real data processed by the product. The existence of product defects or inadequacies is inferred from unexpected system outputs. Testing may be carried out during the implementation and after.

When defects are found these are removed by debugging. Defects in the code are located and the product modified to meet the requirements. Testing is repeated to ensure that the change has been made correctly.

THE TESTING PROCESS

The testing process proceeds in stages where testing is carried out incrementally in conjunction with system implementation.

UNIT TESTING

Individual components are tested to ensure that they operate correctly. Each component is tested independently, without other system components.

MODULE TESTING

A module is a collection of dependent components such as a collection of procedures or functions. A module encapsulates related components so that it can be tested without other system modules.

SUB-SYSTEM TESTING

This phase involves testing collections of modules that have been integrated into sub-systems. The Sub-system test will concentrate on the detection of interface errors by rigorously exercising these interfaces.

SYSTEM TESTING

The sub-systems are integrated to make up the entire system. The testing process in concerned with finding errors that result from unanticipated interactions between sub-systems and system components. It is also concerned with validating that the system meets its functional and non-functional requirements.

TESTING STRATEGIES

A testing strategy is a general approach to the testing process rather than a method of devising particular system or component tests. Different testing strategies may be adopted depending on the type of product to be tested and development process.

THREAD TESTING

Thread testing is an event based approach where tests are based on the events that trigger system actions. As part of the testing process the product is analyzed to identify as many threads as possible. Threads are not just associated with individual events but also with combinations of inputs that can arise.

Threads are identified from an architectural model of the system that shows interactions and from descriptions of system input and output.

Share it:
Share this page on Del.icio.usDel.icio.us Share this page on DiggDigg Share this page on FacebookFacebook Share this page on GoogleGoogle Share this page on MyspaceMySpace  
Share this page on RedditReddit Share this page on StumbleuponStumbleupon Share this page on Yahoo!Yahoo! Share this page on TwitterTwitter Share this page on NewsvineNewsvine