JaSST'17 Tokaiに参加してきました

2017/12/08(金)に開催されたJaSST'17 Tokaiに
参加&ワークショップのアシスタントしてきたので、レポートします。
始めてJaSST Tokai参加しましたが、
講師の方や参加者から色々なお話が聞けて良かったです。

はじめの一歩、やってみる現場改善

細谷泰夫氏(三菱電気)
<概要>
現場の改善を行おうとすると変化を伴うため、恐れや抵抗がある。それらとうまく付き合ったり、かわしたりしつつ、どう改善を進めていくかという話でした。
改善活動の形態は次の3つ
(1)チームの一員
良さそうなことはとにかくやってみる
→興味を持ってくれた人に共有、巻き込む
→アピールする(社内、社外)

(2)リーダやマネージャ
基本的にはチームの一員と一緒
他へ展開しようとした時、組織の壁にぶちあたる、どうやって越えるか?
→段階的に導入

(3)組織外の支援者として
支援先が抱える問題やその原因を共有しないまま新しい方法を導入してもうまくいかない
→まずは解決したい課題の明確化、目的の共有
 あとは(1)や(2)と同じ

恐れや抵抗を具体的に越えていくための方法として、講演の中で紹介された本が、
こちらの
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
です。
Fearless Change本の中で紹介されているパターンを体感するためのゲームもあるそうです。

<感想>
(1)チームの一員から(2)リーダやマネージャ的な立場に移行しつつある立場として聞いてました。
自社の場合は、始めてみる分にはさほどの抵抗感はないものの、
定着するまでに試行錯誤がいるなあ、というのが今感じているところです。
改善は定着するまで、行きつ戻りつの繰り返しだと思うので、
最後の方で言われていた細谷さんのモットー
短期的には諦めよく、長期的には執念深く
を真似させてもらうつもりです。

講演を聞く中で、自分に足りてないのはアピールする、だと思いました。
幸いなことに、自社ではアピールのハードルは比較的低いので、
Fearless Change本を読んで実践してみようと思います。

「様々な現場で、改善・生産性向上を進める上で気をつけてきたこと 〜 誰がために、その改善を行うのか 〜」

