skillup

技術ブログ

ドキュメント作成

テスト仕様書の必要な項目の定義など(横項目の定義)

投稿日:

前回はテストの項目をどのように作るか(分類するか)だったんですが、今回はテスト仕様書などを作る際に必要な項目の定義をまとめてみようかと。

テスト仕様書を作るとしたら前回は縦(バリデーションの組み合わせをどう作るか、ロジック表をどう作るか)だったんですが、今回は横の項目ですね。便宜的に横項目と呼ぶとします。

横項目存在意義

テスト項目所など、Excelで作ることが一般的だと思いますが、フィルターして項目数を数えたりする、最初の段階で大きく切り分けたりするときに、項目同士の掛け算で作った方が便利だから・・などが挙げられると思います。

カテゴリ(画面単位、API単位)×テスト種別(正常系か異常系かなど)×具体的な項目内容(バリデーション、基本的なロジック)・・・・など

横項目切り分け観点

カテゴリ

まずその項目がどのカテゴリーに属性しているかです。

画面であれば、画面単位、API単位であればAPI単位ですね。言われなくても作りますかね・・・・場合によっては大カテゴリ、小カテゴリなど複数のカテゴリに分かれるかと思います。

テスト種別

異常系か、正常系かなどですね。

異常系に分類されると物としては、通常のバリデーションやその他、NG判定になるもの、例外エラー(DBエラーなど)などでしょうか。

細かい分類では正常系と準正常系なんて分類もあり、後者はバリデーションやNG判定など通常の仕様通でNG判定が出るもののようです。(この場合の異常系というのはDB接続エラーなどは使用想定外のエラーになります。)

「正常系」・「準正常系」・「異常系」テストについて、まとめてみました。

テスト内容

具体的に何をテストするのか、一言でまとめてもいいかもしれないです。

例、〇〇のバリデーションなど

テスト手順

具体的にどのような動作を踏まえてテストをするかなど、番号付き箇条書きで表記されることが多いと思います。バリデーションやN×Mなど機械的かつパターンが多いものはマトリックス表にしたほうが勘弁かと思います。

個人的にはスキルが結構出る部分かと思っており、簡略化させる方法は色々とあるのでは・・・と思っております。(事前データプラスSQL入れられればベストですかね・・・)

機体動作

どのように動いたらOKと言えるのか、これもまあ普通に書きますかね。

証跡

いわゆるエビデンスです。個人的には色々と工夫できると思っております。

コストがかかるケースは1つ1つのスクショですね・・・やってて気持ちが沈む作業の1つかと思います。

対策としては

  • バリデーションなどの時はまとめて(できるだけ少ないケースで網羅を考える)スクショを撮る
  • SeleniumやJSのライブラリを使う(運用コスト結構あります)

ですかね・・・個人的には運用コストの少ない自動マクロみたいなものをブラウザに覚えさせるのが一番かと思います。

スクショ以外にはログですかね。これはコマンドラインですので、色々と簡略化できるポイントが大きいのではないかと思います。

その他事務的な項目

これ以降は工夫の余地があまりないですけれども、

結果、日時、やったひと、検証したバージョンですかね・・・・

 

-ドキュメント作成
-,

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

コレクションの頻出処理に関して

PHPでコレクションを使っていますが、慣れると本当に便利ですね・・・まあforeachとかでグリグリやってもいいのですが、無駄にコードが長くなります。 自分がコレクションでよく使う再頻出のメソッドなど …

no image

業務管理アプリの商品コードに関して

一般的な業務管理アプリを作っていると商品や顧客などもオートインクリメントのidではなく、独自の仕様で決められた「商品コード」などを持っていることが一般的です。 昔通販がらみのシステムを使っている時も商 …

no image

設計業務での改善点など

比較的大規模なプロジェクトの設計段階で思ったことなど。会議など頻繁に開かれると思いますが、聞いているだけだったり、各人が色々なことを喋って内容がまとまっていなかったり・・結局何をやりたいかわからなくな …

no image

アジャイル開発について

エンジニアとして仕事をしてから7〜8年立ちましたが、その間9割近くはいわゆるアジャイル開発でやってきたと思っていました。今は比較的大規模な開発をしておりますので、ウォータフォールですが・・・ が、先日 …

no image

レビューについて

以前、コードレビューそのもののポイントについてはコードレビュー時のポイントでまとめましたが、レビュー自体の体制の注意点やそこでの気づきなど。 Contents1 目的2 定型的なものはチェックリストを …

アーカイブ