JSTQB テストアナリストの勉強会

この記事は、ソフトウェアテスト #2 Advent Calendar 2018 3日目の記事です。

そうだ、JSTQB テストアナリストを取ろう

ソフトウェアテスト技術者の認定資格に、JSTQB テストアナリストがあります。

JSTQBは「Foundation」「Advanced」「Expert」の3段階に区分されていて、 テストアナリストはAdvancedレベルに該当します。

過去問も模試もない

JSTQB テストアナリスト試験は、2016年から毎年1回のペースで実施されており、 次回は、2019年2月です(※受験申込みは既に終了しています)。

実施自体がまだ4回目ということもあり(?)、模試などの情報がほぼ存在せず、手探りで受験対策をする必要があります。 JSTQBでは試験問題を持ち帰ることができないため、過去問を使った学習もできません。

ということで、勉強会が始まりました

そんな経緯で、有志の方が勉強会を立ち上げてくださいました。

第2回JSTQB Advanced Level テストアナリスト試験対策勉強会 - connpass

JSTQB の試験問題は、同シラバスの内容から出題されます。 勉強会では、班ごとに分かれて、シラバスを参考に問題を作成し、解きあうということを行いました。 問題を作るためにはシラバスを細かく読み込む必要がありますので、大変ですが良いトレーニングになります。

↓の一覧を使いながら、シラバスに沿ってK2(理解)、K3(適用)、K4(分析)レベル相当の問題を作成していきます。 f:id:trickmr:20181202221723p:plain

実際に参加してみた感想ですが、 シラバスに記載されている学習の目的に沿って進めることがとても大事で、 闇雲に丸暗記を頑張るのはよろしくないということを実感しました。

今後も、2週間ペースで開催予定になりますので、ご興味のある方は是非参加してみてください!

ソフトウェアテストにまつわる英語文献2018

ソフトウェアテストにまつわる英語文献を自分なりにまとめてみました。

JaSST'18 Kyushuの行き帰りに「Advanced Software Testing- Vol. 1」を読んでみたのですが、 図解や事例が豊富で非常に理解しやすかったです。

たぶん買う。

※2018/11/24現在で、和訳が流通していなさそうなものを列挙しています。
「これ和訳あるやろがボケ!」ってものがあったら優しく教えてくださると嬉しいです。

※Advancedレベルは、最新の2012年版が和訳されているため対象外としました。 アジャイルテスターも同様です。

シラバスのダウンロードはこちらのリンクから。
https://www.istqb.org/downloads.html
以下に直リンクも作りましたが、「Downloads」からアクセスしないと怒られる模様です。

Foundation 2018

Certified Tester Foundation Level Syllabus Version 2018 Version

モデルベースドテスター

Foundation Level Certified Model-Based Tester Syllabus Version 2015

セキュリティテスター

Certified Tester Advanced Level Syllabus Security Tester Version 2016

テストオートメーションエンジニア

Certified Tester Advanced Level Syllabus Test Automation Engineer Version 2016

テストプロセス改善

Certified Tester Expert Level Syllabus Improving the Testing Process (Implementing Improvement and Change) 2011

テストマネジメント

Certified Tester Expert Level Syllabus Test Management (Managing Testing, Testers, and Test Stakeholders) 2011



 

  • 書籍

Advanced Software Testing - Vol. 1

Advanced Software Testing - Vol. 2

Advanced Software Testing - Vol. 3

ISO/IEC/IEEE 29119 SOFTWARE TESTING STANDARDS (English Edition)

More Agile Testing

Developer Testing

xUnit Test Patterns

Explore It!

Bug Advocacy

 

バグレポートは伝え方が9割(※個人の感想です)

こんにちは。カルバートです。

GW前に参加してきた、「"Issueの書き方と伝え方"勉強会」の内容と、当日感じたことを書きます。

connpass.com

 

当日のツイートまとめ

togetter.com

 

エラーと欠陥と故障と不具合/バグの違い

JSTQB用語を学ぶときの最初の障壁(※個人の感想です)、エラーや欠陥などの用語の違いについて、秋山さんのスライドがとてもわかりやすかったです。

https://image.slidesharecdn.com/20180421-aster-180420130433/95/20180421-issue-4-638.jpg?cb=1524229592

エラー:てへぺろ→人間だもの間違うことはあるよね

欠陥:家のヒビ→てへぺろ結果埋め込まれてしまったもの(ディフェクト)。経年劣化などで表面化してきたものはフォールトと呼んで区別する場合もある

故障:期待と違う結果→ヒビのところから家が壊れた、ディスプレイの画面が乱れた

