Posted date
Updated date
Nablarch System Development Guide
Table of contents
- Preface
- Purpose of this document
- Who should read this document?
- Notes on reading
- Overall picture
- Project plan
- Requirements definition phase
- Requirement definition
- Architecture design
- Checking the project deliverables
- Test plan
- Creating a development guide for a project
- Design phase
- Standardization
- Programming and Unit testing phase
- Initial build of Nablarch project
- Setting up the team development environment
- Preparation of setup guide for development environment
- Establishment of development standards
- Integration test phase
- Preparation for integration test (communication confirmation)
- System test phase
- Maintenance operation
- Nablarch Pattern Collection
- Commonly used patterns in Nablarch
- Nablarch anti-pattern
- Nablarch Batch Processing Pattern
- Classification by startup method
- Classification by input/output
- Important points
- Asynchronous Operation in Nablarch
- To sending emails
- Nablarch Anti-pattern
- Web application
- Nablarch batch
- JSR352 batch
- Customization of UI Standards
- UI standard (screen)
- UI standard (screen) separate volume_UI parts catalog
- Examination of Test Items
- Collecting test viewpoints
- Extraction of test viewpoint
- Nablarch Environment Construction
- Generating projects from archetypes
- Component settings
- Introduction of static analysis tool
- Java Style Guide
- Setting Up the Team Development Environment
- Preparation of Setup Guide for Development Environment
- xxx Project development environment construction guide
- Prerequisites
- Development environment construction procedure
- Package Configuration Study
- Concept of package configuration
- Example of division by business function
- Example of division by class role
Examination of Test Items
The test items should be defined for each phase to ensure that there is no variation in execution content of tests depending on the person in charge. However, increasing the number of items to improve the quality, increases the cost, makes detection of bugs more difficult, and may cause deterioration of QCD.
This section describes the concept to select the items to be tested.
Collecting test viewpoints
First, create a unit test specification format for the project by referring to the test type and test viewpoint catalog(Only Japanese Edition).
It does not mean having more test items is better. More test items will make it easier to ensure quality, but will affect cost and delivery time. Therefore, it is necessary to set test items that meet the project QCD goals.
Extraction of test viewpoint
Initially, prepare test viewpoints from the viewpoint catalog to avoid oversight, but exclude those that are not relevant to the project. For example, if your project does not have requirements for batch processing or sending emails, exclude these viewpoints.
The required viewpoints have to be selected here. Think about “what are the mistakes that a manufacturer can make, which will lead to the detection of bugs from this test viewpoint?” looking at the test viewpoint. As a result, if following are the test viewpoints, consider omitting them.
- When there is no chance that the test will find a bug, or the probability is very low and not worth the cost.
- When the bug can be detected by other activities.
- When the bug can be detected in reviews.
- When the bug can be detected by the test in the next phase.
For example, when realizing the layout using jsp:include
in the screen confirmation item, checking the individual common areas (headers and footers) can be omitted. This is because if the coder engages in development according to the project development standard, then there are no factors that will embed bugs in the process of creating the screen.
If the coder creates the screen without following the project development standards, the common areas may not be implemented correctly. However, you can check if the coding is according to the standard by reviewing the source code, and if the project development standards are developed properly, there is no reason for the coders to code in their own way.
In this way, it is possible to determine that checking the common parts can be omitted from the following viewpoints.
- Considering the project characteristics, bugs are less likely to be embedded.
- Bugs can be detected in other activities.
- Even if there is a bug, the effect is minor.
Instead considering a test viewpoint with a closed unit test, project productivity can be improved with a viewpoint based on the project characteristics.