Coding (コーディング) is the work of writing out the processing steps fixed in detailed design according to the grammar of a programming language, producing source code; it is also called programming (プログラミング).
Detailed design
Coding
Unit testing
Each finished program is run on its own and checked in unit testing.
3 / 3
The work covers turning the processing flow and data handling in the detailed design document into instructions line by line, and checking the written steps for errors. A team agrees in advance on coding conventions (コーディング規約) for naming, indentation and the like, so that code stays easy to read no matter who wrote it. Readable code cuts the effort of later reviews and maintenance.
AnalogyIt is like assembling furniture while following the instruction sheet. The dimensions and steps on paper are turned, one by one, into real parts.
How to remember"Code" means a set of symbols: think of turning human ideas into symbols a machine can read.
Exam points
ExamCoding is the phase that comes right after software detailed design (ソフトウェア詳細設計), and the programmer who receives the detailed design document carries it out.
ExamCoding (programming, プログラミング) also covers checking the written processing steps for errors.
Mix-upDeciding the items on screens and printed forms is the job of external design (外部設計); coding is the stage that turns an already settled specification into code.
A code review (コードレビュー) is a check in which finished source code is read without being run, to find errors, convention violations and hard-to-follow writing.
Having someone other than the author read the code makes it easier to catch errors the author missed through their own assumptions. The earlier a defect is found, before the code even runs, the narrower the fix and the lower the cost of rework.
AnalogyIt is like asking a colleague to read your draft before you hand it in and mark typos and unclear passages in red.
How to rememberreview = re (again) + view (look): the word itself says to look over finished work once more.
Exam points
Mix-upA code review is a static check that only reads the code, and it is a separate activity from testing, which runs the program and checks the results.
A joint review (共同レビュー) is an activity in which stakeholders in different roles, such as developers and users, go over a work product together, check whether it meets the requirements, and reach agreement.
What gets inspected is the work product of each phase, such as the requirements definition document or a design document. With the user side taking part, it becomes easier to find mismatches with the requirements that developers alone would hardly notice.
AnalogyIt is like a meeting before a house is built, where the owner and the architect spread out the plans together and check room by room that the layout is what the owner wants.
Exam points
ExamSystem requirements (システム要件) are not decided by developers alone; the user department joins in and checks their content together with them.
ExamA joint review can be held even without a working program, so gaps from user requirements can be checked while things are still at the design-document stage.
ExamReview is one way to confirm the quality of a work product, and a joint review is one form of review.
Debugging (デバッグ) is the work of pinpointing where the cause lies for a defect found in testing or elsewhere and fixing the program.
Defect found
Cause located
Fix
Retest
The fixed part and the parts it affects are tested again.
4 / 4
You follow the program's behavior line by line, or display variable values partway through, to narrow down where the error is. After the fix, both the changed part and the parts it affects are tested again.
AnalogyIt is like a light at home that won't turn on: you check the bulb, the switch and the wiring in turn, find the faulty spot and replace it.
How to rememberA bug is an insect; add de- (remove) and the word itself says to clear out the bugs that crept into the program.
Exam points
ExamWhen testers and developers are separate, debugging falls to the developers who wrote the program, and testers report the defects they find to the developers.
ExamThe number of bugs found (the bug detection count, バグ摘出数) is one indicator of program quality.
White-box testing (ホワイトボックステスト) is a technique for designing test cases while looking at a program's internal structure (the sequence of instructions and its branches), used mainly in unit testing.
Read the internal structure
Choose paths to run
Prepare test data
Run and check
Run it and check that the results match what was expected.
4 / 4
Test cases are built according to a coverage criterion (網羅の基準), which says how far the internal paths must be exercised. For example, running every instruction at least once is statement coverage (命令網羅), and taking both the true and the false outcome of every branch at least once is branch coverage (分岐網羅).
AnalogyIt is like holding a map of a maze, picking the forks you want to check and actually walking them to see whether any lead to a dead end or the wrong exit.
Exam points
ExamWhite-box testing is used mainly in unit testing (単体テスト) and checks the paths inside a program comprehensively.
ExamAnalyzing the internal structure to decide on test cases is white-box testing.
Mix-upThe technique that checks conformance to the specification from inputs and outputs alone, without looking inside, is called black-box testing (ブラックボックステスト); choosing data so that every branch and instruction is run is not part of it.