不具合/バグ:故障が表出した(人間が観測できた)もの→レポートの対象になるのはこれ

 

私のまわり(おもにWEB系ドメイン)では、これらの概念を特別に区別して扱っていることはないのですが、厳密な分析を行ったりする場合には、区別して整理する必要がありそうですね。

 

「報告する人」と「報告を受ける人」は対立構造になりがち

今回は4名の方が発表されましたが、バックグラウンドが皆様それぞれに異なっており、注意すべきと考えているポイントも異なっていると感じられたのが印象的でした。

 

本来、不具合/バグを報告するレポートは、「サービスが期待する振る舞いをしていない」という事実を伝え、サービスを改善するために書かれるべきだと思います。実際、レポートそのものは事実を伝えるべく書かれるのですが、内容がネガティブなものにならざるを得ないため、「報告する人」から「報告を受ける人」への攻撃と受け止められがちなのかなと感じます。

 

「報告する人」の視座

秋山さんやリナさんの発表では、「報告する人」の立場から、テスト担当者と開発担当者が明確に別れている前提で、どのように感情を損なわず、お互いの納得感をもって、事実を記録し、情報の同期を適切に行うかという趣旨のお話をしていただきました。

 

リナさんのケースは個人的にとても衝撃的で、自分なりに表現すると、映画の中の理想の世界でした。黒い白鳥なんてお話の中の世界なんだから、現実を見なさい。白鳥は白いのよと教わってきた人が黒い白鳥を見たときの衝撃という感じでしょうか(伝われ)。

関係性ががっちり構築されていると、こんなにも理想的な立ち回りができるのだなあ。。。と感じた発表でした。普通の人にはマネできないと思います。

 

「報告を受ける人」の視座

一方、渋谷さんの発表では、「報告を受ける人」の立場で、様々な考え方を伺うことができました。僕自身の経験でいうと、とある案件の本番導入に「報告を受ける人」の立場で立ち会ったことがあるのですが、それはもう地獄でしたね。「おまえらの作ったサービスがちゃんと動かないから大変なことになっている!どうしてくれる!」という感情が篭ったレポートを毎日何十件も読んでいました。ただ、その感情の先に、「サービス提供者として気づけていなかった、隠れていた要件」が存在していたりするので、二度と思い出したくない反面、自分の原点のひとつになっている経験でもあると感じています。

 

みっきーさんの発表は時間の関係で深く議論できませんでしたが、また別の機会があると嬉しいです。

 

結局は人が相手なんだし、思いやりが大事

バグレポートに限らないのですが、結局人間である以上、耳の痛い情報を受け取るときにネガティブな感情が発生してしまうことは避けられないのかなと思います(人間というものがそういう風に実装されてしまっている)。

その特性(仕様)を理解して、「報告する人」と「報告を受ける人」がお互いに気持ちよく仕事をするために、まず「伝え方」を工夫することが大事なのかなと感じた1日でした。

 

 

発表資料

www.slideshare.net

 

www.slideshare.net

 

 

不具合票あれこれ - Google ドキュメント

 

参考書籍 

ソフトウェアテスト293の鉄則

ソフトウェアテスト293の鉄則

 

 

余談

秋山さんから、デザートをいただきました。ありがとうございます!とても美味しかったです!

f:id:trickmr:20180513154027p:plain

 

信頼度成長曲線は信頼できるのか。

こんにちは。カルバートです。

先日、信頼度成長曲線を語る夕べに参加してきました。

kataruyube.connpass.com

 

信頼度成長曲線とは

信頼度成長曲線とは何なのか。自分の理解の範囲で言い換えると、

いつまでテストすればいいの?を数学的に予測するやり方です。

そもそも未来を予測することはできるのか?という難しい問題提起に対して、偉大な先人たちは様々な数学的モデルを考案してきました。ロジスティック曲線やゴンペルツ曲線など、様々なモデルが存在します。いずれも、自然界の事象を数式でモデル化することで、未来の予測に活用しようとしたものだと理解しています。

 

ソフトウェアの不具合検出に、その技法は応用できるのか

「語る夕べ」に参加したうえでの個人的な感想は、「理論上不可能ではないが、実務に応用するためには前提条件を整えるコストがかかりすぎて、難しいのではないか」でした。ざっと調べた限りなので間違いがあるかもしれませんが、たとえば生物の発生にロジスティック曲線を適用する場合、外部の環境(気候や食糧など)が一定しているという前提が満たされている必要があります。ソフトウェアテストにあてはめた場合、「不具合は偏在しない」「不具合の発見されやすさは常に一定」といった前提が必要になってきます。テストレベルが低ければ部分的には応用できるかもしれませんが、それらだけ切り出して分析することでテストの収束が予測できるかというと、また別の話なのかなと思いました。

 

