テスターちゃん【4コマ漫画】

ソフトウェアテストの用語、やり方などを4コマ漫画でわかりやすく説明する(予定の)ブログです。脱線も多いです。



98.テスト界隈で使われる言葉『QA=テストすること?』

f:id:m_training:20201016085637p:plain

98.テスト界隈で使われる言葉『QA=テストすること?』

QA=テストすること?

前に「QA=テストすること?」といったことが話題になったことがありました。

答える人によって「大体そんな感じ」という人もいれば「全然違う!」という人もいたりしたかと思います。

これは恐らく自分の会社のQA組織ががどのレイヤーにフォーカスしているか、どんな目的で活動しているかによって答えがわかれるのだと思います。

 

QAの話は、JaSST'19 Tokyoの秋山さんの「QA入門」の資料がとても分かりやすいです。

http://jasst.jp/symposium/jasst19tokyo/pdf/D4-1.pdf

 

プロダクト(商品)品質にフォーカス

ユーザーが直接触るものはプロダクトです。

このプロダクトがちゃんとしてないといけません。

ちゃんとしている、というのはバグがないこと……ではなくて、ユーザーが期待する価値(要求やニーズなど)が提供できている状態のことです。

その「このプロダクト、ちゃんと価値提供できてるかなー」の確認手段としてレビューやテストがあります。

 

なので、例えば一つのプロダクトにフォーカスし取り扱っているチームは、QA=テストすること、といったイメージになるかと思います。

 

プロダクト品質に着目してるときは、それぞれのプロダクトごと……つまり「単発」で品質保証をしている形かと思います。

続きを読む

悩みごと

f:id:m_training:20201010183441p:plain

悩みごと

作者の考えではありますが、悩みごとはマンガに描いた通り「思い通りにならないこと」を頭の中でグルグルさせているんだと思っています。

例えば

「〇〇さんは自分のことをどう思ってるんだろう……う~んう~ん」

などでしょうか。

相手が自分のことをどう思っているかなんて正直わかりません。

なんだけど、自分を良く見せるためのアピールはできたりしますね。

 

このように悩みごとは二つの部分にわけられるかと思います。

続きを読む

96. テストの目的 その⑧

f:id:m_training:20201004172110p:plain

96. テストの目的 その⑧

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

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

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

 

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

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

 

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

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

 

目的を意識する

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

続きを読む

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

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

testerchan.booth.pm

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

電子書籍は500円です。

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

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

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

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

 

さて。

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

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

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

 

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

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

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

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

 

続きを読む

95. テストの目的 その⑦

f:id:m_training:20200922214214p:plain

95. テストの目的 その⑦

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

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

xxのテストは通った。

〇〇のテストは通った。

etc, etc……

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

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

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

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

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

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

 

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

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

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

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

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

続きを読む

94. テストの目的 その⑥

f:id:m_training:20200906162224p:plain

94. テストの目的 その⑥

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

とか

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

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

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

 

検証と妥当性確認の違い

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

続きを読む

きゅんちゃん設定画

f:id:m_training:20200829223053p:plain

きゅんちゃん設定画

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

 

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

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

 

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

続きを読む

93. テストの目的 その⑤

f:id:m_training:20200823161734p:plain

93. テストの目的 その⑤

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

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

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

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

で。

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

 

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

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

 

続きを読む

92. テストの目的 その④

f:id:m_training:20200802205359p:plain

 92. テストの目的 その④

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

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

 

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

 

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

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

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

 

続きを読む

91. テストの目的 その③

f:id:m_training:20200719164233p:plain

91. テストの目的 その③

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

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

テストをしないと

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

といったところ。

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

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

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

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

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

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

続きを読む