Software testing involves the execution of a software component or system component to evaluate one or more properties of interest. The most common properties to evaluate in a software application are:
- meets the requirements that guided its design and development,
- responds correctly to all kinds of inputs,
- performs its functions within an acceptable time,
- it is sufficiently usable,
- can be installed and run in its intended environments, and
- achieves the general result its stakeholders desire.
1 Test types
It exist many levels of
software testing. They vary depending on the role of the programmer that is going to write the test and the part of the program to be tested.
Axional ERP is susceptible of executing Unit, Integration, Performance and Stress tests as it will be seen bellow.
1.1 Unit testing
Unit testing refers to tests that verify the functionality of a specific section of code, usually at the function level. In the
Axional ERP application context, refers to the business logic code stored in dictionary modules:
- Database architecture: Tables, indexes, constraints, etc.
- Database programs: Triggers, procedures and functions.
Unit tests can be executed in serveral ways, but it is recommened to use the
Axional Test module to perform this type of test.
It implements the necessary forms and reports to implement and monitorize Unit tests within the context of an
Axional Studio application.
1.2 Integration testing
Integration testing verifies the interfaces between components against a software design. Software components may be integrated in an iterative way or all together ("big bang"). Normally the former is considered a better practice since it allows interface issues to be located more quickly and fixed. Integration testing works to expose defects in the interfaces and interaction between integrated components. In
Axional ERP application the mentioned components, which can be verified by integration tests, are:
- Axional Studio forms interface (User interface business logic)
- Column attributes.
- Column options.
- Soft References.
- Reset logic.
- Axional Studio transaction handler (Server-side business logic)
- JRepObject configuration: TRX Manager.
- Database transactions.
- Validation script.
The same way it happens with Unit tests, it exists many ways of executing Integration tests using external applications.
Axional Test module implements what is called Black-box testing.
It treats the software as a "black box", examining functionality without any knowledge of internal implementation, without seeing the source code.
The testers are only aware of what the software is supposed to do, not how it does it.
1.3 Performance test
Performance testing is a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.
1.4 Stress test
Stress testing is normally used to understand the upper limits of capacity within the system. It consists of overloading existing resources in an attempt to break the system down. This kind of test is done to determine the system's robustness in terms of extreme load and helps application administrators to determine if the system will perform sufficiently if the current load goes well above the expected maximum.
2 Test plan
The test plan is considered the infrastructure to develop the system test. This plan includes both the architecture of the databases and the protocol to carry the test plan out.
The following sections try to explain how to test the different Axional Applications.
2.1 Test databases architecture
ERP Dictionaries provide the functionalities corresponding to each ERP module. It consists on the databases wic_icon for finances, wic_iges for supplies and purchases, etc. The mentioned functionalities are the subject of the test; so, any Test Master Data and Test Data databases should have associated at least one ERP Dictionary.
The JUnit dictionary (wic_junit) is an special dictionary required by Test Master Data databases for enabling the menu options for defining the test cases.
Test Master Data databases has two purposes:
- Test data storage. The ERP Dictionaries provide the necessary structure and forms for adding specific module master data and implementing functional circuits to be tested. Test Master Data is usually a clone of the ERP Master Data database. Thus, it contains the initial data for testing.
- Test cases storage. The JUnit Dictionary provides the necessary structure and forms for implementing Test Case and Test Data.
Even though Test Master Data databases contains the necessary data for executing the tests, a test execution could alter the expected initial state of test data, or it could even affect other tests; so, it is highly discouraged executing tests on this database.
Finally, Test Data databases are the ones used for tests execution. These databases are the only ones within the Test Environment which might contain volatile information. That is, they can be destroyed and rebuilt, generally as a copy of Test Master Data databases, in order to have consistent data at the beginning of the test execution.
Integration, Performance and Stress tests cannot use rollback command to undo transactions. Due to this fact, it becomes MANDATORY executing them on the Test Data database.
Axional Test UNIT TEST uses rollback command, it is highly recommended to use Test Data database for UNIT TESTS execution.
The graphic below shows an example of definition for the following modules:
- RF (wic_term)
- Finances (wic_icon)
- Supplies and purchases (wic_iges)
- Axional Studio (wic_studio)
2.2 Test Protocol
The following steps defines a good practices guide to executing a satisfactory test plan over an Axional Application:
- DROP and create the Test Data database (test_[module])
- Import data from Master Test Data database (junit_[module]) to Test Data database (test_[module])
- Execute individual test
3 Test driven development
TDD Test-driven development is an evolutionary agile design technique where you write your test code before your functional code. This way one thinks through the requirements before writing the functional code. The simple concept of TDD is to write and correct the failed tests before writing new code (before development). This approach tests every single line of code, unlike traditional testing.
Test-driven development is related to the test-first programming concepts of extreme programming (XP), as it attemps to reduce development cycles by having multiple shoter ones. Also recommended for rapidly evolving designs.
Write your test code in very small steps: one step and a small bit of corresponding functional code at a time, usually a Unit test. First, a test is written and it is verified that the tests fail. Next, the code that makes the test pass successfully is implemented and then the written code is refactorized.
- Add a test.
- Run all tests and see if any new test fails
- Write some code.
- Run tests.
- Refactor code.
- Acceptance TDD (ATTD): write a single acceptance test (behavioral specification) and then just enough production functionality/code to fulfill that test.
- Developer TDD: write single developer test (unit test) and then just enough production code to fulfill that test.
For more detailed information, please consult the external link Test driven development.