山本久仁朗 氏(アカツキ
<概要>
様々な組織でQAとしてキャリアを積む中で、
色々試行錯誤されてきたこと、うまくいったこといかなかったことの紹介でした。
(1) QA部署の存在感と実績を積み上げる@部署立ち上げ時期
 リスクベースドテスト導入
 →リスクの早期削減による手戻りの削減
 各チームへのツール提供、横串活動
 
(2)QA組織のやるべき事
清水吉男氏によると以下の4つ
・ミツバチの役割:他プロジェクトへの展開する
・ペースメーカーの役割:先に進める
・ブレーキの役割:ダメそうなら止める
コンサルタントの役割:世の中のトレンドにアンテナを張る

<感想>
自社でもQA組織をやっているものの、
まだまだ人数も少なく、試行錯誤中なので
リスクベースドテストや、各PJへの展開などはぜひ進めていきたいところ。
QA組織立ち上げ時に、どのようなメトリクスをとっていたかなど
参考になる話も後の懇親会で質問させてもらえたので、
自社展開しようと計画中です。

「バグ票カウンセリング 〜 バグ票の悩み、話してみよう!解決しよう! 〜」

こちらは、アシスタントとして参加してきました。
資料は後ほど公開されたらリンクを貼っておきます。

参加者の皆さんにバグ票のレベルアップを体感してもらおうと、
サンプルの問題事象を提示して、
まずはいつも自分が書いているように、バグ票を起票してもらいました。

次のバグ票改善として以下の3点を紹介しました。
(1)再現性:バグ票に書かれている内容を再現できるか
(2)独立性:バグ票1件で1つの問題について書かれているか
(3)中立性:思い込みや推測で書いていないか

これらの観点を踏まえて、再度同じ問題事象でバグ票の起票を行ってもらいました。
起票の仕方に変化の見られた方が何人かいらしたので、
レベルアップを体験してもらえてたらいいな、と思っております。

ワークの最後に、参加者のみなさんが抱えるバグ票についての問題について
分類してみました。

時間の都合上、それぞれ深堀りできなかったのが残念ですが、
観点ごとに解決へのアプローチが異なるので、
今回のワークがヒントになってくれると嬉しいです。

情報交換会&懇親会

情報交換会は、バグ票島の担当として、いらっしゃった皆さんと
バグ票にまつわる様々な話をしました。
じゃんけん大会では、気になっていたFearless Change本をまさかのGET!

正直これはかなり嬉しかったです。
読んで実践します!
特に「みんなを巻き込む」とか「成功の匂い」あたりが気になってます。

懇親会では、最近気になっているKPIについての疑問を色々な方に聞いてみました。
突然オープンすぎる質問をした皆様すみません。
真剣に答えてくださってありがとうございます。
自分なりの答えを試行錯誤してるところなので、
この辺は何かまとまったらどこかに書こうと思います。

JaSST Tokyo '17に参加してきました

2/3(金)AM開催のテスト分析とテスト設計勉強会と
2/3(金)、4(土)開催の2日間開催のJaSST Tokyo '17行ってきました。

■テスト分析とテスト設計勉強会

こちらは、以前書いたWACATEでのリリカルさん(@mhlyc)の疑問から発生した勉強会です。

勉強会の詳細や資料はこちらにアップされてますので、参考にどうぞ。登壇された方はどなたも発表が面白く、色々と現状の自分の理解を整理したり考えるきっかけになりました。
https://connpass.com/event/47938/?utm_campaign=&utm_source=notifications&utm_medium=email&utm_content=title_link


勉強会を通しての理解は、
テスト分析:「何」をテストするのか、対象を理解すること
テスト設計:「どう」テストするのか、テストのやり方を考え、観点とかテストケースのひな型を作ること
と私は理解しています。

分析と設計の違いは、LTで登壇されてた河野哲也さんの説明が、すごくしっくりきました。
ソフトウェアで考えると分析、設計をやる人が同じだったり、各成果物が分かりにくかったりで分解しづらい。
そこで次のような注文住宅の例を出されていたのですが、分かりやすかったです。

 注文住宅における分析
  登場人物:住宅メーカーの営業、注文主
  やること:注文主の要望のヒアリングと整理
       要望のうち、できないことの明確化
 注文住宅にのける設計
  登場人物:設計士
  やること:住宅の設計
  アウトプット:設計図

分析でやってることって、「これからしようとしていること」への理解と整理なんですよね。だから特にこれと決まったアウトプットがなく、はたから見ると分かりにくい。
会社の上司とも、分析、設計について話したんですが、MindMapだったり、何かしらのリストであったり、やはり分析フェーズのアウトプットは明確でないよね、という話になりました。
昔は「テスト観点」まとめるのがテスト分析だと思ってました。現在は、分析した結果を受けてのどうテストするかが「テスト観点」だと思ってます。ただ、観点を考えているときのモヤモヤは分析の面も入るので、この辺分析と設計は行ったり来たりを繰り返すものかなーと。いろいろやってみて、理解が変わったらまた書いてみようかと思います。

■JaSST Tokyo 2017感想
特に印象に残ったものの感想をあげてみます。

論文発表1 : テストマネジメント 「品質予測モデルの構築およびプロジェクト管理への適用事例」
 SEPGとして、品質予測モデルの構築して、3プロジェクトへ適用していったお話。モデルの作り方がすごくかっちりされているなーという印象を受けました。途中の予測モデルの構築のやり方は数式が出てきたあたりで脱落しました。すみません。。

 テストマネジメントツールSquashTMを利用した継続的テスト改善 」
 会社の後輩の発表でした!日本では適用事例が(たぶん)初となるテストマネジメントツール「Squash TM」を適用してみた時の話です。テストマネジメントツールの導入は、テストエンジニアの皆さん関心が高いようで、盛り上がった発表でよかったです。
 発表資料は、後日JaSST公式から公開されますが、今回登壇した後輩が、Squash TMの紹介記事を書いてますのでご参考にどうぞ。
 SquashTMことはじめ。
 http://qiita.com/miwakai/items/843c76e50eef7719ae6d

「VSTePのファーストステップ〜JaSST'16東北出張おかわり会〜」
テスト分析の技法であるVSTePのワークショップ。VSTePの詳細は、以前のJaSSTの西康晴さんの資料を参考に。
http://www.jasst.jp/symposium/jasst13tokyo/pdf/A2-4.pdf
今回のワークショップで扱った範囲は次の通りで、ワークのグループ毎に、みんなで納得できることをポイントに実施。
 <1>テスト観点出し
 <2>テスト観点図の作成
 <3>テストコンテナ(テスト観点をグルーピングしたもの)の作成

「みんなで納得できること」というのがミソで、これでグループ全員が戦力になれる、誰でも作ったテストについての質問を受けた時に答えられるという状態になります。

 <1>テスト観点出し
 ・面白い! 人と話すと自分になかった視点が出てくる。

 <2>テスト観点図の作成:出した観点をツリー上に整理していく

 ・<1>で出した観点を、うまくツリーに整理するのが難しい。
 ・なんとなく気になったからあげてみたとか、うまく階層化出来ない観点がいる。
 ・ツリー状にすると抜け漏れやまとめられるものが出てくる(InがあるけどOutがない、共通化できる奴はどれだ?)

 <3>テストコンテナの作成:ツリーにした観点をさらに整理、分割して意味のあるグループにする

 ・テスト計画ともリンクできるようにコンテナを作成
  →最初に確認したい基本的なパスを通すコンテナがないね!ということに気づく
 ・コンテナ間で依存関係のある奴はどれだ?
 ・コンテナで先にやっといたほうがいいやつどれだ(バグ出たときに手戻りがでかいやつ)

というようなことを、ワイワイ話しながらやるのでとても楽しかったです。納得感大事。

ちなみに「最初に確認したい基本的なパスを通す」ことを、うちではなんとなく「疎通テスト」と呼んでいるけど、ご一緒した他社の方のところだと「疎通テスト」はpingが通ることを指すんだそう。用語の共通認識って大事ですね。

テストと人工知能
人工知能を使ったシステムをテストする話と、人工知能ディープラーニングを使ったテストツールのお話でした。個人的にはMagic Potという画像認識などの技術を使ってる自動テストシステムが面白かったです。テスト実行は今後AIとかが活躍する分野になり、テスト設計や分析などのスキルが増す求められると、最後の方で話されてましたが、これは今後のスキルを考えるうえで重要ですね。

「品質保証活動の本質」
品質保証なんて言葉のないころから品質保証活動やってこられた方の話なので重みがあって面白かったです。最近はプロジェクトでデータを扱うことをやっているので、「データは提供してくれる人のために使うべき」って話には考えさせられました。自分は割とデータ取りっぱなしとか、取る目的整理できてなかったりは自分もやってしまいがちなアンチパターン。そこちゃんと考えないと品証も開発も苦しいだけですね。この点は、自分の課題です。

WACATE2016冬「あなたのためのアラカルト」に参加してきました(2日目編)

遅くなったWACATE感想2日目編です。

2日目もよく晴れて絶好の勉強日和!発表資料公開されているものはおいおい追加しておきます。

12/18(日)
-■BPPセッション「WACATEによる加速事例〜加速が止まらさんない世界」(ときわ かおり)
 <感想>
WACATEに参加してからの加速の様子や、実際に現場で何に取り組んでこられたかがよくわかるセッションでした。WACATEの半年に一回ってペースは、自分の振り返りやらアウトプットのタイミングとしてちょうど良さそうな印象を受けました。

-■問題を捉えよう 〜自律の入口へようこそ(常盤 香央里)
<概要>
 自律して問題を把握し、解決につなげていくための手法を、SaPID法に沿ってやってみるセッション。問題を捉えることから始めれば解決に近づくというところがポイント。

<感想>
ワークで、実際に自分が感じている問題を一つ書き出す、その後「それで何が困るのか」を深めてみるというのをやってみるのが、すごくよかったです。自分が問題としてパッと挙げられるものは、大体単なる事象なんですね。それによって本当に困ってることに近づくためには、さらなる問いが必要。

-■忘れたころにやってくるテスト技法 〜組み合わせテスト〜(藤原 洋平)
<概要>
1.「組み合わせテスト」
  組み合わせによる爆発
   →テストで確認したいポイントは抑えつつ、テストケース数を削減したい

  ※用語の確認
   因子:入力の条件、組み合わせの要素
   水準:因子がとりえるパターン
   有則:因子が動作や結果に影響する関係を持っている
      仕様上のかかわりがある
   無則:結果には影響しない
   禁則:実現不可能な因子の組み合わせ

  2.技法の種類
   <有則系>
   ディシジョンテーブル
   原因結果グラフ
   CFD
   ドメイン
   <無則系>
   ペアワイズ
   直行表
   クラシフィケーションツリー

   (1)ディシジョンテーブル
   (2)ペアワイズ
    ツールの紹介
    ・PICT
    ・PictMasterOA
   (3)直行表
    直行表の選び方
     ・テストの目的
     ・コスト・費用対効果
     ・因子・水準が洗い出されていること

<感想>
こちらもワークで直行表、ペアワイズをやってみたのがよかったです。設計技法は会社でも取り組んでるので、自社のテストチームで同じようなワークをやってみようと思ってます。
ただ、未だによくわかってないのが直行表、ペアワイズってどんな条件のシステムに向くんだろう、というところです。以前ペアワイズを使ってみようとしたんですが、禁則が多すぎるなどでうまく使えず、結局手でテスト項目を作ったことがありました。一緒にワークしたメンバーに聞いても、同じ疑問を持っていました。もうちょっと経験が必要なのかな。

-■伝わる報告書への第一歩(小池 香織)
<概要>
自分の取り組み、作業などをきちんと伝えるためには、どうしたらよいかというセッション。ポイントとしては、相手が何を知りたいのか、報告先がどう思うか、に注して書くこと。事実、推測、感想の3点は分けて書く。

<感想>
これもワークで行った、悪い報告書の例の訂正が面白かったです。自分の書いた文章だと悪い点に気づかないこともありますが、人の書いた文章だとよく見えるなーと。我がふり直さなければ!

-■僕らの僕らによる僕らのためのBOK等の解説(朱峰 錦司)
 1.BOKとは
  特定の専門領域についての知識体系
  →BOKガイドでまとめられている

  例)SWEBOK
    SQuBOK
    PMBOK
    REBOK
    BABOK
 2.本日のターゲット
  SWEBOK ソフトウェアエンジニアリングについての知識体系。辞書的
  SQuBOK ソフトウェアの品質についての知識体系。辞書的
  PMBOK プロジェクトマネジメントについての知識体系。
