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

まつやまです。

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

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

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

ソフトウェアテスト

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年出版という扱いで出てきたのですが、かなり古い本のはずなので、割愛させていただきました。

プロセス改善

  • 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 

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

【勉強会レポート】D3:グルメなテスト自動化&テスト設計モデリング に参加してきました

まつやまです。本日は「グルメなテスト」のイベントに参加させていただきました。

会場は床が芝生のようになっていて、とてもリラックスできる空間でした! 

イベントは、3名の方が1人ずつ発表される形で進みました。
発表テーマは以下のとおりです。 

発表テーマ

「Flakyなテストとその判別方法の解説」(ブロッコリーさん)
「お弁当QAのあみだくじ 〜時系列のイベントを洗い出す〜」(EgaSaさん)
「明日から始めるSelenideによるブラウザテスト 2018年版」(島根 義和さん)


ここからは、各発表ごとのまとめを書いていきます。


「Flakyなテストとその判別方法の解説」(ブロッコリーさん)

発表資料

https://speakerdeck.com/nihonbuson/flakytests

ブロッコリーさんは、JaSST'18 Tokyoの基調講演をはじめ、合計3回に渡ってJohn Micco氏の講演を聞き、さらには直接John Miccoに会いに行って質問をされたそうです。(すごい情熱だ) 

JaSST'18 Tokyoの基調講演などに参加された方にとっては既知の情報を含みますが、Googleではほぼすべてのテストが自動化されており、結果がDBに(一定期間)保存されています。

テストは大きく分けて「Presubmit Testing」と「Postsubmit Testing」の2つに分かれます。前者はコミット単位のテスト、後者は複数回のコミットをまとめた単位のテストです。

テストには多くのリソースを必要とするため、すべてを実施することはできません。そこで、テストを減らすための取り組みを行なっています。

取り組みには「Greenish Service」と「Skip Tests」の2種類があり、前者は確率論で「テストしなくてもおそらく大丈夫」を判断し、後者はテストの「成功/失敗」に着目し、その状態変化の頻度(回数)が多いものを「あてにならないテスト」としてあぶり出しています。

Googleのテストケース及びテスト結果は、非常にシンプルな構成のテーブルに格納されています。特に、テスト結果のカラムに格納される値で、それが開発者の責任なのか、インフラなどコードが関係ない部分での責任なのかを分類できるようになっています。

ブロッコリーさんも強調されていましたが、Flakyなテストを抽出するためのSQLは非常にシンプルで、技術的にはおそらく1年目のエンジニアでも書けると思います。(ここまでシンプルな設計に落とし込めたところがすごい)

ということは、うまくやればGoogleの良いところを、明日から自分の仕事場にも持ち込めるかもしれない。そんな希望が垣間見える内容だったと感じています。

なお、Flakyテストのチュートリアル資料は公開されています。
https://github.com/jmicco/JaSST_tutorial

 

「お弁当QAのあみだくじ 〜時系列のイベントを洗い出す〜」(EgaSaさん)

EgaSaさんによると、現在スウェーデンで開催されているICST(International Conference on Software Testing) 2018は、講演の動画が無料で公開される予定だそうです。これはやばい。

閑話休題。お弁当QAモデルというのは、WEBフロントなどのテストを素早く行うためのモデルだそうです。一般的なモデリング技法は非常に重たい(実務で使うには時間がかかりすぎる)ため、このようなモデルを採用しているとのこと。

今回は「お刺身モデル」の紹介をしていただきました。書き方はかなりシンプルで、左端にステークホルダーを書き、横軸に時系列の線を引きます。そこに、イベントを斜めの線で差し込んでいきます。

その後、「コンフリクト」や「イベントが発生しない場合」などの要素を追記して、最後に、モノサシなどで時系列をトレースしながら、テストケースの設計を行っていきます。手書きでやるのがおすすめだそうです。

(と、今日の時点では理解しましたが、正直曖昧です。また後日この内容で記事を書ければと思っています)
このモデルを採用するメリットは、まず手軽であるということと、手軽であるがゆえに、メンバーに使ってもらうハードルが下がるということです。特に、非エンジニアの方には刺さりそうだなー!と感じたので、見よう見まねで明日から使ってみようと思います。

 

「明日から始めるSelenideによるブラウザテスト 2018年版」(島根 義和さん)

今日の内容を復習するために「Selenide」でぐぐったら、発表者ご本人の記事がHitしました(^^;)

JShellを使ってSeleniumで対話的にブラウザ操作を行う
https://qiita.com/shimashima35/items/918b26c4260e764ce90a

Javaで簡単にUIテストを書けるSelenideを使おう~Selenideの概要とテストの保守性を上げるPage Objectパターンの紹介
https://codezine.jp/article/detail/10335

内容はSelenideのチュートリアル(ライブコーディング)でした。

私は、Seleniumは触ったことがあるのですが、Selenideは(名前は聞いていて興味はありつつも)まだ触ったことがない状態でした。

