niki12260714の日記

フリーランスのITエンジニアの呟き。

ソフトウェアのテスト技法 6日目

テストの計画

スクリプトテスト、探索的テストは、それぞれテスト計画をする時期が違う。
早期に計画するか、テスト中に計画するかだが、どちらが良いという話ではなく、計画とは変化するものであり、それを忘れてはならない。
計画はあくまで予定であり、状況に応じて柔軟に修正するもの。
結構忘れがちなので、こうやって書かれることで改めて勉強になった。

支援技法

欠陥の分類

ここら辺、FLで覚えた気がする。
忘れている項目は業務で抜けているところなので、テスト設計書作る時に指針としてメモしておこう。
とはいえ、毎回全部おさらいしていたら時間もリソースも足りないので、そこらへんは運用を考えたい。

テストの終了判定

どこまでテストをすれば終わりか?
テスト担当者としては「不具合が十分におさまったところ」と思うが、不具合があっても出荷したい時があるのを忘れてはならない。
テスト担当者の目的は「製品を出荷するリスク情報を経営陣に提示する」ことであるのを忘れてはならない。

一巡したので、演習問題を解いていこうと思いましたが、解答がないのが不便なので、別のテキストを使用しようかと思います。
演習したら同じ単元を読み直すというやり方。
明日以降のブログは、演習の感想とか反省を書こうかと思います。

ソフトウェアのテスト技法 5日目

データフローテスト

変数を定義する前に参照する、破棄するといったバグ検出に役立つ手法。
他の手法でもそうですが、「何に注目するテストか」という観点を思い出せました。
あとこれは、開発していると体得するけど、ちゃんと理論として知っておくとRSpec等の実装で大いに役立つと感じる。

テストのパラダイム

スクリプトテストと探索的テスト。

スクリプトテスト

業務で使っているパラダイム
「誰が実施しても同様の結果を得られるテスト」として、共通認識を作るのに適している。
しかし実際、要件固めながら作っているのがほとんどの現在ではIEEE 829準拠のドキュメント作る時間はないですよね……
あと「このドキュメントは何に必要か」をテスト設計者が理解して無くてぼんやり作っているパターンとかも前の現場であったし、「誰でもが実施できる」が「誰でもが適切に設計できる」ではないのが注意。

探索的テスト

アドホックテストとは異なることに注意。
「テストケースを実施しながらシステムを学習し、テストケースの設計をコントロールする」というテストで、この定義だけだと分かりにくいけれど、本書で説明に使われた「20の扉」で理解できる。
「このシステムはどうあるべきか?」を考えられ、注意深く応答を読み取れる技術者でないと実施は難しい。
業務で行うなら、不定期に機能の一部に対して実施し、テスト技術者のテストスキル向上に使うのも良さそう。

テスト計画も少し読んだけど、また明日。
演習問題については、解答がないっぽいので、別の参考書をしようかなと検討中。

ソフトウェアのテスト技法 4日目

ユースケーステスト(昨日の続き)

例題を確認。
定義をした後に、実際にテストケースをどうやって抽出するかのお話。
トランザクションに注目するということで、例外処理のパスをどうやって通すかに言及され、ツールが紹介されていましたが、アクセスしたらNot Foundでしたよね……
ツール探しは別途必要。
また、実際の業務と比較しての反省は、境界値テスト、デシジョンテーブルに時間を多く割き、ユースケーステストがほぼ正常系のみに終わっているということに気が付いた。
本来はここも時間取ってケースを考えて取捨選択すべきなので、時間がとれる仕組みづくりを考える必要アリ。

ホワイトボックステスト技法

パスに注目する制御フローテストと、データフローテストがあるというお話。
制御フローテストのことしか覚えてなかったので、勉強しなおし。

制御フローテスト

コードカバレッジにだけ注目するのは危険だということをきっちり説明されていて、ここ反省。
ではどうやってフローを決めるかということで、「構造化テスト/基礎テスト」で取り方を知った。
今はほとんどブラックボックステストしかしてないし、コードを読むときもあるけど、変更箇所を重点的に読むにとどまり、「プログラム内部のフローに対するアプローチ」が徹底的に欠けていると気付いた。
RSpecで書かれている内容のチェックがコードカバレッジのみになっているので、テスト担当者がホワイトボックステストにどこまでアプローチすべきか、やはりここも仕組みを考えたい。
テスト担当者でなく、実装者にやってもらうことになるだろうけど、それならば実装者にどのように保証を貰うか。
品質保証の担当部門の位置づけにも関わってきそう。