プロセスと入力・出力成果物を整理している
      →プロセエス定義のひな型にできる

<感想>
3つのBOKの概要を1時間で紹介してもらう、ちょっと駆け足気味なセッションでした。でも、各BOKの雰囲気はつかめたし、実際にBOKガイドを読んでみようという導入になりました。自分の場合は積ん読してるSQuBOKからですね。

-■シン・テストエンジニアのキャリアについて(山本 くにお)
甘口モードの資料はこちら。辛口版は参加者だけのお楽しみ。

<感想>
「QA・テストが日本の産業を救う」という熱い想いのもと、今までのキャリア失敗談を紹介してくださるセッションでした。「QA・テストが日本の産業を救う」は自分もそう思ってます。

■全体を通して
自分の興味が広がったり、日頃の疑問点を話せたりですごく楽しい二日間でした。ソフトウェアテストのプロセスに沿って広く浅くできて、自分の中でのプロセスの理解が整理でき、最初のWACATE参加が冬で自分にとってはよかったと思ってます。夏も行きたい!
夏は6/17,18だそうです!

WACATE2016冬「あなたのためのアラカルト」に参加してきました(1日目編)

12/17(土)、18(日)に行われたWACATE2016冬「あなたのためのアラカルト」に参加してきました!

会場のマホロバマインズ三浦からは富士山がばっちり!
北は東北から、南は九州まで、ソフトウェアテストに関係する人が集まってわいわいやってるのは楽しかったです!
特にWACATEはWorkshop for Accelerating CApable Testing Engineers と銘打ってるだけあって、各セッションでワークができるのがよいですね。班のメンバでグループワークなんかすると他社の方のやり方とか、自分が見えてなかった点とかが見えてきます。で、「あ!この考え方真似させてもらおう」ってポイントが見つかるのが嬉しい!