チュートリアルでは、REPLツールであるJShellを用いての、対話的なスクリプトの実装&実行を行ってくださいました。(ビズリーチさんのWEBサイトを操作する実演もありました!)

開発者ツール起動からの、byidでUI上の要素を指定、といった作業は経験していますので、このあたりはすんなり理解できたと思います。$で値を取れたり、何となくいろいろ便利なんだな?という程度のイメージはできました。

「お刺身モデル」と同様、やはり実際に使わないとちゃんとイメージできないので、これも一度使ってみようと思います。テストだけではなく、様々な用途に応用できるとのこと!

 

まとめとか感想とか


JaSSTの内容は本当に濃くて、噛み砕いていくとまだまだいくらでも味わうところがありますね。Flakyなテストにマヨネーズをかけて(?)美味しい料理にして下さったブロッコリーさんは本当に素晴らしいです。

お刺身モデルはまずは手軽に試せそうな印象がありました。Selenideはこれまで携わってきた自動化スクリプトの延長線上に存在することがイメージでき、学習のハードルがぐっと下がりました。

普段一人で勉強していると、何となく勉強のための勉強というか、変に(ネガティブな意味での)意識高い系に陥ってしまうことがあるのですが、外部勉強会に参加するたびに、そこのベクトル矯正といいますか、むきなおりができて、明日のための燃料がチャージされるイメージがあります。

私はまだ社外での発表をあまり行なっていないのですが、もしそれが誰かの燃料になるのであれば、機会を増やしていきたいと思います。

 

イベントページ

https://d-cube.connpass.com/event/83288/

【ネタバレあり】FindingBugsで遊んでみた

まつ(@mty_mno )さんが公開された探索的テスト用アプリで、早速遊ばせていただきました!

http://milk0824.sakura.ne.jp/finding_bugs/testerchan.hatenadiary.com

自分の思考プロセスや操作の癖が垣間見えて面白かったので、簡単にまとめてみました。

(※実績解除のネタバレが含まれますので、実際に遊ばれてから読まれることをおすすめします。)

結果はこちら

見つけた順番 見つけたバグ コメント(どういう考えや操作でこれを見つけたか、など)
1 投稿で入力をしないとカウンターが現れない 事故です。
2 リストで月が1ヶ月前表示 これはすぐに気付きました。SYSDATEを体内に持っていることが自覚できたのは面白かったです。これが2番目に来た理由は、「まずは投稿機能を使ってみたいと思った」からです。
3 投稿で、投稿した後に文字が消えない これもすぐに気づきました。
4 リストで何度も「良いね!」ができる これもすぐに気づきました。押せるものはとりあえず繰り返し押してみよう、という思考で操作していたと思います。
5 画像がアップロードできない 「そろそろ画像アップロード機能も使ってみよう」で気付きました。チュートリアルにあったのに、見てませんでした。
6 おすすめで同じフォロワーをフォローできる 「とりあえずおすすめユーザーを全部フォローしておこう」の作業中に気付きました。
7 プロフィールでフォロー解除をキャンセルしてもフォロー解除される 「そろそろプロフィールも編集してみよう」で気付きました。自分で自分が面白かったのが、フォロー解除のキャンセルを先に行ったことです。これは理由が恐らく2つあって、単純にフォロー解除をされたくなかったのと、キャンセルを先に試してみたかったからです。
8 プロフィールで文字数オーバーでも名前を変更できる とりあえず文字数が絡むものは、最大桁数を入力したくなりますよね。
9 プロフィールで名前を変更してもヘッダの名前が変更されない 名前変更からの流れで、自然に気付きました。
10 リストで出したコメント欄を消せない フォローしたユーザーの投稿にコメントしようとして気づきました。状態を元に戻せるかなーというのは確認したくなりますよね。
11 リストで出した削除ボタンを消せない 状態を元に戻せるかなーというのは確認したくなりますよね。
12 リストで人の記事を削除できる あれ、自分以外のユーザーに削除ボタンが見えてるぞ?と気付きました。
13 投稿で文字数オーバーなのに投稿可能 「そういえばいちばん基本的なことをやってなかったなー」で気付きました。
14 2個目のコメントを書き込むことができない これも「とりあえず繰り返してみよう」で気付きました。
15 おすすめで同じ人が表示される これはなかなか見つかりませんでした。同じ人をフォローできる時点で、そういう仕様なのかな?と思ってしまいました。

ひととおり遊んでみた感想

何かの機能(≒観点)にフォーカスしている間は、「他の機能が目に入らない」という感覚がありました。

脱出ゲームのアプリを解いているときと同じ頭の使い方をしていたのかな?と思います。

あとは、どうしても機能に意識が行ってしまって、ユーザーとしてどう使うかといったところが疎かになってしまい、「探索的テストは、ユーザビリティのテストなどには向かないのかな?」などと思ってしまいました。※個人の感想です。

自分の行動を振り返ってみると、いろいろ気付くことがあって面白いですね。

【探索的テスト】ウォーリーをちょっと探してみた

まつやまです。

探索的テストについて、「ウォーリーを探せ、をやりこむと分かるよ」というアドバイスをいただきましたので、まずはちょっとだけ探してきました。 図書館の児童書コーナーで。

