仕様チェックプログラム エラー。 「これバグでしょ?」 vs. 「それは仕様です!」(前編) (1/2)

エラー処理とログ出力

仕様チェックプログラム エラー

テストは、ソフトウェアの品質を高めるために欠かせない、重要なプロセスだ。 規模の小さいソフトウェア開発でも、テスト項目の数は数百、数千にもなることも珍しくない。 膨大なテスト項目をクリアして初めて、ソフトウェアは世の中にリリースできる。 肝心のテスト項目には、抜けや誤りがあってはならない。 そこで、ふつうはテストを実施する前に、まず、テスト項目のレビューを行っているだろう。 だが、テスト項目をレビューする、という方法は、テスト項目の正しさをチェックする術としては、効率が悪い。 どんなに時間や人を費してテスト項目のレビューをしても、どうしても項目の抜けや誤りを見落としてしまう、という人も少なくないだろう。 十分なテストを行うためには、テスト項目を作ってからではなく、項目を挙げる前にレビューを行うべきだ。 開発も終わりに近づくと、チームの一部のメンバーは、テストの準備に取り掛かる。 準備を任されたメンバーは、しばらくは作業に没頭しているだろう。 そしてある日、膨大なテスト項目を書き連ねた文書を見せて、こう言って来る。 「できました。 レビューして下さい」。 ソフトウェアの品質は、テストにかかっている。 テスト項目が不十分であれば、バグが見逃され、できの悪いソフトウェアをリリースしてしまうことになる。 だから、膨大なテスト項目でも、1つずつ目を通して、レビューを行うことになるだろう。 だが、この作業は、極めて大変で困難なものである。 テスト項目は、たいていは一覧表の形になっている。 1つ1つの項目には、テストする操作の手順と、実行結果が書かれている。 テスト結果を記入するための空欄も用意されているだろう。 膨大なテスト項目が並べられた巨大な一覧表のすべてに目を通し、内容をチェックする。 気の遠くなるような作業だ。 それでも、責任感のある開発者は、何としてもやり遂げようとする。 だが、その努力は報われないだろう。 テスト項目の一覧表は、テストを効率良く進めていけるように、項目を順に羅列したものだ。 何をやるかは書いてあるが、何のためにやるかは書いていない。 テストを実施するには適した形式だが、内容を理解して、正しいかどうかをチェックするには、まったく不向きだし、不可能でもある。 これをレビューしようというのが、そもそも間違いなのだ。 「できました。 レビューして下さい」。 無理です。 機能仕様書や設計書といった文書は、これまでもすでに作成してきているし、レビューも行ってきているだろう。 だが、機能仕様書は設計のため、設計書は実装のために作る文書である。 設計や実装を行うために必要な、最小限のことしか書かれていないかもしれない。 レビューでも、設計や実装に支障があるかどうか、という点しかチェックしていないかもしれない。 テスト項目の正しさを検証するためのレビューでは、従来のレビューとは違った観点から、これらの文書をチェックする必要がある。 例えば、エラーが発生した時のログ出力の方式などは、後で考えればいいや、ということで、機能仕様書や設計書では記述が省かれているかもしれない。 それでも、設計や実装には特に問題なく進めたかもしれない。 だが、このままでは、テストではログ出力に関するテスト項目が完全に抜け落ちてしまうことになる。 これまでの文書の作り方に対する改善のアプローチとしては、具体的には下記の2通りが考えられるだろう。 テストの前に見直しのレビューを行う 機能仕様書や設計書を作成した時点では、これまで通りのレビューを行う。 テストの前に、テストのためにもう一度レビューを行う。 但し、テストのためにレビューする時点では、すでに設計、実装まで終了しているので、何か抜けや誤りが見つかると、手戻りが発生することになる。 テストを見据えて文書を作る 機能仕様書や設計書を作成する時点で、目先の設計や実装のことだけでなく、将来のテストのことまで見据えて、文書を作るようにする。 テストという新たな視点から、文書を多角的に見ることで、抜けや誤りをより減らすことができる。 また、要件定義や設計という早い段階で問題点を洗い出すことができ、リスクの軽減にも繋がる。 ダイアログ画面のテスト方針• モーダルかモードレスか• モードレスの場合• フォーカスの移動• ダイアログに関連するパラメータの変更• 同じダイアログをもう1つ表示• 画面を閉じる順序やタイミング• OK/キャンセル/適用• リターンキー/エスケープキーの入力• タブオーダー• ラージフォント/スモールフォント• スペルミス/用語の統一• フォーカスの移動• アプリケーションの他のウィンドウに切り換え• アプリケーションのメインウィンドウに切り換え• ウィンドウの最小化• タスクバーから他のアプリケーションに切り換え• Alt+Tabキーで他のアプリケーションに切り換え• Windowsメニューから他のアプリケーションを起動 テスト項目を書き出す前に、このようなテスト方針に抜けや誤りがないかをチェックする。 テスト項目は、テスト対象のソフトウェアに強く依存している。 良く考えられたテスト項目も、他のソフトウェア開発には流用することはできない。 それどころか、ソフトウェアの機能追加や仕様変更があった時も、以前のテスト項目は使えなくなってしまう。 ただテスト項目を残しておくだけでは、ソフトウェアの改造に際しての回帰テストすら、満足に行えないだろう。 テスト項目は、テストを実施するためだけの使い捨ての文書なのだ。 テスト方針を残すようにしておけば、たとえ機能追加や仕様変更があった時も、方針を少し手直しするだけで済む。 変更のあった点だけ、改めてテスト項目を挙げ直すことも容易になる。 さらに、テスト方針は、1つのソフトウェアに特化しない、汎用的なものになることも多い。 一通りのテスト方針を確立すれば、それはいくつものソフトウェア開発で利用できる、共通の資産となるだろう。 テスト項目を挙げる前にレビューを行うことは、テストの抜けや誤りを無くすだけでなく、テスト方針という資産を生み出すことにも繋がるのだ。 Copyright C Seiichi Yoshida. All rights reserved.

