アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その3
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその3になります。
前回は「アジャイルテストの4象限」について書きました。
今回は「テスト自動化の阻害要因」についてです。 自動化というとQA/テストエンジニアとって、実現すればあらゆる苦行から救ってくれる魔法のように思えてしまいますが、果たして実際のところはどうでしょうか。 どういった効能があり、どういった阻害要因があるのかについて、学んだことをアウトプットしていきます。
では、そもそもなぜ自動化する必要があるのか？という点から始めたいと思います。
なぜ自動化するのか？
本節にでは自動化する理由が8つ挙げられています。
- 手動のテストは時間がかかりすぎる。
- 手作業は間違いを起こしやすい。
- 自動化は人々を自由にし最高の仕事を行えるようにする。
- 自動化されたリグレッションテストはセーフティネットを提供する。
- 自動化されたテストはより早く頻繁にフィードバックを与えることができる。
- コーディングをこれまで以上にできるようにするためのテストと例。
- テストが文書化を提供してくれる。
- 自動化は投資上の十分な見返りがある。
（P256 13.1 「なぜ自動化するのか？」より）
ふむふむ、自動化を試みようとするエンジニアは大半が上記のようなことが「できたらいいな！」と思うのではないでしょうか。（しかしながら、いささか多くを求めすぎでは・・という危惧も抱きます。）
気になったものについてピックアップしてみます。
- テストが文書化を提供してくれる。
静的な文書を最新の状態に保つことは難しいことです。しかし、もしシステムが変更された際に、自動化されたテストを更新しなければ、テストは失敗します。私たちは、ビルドプロセスを「グリーン」に保つために、それらを更新しなければなりません。自動化されたテスト>は常に、私たちのコードがどのように動作するかを正確に書いたものであるということを意味します。
（P262 13.1.7 「テストは偉大な文書化である」より）
これはテストケース自体が仕様書になるといっているのだと思いますが、この考えは絵に描いた餅になりがち・・・。新鮮な状態に保ち続けるのはなかなか難しいと思います。 テスト対象の規模や歴史が積みあがってくるごとに増していく自動テストケース。重複するコードを共通化してシンプルにするも、新たな機能に対応していくうちにどんどんとメンテが困難になってしまう、なんてことは自動化あるあるではないでしょうか。
さて、自動化するにあたっていろいろな心配事が湧き上がってくると思います。これらは「自動化を妨げる障害」として著者の経験が纏められています。
自動化を妨げる障害
- プログラマの姿勢
- 痛みのこぶ
- 初期投資
- 常に変化するコード
- レガシーシステム
- 恐れ
- 古い習慣
（P263 13.2.2 「私たちのリスト」より）
これらについては一つずつ見ていきたいと思います。
プログラマの姿勢
ここではプログラマの姿勢について論じられています。
従来的なチーム編成ではDEVチームQAチームといった具合に別個の組織として存在しており、DEVチームは機能テストの自動化についてまったく考えたことがないでしょうと言っています。 アジャイルな体制においてはDEV, QAといった役割を超え、一体的な体制で開発していくことが良しとされているため、そのような意識では困りますよ！ということです。
また、自動化用のコードを実装する場合にはDEVよりの経験が必要となるため、プログラマにもQAレイヤーでのテストに対して積極的な姿勢が必要です。
痛みのこぶ
（特にテスト自動化に限ったことではありませんが）初期段階においては多くの時間がかかります。 これを時間に対する作業量のグラフとしたとき、ポコッとこぶがあるような見た目になります。
この状態を乗り越えるには適切な指導やマネジメント層の支援も必要となってきます。適切な指導/支援が受けられる環境であれば、組織としてテスト自動化への積極的な取り組みが行われているように思えますね。こぶも小さなものとなりそうです。
初期投資
自動化を始めるに当たってはどのような技術を使って実現するのか、十分な検討が必要となります。
自前で作ったものをフレームワークを使用するのか、すでにあるものを使うのかどうか。 高価なソフトウェアを導入しても、実現したいことに対してはオーバースペックである可能性もあります。
十分に評価できる時間（つまりはお金ですね！）を事前に投資できるとよりよい成果をうみだせるのではないでしょうか。
常に変化するコード
GUIに対しての自動化は困難を伴うと予測されます。なぜなら頻繁な変更がおこなわれ、その都度追従していくのは多くの手間がかかってしまうからです。
このような状況を改善していくにはプログラマとテスターの協調関係をより強めることが必要といっています。頻繁に変更が行われたとしても、機能としての意図は大きく変わらないはずなので、そこに着目してテストを編成していくのがよいとしています。
たとえば何らかの計算をする機能であれば、適合するテストデータをあらかじめ用意しておき、それを流し込むテストコードを変更に強い設計にしておく、といったことなのかと思います。
レガシーシステム
過去に実装されたコードにはテスタブルな状態にないものも存在します。これらはリファクタリングするなどしてテスト可能な状態に持っていくことが重要ですが、新規開発も行いながら過去のコードも触っていくというのはなかなか困難な作業となります。
実現にあたってどのような戦略を持てばよいのか、次の章で紹介されていますので次回のエントリでアウトプットしていきたいと思います。
恐れ
この項は著者の思いがかなりでているところなので、原文を引用します
プログラミングを行わないテスターはアジャイル世界において提供するものが何もないと、しばしば言われてきました。私たちはそうではないと信じています。どのように自動化すべきかをテスター個々人が心配する必要はないのです。これはチームの問題です。
（P268 13.2.8 「恐れ」より）
それぞれの知識を持ち寄って、協調していくことにより、恐れをはねのけていきたいですね！
古い習慣
困難にさいなまれたとき、ついつい居心地のよい古い習慣に戻ってしまうことがあります。インクリメンタルな自動化を行っていくべきところで、毎回手動でのテストを実施するようになってしまう、といったことです。これでは変化への柔軟性に大きく影響が出てしまう恐れがあります。後々大きなバグが生み出され、ビジネスにも影響してしまう可能性があります。
まとめ
今回の章は「テスト自動化」についてのものでした。記述内容からどのレイヤーなのかがちょっとわかりづらいところもありましたが・・、ざっくりとまとめると・・。
- 自動化によって開発工程におけるセーフティネットが築ける
- ネガティブな阻害要因は必ずでてくるが、恐れずチーム全体で解決していく
と理解しました。
次回は・・・
テスト自動化にあたっての戦略について、アウトプットしてきたいと思います！
ではまた次回。
アプレッソ品質マネジメント部に9月（去年）からJOINしました
どうも初めまして、こんにちは。9月にJOINしました、金森と申します。 9月といっても、去年の9月、つまり一年越しの自己紹介となってしまいました。 物凄く遅くなってしまい今更感がありますが、この場を借りて簡単な自己紹介をさせていただきたいと思います。 ネット上でこうやって自己紹介することは初めてなので、結構緊張しています 笑
職歴について
アプレッソ入社前までは中小のSIerにてテストや開発を行っていました。 最初はアパレル関係のシステムのテストに一年ほど従事していました。 その後、物流会社のシステムに携わり、そこでDataSpiderに出会いました。 DataSpiderを使っていた、またテスターとしてもっと頑張りたいと思いアプレッソ品質マネジメント部にJOINしました。
DataSpiderを使ってみて
実際にDataSpiderを使って一番良かったと感じたことは、比較的経験の少ない人でも使え、使い方を覚えれば容易に開発できることであると思いました。 所属していたプロジェクトは私含め経験の浅い人が多かったのですが、開発がスムーズに進みました。 使い方もそれほど複雑ではなく、どんな人でも開発ができることは最大の長所であると感じました。
アプレッソにJOINして・・・
アプレッソに入社して約1年、テスト実施に携わっていました。 そこで感じたことですが、まずQAチームという立場からテストができることが良いことであると感じました。 前職で比較的小規模なプロジェクトに携わっていたのですが、そこでは自分で作成したプログラムを自分でテストしていました。 そのため、どうしても見落としてしまうことがありました。 なので、開発だけでは見つからない不具合を別の視点から発見できることがいいことであると思いました。 また、前職で携わっていたプロジェクトで、開発とテスターの力関係が開発 > テスターという力関係のプロジェクトがありました。 そのような風潮がないことも良いことであると感じました。
これから
現在開発全体でスクラム体制を取り入れ、アプレッソQAチームはその中でQAがどう関わっていくかを常に考えています。 私もテスト実施者としてどのように表現するかを常に考え、日々精進あるのみです。 自分の知らないことをやることは大変ではありますが、それと同時に楽しいことでもあります。 以上、簡単ではありますが、自己紹介とさせていただきます。 今後ともよろしくお願い致します。
追伸
10月からジョブローテーションで2か月ほどサポートチームに移ります。 気持ちを一新し、頑張っていきます。
趣味とか
ゲーム（ポケモンとかが好きです） 野球観戦（横浜DeNAベイスターズのファンです、久しぶりのAクラスで嬉しいです）
JavaOne 2016 3日目 & 4日目 - Message in the (Panama) Canal
こんにちは、開発部の野口です。
案の定 3日目のレポートは飛ばしてしまいましたが……巻き返していきます。 例によって、特に印象に残ったものをピックアップしてお伝えします！
Connecting Oceans with Project Panama: A Journey into Native
JNI の置き換えや Vector API の追加を目指す Project Panama についてのセッション。
Project Panama という名前は（ご想像の通り）北アメリカと南アメリカの境にあるパナマ運河からきていて、”connecting the gap” をコンセプトとするプロジェクトです。つなぐのは、Java と Native との間の gap、ですね。
Project Panama は JDK 9 には入りません。
JDK 10 以降でのリリースを目指して、鋭意研究開発中です。
野心的な機能が色々と含まれますが、すべてを実装し尽くしてから出すというよりは、部分的に使えるようにして、早くリリースすることを目指しているそうです。
Java と Native とをつなぐ、安全で、簡単に使える、高速なインタフェースを構築することが大きな目標です。
Java がネイティブコードと連携するための方法としては JNI があり、また JNA をはじめとする、JNI の使用を容易にするためのライブラリも広く使われています。
Project Panama は、それらを「安全性、使用の容易さ、速さ」の 3 つの面で超えることを目指します。
よくばりですね！
簡単なデモもありました。
jextract というツールで C のヘッダを読み込んで自動生成されたクラス群を使って、OpenGL のライブラリを呼び出します。
▲ネイティブっぽい雰囲気の Java コード
実際のコードを見ると、想像以上にネイティブコードっぽい Java コード、つまりネイティブとの一対一対応に近いラッパーを Java のクライアントコードから触ることができていて、これらのクラス／インタフェース群がすべてコマンド一発で生成されるのだとしたら、かなりナイスです。
安全性についても色々と考慮されており、さらにこれでパフォーマンスも JNI を上回るとしたら……。
AutoCloseable や 関数型インタフェースといった近年 Java に入った機能も大いに活用して設計されており、たしかにこれならやれるのかも、と期待が持てます。
ただし、あくまで研究開発段階ということで、今後仕様や設計が変わる可能性は大いにあるとのことです。
実際、セッション終わりの質問タイムも紛糾しました。
まだまだ課題は山積みのようですが、業務上 JNI のつらさを味わうことがちょいちょいあるので、期待したいところです。
Thinking in Parallel
Stuart Marks と Brian Goetz というグルーヴィーな登壇者による、並列処理についてのセッション。
今後入る予定の新機能についての議論があるかなとも思っていましたが、案外そういうのはなくて、基礎的な内容でした。
にも関わらずここに書いているのは、とても面白かったから！
大まかに言って、前半は Stuart が Stream API の価値について説き、後半は Brian が並列処理についての議論をするという段取りでした。
ごく簡潔にまとめてしまうと、Stuart の主張は、従来の for ループを使うよりも、Stream API を使用するほうが常によい。
理由は、新しいから、カッコいいから、関数型だから……ではなく、「抽象性のレベルが（for ループよりも）上だから」。
ごもっともです。
たとえば C を使わずに Java を使うのと（細部にこそ違いはあれ）同じなのかなと思います。一方で、「それでも Java でなく C を使うケース」というのもあることを考えると、完全な論理ではないとも思いますが、少なくとも、（C 言語を使うのに十分な正当性が必要であるように）for ループを使うのには十分な正当性、たとえばパフォーマンスのボトルネックであることが特定されているとか、が必要と言えそうです。
一見 Stream で処理するのが難しそうな「値のリストをチャンクに分割する処理」も、「インデックスのストリーム」という考え方を導入することで Stream で処理できるよ、という例には目を開かされました。*1
それから、後半の Brian の主張はというと、こちらは「並列化するほうが常によい」……ではもちろんなく、必要なときにだけすべし、でした。
理由は、「並列化は最適化だから」。はい。
並列化はたいてい、メモリ空間と効率（省エネ）を犠牲にして、スループットを向上させるために行います。よって、その費用対効果が十分だと判断できる場合以外には、すべきではありません。
Stream API は並列処理をサポートしています。
ここで、Stream API で並列処理によってスループットが上がる可能性があるための条件として、
- データの数が多く、一件あたりの処理コストも高いこと
- データの（メモリ上での）局所性が高いこと
- 処理の分割コストが低いこと
- 最終的な処理結果の統合コストが低いこと
- 順序に依存しないこと
が挙げられていました。
美しいリストです……。
もちろん、これらの要素を感覚で判断して決めてしまうのではなく、実データ（少なくとも、それに近いデータ）による実測が必要です。（最適化ですから最適になっていることを確認しないと！）
なお、上の議論は値の計算処理を前提としていて、I/O が絡む場合は少し変わってきます。
Let’s Get Lazy: Explore the Real Power of Streams
『アジャイルプラクティス』や『Java による関数型プログラミング』などの著書を持ち、JavaOneでも例年数多くのセッションを担当している Venkat Subramaniam による遅延処理についてのセッション。
去年は縁がなく、今年初めて彼のセッションを取ったのですが、さすが期待通りの内容でした。
まず Haskell の動作や Scala の lazy キーワードによる遅延評価を紹介したのち、Javaでは Supplier のラムダ式で同じようなことができるよね……、といった具合に、一歩一歩下地を作ります。
個人的には、評価した値を再利用するパターンも何か紹介してくれるかなと期待していた（結局なかった）ので、そこにはやや不満もありましたが、全体としての構成と運びが見事すぎて、帳消しになりました。
後半は、Stream API がいかに lazy であるかの紹介。
Stream は終端処理が呼ばれるまではあくまでパイプラインを組むにすぎず、各種の条件（filter）や変換（map）は終端処理を呼んだ時点でまとめて処理されます。
そのため、個々の処理が行われる回数は、従来の for ループで効率的にロジックを組んだ場合とまったく変わらない。ということを、実際の動くコードで、デバッグプリントも使いながら巧みに説明します。
▲なんかペンみたいなやつでパイプラインを示す
▲デバッグプリントでどのロジックが何度呼ばれたかを示す
どれも既に知っていることなのですが、よく整理された説得力のある説明で、知識が更新され、定着していきます。
終盤には無限ストリームを説明し、またリストを返すメソッドをストリームを返すメソッドにリファクタリングすることで、行われる処理の量（実行時間）を大きく削減するというデモも行いました。
この辺のコンセプトは彼の著書である『Java による関数型プログラミング』でも説明されている（されていた……はず）のですが、こうして説明を受けることで本当に明日から使える知識になります。
こういうところ（すぐれた教師の教えを直接受けられること）にも、JavaOne のような技術カンファレンスの価値はあります。
Ask the JDK Architects
去年も色々な面白トークを聴くことができたこのセッション。
今年は Mark Reinhold、John Rose、Brian Goetz の 3 名が登壇して、参加者からの数多くの質問に答えました。
▲The JDK Architects
今年のキーノートでまさに Brian が発表していたローカル変数の型推論について、去年も話題に上がっていた（気がする）「Java で一番後悔していること」、果ては彼らが好きな IDE まで……。
いくつかピックアップして紹介したいのですが、いまいち聞き取れなかったところの補完をするのに手持ちの iPhone *2 だけでは心許ないので、日本に帰ってから補足します！！
Oracle Appreciation Event
そして……会社から JavaOne 行かせてもらってる組として役得としか言いようのないこのイベント……！
▲今年は AT&T パークで行われました
Sting のステージ開始から 2 曲目で早々に Gwen Stefani が（再）登場し、一緒に「Message in a Bottle」を歌うなどしていました。
別々のスターが同時に二人ステージ上にいる状況に混乱して、少し泣きそうになりました。
▲Sting & Gwen Stefani!!
JavaOne 2016 も残すところあと一日。
最後（蟹 One）まで気を抜かず、励みます。
JavaOne 2016 2日目 （その2）
こんにちは、開発部の陳です。
同行している野口とは選んでいるセッション構成が少し違うので、 そのうちに印象の深いものを、2日目レポートの裏番組でお送りします。
Pick Diamonds from Garbage
セッション名の通り、ゴミ（GC ログ）からダイアモンド（有益な情報）をあさる方法を紹介するチュートリアルでした。
構成は順に、 KPI の説明、GC ログの読み方、ツールの紹介、Q&A になっています。
GC の KPI を説明するのに、 バカンスでサンフランシスコからハワイに行くのに、 戦闘機と旅客機どっちが適切かという面白い比較をしました。
- Latency = 一人の乗客を運ぶのにかかる時間 / GC pause time
- Throughput = すべての影響を考慮した上で、24時間で運べる乗客数 / useful works
- Footprint = 一人の乗客を運ぶのにかかるコスト / CPU, memory
この例えは一見奇抜ですが、GC を広い意味でオブジェクトの移動として捉えれば、納得できます。
そのあと GC ログの読み方を紹介したが、
- Java の実装ベンダー
- JVM バージョン
- GC アルゴリズム
- 起動時引数
によって、形式だけでなく含まれている情報もかなり違うという無情な現実を突きつけられました。
さらにその現実の残酷さを実感するため、ここでこの曲を流しました…
最後に現実との戦いに生き残るため、いいツールを紹介してくれました。
GC ログをアップロードすると、人が読みやすい形式テーブルやチャートに変換してくれるほか、 さらに統計情報や、GC の動きを分析して、可能な問題点を洗い出すという便利なツールです。 REST API も提供しているので、パフォーマンステストを含む CI に組み込むと幸せになるかもしれません。
Functional Data Structures With Java 8
Zeroturnaround の Oleg Šelajev さんが、Java 8 ベースの「関数型データ構造」を紹介するセッションでした。
コレクションを関数型の手法で実装するという素敵な試みで、 個人的（主に情報学的な観点）にはとても面白い内容だと思いますが、 普通の Java 開発者が普段の仕事でプロダクションコードで使う場面はあまりないでしょう…
セッションのスライドはこちらで公開されています。
Disciplined Locking: No More Concurrency Errors
Checker Framework の中の人、Werner Dietl 先生と Michael Ernst 先生によるセッションで、
主に @GuardedByアノテーションの使い方とコード検証にまつわる話でした。
@GuardedByは 2006 年に Java Concurrency in Practice の作者、Brian Goetz さんが提案したもので、
データ競合を防ぐためのロックを文書化するためのアノテーションで、いまやデファクトスタンダードになっています。
しかし、このアノテーションには正式な定義がないため、解釈によって意図した使い方と異なる実装になる可能性があるので、
このセッションで、@GuardedBy の定義を厳密化したうえで、Checker Framework によるソースコード検証方法を説明しました。
ちなみに、このセッションの元ネタとなる論文はこちらです。興味のある方はぜひご一読を。
裏番組も（たぶん）つづきます
初日の会場の寒さに負けて、風邪気味になってきましたが、体力がある限り更新続けて多くの情報をお届けしたいと思います。 もし体力が尽きてダウンになったという事態になったら…まあ、その時にまた考えます。
JavaOne 2016 2日目 - JDK 9 がくるよ（7 月に）
こんにちは、開発部の野口です。
今年も JavaOne にきています。（二年連続二回目）
というわけで 2 日目のレポートをお送りします！！
と、バシッといきたいところなのですが、不覚にも PC の AC アダプタをうちに忘れてしまい、iPhone で書いています……。
ので、特に印象に残ったものをダイジェストでお伝えしてまいります。
JDK 9 Language, Tooling, and Library Features.
JDK 9 の最新状況もろもろをダイジェストで伝えるセッション。
さすがに人気でした。
1 年前にはちょうどこの JavaOne 2016 の期間中にリリースされる予定だった JDK 9 は、その後リリース計画が半年ずれ込んでいましたが、最近さらに延期の提案がされ、現在は 2017 年 7月の見込みのようです。
気を取り直して、内容はというと、まず Modularity（Project Jigsaw）の話、それから JShell や 新しい Javadoc などツールの話、言語への変更について、ライブラリについてのアップデート、そして最後に Q&A という構成でした。
私は、リリースがまだ先ということもあって、JDK 9 のことは今まであまりちゃんと追っていなかったのですが、今こうしてキャッチアップしてみて、やはり JDK 8 ほどのインパクトのあるアップデートではないのかな……というのが正直なところです。
とはいえ、大きなものでは Jigsaw による依存性管理の改善をはじめ、Java がより使いやすくなる地味ながら着実な変更が色々と入ってくる印象です。
個人的には、Java で REPL が使えるようになる JShell がなんとなく想像していたよりも便利そうで、ワクワクしています。
コマンドライン上で評価した値に（自動的に割り振られる）「$1」のようなシンボルを通して簡単にアクセスできたり、メソッド名を途中まで入れてからタブで候補の一覧が表示されたりと、軽快なデモを見ていると、触ってみたくなる感じでした。
動画が上がっています。
JShell のデモがこの動画の 12:40 からなので、ぜひ見てみてください。（もちろん JDK 9 の Early Access を入れて触ってみるのもよいです！）
また、Javadoc でインクリメンタルサーチが使えるようになるのも地味に嬉しいですね。裏で Java が……ということはさすがになく、JavaScript で実装されているそうです。
スライドも上がっています。
色々と詳細な情報が記載されているので、気になる方はぜひチェックしてみてください。
The Diabolical Developer’s Guide to Performance Tuning.
「Diabolical Developer（悪魔の開発者）」というやばそうな肩書を持つ人によるやばそうなセッション……のはすだったのですが、Java Champion の Kirk Pepperdine が登壇していました。
といっても、もともと予告されていたこのセッションの内容が Kirk Pepperdine のパフォーマンスチューニング手法を紹介するものだったので問題なし。
結果として、とても充実した内容でした。
パフォーマンスチューニングの王道に沿って（測る、仮説を立てる、少しだけ変える、測る、仮説を立てる……）問題を絞り込み、JVisualVM をはじめとした定番のツールを使って探り当てるという、言葉で説明してしまうとなんてことない内容なのですが、目の当たりにすると実に鮮やかです。「こうやってやればいいんだ！」という感動があります。
その考え方や手法自体は、今回のものではないですが、以下のスライドに紹介されています。
また、やはり今回のものではないのですが、今回のセッションに似た構成のセッションのビデオも見つけました。
解像度が低くて画面がよく見えないので少し辛いかもしれませんが……雰囲気は伝わるかなと思います。
Learn About DI and Web Frameworks Through Implementation
最後に紹介するのは、日本ではおなじみの、きしだなおきさんのセッション。
BOF（Birds of a Feather）というユーザセッションの枠で、入場チェックも特にないなどざっくりした運用の中、始まる少し前までは人もまばらだったのですが、始まる頃にはそこそこの人が集まっていました。
内容は、ドンズバでこれです。
私もこの記事は一度ざっと読んではいたのですが、改めて一歩一歩着実な説明を直接聞くことで、理解が浸透しました。
きしださんは（アメリカでセッションを担当できるからといって）特別に英語が得意というわけではなさそうで、セッション中少し言葉に詰まる場面もあったのですが、参加者は終始興味深く聞いていたように思います。実際、とても面白い内容でした。
しっかりした内実があれば多少言葉が苦手でもやれる国（アメリカ）、あるいは業界（IT）なのだよな……という思いを少しだけ強くしました。
つづきます
JavaOne はまだまだ続きます。
時差ボケもあり、私も同行している陳もへたり気味なので更新を続けられるかはなはだ不安ですが……！
そのへんのチャレンジも一種のエンターテインメントとしてお楽しみいただけると幸いです。
JavaOne 2016 1日目
こんにちは、開発部の陳です。
サンフランシスコで開催される JavaOne 2016 に来ています。
初アメリカで若干心細いですが、去年参加した野口も同行しているので、 いざとなれば経験者の知識に頼れば問題ないでしょうという気持ちだから、割りと気楽にやっています。
世間話はここまでにして、初日の状況を簡単にレポートします。
午前中のセッション
去年の教訓を活かして、ちゃんと事前に登録して、参加してきました。 ただ、時差ボケが心配なので、午前中は11時開始のセッション一つだけにしました。
参加したのはユーザグループフォーラムセッションの Coding with the Best: Learn How Great Developers Code Their Lives [UGF7870] です。
主な講演者の Bruno Souza さんは JUG の活動以外に、 Code 4 Life というサイトを運営していて、成功した開発者たちの経験をもとに、 開発者を志業とする人々がより簡単になりたい理想な自分になれるよう、 アドバイスなどを発信しています。
このセッションはまさに Code 4 Life の元ネタとなる開発者たちが経験を共有してくれるという内容でした。
似ているような経験を持つ開発者なら共感できるでしょうけど、 自分的には一人ひとりの話が早すぎて、内容も発散しているようで、 結論が見えていないうちにに終わってしまいました。
文章として書かれているものがあれば、もう少し追えたかもしれないが、 ここらへんはディスカッションという形式の制限かもしれません。
セッションの最後に出てきたチェックリストはいくつ具体的な建言が書かれていて、 以前読んだアプレンティスシップ・パターンを思い出させてくれました。
この本が未読の方は、Code 4 Life に登録してみるのもいいでしょう。
- 教訓：スライドのないセッションはつらいです。何も把握していないうちに終わってしまうかもしれません。リスニングによほどの自信がなければ、スライドのあるセッションに行きましょう。
昼休み
日曜日に JavaOne 弁当がないのは知ってましたが、朝来る途中にお昼買っておくのを忘れました。 午前中のセッションと Key Note の間に 30分しかなくて、会場の近くも店が少なかったので、 結局ちゃんとしたお昼を食べられませんでした。
- 教訓：日曜日（初日）は午前中のセッションに行く前に、お昼買っておきましょう。
Key Note
一言でまとめると、「火星探査は熱い！会場は寒い！」に尽きます。
開幕：Java の３つのＥ
最初は Java の３つのＥ ― Easy, Efficient, Expansive ― を軸に、 CERN、gatk、Twitter、Databricks などの企業や組織の事例を交えつつ順調に説明をこなしてきました。
しかし、Anita Sengupta 博士が登壇してから、 完全に NASA のイベントになったかのように、火星探査機にまつわる話しか出てこなくて、 火星の話は面白いけど、肝心な Java はいつの間にか完全に地球の重力圏から去ってゆきました。 そして Java が遠くに離れていくにつれて、会場の温度（物理的に）もどんどん下がって行きました…
寒すぎて生きていくのがつらいと感じた頃、やっと Java の話が再開しました。
火星のあとは引き続き Wavefront の事例があって、説明自体はかなり短いけど、 技術的に面白いことをやっている雰囲気が結構出ていました。
本番： Java SE 9
３つのＥの話が終わったあと、 Mark Reinhold さんが登壇して、Java 9を簡単に紹介しました。
JShell のデモには少しトラブルがあったけど、見せてくれた * タブ補完 * import によるパッケージ追加 は便利で使いやすようです。（JShell を使う場面自体は少ない気がするが）
JShell のデモにつづいて、Jigsaw の話に入って、jlink で小さめの JRE を自作する実演をしました。
そのあとは Brian Goetz さんが登壇して、少し Valhalla と Panama を紹介したあとに、短い本番が終わりました。
終局： Java EE 8
Anil Guar さんが Java EE 8 の進展と Java EE 9 のロードマップを説明したあとに、 パートナーが登壇して事例や意見を共有する形で終わりました。
ちなみに登壇したパートナーにはいつも Java Day Tokyo / JJUG でおなじみの富士通の数村さんと、 今年の Java Day Tokyo で事例紹介で登壇した興和損保の浦川さんの姿がありました。
感想
連続何回か Java Day Tokyo に参加してきたせいか、 現場で聞くキーノートのワクワク感がだいぶ薄れてきました。 そして、楽しい火星探査のおかげで、クダクダです。 さらに、会場が寒すぎて、途中で頭が痛くなってきて、話があまり頭に入りませんでした…
- 教訓：会場内でも防寒対策をしっかりしましょう。
追伸
JavaOne 2016 のサイトのオンデマンドビデオは火星探査の部分を切り出して別ビデオとして編集したものになります。 キーノートの内容を把握したいなら、こちらのほうがおすすめです。
アジャイル開発になったらQA担当者はどうなるの？ 〜「実践アジャイルテスト」で学んだこと〜 その2
こんにちは、品質マネジメント部の磯です！
書籍「実践アジャイルテスト」にて学んだことをアウトプットしていくエントリその2になります。
前回は「文化的なチャレンジ」について書きました。
さて今回は「アジャイルテストの4象限」についてです。
アジャイルテストの4象限
上記の図には様々なテストタイプが記載されています。個々のテストはおなじみのものかと思いますが、アジャイルテストではこれらをQ1～Q4に区切り（Four-quadrant）整理しています。また、これらは開発工程が進むごとにQ1から順繰りに実行するものではなく、現状にて必要なテストを選択するものであるのが特徴かと思います。一つずつみていきましょう。
Q1：チームを支援する技術面のテスト（P107〜より）
- 代表的なテスト：単体テスト、コンポーネントテスト
開発チーム内での開発そのものを支援するテストになります。これらは「自動」と記載されているとおり、自動化が容易でより多くより速くテストの実施が可能であるとしています。
また、「チームは継続的インテグレーションやビルド、テストプロセスをセットアップすべきです。それによってフィードバックをできるだけ早くすることができます。」（P125 7.6 「まとめ」より）
Q2：チームを支援するビジネス面のテスト（P127〜より）
- 代表的なテスト：機能テスト、ストーリーテストなど
開発対象がビジネス面での要求を満たしているかのテストになります。「自動と手動」とあるようにものによって自動化が容易なもの、難しいものがあります。要求は以下のように導き出すとしています。
「ストーリー 」+ 「例」+ 「会話」 = 「要求」
上記は顧客より提示されたストーリーに対して、「こういった場合は？」などと例をだして「会話」し、「要求」を持ち引き出すという意味になります。
本象限でQA担当者が貢献できる重要な部分として、「顧客が、達成の条件を表現すること、各ストーリーの期待される、もしくは期待されない振る舞いの例を作成することを助けること」（P148 8.7 「まとめ」より）としています。
Q3：製品を批評するビジネス面のテスト（P189〜より）
- 代表的なテスト：探索的テスト、シナリオテストなど
開発対象をビジネス面から批評していくテストになります。今風にいうとユーザー体験についてのテストまとめた象限と理解しました。
これらのテストタイプは実際に人の目で見ていく、批評していくことが重要とされており、自動化は適さないと言っています。しかし必ずしも全て手動にて実行する訳ではなく、必要なテストデータの作成といった部分では自動化の余地があります。
顧客へのデモもこの象限に含まれます。
Q4：製品を批評する技術面のテスト（P217〜より）
- 代表的なテスト：パフォーマンステスト、「～性」テスト
非機能要求についてまとめた象限になります。ここでいわれている「〜性」テストとは「保守性」、「可用性」といったISO9126に含まれるものを指しています。
「非機能テストについて考える時間はリリース計画時やテーマ計画時です。必要に応じて小さな反復を繰り返しながら、早めに計画を始めましょう。」（P222 11.3「いつやるのか？」より）とありますが、たとえばストーリーとして「ボタンを押してから最長5秒以内に結果が出力される」といったものがあった場合、実施が検討する価値があると思われます。
まとめ
以上が「アジャイルテストの4象限」になります。
先にも書きましたが、順繰りに実施していくわけではなく、現状に適したテストを各象限から選択して、様々な範囲の観点からインクリメンタルに品質を作り込んでいくということが理解できました。第4象限については実施するタイミングが難しい気がしますが、しっかり見極めてトライしていきたいですね。
次回は・・・
アジャイルテストにおけるテスト自動化について書いていきたいと思います。
ではまた！
