96. テストの目的 その⑧

96. テストの目的　その⑧

 これでテストの目的は最後です。

最後にもう一度一覧を出しておきますね。

• 欠陥を防ぐため、要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
• 明確にしたすべての要件を満たしていることを検証する。
• テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
• テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
• 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
• ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
• 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。

このテストの目的が、自分たちのテストに全て当てはまるわけではありません。

そしてどれか一つ、ということもなく複数の目的が含まれるかと思います。

ただ「バグを出す！！」とか「仕様通り動いているかチェックして終わり」とかではなく、自分たちの行っているテストは今何を目的として行っているか、を意識してみましょう。

何となくやっていて「なんでコレやってるんだろう……」なんて目的がわからない場合は……実はテストではなく、ただ触ってるだけかもしれませんよ！

目的を意識する

これはテストだけではなく、仕事もそうですし、自分の人生にだって言えるかもしれません。

【紙の本/電子】同人誌版テスターちゃん6巻頒布開始！

同人誌版テスターちゃん6巻の紙の本/電子書籍(pdf)の頒布をBOOTHで開始しました！

testerchan.booth.pm

紙の本は送料込みで600円です。

電子書籍は500円です。

書籍版1巻または同人誌版5巻からの続きのナンバーです。

テスターちゃんは続きといっても、全部の本を話が完結するところでまとめているのでどこから読んでも良いのですけどね！

ちなみに書籍版1巻は同人誌版1～5巻の本編のみをまとめています。