次の

4. 入力チェックプログラム — プログラミングガイド 第15版 2019

仕様チェックプログラム エラー

システム設計者の意図は仕様書でしかプログラマに伝わりません 設計者とプログラマが同一人物であれば、作るべきプログラムの内容が分かっています。 仕様書に曖昧な表現をしても影響ありませんが、通常は別人。 システム設計者の意図は仕様書でしかプログラマに伝わりません。 優秀なプログラマは、疑問点などを整理して設計者に質問し仕様の曖昧さを排除します。 しかし、経験年数が少ないと自分なりの解釈でプログラミングしてしまい、結果的に手戻りが発生します。 日本語は多彩な表現ができます。 雨が降るにしても「ぽつぽつ」「ざーざー」「ぱらぱら」「しとしと」と、様々な表現が可能です。 いくつもの表現ができる日本語で仕様を記述するのは至難の業。 ITベンダーの多くは新入社員に対してプログラミング研修は行いますが、仕様書の書き方について教育は行われていません。 先輩の書き方をまねて勉強するしかなく、個人まかせになっているのが実態です。 曖昧さがある日本語ですので誤解や思い込みが常に発生します。 例えば、「画面で入力チェックを行い、不適切な文字が入力されていたらエラー表示する」という仕様について考えてみましょう。 不適切な文字とは何でしょう。 エラーはどのような内容を表示したらよいのでしょうか。 文章以外に入力項目毎の別表を作って曖昧さをなくします。 ある項目が入力された場合に、別の項目も入力されないとおかしい場合は関連チェックとして記載します。 (入力項目)日付 数字チェック&妥当性チェック(月は1~12のみなど)を行い、エラー時は日付エラーを表示する エラー表示については指針をもうけ全画面共通にしなければなりません。 画面によって日付エラーや数字エラーなど、様々なメッセージが表示されたらユーザーは戸惑うだけです。 形式手法(フォーマルメソッド)による記載 形式手法記述言語を使いこなすには教育が必要 仕様書の記載には形式手法(フォーマルメソッド)という方法もあります。 日本語ではなく形式仕様記述言語を用いて表現します。 曖昧さのない言語で表現することで思い込みを排除し、手戻りをなくす手法です。 ただし形式仕様記述言語を導入すれば、全てがかなえられるような魔法の道具ではありません。 まず形式仕様記述言語を、関係する全てのメンバーが使いこなせなければなりません。 日本語と違い、見ただけでは暗号のようなプログラミング言語です。 理解し、記述できるように教育が必要となります。 自社だけでなく、協力会社を含めてプロジェクトを推進する時は協力会社にも教育が必要です。 形式手法記述言語を用いて仕様を記述する場合、従来の日本語による仕様記述よりも工数が多く掛かります。 これは数学的に厳密な仕様を作るのに時間がかかるためです。 ただし設計の質が向上しますので後工程での手戻りを減らし、プロジェクト全体の工数を減らせます。 3倍程度、生産性が上がった事例や大規模プロジェクトで導入した事例があります。 形式仕様記述言語からプログラミング言語を自動生成することも一部で行われています。

次の

仕様チェックプログラムについて

仕様チェックプログラム エラー

チェックプログラムのダウンロード 「月額変更届」、「算定基礎届」、「賞与支払届」、「社会保険取得届(CSV)」、「社会保険喪失届(CSV)」の手続きを電子申請する際、また処理ファイル「電子媒体申請」よりデータを作成する際は、日本年金機構HPからダウンロードできる仕様チェックプログラムで、作成したデータが年金事務所で確認できるかどうかのチェック作業が必要です。 仕様チェックプログラムはこちらからダウンロードできます。 00に対応しているのは台帳V10. 11以降になります。 【届書作成プログラム内の仕様チェックプログラムVer. よくあるご質問 お問い合わせ チェック時に場合「元号不正」エラーとなってしまう。 回答 仕様チェックプログラムVer12. 00未満がインストールされている可能性があります。 現在の仕様チェックプログラムをアンインストールし、仕様チェックプログラムVer12. 00をインストールしてください。

次の