射撃の的になりつつ前進

品質保証やソフトウェアについてのちょっとしたメモです

WACATE 2015冬に行ってきました

ソフトウェアテスト 品質保証

先週の三連休、ソフトウェアテストワークショップ『WACATE 2015冬』に参加してきました。 WACATEは年2回、夏と冬に行われているソフトウェアテストに関する話題を取り扱ったワークショップです。

wacate.jp

2015冬のWACATEは、「ISO 29119」「テスト計画」「ドメイン分析」「テスト改善（TPI NEXT）」「探索的テスト」など、幅広い内容のワークショップが行われました。
今回は、ワークショップに参加して自分が感じたことを含めて、行われた内容をレポートしようと思います。

ワークショップのプログラムは以下の通りでした。

1月9日 プログラム
10:00～10:30 オープニング
「ようこそWACATE2015 冬へ！」
10:30～11:30 ポジションペーパーセッション
11:40～12:10 BPPセッション
「私の「テスト」、あなたの「テスト」」
13:10～14:40 セッション1
「突撃となりのテスト計画 〜こんなときお隣さんはどうしてる？〜」
14:50～16:20 セッション2
「わりとディープ？同値分割↔境界値分析」
16:20～16:50 セッション3
「TPI NEXTで自分たちのテストを評価しよう」
19:00～20:55 ディナーセッション
21:20～23:00 夜の分科会「皆で語ってみませんか？」
1月10日 プログラム
9:00～9:30 セッション4「英語なんてこわくない～英語ドキュメントを読んでみよう」
9:30～10:30 セッション5「60分でわかった気になるISO29119」
10:40～12:10 セッション6「探索的テストはじめの一歩」
13:10～14:10 セッション7「質問されない資料にするための4ステップ」
14:20～15:50 クロージングセッション「ソフトウェアテストの最新動向の学び方」
16:00～16:30 クロージング「2日間の終りに」

今回のWACATEも、例年通りマホロバ・マインズ三浦で行われたのですが、私は初参加だったので景色の良さに感動していました。

会場からこのような素敵な景色が見える中、午前10時からワークショップが始まりました。

1日目

オープニング&ポジションペーパーセッション

オープニングでWACATEの概要説明や諸連絡があった後、ポジションペーパーセッションがありました。 ポジションペーパーセッションとは、WACATEに申し込む際に提出する「ポジションペーパー」（意気込みや問題提起や議論したいことなどをまとめた立場表明書）をもとにして同じテーブルに着席している参加者同士で自己紹介をし合うというセッションです。ポジションペーパーは冊子になって全員の手元に配られているので、そちらを見ながら自己紹介を行いました。

このポジションペーパーセッションでは、いろんな業界からいろんな立場の人が参加していらっしゃることがわかり、個人的にとても興味深く参加者の方々のお話を聞くことができました。

ソフトウェアテストのワークショップなので、仕事で品質管理・品質保証や検証を行っている方々がいらっしゃるイメージだったのですが、ソフトウェアを開発している方、プロジェクトマネジメントをなさっている方など様々でした。参加している世代も、新入社員からベテランの方々まで、様々な世代の方が参加していらっしゃいました。

そして今回のWACATEは全参加者59名のうち半分ほどが初参加だったというのがわかり（名札の色が参加回数によって違う）、萎縮せずワークショップを楽しむことができました（経験者しかいらっしゃらなかったらどうしようと不安だったのですw）。

BPPセッション：私の「テスト」、あなたの「テスト」

BPP（ベストポジションペーパー）セッションとは、前回のWACATEで提出されたポジションペーパーのうち、参加者から一番支持されたポジションペーパーを書いた方が行うセッションです。

今回は、前回の受賞者である裏山さつきさんが「テストとは何か？」というテーマでセッションを行っていらっしゃいました。

聴講者にはA3サイズの白紙が配られ、自分にとっての「テスト」とは何かをマインドマップで書き出していくというワークを行いました。

