テストする人。

ソフトウェアテストってわかんない。テストとQAのゆるゆるブログ。

リナ流テスト設計方法 4 バックエンドが入るようなところの設計のやり方

adventar.org

17日目です。
毎年ひとり完走アドベントカレンダーを書いているんですが、今年は仕事関連以外のことをあまりできていないので仕事ネタにしました。

🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄🎄

リナ流設計方法

www.jasst.jp

で話した話をもうちょっと切り取って書こうかなというお気持ちになったのでちょっと考える

長くなりそうだったら途中でやめるかも。

この書き方は自分がむかしっから書いている基本スタイルです。 前提として、私は画面を操作するようなシステムやサービスのテストをすることが多いです。

カテゴリーとしては大きく3つあります。

  • デフォルトの表示系
  • 動作系でもバックエンドの操作がないまたはほとんどなさそうなもの
  • 動作系

バックエンド・つまりロジックや更新・画面遷移などもりもり

もりもりすぎてわけるかも

  • 仕様書が書いてあるなら、一旦?上からまずはうつす(いわゆるCPM法と言われていた方法。大体良くないと言われる方法です)
  • 日本語を噛み締める だいたい噛み締める必要があるものは、絵を描きたくなってくる ここで仕様の検討不足(仕様バグと呼ばれたりもする)がでてくるので、PMに確認する

  • うつそうとすると、日本語なんか整理されてそうでされてないところにでくわす

  • ひとまず仕様は一番シンプルな大きさに分解する
  • その次に組み合わせ(複数同時に実行されうる)を一番シンプルな大きさで書く
    ** だいたいそのときにデシジョンテーブルをつくる

  • テストデータの作り方などの疑問がでてくる エンジニアに相談する

  • いけるかなと思ったら一旦おわり  だいたいいけてないことがテストするとでてくる