というわけで、各セッションの振り返りと感想です。

-「テストは料理だ!」(竹花 和裕
資料はこちら。

<概要>
料理に例えて、テストプロセスとは何ぞやを説明してくれたセッション。
テストに限らず、プロセスを把握しているということは
→全体を抽象化して把握できている
→全体を把握して自分の仕事を設計することができる
と いうわけでプロセスはとても重要。

JSTQBのテストプロセスはこんな感じ。
 (1)テスト計画
 (2)テスト分析
  「何」をテストするのか
  テストするものの理解
  どんな振る舞いか
 (3)テスト設計
  「どのように」テストするのか
  テスト方針の整理
  どの技法を使うか
 (4)テスト実装
  実行の方針を決定
  設計で決めたテスト技法を適用
 (5)テスト実行
 (6)レポート・評価
  ステークホルダーが理解できる用語で書く
 (7)終了作業
  振り返り

<感想>
プロセス全体について説明してもらい、その後の導入になってよかったです。ここではワークでテストプロセスの(1)〜(7)まで、自社でどのような作業とアウトプットがあるか、PFDで整理してみるというワークをやりました。他社で、どのようなプロセスの分け方をしているか、各アウトプットがどうなるのかが見られて興味深かったです。 
自分としては、
 分析:「テスト観点」
 設計:「テスト項目」
 実装:「テスト手順」「テストスクリプト
が出てくるイメージです。ただ、分析と設計についてはちょっと迷ってるところもあるので、もうちょっと整理したいですね。

-見積もり入門 規模ってなんだろう?(福良 智明)
資料はこちら。

<概要>
見積もりは、ステークホルダーに適切な意思決定をしてもらうための判断材料の提供を行うもの。
まずは、数値ができるものをもとに規模を見積もる
→規模をもとに工数や費用、工期の見積もりを行う。

規模の見積もりの方法は、
 (1)LOC
 (2)FP法
 (3)ストーリーポイント
の大きく3つ。FP法が、ユーザ視点になっている、国際的に標準化され人に依存しない、という点で広く使われている。ワークは実際にFP法で見積もり。

<感想>
見積もりは普段あまり触ってない分野なので、新鮮でした。FP法はあくまで、ユーザ視点なので、ユーザに見えない部分が見積もりに出てこないというのが自分が見事にミスってた部分でした。ワークでやってみて実感しましたが、初期段階と、ある程度設計が進んだ段階で見積もりずれそうですね。なんとなくですが、初期段階で見えてないことがありそうな感じがしました。

-幅広なテスト分析ができるようになろう(山口 寛子)
資料はこちら。

<概要>
テスト分析はなぜ必要か、どのように行うのかを紹介してくれたセッション。
 1.テスト分析とは
 (1)「何」をテストするか決める
 (2)メリット
  テストの抜け漏れ防止、テストのやりすぎ防止、テスト対象とテスト要求の紐づけ
 (3)プロセス
  ・テスト対象分析
  ・テスト要求分析
 2.テスト対象分析をやってみよう
 (1)テスト対象分析
  ・準備
   <1>テスト対象が記述されたドキュメントが存在するか
   <2>ドキュメントはレビューや、修正(適宜)されているか
  ・やり方
   <1>3色ボールペン
   <2>インプット資料の目次
   <3>6W2H
    開発 Why、What(仕様)、How to、Whom、How much
    顧客 When、Where、to Whom
 (2)テスト要求分析
  ・FV表
   テスト対象分析の内容から、ユーザストーリを挙げる
    ・目的内容
    ・検証内容
    ・技法
  ・品質特性から展開
   ISOの製品品質。非機能要件の抽出にお役立ち
  ・Ostrandの4つのView
   ユーザView
   仕様View
   バグView
   設計View
 (3)その他
  ・ゆもつよメソッド
  ・VStep

<感想>
自分としては、今回最もためになったセッション。6W2Hのワークをやってみると、あのとき出してしまったバグは、この分析やっておけばある程度防げたんじゃなかろうかと思いました。これと2日目のテスト技法のワークは、仕事でも力を入れようとしている部分にちょうど合ってます。ちょっとアレンジして社内でワークやりたいな。

  • 普段の活動がどのように役立っているか説明できますか?

 「それ役に立つんですか?」への備えとして (森崎 修司)
SQiPにみんな論文出そうぜ!というセッション。

  • ディナーセッション

おいしい夕食を堪能しながら、テストトークで盛り上がる。抽選会の商品で直行表下敷きがあったのに驚きました。ちょっと欲しかったw

  • 分科会

WACATE初心者グループに参加してきました。「開発側から見たテスト側がどう見えるか」、とか「何をテストしてほしいのかをどう引き出せばよいのか」とか面白い話題が色々。

なんだか、長くなってしまったので2日目編は別途投稿します。

JaSST2016 Tokyoに参加してきました

3/8(火)に行われたJaSST2016 Tokyoに参加してきた感想です。
有料イベントだとどこまで書いてよいのか迷いますが、当日などにtwitterでつぶやかれていた範囲では大丈夫ですかね。
当日の様子はtogetterでどうぞ。

全体としては、基調講演でIoTが取り上げられたり、OSSの品質に関するセッションがあったりで、IT業界の変化に合わせて、ソフトウェアテスト業界に求められることも以前とは変わってきたな、と思いました。

基調講演でJon Hager氏が言ってたように、挑戦しがいのある時代ですね!

特に面白かったセッションについて、ざっと書きます。

■1.基調講演
「Software Test Challenges in IoT devices
IoTデバイスにおけるソフトウェアテストの課題」 講師:Jon Hager
<概要>
IoTテストの難しさは、ITと組み込みの世界が近づくことにある。様々なセンサからあがってくるデータを分析して、使える形にして、とハードからソフトまで様々なものがつながる。
テストとしては、従来の技法が使えるため個々のシステムとして見る際は新しくないが、組み合わせてシステム全体のテストとして見ると新しい。 
IoTは様々な課題が分かるとともに、今のテストエンジニアにとっては大きなチャンスである。
 
<感想>
IoTのシステム全体のテストとしては、組み合わせが難しい。けれども、考え方としては、ベーシックなテストの技法を組み合わせて使っているという印象でした。
例で上がっていた約65,000件のテストを119件まで減らしたという事例だと、直行表や同値分割の考え方使っているのかな、など。

対象が広い分、いかにして項目を絞って品質を上げるかに、より頭を使っています。技法としては従来のものが有効なので、技法の使い方、効果的な組み合わせ方が必要だなと感じました。

■2.OSSのテスト
〜結果にコミットしてコードをコミットしてます。
モデレータ:和田卓人(タワーズ・クエスト)
パネリスト:川口 章 (ノーチラス・テクノロジーズ)asakusafw
      竹添 直樹 (ビズリーチ)GitBucket
      山本 裕介 (サムライズム)Twitter4J
<概要>
OSSの場合は従来のプロダクトと違い、開発コミュニティがあったり、他のプロダクトや環境の組み合わせが膨大すぎてテストが困難。
使ってもらいユーザが増えると、開発コミュニティも育つ。
OSSの品質保証はユーザからのフィードバックによるところが大きい。
ユーザを増やしていかないとフィードバックがもらえない。
海外からもフィードバック受けるためにドキュメントなどを英語で整備する。

<感想>
従来の製品と違い、公的な保証がない点がをどうしているのか興味があったので、とても面白く聞けました。自分たちではテストしきれないし、連携先も多いため、リリースして使ってもらい、フィードバックを受けて修正する、という流れでやっているようです。なんで、ユーザ数を増やすための英語が重要!いろんなところで言われてますが、英語はやはり重要ですね。勉強しなくては。

■3.テスト自動化1
〜自動丸になるためのルーティンとは?〜
 太田 健一郎 (SHIFT)
 永松 康能 (テルモ
<概要>
テスト自動化をやる前に、以下のことをやっておくことが重要。
1)自動化の目的を明確にする
→自動化の前にやることはないのか、とか
その問題は本当に自動化で解決できるのか、とか
2)利害関係者との調整
3)自動化することになったら、KPIを決めて関係者と合意する
→顧客、上司との合意が大事
4)最小限の範囲でトライアルする
5)利用するツールについては事前に慣れておく

