システム開発の下流工程あるあるなどの雑記
仕事の話です。とあるシステム開発で、6～8人くらいでの製造、テスト工程を経験しているところです。要件定義（RD）→基本設計→詳細設計→製造（PG）→単体テスト（PT）→結合テスト（IT）→総合テスト（ST）と進んでいくウォーターフォール型のプロジェクトですが、その中で下流の各工程のあるあるや、気をつけたいこと、思っていることをつらつらと書いてみることにしました。-----------------------製造工程【行う主な業務内容】・開発環境構築・コーディング仕様書に則ってソースを書いていく工程です。PT(単体テスト）に比べても、ひたすらソースにもくもくと向き合う時間になる印象です。【あるある】・環境構築でSVNとかからソースをチェックアウトしてきたとき、ビルドエラーはほぼほぼ起きる。mavenだったらpom.xmlの誤り（依存関係の解決）だったり、ソースのビルドパス誤り。これはAntですが、以前、Javaのバージョンと、プロジェクトファセットのバージョン、コンパイラのバージョンが一致していなくてエラーがとれないってこともありました。ここで思わぬ足止めを食うことは想定の範囲内でないといけない。（とはいえ試験環境の構築に比べたら工数はずっと少ないはず。）【ありがちな失敗】・コピペミス単純だが多いです。コピペしてきて、差異となる箇所は手を加えないといけないところ、そのままにしてしまうミス。特にエンハンス開発だったり、部分的に流用できる既存システムのソースがある場合、かなりの高確率で起きる。これがIT（結合試験）で見つかるとチケットの原因欄を書くのが非常に気まずくなるので、PTまでには潰しておきたい。・定数クラスと定義ファイルの齟齬定数定義と定義ファイルのvalueが一致していない問題。特によくあるのは「Id」と書くべきところを「ID」としてしまうミス。他には「flg」と「flag」とか。・定数クラスの変更影響うっかり定数クラスを変更したが、定数を参照するファイルの修正が漏れていてビルドエラー。初歩的なミスなのでやってしまうと恥ずかしい。定数クラスを参照する全プロジェクトをチェックアウトしてきて、eclipseだったらctrl+hで他プロジェクトでも使っていないか確認。・メッセージ指定誤り出力するエラーメッセージが仕様書と違ってしまっているパターン。エラーIDの指定誤りということで、仕様書との突合せ不足。・数字の範囲チェック誤り「>」とすべきところを「>=」としてしまう系のミス。かなり初歩的で恥ずかしい。しかし私は「気をつけないとな」と思っていたのにやらかしたことがあります。。・コメントミスソースに集中していて、コメントが明らかにおかしい場合がわりとある。正しいコメントを書きたいよね。（サービスイン済のプロジェクトでもそういうのがたまにある。その場合信用するのはもちろんコメントではなくソースです）-----------------------単体テスト（JUnit使用前提で書いています）【行う主な業務内容】・要因分析表作成→条件分岐・例外発生箇所などを横軸の「要因」、それら要因の取りうる値を縦軸の「状態」とし、マトリクスを作成する。（このマトリクスがないと、カバレッジの保障が全くできないし、レビュアーも判断のしようがないです。）・単体テスト項目書作成→要因分析表をもとにテスト項目書を作成します。・テストソース作成、実行→テストケースのテストソース全て書いてから一括実行ではなくて、書きながら実行。・不具合修正→単純ミスはここで全て検出しておきたい。気持ちとしては。【あるある】・コード量が多い。たいていの場合、プロダクトコードよりステップ数が多い。・パターンがつくれれば作業スピードアップだが、そのパターンを飲み込むまでが一苦労な気がしています。特にモックの使い方を飲み込むまでが大変。（PowerMock理解してないけど癖があるらしい。）・個人的にはPG（製造）よりPT（単体テスト）の方がかなり大変です。【よくありがち（？）なミス】・リソースファイルをコミット忘れしてビルドエラー→javaファイルはコミットしたものの、テストに必要な入力ファイル（resourceフォルダ配下）をコミットしておらず、エラーになるパターン。対策としては、コミットしたら他のPCで取り込んでもらって、ビルドが通るか確認してもらうのが一番確実な方法。・テストメソッドの実行順に依存したテストケースはダメ→JUnitのテストメソッドは、実行順がランダムで、上に書いたメソッドから順番に下に流れていくわけではありません。なので、test1メソッドの成功を前提として動くtest2メソッドを書いてはいけません。・定数クラスのあるプロジェクトからビルドしないミス→定数クラスのあるプロジェクト、業務処理を行うプロジェクト、テストプロジェクトにそれぞれ修正を加えたときに、ビルド順としては、①定数定義しているプロジェクト→②業務処理のプロジェクト→③テストプロジェクトが正しい。①定数クラスのビルドをせずに②業務処理プロジェクトのビルドをしようとしてもエラーになります。【その他考慮する点】・テスト観点は？（命令網羅？分岐網羅？条件網羅？）→テスト観点が何なのかは大事です。私が関わったプロジェクトでは、プロダクトコードの分岐網羅100%を目指すという観点でした。（Javaとしての動きが正しいことは保証できるのですが、仕様として正しいことは保証できない。。）・privateメソッドもテスト対象？→privateメソッドのテストは厄介です。ここもテスト対象になるのかはテスト工程の開始前に確認しておいた方が良いです。・IOExceptionとかの発生方法→正常系のテストはそんなに苦労せずにできるかと思うのですが、例外処理をどこまで網羅するのか、という問題はあります。分岐網羅100%と言っても無理して頑張って網羅率を上げても品質保証に繋がらないところもありますね。例えばcreateNewFile()の時のIOExceptionとか、頑張って発生させても品質アップに繋がらないです。-----------------------結合テスト【行う主な業務内容】・要因分析表作成→入力パラメータ、入力ファイル、テーブル状態、条件分岐、エラー発生箇所などを要因、それら要因の取りうる値を状態とし、マトリクスを作成する。（このマトリクスがないと、カバレッジの保障が全くできないし、レビュアーも判断のしようがないです。）・結合試験項目書作成→要因分析表をもとにテスト項目書を作成します。・テスト用の環境構築、ttlの作成、ジョブ管理システム（有名どころだと例えばJP1とかシステムウォーカー）へのジョブ登録・テストデータ作成・打鍵（実施）・不具合修正・エヴィデンスチェック、レビュー【ありがちなミス】・期待値誤り→鉄板ミス。項目書の期待値が誤っているケースは必ずあります。自分があまり仕様に詳しくなかったら知っている人にすぐに聞くこと。・手順の誤り、不足→これも多いですね。特にテーブル状態の条件が書かれていないパターンが多い。これが困る。・性能試験など大量データを扱う試験では、ログレベルを荒くした方が良い（例えばDEBUG→INFOに）。ディスク容量が貧弱なところでDEBUGレベルで性能試験やって、ログの大量出力でDBが落ちたことがありました。DMLを実行するときはアーカイブログを監視する必要あり。・ジョブパラメータミス→Javaは正しいはず、shファイルも正しいはず。なのになぜかエラー。っていうのでジョブパラメータの誤りというケースがありました。・ディレクトリ、テーブルへの権限付与ミス遭遇したエラーの原因が、SELECT FOR UPDATEするのにUPDATE権限がユーザにgrantされていないっていうDDLのミス。っていうのがありました。・コミット漏れでのビルドエラー→PGやPTのみならず、ITでもやっぱり起きてしまいがちですけど、ITでやると結構気まずいことになります。【あるある】・ツールの使いこなし→テスト工程って、とりわけ「数をスパスパ捌く」って雰囲気の作業工程になります。要件定義や設計フェーズに比べてスピード勝負で、かつ、ほぼ同じ内容のことを繰り返し行うことになる。その中で、サクラエディタとかExcelの使い方をあまり知らないでやっていると、相当なタイムロスになります。ツールを使いこなせているか、ツール慣れしているかどうかが如実に表れてしまうので、使い方を押さえておくことが大事。使いながら少しずつ覚えていく。・コミュニケーションの速さが大事→これは試験全般に言えることだが、テスト工程は実施件数、OK件数など、数的進捗を特に求められがち。要件定義や設計のときよりもスピーディにスパスパ捌いていく能力が求められる印象。そこで最重要なのは的確な連携。・複数人でのテスト実施時にテーブルデータが競合する問題→こういうのを避けるためのWBSだと思っています。しょうがなく競合してしまう場合は、打鍵の開始と終了のタイミングをチームメンバと声かけあって、うまく進めるようにするしかない。・性能試験以外のテストケースでは、テストデータの件数は少ない方がログの可読性が良い。→性能試験ではないのに15000件くらいのテストデータ作成して実行していましたが、その必要性はなかったのでは？と。実際の運用時の件数に合わせて実施した方がいいなどと思っていましたが、それは総合テストですれば良いこと。・性能試験の実施タイミング。性能試験をいつやるかがWBS的には結構重要。業務処理が正常終了することが大前提なので、基本的には工程の最後にもってくることになると思います。億単位のレコードを作成するなど、性能試験のテストデータ作成が地味に時間がかかる。実施後は測定結果に対する見解も必要なので、それ込みだと結構かかる。・消化率の把握、整理→特に中盤以降は、実施結果のOKとNGと未実施と潜在NG（実施してないけどNGであることが明瞭）のテスト項目が混ざってきて、どの試験項目を実施すれば良いのか、が見えづらくなってきます。当然不具合対応も同時並行で行わないといけないのでマルチタスク化していきます。ここで状況整理をうまくできるかどうかが大切。私はここで整理できなくなってしまい、自分がチームのボトルネックになってしまいました。。。苦い。・サーバとかリモートデスクトップへの同時アクセス許容数は確認しておきたい。→許容数が少ないとテスト進行上かなり痛い。インフラチームとかに早めに対応してもらうなどの対応が必要。・テスト用資材の不足問題→例えばスマホアプリの場合、実機テストって必ず必要になりますが、実機が足りないとかありがち。SIMカード足りないってありがち（※「課金系のテストケースではSIMカードが必要です」っていう経験があります）。【テスト開始前にやっておきたいこと】・打鍵方法の確認→ジョブであればジョブやジョブネットの実行方法、オンライン処理であればcurlコマンドの使い方とか、が要確認だと思います。・エヴィデンスの取得方法→どのエヴィデンスを取得すれば良いのか確認しておきましょう。例：デバッグログ、エラーログ、システムログ、テーブルダンプデータ、出力ファイル、入力ファイル、スクショなど。・エヴィデンスレビューエヴィデンスレビューってあるのか要確認。・スタブ、ドライバの準備→スタブ作成って私はしたことがないのでよくわかりません。NGが出たときに原因がなかなか特定できなくて、実はスタブ原因でしたっていうのは避けたい。。・多重実行の方法例えばジョブの多重実行ってどうやるの？とか。【その他頭に入れておきたいこと】・テスト項目書を一項目ずつレビューの場で説明していくのは現実的でない。レビュアーとしては、項目書をバーッと見て、体裁チェックはできるだろうが、項目漏れがないかは確認しづらい。項目書をどのような観点で、何を元ネタにして作成したのかを説明するのが良い。その上で重要な箇所をいくつか抜粋して説明し、残りは回覧レビューとする、のが最も良い方法かな。・どの単位でチケット起票すれば良いか？→NGが出たときにテストケースごとにチケット起票する、なんてことはおそらくどのプロジェクトでもやっていないはず。どういう単位でチケット起票する思想なのかはキックオフとかで必ず認識合わせしないといけない。・定義ファイルの書き換えでサーバ要再起動？→定義ファイルを書き換えた場合、サーバの再起動が必要なのかどうかはケースバイケースです。・横展開確認→ひとつの不具合が検出された場合、他にもないか確認はしましょう（当たり前）。・テスト開始前に、発生するとしたらどういうエラーなのか、頭に描いておく→ある程度経験がないと難しいですが、エラーが出てから０から「えーっと、原因は何かな？」と探るのではなく、実施の前から自分の中で想定されるエラーを想定しておけば仕事が速くなりますよね。言うのは簡単ですけど、考える癖をつけることが大切。・テラタームのウィンドウの背景色→DBサーバ、バッチサーバーとか色々なサーバのウィンドウを立ち上げていて、背景色がデフォルトの黒だと、どれがどれだかわからなくなってきます。色を変えた方が見やすい。細かいことだけど、こういうことの積み重ねが大きな作業効率の差につながる。（といって、背景色を赤にして赤文字で表示されていたファイルを見落とす、という愚行をしてしまった。。）・排他取得エラーの発生のさせ方→BEGIN:SELECT FOR UPDATE;→打鍵→COMMITもしくはROLLBACK。・リリース申請→リリース申請誤りは結構気まずいことになるので、ダブルチェックしたいよね。（ちなみにトリプル以上のチェックはあまり効果がないと言われています。）・テストデータ作成は主に入力ファイルとテーブルデータ作成だと思うが、前者から行った方がいい気がしている。-----------------------総合テスト【行う主な業務内容】環境構築テストデータ作成テスト実施不具合修正【あるある】・環境構築がテストの中でおそらく一番大変。資産（jar、war、sh、xml、properties）配備の時、上層部や顧客の承認をとらないといけない。疎通確認も手順書を作成してきっちり行う感じ。・テストデータをテスト環境で作成するとなるとわりと面倒。ルール的にも基本的にはテスト環境のDBへのデータ直入れは最小限にして実施するイメージ。テストデータのレビューが入ることもあり得る。・PT、ITと比べてテスト計画が綿密に立てられる。・ITまでスタブ、ドライバでやっていた箇所での不具合発生。以上（気づいたことがあれば追記していこうと思います。）
