How to think, plan and run tests in order to meet all quality requirements BY JOHN JAN POPOVIC

Software Testing
------------------------------------------------------
TESTING WHILE CODING
------------------------------------------------------
The proof that all expected technical requirements are completely satisfied is performed not only during the final product testing, than also during the early stages of the development is the fundamental idea behind the iterative software growth stages. Testing while coding is conceptual work not easy to establish. Planning of the iterative software growth stages, and the creation tests case examination scenario, context, input parameters and desired output data must be done upfront, before the coding starts.
At the end of each short iterative cycle, we have failure detection diagnostics, and in consequence we must create refinement proposal, and at the end the code patch must be crafted, implemented and deployed. If no failures have been detected we should move to a new more complicated test, and so on, until all functionality and quality requirements are meet or exceed requested performance. While crafting the software we are inspired by the precisions and excellence of ancient Swiss watch-making craftsmen.

Quality requirements
Quality Assurance QA test planning, precedes code crafting, growth and refinement. We must creates a test plan and populate it with test cases from trivial to complicated one with desired results outcome. We should also relate test cases to functional requirements, deploy a test plan, start executing test cases and designate them as successful or failed. We must create the software which generates reports on our test cases.
During the development we should also be able also :
- to create a sequence of test instances in a batch,
- to monitor test case execution in a Log file, and report success, failure, and a type of error or warning during and after the execution of the code
- to add and to remove particular test cases from the test batch
- to do requirements tracking
- to track the software growth, mutations and evolution on the roadmap milestones
- to do bug reporting and solution tracking

The Test Case examinations.
The tool includes test specification, planning, reporting,

The Milestones and Incremental Development process is not only a great way to map out complex functionality, it's also IMPORTANT to test out critical features before they're launched. During our INCREMENTAL DEVELOPMENT process we can make some changes in the application structure in an effort to better organise bug-tracking, development and feature releases.

Pre-Alpha
Pre-alpha phase refers to all activities performed prior to alpha testing. These activities can include collection of real life experimental data, of real life routine scenarios, prototyping, pre-disaster scenario symptoms early detection, solved and unsolved problems database, requirements analysis, data structures analysis, valid and invalid data patterns, error detection and correction and algorithm design.
In software development, there are more versions of pre-alpha prototypes. Milestone versions include specific sets of incremental features, which are released as soon as the feature functionality is correctly performed.

FEATURES SHOULD GROW VERTICALLY AND NOT HORISONTALLY
Vertical vs. Horisontal development philosophy. Vertical development philosophy is referred to small set of perfectly performed features, where all quality requirements are implemented. We are committed to provide functionality that meet or exceed promised performance.
---------------------------------------------------------------------------------------------------
PLANNING AND BIG PICTURE ORIENTATION: Where you’re, and where are you going?
---------------------------------------------------------------------------------------------------
“Programming without an overall architecture or design in mind is like exploring a cave with only a flash-light: You don’t know where you’ve been, you don’t know where you’re going, and you don’t know quite where you are.”
– Danny Thorpe, former Chief Architect of the Delphi programming language

----------------------------------------------------------------------
FROM TRIVIAL TO IMPOSSIBLE -- FROM VAGUE TO PRECISE
----------------------------------------------------------------------
Proving that theoretical model is fulfilling formal practical requirements is done in phases.

– PHASE 1: Real life experiments, reasoning and formal requirements, input - black box - output modelling, algorithm prototype simulation

– PHASE 2: Construction of the ideal test-case database, code and the prototype refining until the simplest most trivial test case is not correctly performed

– PHASE 3: Try the alpha prototype code with gradually more complicated test-case data, refining the code until all test cases are not correctly executed, and the simulation has provided desired and anticipated results.

– PHASE 4: The beta code testing is run on real-life data; and we monitor and control if the code is correctly executed; and during the process we try to capture all exceptions, discrepancies, anomalies, alerts, reports and crush results; in order to construct a test-case database of reproducible anomalies & crushes situations.

– PHASE 5: Induced crush testing before 1.0 release. We are committed to provide functionality and service that meet or exceed promised performance, and the use of real-life data with some random garbage input. Testing will be performed to prove such functionality in the induced stress conditions.

-----------------------------
QUALITY REQUIREMENTS
-----------------------------
Whatever the approach to software development may be, the final software must satisfy some fundamental quality requirements. The following software properties are among the most relevant:
* Efficiency/performance: the amount of system resources a program consumes (processor time, memory space, slow devices such as disks, network bandwidth and to some extent even user interaction): the less, the better. This also includes correct disposal of some resources, such as cleaning up temporary files and lack of memory leaks.

* Reliability: how often the results of a program are correct. This depends on conceptual correctness of algorithms, and minimization of programming mistakes, such as mistakes in resource management (e.g., buffer overflows and race conditions) and logic errors (such as division by zero or off-by-one errors).

* Robustness: how well software solution reacts to invalid input problems not due to programmer error. This includes situations such as incorrect, inappropriate or corrupt data, unavailability of needed resources such as memory, operating system services and network connections, and user error.

* Usability: the ergonomics of a program: the ease with which a person can use the program for its intended purpose, or in some cases even unanticipated purposes. Such issues can make or break its success even regardless of other issues. This involves a wide range of textual, graphical and sometimes hardware elements that improve the clarity, intuitiveness, cohesiveness and completeness of a program's user interface.

* Portability: the range of computer hardware and operating system platforms on which the source code of a program can be compiled/interpreted and run. This depends on differences in the programming facilities provided by the different platforms, including hardware and operating system resources, expected behaviour of the hardware and operating system, and availability of platform specific compilers (and sometimes libraries) for the language of the source code

* Maintainability: the ease with which a program can be modified by its present or future developers in order to make improvements or customizations, fix bugs and security holes, or adapt it to new environments. Good practices during initial development make the difference in this regard. This quality may not be directly apparent to the end user but it can significantly affect the fate of a program over the long term.