テスターちゃん100話記念!
テスターちゃん100話記念!
ついについに!!
テスターちゃんは100話を迎えました!!
こんなにも続けてこれたのは、応援してくださっている皆様、楽しみにしてくださっている皆様、共に歩んでくださっている皆様のおかげです。
3コマ目のりんちゃんのセリフは、きゅんちゃんだけでなく、テスターちゃんを見て学んでくださっている皆様にも向けたセリフです。
覚えることはまだまだたくさんあると思いますが、焦らず、マイペースで、楽しみながら進んでいきましょうね!
そのお手伝いができたのでしたら、作者としましては嬉しい限りなのでございます^^
テスターちゃん、次は同人誌7巻、そして書籍2巻に向けて進んでいきます~!
各キャラクターの成長
連載が2017年から、ということで3年ほどが経過しております。
その間にキャラの成長…もとい絵が少しずつ変わっていきました。
ここではそれを紹介です。
続きを読むテスターちゃん、JaSSTのスポンサーになる!
テスターちゃん、JaSSTのスポンサーになる!
日本で有名なソフトウェアテストのイベント(シンポジウム)といったらやはりJaSSTです。
JaSST Tokyoがもちろん一番人が集まるのですが、他に北海道や九州、東北など様々な地域(今はオンライン含め12か所)で行われています。
そして!!
テスターちゃんがJaSST'20 Kyushu(ソフトウェアテストシンポジウム九州)のシルバースポンサーを務めることとなりました!!
作者…がんばりました!
主に金策を…がんばりました!(笑)
テスターちゃんはよく「新しくはいった方に見ていただいています~」といった嬉しいお言葉をいただいております。
マンガに抵抗がない方でしたら、新しくジョインした方にテスターちゃんをお渡しして「読んでみて!」といって目を通してもらえると、それでテストの基礎部分やテストのマインド部分が把握できたりするかと思います。(そういう思いをこめて描いています)
初期教育部分で一定の水準でテストについてをお伝えすることが可能な本といったところです。
テスターちゃんはこんな感じで使えますよと広めたい!と思うことも一つですが、さらに作者の今後の新しい活動、業界貢献のファーストステップとしてのスポンサーでございます。
これからも作者も、テスターちゃんも成長を続けていきます!という意気込みの表れといったところです(笑)
今後もなにとぞよろしくお願いいたします!
99.テスト界隈で使われる言葉『モンキーテスト=アドホックテスト=探索的テスト?』
99.テスト界隈で使われる言葉『モンキーテスト=アドホックテスト=探索的テスト?』
会社によって用語が異なるコトはたくさんあるのですが、その代表格が「自由に行うテスト」です。
作者が聞いたことがあるものだと……
なんとなく「ランダムっぽい言葉」や「軽く触ってチェックする(をスルーと言ってる気がする)」といった意味の言葉が含まれる気がします。
その中でも多く使われているのがモンキーテストとアドホックテストかと思います。
これら会社の用語に慣れた後でテストの勉強をすると
『探索的テスト』
なんて言葉が出てきて「?」ってなってくるのですよね。
この辺、中岫さんのスライドがわかりやすくまとめられています。
98.テスト界隈で使われる言葉『QA=テストすること?』
98.テスト界隈で使われる言葉『QA=テストすること?』
QA=テストすること?
前に「QA=テストすること?」といったことが話題になったことがありました。
答える人によって「大体そんな感じ」という人もいれば「全然違う!」という人もいたりしたかと思います。
これは恐らく自分の会社のQA組織ががどのレイヤーにフォーカスしているか、どんな目的で活動しているかによって答えがわかれるのだと思います。
QAの話は、JaSST'19 Tokyoの秋山さんの「QA入門」の資料がとても分かりやすいです。
http://jasst.jp/symposium/jasst19tokyo/pdf/D4-1.pdf
プロダクト(商品)品質にフォーカス
ユーザーが直接触るものはプロダクトです。
このプロダクトがちゃんとしてないといけません。
ちゃんとしている、というのはバグがないこと……ではなくて、ユーザーが期待する価値(要求やニーズなど)が提供できている状態のことです。
その「このプロダクト、ちゃんと価値提供できてるかなー」の確認手段としてレビューやテストがあります。
なので、例えば一つのプロダクトにフォーカスし取り扱っているチームは、QA=テストすること、といったイメージになるかと思います。
プロダクト品質に着目してるときは、それぞれのプロダクトごと……つまり「単発」で品質保証をしている形かと思います。
続きを読む96. テストの目的 その⑧
96. テストの目的 その⑧
これでテストの目的は最後です。
最後にもう一度一覧を出しておきますね。
- 欠陥を防ぐため、要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価する。
- 明確にしたすべての要件を満たしていることを検証する。
- テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする。
- テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する。
- 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する。
- ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する。
- 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する。
このテストの目的が、自分たちのテストに全て当てはまるわけではありません。
そしてどれか一つ、ということもなく複数の目的が含まれるかと思います。
ただ「バグを出す!!」とか「仕様通り動いているかチェックして終わり」とかではなく、自分たちの行っているテストは今何を目的として行っているか、を意識してみましょう。
何となくやっていて「なんでコレやってるんだろう……」なんて目的がわからない場合は……実はテストではなく、ただ触ってるだけかもしれませんよ!
目的を意識する
これはテストだけではなく、仕事もそうですし、自分の人生にだって言えるかもしれません。
続きを読む【紙の本/電子】同人誌版テスターちゃん6巻頒布開始!
同人誌版テスターちゃん6巻の紙の本/電子書籍(pdf)の頒布をBOOTHで開始しました!
紙の本は送料込みで600円です。
電子書籍は500円です。
書籍版1巻または同人誌版5巻からの続きのナンバーです。
テスターちゃんは続きといっても、全部の本を話が完結するところでまとめているのでどこから読んでも良いのですけどね!
ちなみに書籍版1巻は同人誌版1~5巻の本編のみをまとめています。
なのでJaSSTやテストラジオといったオマケのお話が入っていなかったりします(^-^;
さて。
6巻の話の内容は、テストの基本的な考え方である以下です。
- チェッキング・テスティングの考え方
- テストの目的
もちろん他「在宅業務」などのサイドのお話も入っています!
6巻から紙の本はA5サイズに変更しました。
書籍版と同じサイズです。
前までB5だったのですが、B5サイズは一般的にはマイナーで……。
カバー的なモノもなかったりするんですよね(汗)
続きを読む
95. テストの目的 その⑦
95. テストの目的 その⑦
テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する
テストの目的の最後7つ目が「テスト対象に対する信頼を積み重ねて、所定のレベルにあることを確証する」。
xxのテストは通った。
〇〇のテストは通った。
etc, etc……
これを積み重ねることによって「全体としてこういうテストが全部通ってるので大丈夫」となるわけである。
けどマンガにも描いた通り、ただテストをたくさんすれば信頼が上がって「もう大丈夫!」といえるわけではない。
「所定のレベルにある」がわかるためにはそもそもその「所定のレベル」がどこかがわからないとダメですよね。
そのためには、どこでどうテストをしていけば全体的にOKっていえるよね、といったものを作らないといけない。
それを全部クリアしたら想定した(所定の)レベルには達しているという考えだ。
(もちろん想定外の部分出てきて、決めたテスト計画だと「これ本当に大丈夫?」となることもあるけど、その時は計画を見直そう)
テスト計画をもっと気軽にやろう
こういった計画の話をすると
「ウチはアジャイルだし計画を立ててる時間なんてない」とか
「どうせ計画通りいかないからいらなくない?」とか話が出たりする。
そういう人は以下を見てみよう。
続きを読む94. テストの目的 その⑥
94. テストの目的 その⑥
テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする
JSTQBで書かれているテストの目的の6つ目はタイトルの通り。
妥当性確認は、成果物やサービスが意図された使い方や用途を満たしているかの確認です。
システムは「~したい!」という要求があって、それをどうシステムにするか……と考え要件、そしてより細かい仕様に落としていきます。
その大本の「~したい!」がちゃんと実現できてるんだっけ、という部分の確認です。
作者は妥当性確認はシナリオテストを用いることが多いです。
例えば社内の部署で使う業務システム。
その部署での業務フローがあったりしますよね。
あと想定されているシステムの使い方とか。
それをシナリオにして、ちゃんと運用を満足できるか(やりたいことができるか)の確認です。
もちろん運用は一本道ではなく、日々使うなら様々なイベントが発生したりします。
そういったところもできるならシナリオにして確認したりします。
こういうことをすると各機能単体で見てると良さそうだったのに、
「みんなエクセルで開くから、CSVの文字コードはshift-jisでないとダメ」
とか
「何百回も繰り返す登録作業なのに毎回ハンバーガーメニュー開いて呼び出しなの!?」
「夜間作業のメンバーに伝言を残すメモ欄、改行が反映されないの見づらい」
といったユーザビリティまで、実業務ならではの問題点が出てきたりするわけですね。
検証と妥当性確認の違い
テストの勉強をしているとV&Vという言葉に出会ったことがあると思います。
続きを読む