悩みごと
作者の考えではありますが、悩みごとはマンガに描いた通り「思い通りにならないこと」を頭の中でグルグルさせているんだと思っています。
例えば
「〇〇さんは自分のことをどう思ってるんだろう……う~んう~ん」
などでしょうか。
相手が自分のことをどう思っているかなんて正直わかりません。
なんだけど、自分を良く見せるためのアピールはできたりしますね。
このように悩みごとは二つの部分にわけられるかと思います。
続きを読むこれでテストの目的は最後です。
最後にもう一度一覧を出しておきますね。
このテストの目的が、自分たちのテストに全て当てはまるわけではありません。
そしてどれか一つ、ということもなく複数の目的が含まれるかと思います。
ただ「バグを出す!!」とか「仕様通り動いているかチェックして終わり」とかではなく、自分たちの行っているテストは今何を目的として行っているか、を意識してみましょう。
何となくやっていて「なんでコレやってるんだろう……」なんて目的がわからない場合は……実はテストではなく、ただ触ってるだけかもしれませんよ!
これはテストだけではなく、仕事もそうですし、自分の人生にだって言えるかもしれません。
続きを読む同人誌版テスターちゃん6巻の紙の本/電子書籍(pdf)の頒布をBOOTHで開始しました!
紙の本は送料込みで600円です。
電子書籍は500円です。
書籍版1巻または同人誌版5巻からの続きのナンバーです。
テスターちゃんは続きといっても、全部の本を話が完結するところでまとめているのでどこから読んでも良いのですけどね!
ちなみに書籍版1巻は同人誌版1~5巻の本編のみをまとめています。
なのでJaSSTやテストラジオといったオマケのお話が入っていなかったりします(^-^;
さて。
6巻の話の内容は、テストの基本的な考え方である以下です。
もちろん他「在宅業務」などのサイドのお話も入っています!
6巻から紙の本はA5サイズに変更しました。
書籍版と同じサイズです。
前までB5だったのですが、B5サイズは一般的にはマイナーで……。
カバー的なモノもなかったりするんですよね(汗)
続きを読む
テストの目的の最後7つ目が「テスト対象に対する信頼を積み重ねて、所定のレベルにあることを確証する」。
xxのテストは通った。
〇〇のテストは通った。
etc, etc……
これを積み重ねることによって「全体としてこういうテストが全部通ってるので大丈夫」となるわけである。
けどマンガにも描いた通り、ただテストをたくさんすれば信頼が上がって「もう大丈夫!」といえるわけではない。
「所定のレベルにある」がわかるためにはそもそもその「所定のレベル」がどこかがわからないとダメですよね。
そのためには、どこでどうテストをしていけば全体的にOKっていえるよね、といったものを作らないといけない。
それを全部クリアしたら想定した(所定の)レベルには達しているという考えだ。
(もちろん想定外の部分出てきて、決めたテスト計画だと「これ本当に大丈夫?」となることもあるけど、その時は計画を見直そう)
こういった計画の話をすると
「ウチはアジャイルだし計画を立ててる時間なんてない」とか
「どうせ計画通りいかないからいらなくない?」とか話が出たりする。
そういう人は以下を見てみよう。
続きを読むJSTQBで書かれているテストの目的の6つ目はタイトルの通り。
妥当性確認は、成果物やサービスが意図された使い方や用途を満たしているかの確認です。
システムは「~したい!」という要求があって、それをどうシステムにするか……と考え要件、そしてより細かい仕様に落としていきます。
その大本の「~したい!」がちゃんと実現できてるんだっけ、という部分の確認です。
作者は妥当性確認はシナリオテストを用いることが多いです。
例えば社内の部署で使う業務システム。
その部署での業務フローがあったりしますよね。
あと想定されているシステムの使い方とか。
それをシナリオにして、ちゃんと運用を満足できるか(やりたいことができるか)の確認です。
もちろん運用は一本道ではなく、日々使うなら様々なイベントが発生したりします。
そういったところもできるならシナリオにして確認したりします。
こういうことをすると各機能単体で見てると良さそうだったのに、
「みんなエクセルで開くから、CSVの文字コードはshift-jisでないとダメ」
とか
「何百回も繰り返す登録作業なのに毎回ハンバーガーメニュー開いて呼び出しなの!?」
「夜間作業のメンバーに伝言を残すメモ欄、改行が反映されないの見づらい」
といったユーザビリティまで、実業務ならではの問題点が出てきたりするわけですね。
テストの勉強をしているとV&Vという言葉に出会ったことがあると思います。
続きを読む要件を満たしているかの検証は、テストの中でも最も共通している目的の一つ。
3コマ目でも描いたけど、もっとも重要な活動です。
これは基本中の基本であり、確認するのはもう当たり前という感じ。
で。
それを確認するのは当たり前として、他に何かないか考えましょうといったことを描かせてもらいました。
全てが全て仕様書に書いてあるならそれでオッケーかもしれません。
けどまぁそうもいかないのが世の中でございます。
続きを読む
JSTQBに書かれている言葉としては上の通り。
テストをしないと
「これホント大丈夫なんだっけ…。ちゃんと動くんだっけ…。不安だ。けどエイヤで出すぞ!」
といったところ。
それがテストをすることによって様々な情報が「見えてくる」わけです。
自分たちが考えている使い方だとバッチリ動作することがシナリオテストでわかったとか。
負荷テストを行って、今までの最大アクセス数までは全然余裕で動くことがわかったとか。
セキュリティテストを行って、よくあるような脆弱性の心配は解消されてるとか。
実はオプション画面で繰り返し変更かけると1/100くらいで設定失敗するとか。そこ原因わからなくて直してないとか。
こんな感じで、テストしないときは漠然と「不安だ~」と思っていたことが、テストによって
続きを読む「バグの発見」と書いたけど、シラバスに書かれている文章は上記の通り。
バグを見つけて、それを修正することで市場に出たときのリスクを軽減することができます。
「おいおい、見つけまくって全部直すのかよ!?」みたいに言う人もいるけど、これはまた別の回の「ステークホルダーへの意思決定のための情報提供」の話でやろうとも考えています。
先出しすると、見つけたバグについては「こういうリスクがあるよ」ということがわかるわけです。
そのうえで、どこまでリスクを許容するのかという考え方もあります。
「これだと大きなリスクはないし、次のスプリントで修正」ってことも全然ありなワケです。
けど例えばカーナビみたいな市場に出た後直せないやつだと、次、がなかったりもします。
ユニットテスト、統合(結合)テスト、システムテスト段階ではなるべく多くのバグを見つけまくる、がどのみち幸せかと思います。
そして修正することで市場に出たときのリスクレベルを下げることができます。
続きを読む