綺麗なグラフを見たら建設的に疑おう

当日は、みっきーさんの(つらい)経験をベースに、信頼度成長曲線をそれっぽく見せるための様々なテクニックをお話しいただきました。いくつかは自分自身も経験したことがあるものでした。

未来を数学的に予測するための道具が本来の使われ方をせず、綺麗な数字をステークホルダーに報告するためだけの存在になってしまっている(ことが多いらしい)という話は、なんとも悲しいものです。そんな作業をするために、人生の貴重な時間を使いたくはないものですね。

信頼度成長曲線に限らず、グラフを見たら根拠を建設的に疑う。自分がグラフを書くときは、根拠が誤解なく伝わるよう務める。そんなことが大事なのかなと感じたイベントでした。

 

参考にした書籍 

予測のはなし―未来を読むテクニック

予測のはなし―未来を読むテクニック

 

 

当日のツイートまとめ

togetter.com

第4回 テスト観点を語る夕べに参加しました

こんにちは。まつやま改め、カルバートです。

第4回 テスト観点を語る夕べに参加してきました。

当日のtogetterはこちら。

togetter.com

 

はじめに

まずは登壇者のなそさんが作成されたマインドマップがどーん!

めちゃくちゃ文字が綺麗で、美しいマップです。

何を食べたらこんな綺麗な文字が書けるのでしょうか…羨ましいです。

 

参加型ワークショップ 

当日はまず前回のおさらいから始まり、その後はにしさんのファシリテートを受けて、なそさんのマインドマップに加筆修正が行われていきました。

 

そのサービスのコアバリューは何か

今回のワークショップでは、connpassというサービスを題材に、サービスのコアバリューを列挙し、それを親要素としてテスト観点をブレイクダウンする手法が取られました。ここで重要なことは、機能や操作(※)といった、ソフトウェアの構造上の「わかりやすいポイント」に最初に飛びつかないことです。

(※ connpassの例でいえば、「検索」や「申込」などが該当すると思います)

 

僕はこれまで、要求や要件を親とするアプローチや、機能や操作を親とするアプローチを多く経験してきましたので、これは個人的に新鮮でした。

 

いつでもどこでも

コアバリューの例としてなそさんが挙げられたキーワードに「いつでもどこでも」がありました。connpassは勉強会ポータルですから、いつでもどこでも好きなときにイベントを登録できること、参加申し込みができること、キャンセルができること、あるいはサイトに繋がるといったことが重要なバリューになります(と、この勉強会では解釈しました)。

 

コアバリューを分解する

次に、コアバリューを分解していきます。ここでひとつ、注意点があります。それは、いきなり具体的なキーワードを書かないということです。子ノードを作成するときに、「いつでもどこでも」から連想する具体的なワード(例:ログイン機能)を書きたくなってしまいますが、一歩立ち止まって我慢が必要になります。子ノードを作成する目的は、今すぐにわかりやすいテストケースを作成することではなく、親ノードの持つ「意図」を分解することです。

 

 「いつでもどこでも」を親とするならば、次の子ノードの例は「いつ」と「どこ」になります。これ以上いきなり細かくしてしまうと、MECEや継承関係が後から確認しづらくなってしまいます。

 

思考がアンカリングされていることを意識する

子ノードを出すときのもうひとつの注意点として、思考のアンカリングがあります。今回は、「いつ」というキーワードの意図を紐解いていくと、トラフィックが増えたとしても、それに耐えられること」という意図が浮かび上がってきました。このとき、参加者は全員「トラフィックの増加って、つまりどういうことだろう?」と、具体的なユースケースや、システムのアーキテクトを想像しはじめます。

 

僕の場合は、「某人気イベントに人が殺到したけど、あの重たさは許容範囲内だったんだろうか」とか「トラフィックと一口に言ってもいろいろあるし、内部構造を知っているか知らないかでも気にするポイントは変わるな」といったことが頭に浮かびました。

こういった状態では、脳は「トラフィックが増えたとき」のことをどんどん深く考えてしまいます。それは決して悪いことではないのですが、この状態で他の「意図」について考えようとしても、「トラフィック」思考にどうしても囚われてしまいます。これが「思考がアンカリングされている」状態です。

 