赤いシマシマパターンを探す作業

まずはウォーリーの特徴である「赤いシマシマ」を探します。 ウォーリーはそれなりに簡単に見つかりました。

ウォーリーの特徴は「赤いシマシマ」だけではない

この絵本には、ウォーリー以外にも「似たようなキャラ」が登場します。ほぼ服装は似ていますが、ウォーリーは「男性」「メガネをかけている」などの特徴があり、場面内に本人はひとりしか登場しません。

いちどにメモリに残せる情報は少ない

これはぼくの頭の癖なのだと思いますが、ウォーリーを探す際、「ウォーリーの特徴をすべてインプットしてから探索する」のではなく、「最も特徴的な特徴をインプットして、手当たり次第探索する」「最も特徴的な特徴に合致した場合、次の条件を適用する」となりました。 探索の順序としては、「まず赤いシマシマを探す」「次に、ウォーリーか否かを判断する」となりました。

これは自分の思考を振り返ってみて、とても面白いなと感じたところです。

ウォーリーを探している間、他の情報は見えなくなる

ウォーリーを探せ!の世界では、だいたいあちこちでトラブルが起こっています。絵画が水を吹き出していたり、川に人魚がいたり、鉄道から牛が脱走したり。けれども、「赤いシマシマ」を探している間、これらの情報は全く頭に入ってきません。視界には入っていますが、認識できません。

ページ上部の本文で「ほふくぜんしんをしているひとをみたよ!」と言われない限り、匍匐前進をしている人にも気づけません。ところが、本文を読んだ瞬間、逆にそこが浮かび上がって見えるようになります。これがすごく面白い。

ウォーリーをちょっと探してみて学んだこと

身の回りで起きている様々な事象に対して、いちどに認識できる範囲は驚くほど狭く、また、何かしらのキーワードで意識を傾けないと、情報はそこに存在しているだけで、認識できないのだと体感しました。

探索的テストでチャーターを設定する意義が、ちょっとだけわかった気がします。

ということで

これからもウォーリーを探し続けてみたいと思います。ゴールは「やり込んだ」と思える程度で。

レビューを語る夕べ 第3回 簡易まとめ

先日参加した「レビューを語る夕べ 第3回」をまとめようと試みていますが、時間がかかりそうなため、簡易まとめを出してみようと思います。 登壇者の方の解釈と異なる可能性がございますが、ご了承ください。


レビューを語る夕べの狙い

レビューのスキル教育において、特に暗黙知の継承をどうしたら良いか考えたい


インプット資料

togetter.com


当日話されたこと

  • レビューをする際、成果物の一部を主観的に「怪しい」と感じることがある/感じる人がいる
  • 主観的な「怪しい」を感じ取るための(プロセスの精度を上げるための)オレオレ技法がある
  • 逆に、ゲーティングのレビューなどでは主観の影響をなくすためのオレオレ技法がある
  • 「魂」や「熱意」など、ロジカルに説明することが難しいと感じるものがある
  • 指摘事項を指摘するべきタイミングは、個人によって解釈が異なる
    • たとえば例外に関する指摘について、ソフトウェアの設計レビューで行うものだと考えているか、テスト設計のレビューで行うものだと考えているかといったことが個人によってまちまち(この認識がずれた状態でWモデルを採用すると失敗する)


感想

  • ひとくちに「レビュー」といっても、参加者のバックグラウンドが様々異なるため、フォーカスしづらい
  • ある程度ペルソナ的なものを用意して、議論のスタートを揃えたほうがいいかも?


当日のハッシュタグまとめ

togetter.com

第1回 テストもぐもぐ会

とりあえず言いたいこと

オムそばさんの企画力すごい

とりあえず言いたいこと その2

お料理がすごく美味しかった

トゥギャりました

togetter.com

「テスト」にまつわるお題

めっちゃ真面目なお題ばかりでした。すごい。

色々なお題がありましたが、「テストにまつわるお悩み」が多かったですね。

  • いまからテストを学ぶ新人に伝えたいこと
  • テスト管理ツールについて意見交換したい
  • テストって楽しいの?
  • XXなことがあって正直つらい
  • QAが増えなくて悩んでいる

などなど。

プロジェクト全体の見通しが悪いことで自分のロールがわかりづらかったり、自分がコントロールできない領域に対してもどかしさを感じていたり、単純に作業感がすごくて精神的に辛かったり、いろいろお悩みがあるのだなあ。。。と感じました。

僕が用意していったお題は完全に休日向けで、遊び要素しかないものでしたので、また別の機会にもぐもぐお話しできればと思います。

個人的に面白かったこと

ブロッコリーさんやなそさんの話のアプローチがとても面白いなと感じました。 「立ち返りの問い」を投げることで、お題を出した人のお悩みを深堀りし、「お題の再設定」を促していらっしゃったと感じます。

個人的に面白かったこと その2

僕自身は、バグを検出すること自体に快感を覚えるタイプの人間なのだということをあらためて自覚しました。