自分の作ったマインドマップを見ると、「やりたいこと」の枝がものすごく伸びていて、毎日やらないといけないことをこなすので精一杯の状況だけど、自分としてはやりたいことがたくさんあるんだなと再認識しました。

f:id:haruna_nishiwaki:20160117204819j:plain

セッション1：突撃となりのテスト計画 〜こんなときお隣さんはどうしてる？〜

午後のセッション１つ目は、テスト計画についてでした。つい先日、担当プロダクトのテスト計画を詳細化していたところだったので、自分にはとてもタイムリーな話題でした。

テスト計画とはどういったもので、何をすべきなのか説明があった後、現在の現場でのテストについての問題や疑問、悩みを書き出し、同じテーブルの方々に共有するというワークを行いました。

私の着席していたテーブルで出た課題は、

  • テスト項目が多すぎる
  • 重要なテスト項目に抜けがあった
  • テストの終了条件がない
  • テストケースを水増しする人が居る
  • 同じテストを数十バージョンのソフトウェアで実施する
  • テスト計画がころころ変わる
  • テスト順序がごちゃごちゃ
  • テスト開始時と終了時でテストの規模が違う
  • メトリクスのレポートに時間がかかる
  • テスト仕様とソフト仕様が違う
  • 不具合がブロッカーになりテストができない
  • 開発者間の品質に対する意識のばらつきが大きい

などでした。

講演者の@kitkitsukiさんによると、これらのテストに関する課題に多く共通することは、テスト計画を立てていないか、あるいはテスト計画が運用されていない、つまり活用するに値するテスト計画を立てられていないことが原因としてあるとのことでした。

次に、出た課題を種類によって「戦略」、「段取り」、「成果物」に分類し、対策を考え、付箋を続けて貼り付けて行きました。

f:id:haruna_nishiwaki:20160117210852j:plain

また、テスト計画を立案するのには「プロセスフローダイアグラム」を使うと最終成果物から遡ってテストプロセス全体を俯瞰してみることができるようになり、抜け漏れを防いだり、必要最低限の成果物とプロセスに最適化できるとのことでした。

セッション2：わりとディープ？同値分割↔境界値分析

次のセッションは、同値分割と境界値分析に関してでした。JSTQBのFoundation levelの試験勉強をした時に勉強したものの、実務に置いてそこまで複雑な同値分割や境界値分析をしたことがなかったので、食らいつくように聞いていました。

まず、同値分割と境界値分析の概要説明があり、そのあとワークとして実際に問題を解いていきました。問題は非公開ということなのでこちらでもご紹介はしませんが、例題をもう少し複雑にした内容が出題されました。

ここ1年ほどテストケースを作成していなかったので（ずっとテスト計画やCI環境保守などをやっていた）、久しぶりということもあり、ちょっと「ん？どうだっけ…」となることがあり、良い復習になりました。

セッション3：TPI NEXTで自分たちのテストを評価しよう

次のセッションは、最近翻訳版が発売されたTPI NEXTⓇ ビジネス主導のテストプロセス改善についてのセッションでした。

「監査や改善手法についての本」だという認識だったのですが、監査を行うには当然評価も必要なので、今回のセッションは主にTPI NEXTの内容に沿って自分たちの現場のテストプロセスの成熟度を評価してみよう、というものでした。

ワークとして、実際に自分の現場がどの成熟度に位置しているのか、欠陥検出においての成熟度をチェックしたのですが、意外と「最適化レベル（4段階の成熟度のうち、最も成熟しているレベル）」や「効率化レベル（4段階のレベルのうち上から二番目）」を達成できていると手を挙げた方が少なく、いろんな現場でまだまだ改善できるところが残っているのだなと感じました。

ディナーセッション

ディナーセッションでは、宴会場でご飯を食べながら申し込んだ時の参加にあたっての一言をネタにWACATEの今までやこれからに対するお話をされていました。その中で自由に発表ができる場があったので、私が参加しているQA女子会についても宣伝をしてきました。結局、一人も新たに申請してくれませんでしたけどね…。

