【ゲーム感想】ペルソナ４ザ・ゴールデン（P4G) クリアしました

前回の記事（【ゲーム感想】ペルソナ４ゴールデン（P4G）をはじめました - 底辺過ぎてちょっとビビる）からだいぶ経ってしまいましたが、クリアしてしまいました。

前回はインプレッション的な記事だったんだけれども、今回はクリアしたのでちょっと全体的な感想なんかも書いていきたいと思います。例によって？これからplayする人のためにもネタバレは基本的「なし」の内容です。

※ちょっと長めの記事です。ダラダラとすみません

※ペルソナ４の登場キャラクターたち

【詳細設計書】参照すべきドキュメントが多すぎる問題

今のプロジェクトでテスト仕様書を作成し続けてしばらく経つ。
基本的に、テスト仕様書は詳細設計書に書かれている仕様をベースに作成しているので、
そこに記述がないものについては、「そういう仕様ではない」ということでテスト仕様書には記述しない。

たとえば各項目の活性非活性に関して、

• Aというチェックボックスにチェックが入っている状態だと、Bというボタンは押せない
• Cというラジオボタンにチェックが入っている状態だと、Dというテキストボックスは入力不可

などという部分は設計書に記載があればテスト仕様書に挙げられるが、なければ当然スルーされる。で、実際にテスト消化の際に、
「ここにチェックが入ってると、このボタンが押せません」とか
「ここのラジオボタンにチェックを入れていると、このテキストボックスには入力できません」とか上がってくる。