<感想>
以前プロジェクトでテスト自動化がうまくいってなかった時は、3〜5がうまくいっていなかったなと納得しながら聞きました。5について、日頃ツールの情報を集めたり、使ってみたりしておかなければ1と3の話はできないですね。これも足りてないので勉強します。
 
■4.その他
情報交換会ではソフトウェアテストのコミュニティをやってる方々と知り合うことができました。本や事例を紹介していただいたり、QA女子が集まっていたりと色々と面白くなりそうな予感です。勉強会参加すると、こういうモチベーションが上がるのがいいですね!

システムテスト自動化カンファレンス2015参加してきました

12/12(日)に開催された「システムテスト自動化カンファレンス2015」に参加してきました。
2年ぶりの参加ですが、登壇者の皆様の自動化へのアツい思いや、他社での取り組み事例がきけて勉強になりとても面白かったです!

当日の様子や資料をリンクしておきます。

Togetter システムテスト自動化カンファレンス2015 #stac2015
http://togetter.com/li/912197


テスト自動化のスキルを考えよう!
〜テスト自動化エンジニアに求められるスキル、期待される役割〜

ヤマンさん(テスト自動化研究会)
早川 隆治さん(テスト自動化研究会)

このセッションでグサッときたのは
テスト自動化のライフサイクルは、ソフトウェア自体の開発ライフサイクルと同期する必要があるというところ。
自動化がなんとなく上手くいってなくてしんどかった時期は
まさにソフトウェア自体の開発ライフサイクルとあってなかった時期だと納得しました。