なのでJaSSTやテストラジオといったオマケのお話が入っていなかったりします(^-^;

さて。

6巻の話の内容は、テストの基本的な考え方である以下です。

• チェッキング・テスティングの考え方
• テストの目的

もちろん他「在宅業務」などのサイドのお話も入っています！

6巻から紙の本はA5サイズに変更しました。

書籍版と同じサイズです。

前までB5だったのですが、B5サイズは一般的にはマイナーで……。

カバー的なモノもなかったりするんですよね(汗)

95. テストの目的 その⑦

95. テストの目的　その⑦

テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する

テストの目的の最後7つ目が「テスト対象に対する信頼を積み重ねて、所定のレベルにあることを確証する」。

ｘｘのテストは通った。

〇〇のテストは通った。

etc, etc……

これを積み重ねることによって「全体としてこういうテストが全部通ってるので大丈夫」となるわけである。

けどマンガにも描いた通り、ただテストをたくさんすれば信頼が上がって「もう大丈夫！」といえるわけではない。

「所定のレベルにある」がわかるためにはそもそもその「所定のレベル」がどこかがわからないとダメですよね。

そのためには、どこでどうテストをしていけば全体的にOKっていえるよね、といったものを作らないといけない。

それを全部クリアしたら想定した（所定の）レベルには達しているという考えだ。

（もちろん想定外の部分出てきて、決めたテスト計画だと「これ本当に大丈夫？」となることもあるけど、その時は計画を見直そう）

テスト計画をもっと気軽にやろう

こういった計画の話をすると

「ウチはアジャイルだし計画を立ててる時間なんてない」とか

「どうせ計画通りいかないからいらなくない？」とか話が出たりする。

そういう人は以下を見てみよう。

94. テストの目的 その⑥

94. テストの目的　その⑥

テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする

JSTQBで書かれているテストの目的の6つ目はタイトルの通り。

妥当性確認は、成果物やサービスが意図された使い方や用途を満たしているかの確認です。

システムは「～したい！」という要求があって、それをどうシステムにするか……と考え要件、そしてより細かい仕様に落としていきます。

その大本の「～したい！」がちゃんと実現できてるんだっけ、という部分の確認です。

作者は妥当性確認はシナリオテストを用いることが多いです。

例えば社内の部署で使う業務システム。

その部署での業務フローがあったりしますよね。

あと想定されているシステムの使い方とか。

それをシナリオにして、ちゃんと運用を満足できるか（やりたいことができるか）の確認です。

もちろん運用は一本道ではなく、日々使うなら様々なイベントが発生したりします。

そういったところもできるならシナリオにして確認したりします。

こういうことをすると各機能単体で見てると良さそうだったのに、

「みんなエクセルで開くから、CSVの文字コードはshift-jisでないとダメ」

とか

「何百回も繰り返す登録作業なのに毎回ハンバーガーメニュー開いて呼び出しなの！？」

「夜間作業のメンバーに伝言を残すメモ欄、改行が反映されないの見づらい」

といったユーザビリティまで、実業務ならではの問題点が出てきたりするわけですね。

検証と妥当性確認の違い

テストの勉強をしているとV&Vという言葉に出会ったことがあると思います。

きゅんちゃん設定画

きゅんちゃん設定画

今回はテストのお話はなし。

絵の練習がてら設定画を描いたので載せておきます。

夢はでっかくアニメ化ですよｗ

さて、以前もきゅんちゃんの設定を書きましたが、せっかくですのでwikipediaの内容も加えて書き残しておこうかと思います。

93. テストの目的 その⑤

93. テストの目的　その⑤

 明確にしたすべての要件を満たしていることを検証する。

要件を満たしているかの検証は、テストの中でも最も共通している目的の一つ。

3コマ目でも描いたけど、もっとも重要な活動です。

これは基本中の基本であり、確認するのはもう当たり前という感じ。

で。

それを確認するのは当たり前として、他に何かないか考えましょうといったことを描かせてもらいました。

全てが全て仕様書に書いてあるならそれでオッケーかもしれません。

けどまぁそうもいかないのが世の中でございます。

92. テストの目的 その④

 92. テストの目的　その④

 欠陥を防ぐため、要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。

JSTQBの2018V3.1.J02に書かれているのは上の通り。

V3の最初は「欠陥の作りこみ防止の話」と「作業成果物の評価（レビュー）の話」が別々だったけど、今はマージされていますね。

「欠陥の作りこみ防止」については、レビュー、つまり静的テストを行うことによって欠陥を防ぐ、というのがあります。

シフトレフトというやつですね。

あとはマンガに描いた通り、継続的な開発においてはこれまでのテストの情報、中でもバグの情報をレビューに活かすことができます。

91. テストの目的 その③

91. テストの目的　その③

 ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。

 JSTQBに書かれている言葉としては上の通り。

テストをしないと

「これホント大丈夫なんだっけ…。ちゃんと動くんだっけ…。不安だ。けどエイヤで出すぞ！」

といったところ。

それがテストをすることによって様々な情報が「見えてくる」わけです。

自分たちが考えている使い方だとバッチリ動作することがシナリオテストでわかったとか。

負荷テストを行って、今までの最大アクセス数までは全然余裕で動くことがわかったとか。

セキュリティテストを行って、よくあるような脆弱性の心配は解消されてるとか。

実はオプション画面で繰り返し変更かけると1/100くらいで設定失敗するとか。そこ原因わからなくて直してないとか。

こんな感じで、テストしないときは漠然と「不安だ～」と思っていたことが、テストによって

90. テストの目的 その②

90. テストの目的　その②

欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する

「バグの発見」と書いたけど、シラバスに書かれている文章は上記の通り。

バグを見つけて、それを修正することで市場に出たときのリスクを軽減することができます。

「おいおい、見つけまくって全部直すのかよ！？」みたいに言う人もいるけど、これはまた別の回の「ステークホルダーへの意思決定のための情報提供」の話でやろうとも考えています。

先出しすると、見つけたバグについては「こういうリスクがあるよ」ということがわかるわけです。

そのうえで、どこまでリスクを許容するのかという考え方もあります。

「これだと大きなリスクはないし、次のスプリントで修正」ってことも全然ありなワケです。

けど例えばカーナビみたいな市場に出た後直せないやつだと、次、がなかったりもします。

ユニットテスト、統合（結合）テスト、システムテスト段階ではなるべく多くのバグを見つけまくる、がどのみち幸せかと思います。

そして修正することで市場に出たときのリスクレベルを下げることができます。

89. テストの目的 その①

89. テストの目的その①

テストを行う目的

JSTQBのFLのシラバス(2018V3.1.J02)に記載されているのは以下の７つ。

• 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
• 欠陥を防ぐため、要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
• ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
• 明確にしたすべての要件を満たしていることを検証する。
• テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
• テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
• 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。

2011年版のシラバスだと記載は以下の4つだった。

• 欠陥の検出
• 対象ソフトウェアの品質レベルが十分であることの確認
• 意思決定のための情報の提示
• 欠陥の作りこみ防止

ベースは2011年版の4つだけど、それらをより詳細に書き表したのが新しいバージョンといったところ。

テスターちゃんでは新しい方でお話を描いていくつもり。

ちなみに2018年版の最初は9つだったけど、まとまるところがまとまって7つになったようだ。