実際のアプリの挙動と仕様書を見比べて、アプリ側の挙動を「正」とするかどうかは微妙なので
一応確認するのだが、大体仕様書に記述が足りていないことが原因で、結局テスト仕様書を修正することになる。
(というか、制御に関する網羅的な表もなくて作ってる側は混乱せんのか）

これくらいならアプリと仕様書を見比べるだけで済むのでそこまで苦労はないのだけど、
実際は仕様変更という名のもとに、仕様書とは別のファイルが存在し、そちらも確認しなければいけないので手間が倍になっている。

1. 今年春の段階で凍結した仕様書と
2. 設計バグ等が見つかったことにより、ページ単位で修正の入ったドキュメント

これらが別々のSubversionに置いてある。
現状のアプリは「春までに凍結された仕様書通りに作られている部分」と
「修正の入ったドキュメントで作り直された部分」が存在していて
テストを実施した際にテスト仕様書の期待値（確認項目）と差異が出ているのはどちらのドキュメントに対応しているのか探さなくていけない。

この、修正の入ったドキュメントというのも、「5/10時点」で見つかったバグ対応の修正と「6/15時点」で見つかったバグ対応の修正では
ドキュメントが別なので、それぞれ見比べなくてはいけない。

・・・なぜ仕様書にそのまま修正を反映してくれないのだろうか...

実装する人からすれば、修正箇所のみをピックアップしたようなドキュメントなので
どこをどう修正するかわかりやすい、ということなのかもしれないが...

しばらくテスト仕様書の準備作業は続くし、今後はテスト結果のチェックも必要になってくるわけだけど
バグ修正も延々続いていて、そのたびに仕様変更ということでドキュメントが増えていくのだろう。
頭痛い。

見るべきドキュメントはなるべく少なくすべきなんじゃなかろうか
おそらくリリース後にドキュメントの整理というタイミングで今あるバラバラのドキュメントと仕様書を統合していくのだろうけど。
（本来は統合したいのだけど、修正が多すぎて中途半端な状態で設計書として統合出来ないんじゃないかと思う）

工数、という部分を重視しすぎておかしなことになっている気がする。
優先すべき作業を置いておいて、とりあえず当初のスケジュールを尊守すると言う形になっているように見える。

実際、テストの工数ってプロジェクトにおいてもわりと割かれているはずなんだけど
こういう無駄な作業のおかげで手間ばかりかかっている。そりゃ、スケジュール通りに進まんわ。

組込みソフトウェア開発のための構造化プログラミング

研修プログラム開発の基本 ~トレーニングのデザインからデリバリーまで~ (ASTDグローバルベーシックシリーズ)

はじめての設計をやり抜くための本 概念モデリングからアプリケーション、データベース、アーキテクチャの設計まで (エンジニア道場)

【Oracle】DATE型をWHERE句で比較するときの注意点

今日たぶん人生で初めてDATE型のデータをSQL文のWHERE句の条件で使った気がする。

比較条件の使い方を完全に勘違いしていたので、メモ書きとして
今後のために残しておく。

ピンポイントでSTART_DATEが2017-6-29のレコードが取得されるように、
こんなSQLを書いた。

SELECT
*
FROM
TABLE_A
WHERE
START_DATE = '2017-06-29';

START_DATEはDATE型で定義されていて、実際にレコードには「2017-06-29」というデータが入っているのだけど、
いくら実行しても、結果は表示されず。

なんでだろう～、と思ってググったところ
そもそもDATE型は「＝」で結ぶような比較は出来ないということが判明した。

では、どうやって比較すればいいのか。

その前に、DATE型に格納されている値について確認しておく。
表示上、「2017-2-29」とされていても実データの方には、
「2017-2-29 00:00:00」といった感じで時分秒まで格納されているのだ。

ということを踏まえると前述のSQLの場合、

SELECT
*
FROM
TABLE_A
WHERE

START_DATE > TO_DATE('2017-6-28', 'YYYY/MM/DD')
AND START_DATE < TO_DATE('2017-6-30', 'YYYY/MM/DD'); 

という、SQL文になる。一旦、TO_DATE書式を使って、書式をそろえる。
（実際はいちいちTO_DATE書式に揃えずとも問題ない）

時分秒まで指定したい場合は、

  TO_DATE('2017-6-29 12:12:12', 'YYYY/MM/DD HH24/MI/SS');

のように記述する。

DATE型の比較については、BETWEENを使う方法もある。
範囲で検索結果を取得したい場合に有効。

以下の場合、2017-6-28の00:00:00から2017-6-30の23:59:59までに該当する
レコードが検索結果として取得される。

 START_DATE BETWEEN TO_DATE('2017-6-28', 'YYYY/MM/DD') 
 AND TO_DATE('2017-6-30', 'YYYY/MM/DD') 

※間違えていたらぜひ指摘してください('ω')ノ

スッキリわかる SQL 入門 ドリル215問付き! (スッキリシリーズ)

達人に学ぶ SQL徹底指南書 (CodeZine BOOKS)

徹底攻略 Java SE 7/8 Bronze 問題集[1Z0-814]対応

結合試験が始まって、いろいろ思ったこと

先日、結合試験用に作成を続けていたテストシナリオが完成した。その前に作成の終っていた各画面単位のテスト仕様書とDBダンプ作成のための画面単位のDB確認書をもとに結合テストを実施してもらう手はずであった。つまり結合テストを実施するうえでの仕様書は以下のようにまとまっている。

• 結合テスト用シナリオ
• 各画面単位のテスト仕様書
• DB確認書

ボリュームとしてはこんなもんだろう、という印象。不明な点は詳細設計書やテーブル定義書を確認してもらえばよい。

今更遅いのだけど、もっとシナリオを作成する段階で画面単位に作られたテスト仕様書をよく確認しておけばよかった。というのも、いざ結合テストが始めってみてわかったのだけどとにかくテスト仕様書に不備がめっちゃ多いのだ。

結合試験の準備がなかなか終わらない

スケジュール上ではすでに結合試験が始まっているはずなのだけど、いまだに準備が終わらない。これは、単に結合試験の準備が遅れているからというだけではない。単体試験の結果が芳しくないのがそもそも...という状況が大きい。単体試験を進めるたびに

• 仕様バグ
• プログラミングバグ
• 仕様漏れ

が、ワラワラ出てきて詳細設計書の修正をしている最中だからだ。