単体テスト、観点リストを作成します。 行うことはshowModalWindowで書かれたIE専用の箇所をEdgeで表示するためにwindow.openで書き直した所の修正テストです、子画面で開くのはカレンダーです、子画面で日付をチェックして、設定を押すと親画面の該当フィールドに値を表示させます、この場合の単体テスト、観点リストはどうなりますでしょうか まずIEから書き出して、それからEdgeの場合を記載しようと考えています 単体テストや観点ではプログラムの内容は特に気にする必要はなく、チェックした値が入力フィールドにセットされること、子画面が親画面の後ろに行かないこと、子画面を開いている間、親画面の操作ができないこと、という動作です、後気になるのはそのフィールドが検索や登録、更新時に、検索値や登録値としてデータベースの条件になるかどうかですが、これはvalue値で入るから表示されているので確認は不要なのかと考えています。
単体テストと観点リストの作成について、まずIEとEdgeそれぞれに対して考慮する観点を整理することは重要です。特に、window.openを使った子画面(カレンダー)の挙動や親画面との連携に関しては、IE特有の動作からEdgeへの移行時にどのように動作が変わるかがポイントとなります。
単体テスト項目
IE専用箇所のテスト
- 子画面表示の確認:
showModalWindow
を使用して、カレンダーを子画面として正しく表示できるか。 - 親画面のフィールド連携: 子画面で日付を選択し、設定を押した時に、親画面の該当フィールドに選択した日付が正しく入力されるか。
- 子画面のフォーカス確認: 子画面が親画面の後ろに行かず、常に親画面より前面に表示されるか。
- 親画面の操作制御: 子画面が開いている間、親画面の操作ができないこと。
- 親画面への反映タイミング: 子画面で「設定」を押した時にのみ、親画面のフィールドに値が反映されるか(子画面が閉じた際に自動的に反映されないことを確認)。
- 子画面表示の確認:
Edgeでの修正箇所のテスト
- 子画面表示の確認(window.open): Edgeで
window.open
を使用して、カレンダーを子画面として正しく表示できるか。 - 親画面のフィールド連携(window.open): 子画面で日付を選択し、設定を押した時に、親画面の該当フィールドに選択した日付が正しく入力されるか。
- 子画面のフォーカス確認(window.open): Edgeでも、子画面が親画面の後ろに行かず、常に親画面より前面に表示されるか。
- 親画面の操作制御(window.open): 子画面が開いている間、親画面の操作ができないこと。
- 子画面表示の確認(window.open): Edgeで
共通項目(両ブラウザで確認)
- 日付のバリデーション: 子画面で選択可能な日付のバリデーション(正しいフォーマットの日付が選択されること)。
- フィールドに正しく値が設定されるか: 親画面の該当フィールドに選択した日付が正しく設定され、意図しない値が入らないか。
- エラーハンドリング: 子画面で異常な日付(未来の日付や過去の日付など)を選択した場合に、親画面のフィールドに適切なエラーメッセージや処理が行われるか。
データベースの条件との連携確認(オプション)
- 入力値が検索条件として反映されるか: 親画面のフィールドに入力された日付が、検索や登録、更新の際にデータベースの条件として正しく反映されるか(
value
で設定されているため、通常は問題なしとして確認は不要の可能性が高い)。
- 入力値が検索条件として反映されるか: 親画面のフィールドに入力された日付が、検索や登録、更新の際にデータベースの条件として正しく反映されるか(
観点リスト
子画面の表示に関する観点
- 子画面が適切に表示されるか(IE、Edge双方で確認)。
- フォーカスが子画面にあり、親画面が操作できないか。
親画面と子画面の連携に関する観点
- 子画面で選択した日付が、親画面のフィールドに正しく反映されるか。
- 子画面の閉じるタイミングや「設定」ボタンの押下時に正しく値が送信されるか。
ブラウザ依存の動作
- IEでの
showModalWindow
と、Edgeでのwindow.open
の動作に差異がないか。 - 特定のブラウザ(Edgeなど)でのポップアップ制御が正常に動作するか。
- IEでの
UI/UXの一貫性
- UIがIEとEdgeで一貫して表示されているか(特にボタンや入力フィールドの位置やスタイルなど)。
- 操作感が同一か(クリックイベントやフォーカスの移動など)。
結論
- プログラムの内容自体に着目する必要はなく、動作が正しく行われるかがポイントです。
- 特に、子画面と親画面の連携、親画面の操作制御、データベースとの値の連携が重要な観点となります。
なるほど、プログラムの内容自体に着目する必要はないということがわかりました、データベースとの値の連携は気になる所です、strutsで動いていて、idのセットはどうも必要なくIEで解釈されるようなのですが、Edgeでは解釈されるstyleIdとしてjspでセットしたりしているので正しくそれがデータベースの値として反映されるのか気になる所です、メニューとして50画面ほどあるのですが、1画面だけでも行えばいいと考えています
プログラムの内容に着目する必要がないとはいえ、データベースとの連携はやはり重要な確認ポイントとなります。特に、StrutsとJSPでIDをセットし、データベースに正しく反映されるかという点は、IEからEdgeへの移行時に影響が出る可能性があるため、単体テストに組み込むべきです。
データベース連携に関する追加テスト項目
IDのセットに関するテスト
データベースとの連携確認
- 入力されたIDが正しくDBに登録されるか: 親画面のフィールドに入力された値(子画面から設定された値)が、データベースに正しく登録されることを確認。
- データベースからの値が正しくフィールドに反映されるか: データベースに保存されたIDが、次回画面読み込み時に正しく親画面のフィールドに表示されることを確認。
- 検索時の動作確認: 入力されたIDが検索条件として正しく適用され、期待する結果が得られるか(検索結果としてデータベースの値が正確に反映されるかを確認)。
メニューとして50画面ある場合の対応
テスト対象の選定
- すべての画面をテストするのは現実的でないため、代表的な1画面を選定してテストするのは賢明な方法です。
- 特にデータベースとID連携が複雑な画面や、カスタム処理が多い画面を優先的に選ぶと良いでしょう。
- すべての画面をテストするのは現実的でないため、代表的な1画面を選定してテストするのは賢明な方法です。
他画面への適用確認
- 1画面で確認が取れた後、他の画面にも同様の処理やIDセットの方法が使われているか、設定が共通化されているかを確認します。
- 共通部分が多ければ、1画面のテスト結果を基に他の画面への適用確認が簡素化できる可能性があります。
- 1画面で確認が取れた後、他の画面にも同様の処理やIDセットの方法が使われているか、設定が共通化されているかを確認します。
エッジケースのテスト
- テストする画面を1つに絞る場合、その画面がIDの連携や入力バリデーション、特殊な条件(例えば、IDが未セット、または無効な値の場合)に対するエッジケースを多く含むかどうかも確認するべきです。
結論
1つの画面でIDのセットおよびデータベース連携が正常に動作するかを確認し、その結果を他の画面にも適用できるかどうかの方針は理にかなっています。特に、StrutsやJSPの処理が異なるブラウザ(IEとEdge)で問題なく動作するか、IDやデータベース連携の部分で異常がないかを詳細に確認することが重要です。
対象画面の洗い出しはどうしたらいいでしょうか、プログラム修正の場合、jspでカレンダーの箇所クリック時の関数より対象の画面を割り出しましたが、抜けがあると考えています、仕様書からカレンダーボタンがある箇所を洗い出すことになるのかなあと考えています
対象画面の洗い出しについて、以下の手順を踏むと、効率よく抜け漏れのない画面の特定ができるでしょう。特に、JSPでのカレンダーボタンやそれに対応する関数が多岐に渡る可能性があるため、手作業での確認だけでは抜けが生じやすいです。プログラムと仕様書の両方を活用した多角的なアプローチをとるのがよいでしょう。
1. 仕様書からの洗い出し
まず、システムの機能仕様書や設計書を確認し、カレンダー入力が関連する画面や機能の一覧を作成します。
- カレンダーボタンが使われている画面、またはカレンダー入力が必要なフィールドが含まれる機能を仕様書からピックアップします。
- 設計書には画面ごとのUIや操作方法、入力項目の説明が含まれているため、そこから該当箇所を探し出します。
画面遷移図などがある場合、カレンダー入力が関連する遷移先や親子関係を確認して、関連する画面も合わせて特定します。
2. プログラムコードからの洗い出し
仕様書の確認だけでなく、プログラム側からのアプローチも並行して行うことで、より確実な洗い出しが可能です。
#### a. JavaScript関数の調査
- カレンダーボタンをクリックした際に呼び出されるJavaScriptの関数名を特定し、これが定義されているJSPファイルや関連するスクリプトを検索します。
- onclick
やaddEventListener
などでバインドされている部分を確認し、どの画面でカレンダー関連の関数が使われているかを調べます。
- IDEの検索機能を使って、カレンダーボタンが使用されている箇所を検索し、該当する全画面をピックアップします(例えば、calendar
やshowCalendar
といった関連するキーワードで検索)。
#### b. JSPファイル内のHTML要素の調査
- カレンダー機能を持つボタンや入力フィールドのHTMLタグを特定し、そのタグ(例: <input type="button" class="calendar-button">
)を含むJSPファイルを検索します。
- JSP内でカレンダーボタンやカレンダー関連のUI要素がどこで使用されているかを網羅的に洗い出すために、HTMLタグに特定のクラスやIDがついている場合は、それを基に検索します。
3. 既存ログ・コメントからの情報収集
- 過去に実行された操作ログやエラーログが残っていれば、それらを確認してカレンダー機能が使われている画面の特定に役立てることもできます。
- コードコメントや過去の開発メモ、他のメンバーからの口頭のフィードバックなども活用し、見逃している可能性のある画面を洗い出します。
4. テストケースの再利用
5. ユーザーフィードバックの活用
- 最後に、もしシステムが運用中であれば、実際に使用しているユーザーや運用部門に確認を取り、カレンダー機能がどの画面で使われているか、抜けがないかをヒアリングする方法も考えられます。
結論
仕様書の確認とプログラムコードの検索を組み合わせることで、抜け漏れを最小限に抑えつつ、カレンダーボタンやカレンダー機能が使われている画面を特定できます。具体的には、JavaScript関数やJSP内のHTMLタグを検索し、該当箇所を全てリストアップした上で、仕様書やテストケースからも確認を行うと、抜け漏れの少ない洗い出しが可能となります。
まとめ
はい、伝わっているようで良かったです!テストを成功させるには、何をテストするかの理解が重要ですね。そして、テストケースの分類をどのようにするかを慎重に検討することで、効率的で網羅性の高いテストが可能になります。
分類方法として検討すると良いポイントをいくつかご提案します。
1. 操作の種類ごとの分類
- 操作ごとに分類することで、ユーザーの実際の操作手順に基づいたテストケースが作成でき、現場に即したテストになります。例えば、以下のような操作をベースに分類します:
- カレンダーボタンの押下
- 前月・次月ボタンの押下
- 日付の選択
- 各操作に対応する確認結果をまとめることで、操作と結果が対応しやすくなります。
2. 画面ごとの分類
- 画面ごとのテストケースで分類するのも効果的です。画面によって異なる操作やデータ条件がある場合、それぞれの画面に対するテストケースが整理されます。
- 例えば「検索」「登録」「更新」などの画面単位で分類すると、特定の画面で必要な確認が分かりやすくなり、テストの抜け漏れも防ぎやすくなります。
3. 状態のタイミングごとの分類
- テストを「表示前」「表示時」「表示後」のような状態やタイミングごとに分類するのも有効です。特に、操作前後で確認すべき内容が異なる場合、タイミングごとにチェックポイントを明確に分けると良いでしょう。
- 例えば、カレンダーボタンの押下前後でUIの状態が変わることを確認するテストケースを含めると、視覚的にどの時点で何を確認するかが明確になります。
4. データ条件の有無による分類
- データの有無によってテスト結果が変わる場合、データ条件を軸にした分類も重要です。データの有無による操作の影響を確認するため、例えば以下のようなデータ条件でテストケースを作成できます。
- 出力データありの場合
- 出力データなしの場合
- 特に、データがない場合の例外処理やエラーハンドリングの確認が必要な場合、この分類が役立ちます。
5. 確認内容ごとの分類
- 各テストケースで何を確認するかを軸にした分類も考えられます。例えば、タイトル表示、色変更、データベース連携など、確認する内容ごとにテストケースを整理すると、結果の整合性が確認しやすくなります。
結論
操作の種類、画面ごと、状態のタイミング、データ条件、確認内容といった複数の軸を組み合わせて分類すると、特定の目的に応じたテストが整理されます。これらを組み合わせて分類することで、テストの意図が分かりやすくなり、網羅性も高まるでしょう。