まあ、あえて「女子会」と閉鎖しておくこともないだろう、という意思表示なのでしょう。私だって別に閉鎖的な集まりを作りたかったわけじゃないんですよ。上司が「品質保証は女性の方が向いてる」とおっしゃったので、「いや別にそんなことないんじゃないか（実際に私は疑問視している…）」「あるいは一般的に女性の特徴だとされているこの部分は品質保証に向いていると言えるかもしれない」という健全な（ともすれば火種になりかねないが）議論をするために立ち上がった会なんですよ…。

夜の分科会：皆で語ってみませんか？

ディナーセッション中に、分科会のテーマがそれぞれ発表され、今回は4つのテーマで開催されることになりました。残念なことに4つがメモできておらず、自分が参加した分科会以外の分科会がどんなテーマだったかを覚えておりません…。どなたか覚えていらっしゃったらコメントいただけますと嬉しいです(;^_^A

私が参加した分科会は、「開発側と品質保証側がどうすれば協力できるか」でした。私の居る現場では基本的に協力してもらえないことということがほぼないので、他社の状況はむしろどんなものなのだろうと思って参加したのですが、現場によっては対立関係にあるとのことで、そこまで溝が深い現場もあるのだな…とちょっとした恐怖を覚えました。

体力がなく、分科会後の2次会（？）には参加できなかったのですが、まだまだ話し足りないことも多く、次回は是非参加したいです…。

なんか、学会っぽい。

2日目

セッション4：英語なんてこわくない～英語ドキュメントを読んでみよう

2日目しょっぱなのセッションは、英語に関するセッション。私は英語が非常に苦手なので、始まる前からついていけるか不安でやたらとドキドキしておりました。 「英語が苦手」だと思っている人は、自分の中に「英語ができる理想の自分」という像があるが、まずはその像を諦めること、とおっしゃっていました。

確かに、私の周りには英語をビジネスレベルでペラペラ喋る同期や友人がわんさかいるので、そういう人たちとどうしても比較してしまい、英語に対してのコンプレックスがものすごくあります。

英語は完璧でなくても中学英語で日常会話はできる。英語は遅刻しそうな時のダッシュと同じで、可能な限り早く着く事が目的で走るフォームやタイムは関係ない、とのことでした。

確かに、英語はあくまでも手段であって、相手に正しく伝わって目的が達成できればそれで良いのだなと改めて思ったセッションでした（とはいえ、英語のドキュメントはそのスタンスで読めて活用できても、テレカンで海外のチームとミーティングをするときや、社外向けに公文書を英語で書くときにそのレベルだと恥ずかしい思いをしてしまうのですが…それはたぶん、苦手意識を克服した次の段階なのでしょうね…）。

セッション5：60分でわかった気になるISO29119

次のセッションは、ISO29119の概要についてのセッションでした。ISO29119とは、ソフトウェアテストについての国際標準規格です。 今までそもそも全くと言っていいほど規格についての知識はなかったのですが、そんな自分でもどんな規格かという概要をつかむことができ、重要性が理解できました。

規格の全文を読むには購入する必要があるのですが、ナカナカのお値段なので、社費で購入してもらうのがいいと思います（買ってくれるところであれば…）。

セッション6：探索的テストはじめの一歩

次のセッションは探索的テストを体験してみるセッションでした。実際にwebアプリケーションのプロトタイプとその仕様書（のようなメモ）が配られ、ワークとして2人1組で探索的テストを行いました。

毎日探索的テストを行っていますが、体験したものよりももっとカジュアルな手法で行っているので（報告や連絡に手間がかからないように簡易化している）、新鮮な気持ちでテストを行えました。

2回に分けて探索的テストを行ったのですが、2回めの探索的テストは実施前にテストチャータ（どの機能や要件に対してフォーカスしてテストを行うか、どんなデータや技法を使うかなど）を決めてからテストを行いました。

確かに実務の中でも、フォーカスする機能を毎日変えたりはしていたのですが（今日はこの機能を深く掘り下げよう、など）、それは明文化されたものではなくて自分が仕事を行う中で自然とやってきたことだったので、これらを手法の説明の中で明文化しておけば、後進にも「探索的テストとはどういったものか」を正しく伝えられるのかなと思いました。

セッション7：質問されない資料にするための4ステップ

次のセッションは、資料の作成方法についてのセッションでした。品質保証の現場では資料を作成することも多く、提案資料なども作成したりするので非常に参考になりました。

  1. 誰が読んでも同じ解釈ができるか
  2. どんな環境、状況でも成り立つか
  3. ある仮定のもとに成り立っていないか
  4. 他に条件がなくても常に成り立つか

という4つの条件を満たした文章を書けば、質問されない資料（自分の立場からすると、「差し戻しを食らわない」資料）を作ることができるとのことでした。 これをずっと意識しながら資料を作るのはなかなか大変ですが、次に資料を作るときに実践してみようと思います。

クロージングセッション：ソフトウェアテストの最新動向の学び方

最後のセッションは、ソフトウェアテストの歴史から、最新動向はどうやってキャッチアップすれば良いかについてのセッションでした（詳細な資料は非公開ということなので公開されているソフトウェアテストの年表のみの引用になります）。

個人的には、一番これからの自分のキャリアをつくるために参考になると感じたセッションでした。良くも悪くも「自分自身でサバイバルする」という文化の（会社が多い）業界なので、このように情報源を教えてくださる機会は貴重でした。

クロージング：2日間の終りに

提出されたポジションペーパーの中から、参加者の投票で決定される「Best Position Paper賞」、委員会が選定する「Most Accelerating Paper賞」、招待講演者が選定する「Biased Favorite Paper賞」が選出され授与されました。

そしてなんと、そのうちの「Biased Favorite Paper賞」を私がいただいてしまいました…！感激！

Maniaxに記事を書けるようになることを夢見ながら、目を皿のようにして読ませていただきます！

その他のまとめ

Togetterまとめ

togetter.com

ブログ

同じタイミングでブロッコリーさんもレポートされているので（しかも分かりやすい）、厚かましくリンク貼っておきます！ nihonbuson.hatenadiary.jp

仲良しかよ（実際は一言ご挨拶したことしかない）。

社内勉強会でスマホネイティブゲーム開発における品質保証について発表しました

2月20日に行われた社内勉強会で、「ネイティブゲーム開発におけるこれからの品質保証」というタイトルで発表させていただきました。

業界の品質保証はこうなっていく！というような大きな話ではなく、弊社のチームがどうやってスマホネイティブゲーム開発と向き合っていくか、というお話です。

最近はこのように、社内外問わず情報交換・プレゼンス向上のための活動をチームの一員として行っています。

もし情報交換していただける方がいらっしゃれば是非ご連絡ください！

第3回「ヒンシツ大学 Evening Talk」に参加してきました

お久しぶりです、最近漬け物系エンジニアだとかジョッキーによっては走ることもある暴れ馬とか好き放題言われているにしわきです。

一年ほどブログを書いていませんでしたが、この度久しぶりに会社外の勉強会に参加してきたので、レポートしたいと思います。

「ヒンシツ大学」とは、株式会社SHIFTさんが主催されているソフトウェアテストをテーマにした講座で、今回のEvening Talkはその講座のスピンオフセッションといった位置づけのものでした（解釈が間違っていたら申し訳ありません…）。

毎回Connpass上で参加募集されているようなので、ご興味がある方はConnpass上でグループのメンバーになっておくと良いかもしれません。

さて、今回のEvening Talkは、ソフトウェアテスト業界のうさ耳アイドル・きょん氏より「ソフトウェアテストの学習とその実践　～学んだことがなぜ活かせないのか!?～」というタイトルで行われました。

ヒンシツ大学 » 第3回「ヒンシツ大学 Evening Talk」きょん氏を迎えて開催

ヒンシツ大学 Evening Talk #03 "きょん氏とテスト学習の活用を考える" #hindaiET - Togetterまとめ

そのタイトルから受ける印象とは違い、ソフトウェアの分野だけではなく、様々な分野において学習したことを業務に活かすための指針について講演されました。

togetterを見ればだいたいの講義の流れは分かるとは思うのですが、ざっくりと講義内容を以下にまとめてみました。

積ん読をなくすには

せっかく本を買ったのに、読み切らずに長期間放置…ということをなくすため、始めはそもそも「本を読みきって、内容を知識として身につけるためにどうするか」をテーマに講義されました。

1.自分が今学習している領域はどこの領域かを意識しながら学習すること

きょん氏曰く、技術書は以下6領域に分けることが出来る（もちろん領域をまたがっているような本もある）そうで、どの領域を学んでいるか意識して学習することが大事、とおっしゃられていました。

  1. ストラテジ
  2. アーキテクチャ
  3. デザイン
  4. レポート
  5. アプリケーションドメイン
  6. ソリューションドメイン

おそらくそうすることによって、得た知識のラベリングがなされ、業務上で何か問題にいきあたったときに検索しやすく整理しておくため、ということなんだろうなと理解しました。

2.目次をよく読み、目次から内容を推測する

目次を読んで、目次からその章や項目に書いてあることを推測してから読むことによって、予測通りだった時も違った時も記憶に残りやすいということなのかなと理解しました。

ちなみに、きょん氏は40分ほどを使って目次を読み込むそうです。

3.全体像を把握するため、短期間に通して読むこと

当たり前ですが、記憶は薄れていくため、全体像を把握するために数日程度で一度通して読んでしまうことが大事、とおっしゃっていました。

わからない部分があったとしても読み飛ばしてしまって先に進むことが大事とのことです。 本を読む時、その本の大切な所（多分人によって違う）はどこに書かれているかが不明なため、全体像を把握することにより、どこのあたりに大切なことが書いてあるかが探しやすくなるようです。

また、分からなかった部分にはふせんなど印をつけておき、読み返した際わかるようになっていれば説明を書いたり、十分に理解できていれば外したりということを繰り返していくと、徐々に理解度が深まっていくとのことです。

さらに、あまりにも理解しがたい内容だった場合は、その本がよほどの悪書か、自分の知識がその本と合っていないため、同じ領域の優しい本を先に読むべきだという判断もできる、とのことでした。

学習したことを業務に活かすには

その後、身につけた知識を業務に活かすことがなかなかできない、という課題をテーマに講義が行われました。

（自分が覚えている）解答としては、とてもシンプルで、「できるところから、小さなことからでも実践してみること」でした。

大きな問題を全部まるっといっぺんに解決しようとするから難しいのであって、問題を小さく切り分ければ、おそらく学習したことを実践して対処していくことが出来るはずなのだな、と自分は理解しました。

特に、テストを専門にやっている人は組織の中で少ない・あるいは居ないことが多いので、やれることはたくさんあるはず、とのことでした。

ワークショップ

講義のあと休憩をはさみ、こちらの文書を例題に、前半約10分（詳細な時間や内訳は忘れてしまいましたが…）、後半約10分ほどでこの文章を読む、というワークショップが行われました。

私はいつもならダラダラと最初から読み進めるのですが、今回は教えていただいた方法をもとにして文章を読んでみました。

まず、自分が意識したのは、「この文章はいったい何なのか？」を考えながら読むこと。

タイトルからしてテストに関連する文章なのはわかりますが、この文章はいったい誰が、誰の為に書いたものなのかを考えながら読んでいました。

そうすることによって、個人的にはいつもより書かれている専門用語や文章の意味などが曖昧なままではなくはっきりと意味を持った語として認識することができるようになり、いつもよりも読後の理解度は高かったのではないかと思いました。

特に、こういった海外のドキュメントを無理矢理に日本語訳したような文書は、読み終わっても意味が分からなかったな…となりがちだったのですが、今回は少なくとも書かれた目的や誰が対象なのか、何についての文章なのか等は把握できたように思います。

所感

私はそもそも本は全部読まなくてもいいじゃないか派なので、自分にとってその時必要な部分だけ読むという、辞書のような使い方をする人間なのですが、それだと読んでいない部分に大切なことや読みたかった内容が書いてあった場合は気づくことができません。

そのため、今後は本を買ったら目次くらいは熟読して、ラベリングを終え、気になる部分があったらその部分は読む、というくらいには本を読むようにしようかなと心を改めました（あまり本を読むのが得意ではないので…）。

Tokyo.R女子部#2行ってきました

業務の関係でRを使うことになり、前日にTokyo.R女子部#2の開催を知り、突撃で行ってきました。

軽く全員自己紹介をした後、一時間ずつ実践を重視した講義がありました。

irisデータを使ったRの基礎

@fukamon_xxx さん

Rにはインストールした時点でいくつかデータが付属されているので、irisデータというアヤメの花びらの長さ・幅等のデータセットを使ってプロットの機能をさくっと練習しました。私はRを使うのが大学の講義以来だったため、思い出しながらの作業となりました。

Rでテキストマイニング超入門

@nanaya_sac さん

MeCab、RMeCabを使ってNHKの今日の料理のスクリプトを形態素解析するというお話でした。この資料の最後にもありますが、MeCabの辞書生成には罠があり、そもそも辞書生成をできなかったので色々調べてみました。

MeCabで辞書生成ができないのは何故か

資料には

ふっくら,-1,-1,1000,オノマトペ,*,*,*,*,ふっくら,フックラ,フックラ

という一行をcsvで保存する、となっていますが、このままファイルを作成し辞書生成しようとすると、

context_id.cpp(96) [it != left_.end()] cannot find LEFT-ID

というエラーが出ます。

ふっくら,*,*,1000,オノマトペ,*,*,*,*,*,ふっくら,フックラ,フックラ

とするべきだ、という結論に至りました。 公式ドキュメントには、左文脈ID（二項目目）、右文脈ID（三項目目）は

空にしておくと mecab-dict-index が自動的に ID を付与します

と記載されているのですが、少なくともMeCabバージョン0.996では以下のように空にしても辞書生成はできませんでした。

ふっくら,,,1000,オノマトペ,*,*,*,*,*,ふっくら,フックラ,フックラ

csvをパースする際のコードが原因か、パースした文字列をintに変換するときに問題が起こっているのかなあと思っています。真面目にコードを読めばはっきり原因がわかるかもしれませんが、そもそもこれが仕様なのかどうなのかもよくわからないので（空にして、という言葉が本当に空のことを指しているのかがわかりません）もう放置することにしました。

そして左右文脈IDには文字列を格納することも出来るのですが、型変換でintに変換しているためにできるだけなので普通に数字を入れるか「*」を指定してやればよいと思います。

この記事には0を指定すればmecab-dict-index が自動的にIDを付与する、と書いてあったり、昔のテキストには-1を指定すれば自動的にIDが付与されると書いてあったりしますが、-1は上記と同様のエラーが出ますし、0を指定して本当にIDが自動的に付与されているかどうかまで調べていないのでわかりません。ということで私は今のところ「*」を推しておきます（「*」もどういう扱いになってるか分からないので安心して使うには調べる必要がありますが、面倒なのでやりません）。

ということで、色々罠にハマってしまいましたが、勉強になりました。 Tokyo.R女子部はこれからも隔月で開催されるようなので、また参加したいと思います。

研修中

絶賛研修中。力不足を実感する日々です。 研修は個々人でやっていますが、進度的には後ろから数えた方が早いです。 せめて業務で足をひっぱらないように、研修中にきっちり学んでおこうと思います。

そういえば毎日ちゃんと何をしたか、どこが悪かったか振り返って考えるのがいい、 とかどこかの誰かが言っていたから、振り返ってみようかと思います。