この対処としては、アンカリングされている間は頭が空っぽになるまでアウトプットを続け、空っぽになったと思われるタイミングで次に移ることが有効だそうです。このメソッドは、ブログを書いたりするのにも使えそうですね。

 

ここまでのまとめ

・コアバリューを起点に、子要素をブレイクダウンする

・子要素をブレイクダウンするときは、いきなり具体例に飛びつきたくなる誘惑と戦う

・思考がアンカリングされていることを意識する 

 

当日はこのほかにも色々お話があったのですが、一旦ここまででまとめとさせていただきます٩( 'ω' )و  

 

(WIP)2012年以降に出版された「ソフトウェアテストやQAの話題が載っている書籍」の一覧

まつやまです。

TestingCommunityJPでの会話を発端に、2012年以降に出版/改訂された「ソフトウェアテストやQAの話題が載っている書籍」の一覧を作ってみました。カッコ内は出版日です。ほぼAmazon調べです。

TDDや自動化関連が若干多い印象があるものの、そもそも書籍自体が少ないように感じます。情報のありかが、書籍からWEB上へと移行していっているのかもしれませんね。

一覧は、適宜アップデートしていきたいと思います。

※4/24追記:「テスターちゃん1,2巻」「システムの問題地図」を追記しました。 ※5/2追記:「エキスパートが教えるSelenium最前線」「WEB+DB PRESS総集編[Vol.1~102]」を追記しました。

ソフトウェアテスト

QA

  • カイゼン・ジャーニー(2018/2/7) ※「QA担当」が明確に存在する組織のお話です
  • ベタープログラマ(2017/12/15) ※21章は丸ごとQAの章です
  • ジョイ・インク(2016/12/20) ※「QA担当」が明確に存在する組織のお話です


TDD

テスト自動化

CI/CD

  • [改訂第3版]Jenkins実践入門(2017/5/24)
  • Javaビルドツール入門 Maven/Gradle/SBT/Bazel対応(2017/2/8)
  • Gradle徹底入門(2014/11/5)


Amazonでは「継続的デリバリー」が2017年出版という扱いで出てきたのですが、かなり古い本のはずなので、割愛させていただきました。

プロセス改善

  • システムの問題地図(2018/2/17)
  • TPI NEXTⓇ ビジネス主導のテストプロセス改善 (2015)
  • ソフトウェアプロセス改善手法SaPID入門(2014/3/1)


非機能試験

なお、近日中に「安全なWebアプリケーションの作り方」(2011/3/1)のUPDATE版が出るそうです。 blog.tokumaru.org

SWEBOK

  • ソフトウェアエンジニアリング基礎知識体系 ―SWEBOK V3.0―(2014/11/21)


SQuBOK

  • ソフトウェア品質知識体系ガイド -SQuBOK Guide-(第2版)(2014/11/29)


共通フレーム




- 共通フレーム2013(2013/3/4)

雑誌

gihyo.jp gihyo.jp gihyo.jp gihyo.jp gihyo.jp gihyo.jp gihyo.jp

資格関連

【ゲームのはなし】DANCE RUSHで遊んできました

まつやまです。

KONAMIの新作ゲーム、DANCE RUSHで遊んできました。

 

www.youtube.com

 

筐体はかなり大きめ。フットパネルが非常に広く、派手です。とても目立ちます。

料金は、100円2曲とちょっとお高め。

(設置面積あたりの単価を考えると、やむを得ないとは思います)

 

遊んでみた感想

ルールがシンプルで、かなり遊びやすいです。

画面奥から迫ってくる表示に合わせて、両足でステップ&体を上下させるだけです。

今のところは極端に難しい譜面もなく、ちびっこでも遊べる設計になっています。

(わかる人向けに書くと、SDVXとチュウニズムとDDRとダンエボを融合させて、ライトユーザー向けにチューニングした感じ)

 

ただし、曲が少ない&解禁が重い

稼働してあまり日数が経過していないこともあり(?)選べる曲がとても少ないですね。

ゲーム内でポイントを貯めないと遊べない曲も多いのですが、従来の機種に比べて、解禁までに必要なプレイ回数が非常に多いと感じました。

 

 

今後期待したいこと

まだまだ曲が少ないので、どんどん増やしていただきたいですね。

あとは、極端に難しい譜面が増えないと嬉しいです。難しい譜面が出始めると、一気にマニア専用機になってしまうんですよね。。。

(わかる人向けに書くと、難易度が緑と黄色しかないので、いずれ赤譜面は解禁されるものと思います)

 

とりあえず

Gimme a Big Beat 

を手に入れるまでは頑張ろうと思います。