Regression testing (リグレッションテスト, also 回帰テスト) rechecks, after a program is changed, that existing features that were not changed still work as before.
Change the program
Test the changed part
Rerun earlier tests
Release to production
If neither kind of test shows a problem, release the change to production.
3 / 3
A fix or a new feature can break some other feature in an unexpected place. So apart from testing the changed part, you rerun the tests that passed before and see whether any result has changed.
AnalogyIt is like getting your car's brakes repaired and then trying not only the brakes but also the lights and wipers to see that they still work as before.
How to rememberTo regress means to go backward, so the name itself reminds you that this test looks for quality slipping backward because of a change.
Exam points
ExamAfter a fix, prepare tests for the fixed part and rerun the previously passed tests along with them.
ExamWhen a running system is modified, the test that decides whether it can go live is done in a separate environment configured like production, so that live processing is not affected.
Mix-upRegression testing (リグレッションテスト) aims to confirm that unchanged parts are not broken; whether the fixed part works as intended is checked by a different test.
Validation testing (妥当性確認テスト) checks whether the finished system meets user requirements and business needs, in other words whether it is what was actually needed.
Its viewpoint differs from the check of whether the system was built to the design and specification (verification, 検証); it asks whether what was built is useful to the business in the first place. The name describes the viewpoint being checked rather than one particular phase of testing.
AnalogyIt is like trying on a tailored suit not to see whether it was sewn to the pattern, but whether it suits the occasions you want to wear it to.
How to rememberIn English it is validation, from the same root as valid, so remember it as checking whether the system is valid for the people who use it.
Exam points
ExamWhat the user department checks is whether the system meets business needs; whether the programs run as the specification says is checked by the development side.
Mix-upUsers and developers checking together that the design document meets user requirements is a joint review (共同レビュー), not a test that uses a working system.
Acceptance testing (受入れテスト) is led by the ordering party (the users), who use the delivered system under conditions close to real operation to decide whether to accept it.
Unit testing
Integration testing
System testing
Acceptance testing
The ordering party, having received the delivery, leads the testing and decides whether to accept it.
3 / 3
It takes place before formal sign-off (検収, checking the delivered goods and taking them over), and confirms that the functions specified at the time of ordering are all present. The order in the figure is typical of cases where the contractor handles everything up to system testing.
AnalogyIt is like collecting a bicycle from the repair shop: you listen to the explanation, ride it yourself, and pay only once you are satisfied.
How to rememberThe one who decides whether to accept is the one receiving the goods, so the name itself tells you who does the test.
Exam points
ExamAcceptance testing (受入れテスト) is carried out by the ordering party (the users), while developers take a supporting role.
ExamWhen acceptance happens depends on the contracted scope: once the contractor finishes its phases and delivers, acceptance and sign-off (受入れ検収) follow.
Mix-upSystem testing (システムテスト) is where the development side checks overall functions and performance, so it is done by a different party from the acceptance testing the ordering party performs.
A user manual (利用者マニュアル) is a document of operating procedures that people who use the system consult in their daily work.
Its readers are the people who use the system rather than developers, so it describes steps that follow screen operations and the flow of work, not the inner design. It is prepared during the acceptance stage and also serves as material for educating and training users.
AnalogyIt is like the step-by-step sheets a shop prepares for new staff, one for each task such as ringing up sales or handling returns.
How to rememberThe word user at the front of the name tells you who reads it; a design document, read by the builders, has a different reader from the start.
Exam points
ExamA user manual (利用者マニュアル) is used to carry out work after go-live, and is prepared separately from the development documents that record requirements and design.
ExamPreparing the user manual and using it to educate and train users are part of the software acceptance (ソフトウェア受入れ) stage.
Migration (移行) is the work of switching data and operations from the current system to the new one until it is in live use.
Migration plan
Software installation
Data migration and cutover
Live operation
Move the data, switch operations to the new system, and start live operation.
3 / 3
Migration includes software installation (ソフトウェア導入), which deploys and configures the software in the production environment, and the work of moving data from the old system and switching operations to the new one. The cutover method, such as running the old and new systems side by side for a set period, is chosen by weighing the risk of stopping operations against the effort involved. Fixes and changes to programs after live operation begins are called software maintenance (ソフトウェア保守).
AnalogyIt is like moving a shop into a new building: you fix the opening day and who is in charge, install the shelves and equipment, bring in the stock, and then put up the new sign.
How to rememberIn English it is migration, the same word used for birds that change homes with the seasons, so picture moving house with all your belongings.
Exam points
ExamA migration plan (移行計画書) records the schedule and team for switching to the new system, the planned period of running old and new in parallel, and similar items. Screen operating steps belong in the user manual (利用者マニュアル).
ExamDeploying and initially configuring software in the production environment according to the migration plan is software installation (ソフトウェア導入), carried out after the installation plan has been agreed.
Mix-upFixing defects after go-live and changing programs to follow a law amendment are software maintenance (ソフトウェア保守); fixing bugs found in testing during development does not count as maintenance.
Regression testing reruns earlier tests after a change to confirm that unchanged features are not broken.
Validation testing checks whether what was built meets user requirements and business needs, and is what was actually needed.
Acceptance testing is led by the ordering party, who decides whether to accept once the contracted scope is delivered.
The user manual is prepared at the acceptance stage and used for training users and for work after go-live.
In migration, the migration plan sets the cutover schedule and team, and the system goes live after software installation and the switch of data and operations.