ここに手動テストも加わる場合は、次の3つの同期をとる必要があります。
(1)ソフトウェア開発ライフサイクル
(2)テスト自動化ライフサイクル
(3)手動テストライフサイクル

ここがエンジニアとしては頭の使いどころですね!

自動家は見た〜自動化の現場の真実〜
.reviewrc

おいしがさんによる掛け合いプレゼンが面白かったです!
確かに自動家一人だけで進めてたら、色んな要因で挫折してしまいがちだよな、
という自動化あるあるとして聞いてました。

自動化を進めるのは、ステークホルダーとの合意が重要というお話でした。

広告システム刷新よもやま話
テストが当たり前となるまでにやったこと

森下 大介さん(ヤフー株式会社MSC開発本部マーケッターPF開発部)

なんとなく開発でやりにくくて困っていたことを解決するために、
使っていた開発言語を変えたり、インターフェース定義言語を作ってしまったり
さらっと凄いことやってるな、と思ったセッションです。
# どのくらい工数とか根回しとか必要だったんでしょう。。。

楽天の品質改善を加速する継続的システムテストパターン
荻野 恒太朗さん(楽天
菊川 真理子さん(楽天

こちらも掛け合いによる茶番(?)プレゼンが面白かったです!
個人的に興味深かったのは
スライドp40のELKを使って各ツールのレポートを要約しているところ。
ELKもちょっと動かしてみたいところだし、
自分のプロジェクトでも取り入れられそうに思いました。
この辺勉強しなくては!

キーワード駆動によるシステムテストの自動化について
小井土 亨さん(SQiP 運営委員会メンバー、株式会社OSK)

キーワード駆動テストについて
データと操作をスクリプト化する。
GUIが少々変わってもスクリプト修正だけなので変化に追随しやすい。
※デモしてくれましたが、PowershellとNotePadで完結してました。
デモのソースコードはこちらで公開されています。
https://starkeyworddriventest.codeplex.com/

変化に追随しやすいというところが魅力的なのですが
これが最大限に生きるシステムってどんなものか、
というところが正直自分にはイメージが持ててません。

ですが、今後の自動テスト設計時の持ちネタとして
データ駆動テスト、キーワード駆動テストあたりは、
勉強して追っかけておく必要がありますね。

Testing Tools for Mobile App
松尾 和昭さん(クックパッド

AndroidiOSの概要の話から始まり、
クックパッドのテストする人のデファクトを変えてしまった話しに至る濃いセッションでした。
モバイル周りはほとんど触ってないので、概要から入ってもらえてありがたかったです。
モバイルはやはりOSのアップデートで破壊的変更が入るところが大変そうだな、と。

一番すごいなと思ったところは
テストする人のデファクトを変えてしまったところ。
自動化に大事なのは、啓蒙や文化づくりという点はこれまでのセッションでも出てきましたが
ここまでガラッと変えてしまえてるのは本当にすごいなと思いました。

そうだ、高野山行こう -金剛三昧院の宿坊-

せっかくの高野山なので宿坊に泊まります。今宵の宿坊は金剛三昧院。

奥の院で色々なお墓に目移りし過ぎて、連絡していた時間を過ぎてしまいました。
お坊さんが門前で待っててくださって、お待たせしてしまい申し訳なかったです。宿坊だけあって「ようこそお参りくださいました」と迎えてくださるのがよいですね。こちら金剛三昧院は世界遺産です。つまり世界遺産に泊まります!初の経験!

予約はネットで済ませてあるので、さっと確認の後、係のお坊さんが部屋まで案内してくださいます。寺部分と宿坊部分は木造の渡り廊下で繋がっています。風情ありますね。

お部屋は何だかおばあちゃん家な感じで、扇風機が近頃の白っぽいやつじゃなく、金属製の網に青い羽根のやつでした。

部屋備え付けの書物は当然仏教聖典ですよ!日英対照のところがまたいいですね。

一つ誤算だったのは、金剛三昧院が少し外れにあるせいか、携帯の電波の入りが悪かったことです。玄関あたりは普通に入りますが、自分の泊まってた部屋は圏外!ymobileは期待してなかったけど、docomoで圏外なのには驚きました。電波がないとなんとなく不安になる方には、表通りに面した宿坊に泊まることをお勧めします。あと、内鍵はかかりますが、ルームキーはない(外からは鍵をかけられない)ので、そういうのが気になる方も設備に力を入れてる宿坊を探した方が良いと思います。昔ながらの宿坊とか、世界遺産に泊まれるとか、国宝や重要文化財の側で寝られるということにドキドキできる方には本当お勧めです。

夕食は精進料理です。

17:45からと、普段の生活を考えると早めの時間ですね。ただお寺の生活リズムを考えるとこんなものかと。お坊さんが部屋まで持ってきてくださいます。配膳の時に参拝記念に数珠守りと火事除けのお札を頂けます。

ご利益ありそう!金剛三昧院の多宝塔は創建当初の姿を留めている、つまり800年火事にあってないんですよ。

さて精進料理のお夕食は二膳とデザートからなる構成で、当然肉も魚も使われておりません。あと玉ねぎなどの匂いの強い野菜もダメらしいです。名物の胡麻豆腐がつるっともちっとしてて美味しかったです。胡麻豆腐って、てっきり豆腐の一種だと思ってたのですが、実は全然別物だそうです。胡麻豆腐は胡麻を練って葛で固めたもので、加熱すると溶けます。初めて知りました。揚げ物や煮物も上品な薄味で美味しかったです。煮物は高野豆腐入り。さすが高野山。歩き回ってお腹が空いてたので、お櫃(茶碗3杯分)を空にしちゃいましたけど、基本的に消化に良いものばかりなので、翌朝ちゃんとお腹が空きました。お膳を下げる時に、布団も敷いてくださいます。サクッとお風呂に入って、お土産とか調べて翌日の予定立てるか、と思ったら圏外w雨の中歩き回った疲れもあったので、早々に寝ました。翌朝の勤行に遅刻するわけにもいきませんし。

宿坊に泊まる醍醐味の一つは、朝のお勤めに参加できることです。6:15に館内放送でお勤めの時間を教えてくれます。BGMに声明が流れてました。どことなく、賛美歌と響きが似てる気がします。洋の東西問わず、祈りを捧げるメロディーって似たものになるのかな。勤行が行われる本堂は宿坊とは反対側、行く途中の部屋にある襖絵も美しかったです。

本堂に入ると既に何人かの方が待っておられました。正座に耐えられるか心配でしたが、椅子が用意されていて一安心。勤行は圧巻。清少納言がいい声のお坊さんが読経してるのっていいよね、みたいなこと枕草子で書いてましたが、まさにその通り。
読経がひと段落すると、お坊さんが位牌堂と御本尊の説明をしてくださいます。位牌堂は全国の信徒さんから位牌を預かっているそうで、入口以外の三方の壁にずらりと位牌が並んでいるのはなかなか壮観でした。鎌倉将軍家、足利将軍家や土佐の長宗我部家のものもあるそうです。ご本尊は源頼朝が運慶に造らせた愛染明王。前をカッと見据えてて、力強い感じがしました。本尊左には頼朝と北条政子夫婦の位牌、右には室町幕府初代将軍足利尊氏とその弟、直義の位牌。お寺の紋として引両紋(足利将軍家の家紋)が使われてるのは、菩提寺だったからだそうです。基本的に内部拝観はしてないようなので、こちらを見られるのは宿泊者の特権ですね。眼福です。

朝のお勤めの間に部屋に朝食を準備してもらえます。朝ももちろん精進料理。飛竜頭(がんもどきのこと)がお出汁がしみてて美味しかったです。

チェックアウトの前に境内を拝観。多宝塔、経蔵、六つ杉と、お寺の境内には鎌倉時代からずっと存在し続けているものが多数あり、歴史を感じます。少し外れにあるのが幸いして火事や落雷を免れたんですね。また、このお寺に弟子入りしてた天狗が火事から守ってくれているそうです。参拝記念に頂けるお札はこの天狗のです。
多宝塔は、しっかり建ってる感じがして、北条政子のイメージと被ります。近づいてみると、ちょっとあちこち修復した方が良さそうな感じがしました。

経蔵は校倉造だそうです。

東大寺正倉院に使われている建築様式です。正倉院以外で使われてるの初めて見ました。屋根の苔むし具合とか、杉に囲まれて静かに中の経典とかを守っている姿とか良いですね。

お寺を発つ前に、ちょっとばかり寄付。文化財を守るために使っていただければ幸い。
「ご寄付された方は、額の大小にかかわらず、お人形を一つお持ち帰りください」、とのことだったので、うめ吉をゲットしてきました。

なんだか珍しい旅の思い出です。