データフローテストもちょこっと読んだけど、少しだけなのでまとめは明日。
やはりきちんとまとまった本を読むと、業務は手癖で作業していることが多いのに気が付き、ひたすら反省。
理想と現実の乖離の埋め方は永遠の課題なんだろうなぁ、お正月明けに相談したいところ。

ソフトウェアのテスト技法 3日目

状態遷移テスト

最近作ってなかったけど、今取り組んでいる業務で有用なことに気が付いた。
これもデシジョンテーブルと同じで、企画や営業の人と話すときに、分かりやすく説明できる。
対面だと紙に手書きで作ったけど、リモートだと手書きを見せるのは難しいから、なにかツールがないか探したい。

ドメイン分析テスト

JSTQBのFL受けた時にやったような気が?
業務でほとんど使ってなかったのはただ単に完全理解してないからですが、これ使っている現場みたことないな……
2値が関連する場合、デシジョンテーブル使って検証していたけど、今の理解ではドメイン分析との使い分けが良く分かってない。
通読2巡目でもうちょっと考え込む。

ユースケーステスト

UMLがなんとなく分かるようで分からないので、やっぱり業務で使ってこなかった。
が、テンプレートはシナリオテストのまとめとして使えそうなので、やはり通読2巡目でもう一度咀嚼したい。
ちなみにUMLが苦手なのは、どれがアクション、トリガー、アクターがそれぞれなにに当たるかが上手く使えないから。
ユースケーステストを作成するなら、もう1回UMLの基本を理解しなおす必要があると実感している。

技法としてはFL受けた時にやったような気が……というものがほとんど。
やはり定期的にこういうテキストを読み返して普段使わない技法を思い出すのは大切だなーという実感。

ソフトウェアのテスト技法 2日目

同値クラステスト、境界値クラステスト

条件の範囲のお話。
業務で毎日のように使っているので、改めてテストの定義を理解しなおし。

デシジョンテーブルテスト

テスト設計者にはおなじみの奴ですが、業務で書くと意外に驚かれる。
あとこれをもって企画の人に仕様確認をすると、やはり驚かれ、重宝がられる。
仕様整理の時に使うようにフォーマット作っても良いかもしれない。
ただこれは、条件がぬけないように作るのが肝要なので、仕様が未確定で作ると穴が沢山出てきて作り直しになる。
また実際の実務だと条件が大量に出てきて、表が巨大になりがちなので、見やすくする工夫を考えたい。

ペア構成テスト

数学が苦手過ぎて、直行表の理論が完全理解できないのが辛い。
なんとなくの理解でやっているので、実務で使う意識が最近抜けていた。
せめて、All pairのツールを使ってケース抽出を網羅することを意識しなおしたい。

今日の範囲は、ほとんど実務で使っている個所なので、大体知っていた。
ので、本の内容から業務の反省にシフトしているw
演習問題は、一回通読が終わってからやろうと思う。

ソフトウェアのテスト技法 1日目

アウトプットして記憶定着を狙った記事なので、特に有益な内容があるかは不明。
自分にはある。
そして回答があっているかは分らぬ。

1章演習問題の解答

int bleach(int j){
 j = j -1; // 正しくはj = j+1
 j = j / 30000;
 return j;
}

期待値とずれる値は30000の倍数。

入力値 期待値 結果
1 0 0
30000 1 0

境界値チェックだけに頼ったらダメだよね、という例。

ブラックボックステスト

ある意味、実装者の性善説に頼るテストだということと、テストが通らないコードがあるかどうかの判定がむずい。

if (age == 42 && name == 'LEE'){
  // 巨額の報酬を振り込む
}

こんな風に埋め込まれたバグ、ブラックボックスだけやっていたら絶対に見つからないwww

同値テスト

まだ途中。
複数の条件が集まってきたとき、さてどうするというお話に繋がる。

ところで、はてなブログってMarkdown使えたんですね、とっても便利!
お陰で書きやすくなった!

Railsでタグのオプションにif文使いたい場合

参考にさせていただきました。

qiita.com

まんまこのままですが、三項演算子も勿論使えたので。

<%= f.text_field form: "#{条件式 ? '値1' : '値2' }" %>

 オプションが文字列になるものはいけそうです。