NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'18 Tokyo

A1）基調講演
「Advances in Continuous Integration Testing at Google」

概要

本セッションでは、Googleのテスト事情と、コスト削減やスケジューリング改善などの課題を解決する最新の研究内容について、Micco氏が語った。

テスト事情

Googleでは、テストを大切にすることが文化になっている。社員がトイレにテストのテクニックを貼ったり、Google Testing BlogやGTAC(Google Test Automation Conference)で情報を発信したりしている。また、新規採用の際は、コードだけでなくコードに対するテストも書けなければならない、という方針をとっている。

Googleには手動のテストが専門のエンジニアは存在せず、すべてのテストは開発者自身の手で、自動テストによって行われている。これは、Googleの開発規模で継続的インテグレーションを行うには、手動テストではとても間に合わないからである。ただし、UX(User eXperience)や外国語への翻訳のテストに関しては手動で行われている。

自動テストのコスト削減やスケジューリング改善のために、Googleではいくつかの取り組みをしている。

まず、ソースコードの依存性グラフを作ることで、およそ450万件というテスト件数の中から、変更に伴う影響を受ける範囲に限定してテストを実行している。これらのテスト実行結果は2年間保存される。テスト結果がPassからFailに遷移した場合は、スケジューリングをさかのぼって、どこから変わったのかすぐにチェックしている。

また、自動テストのスケジューリングは、マイルストーンスケジューラーによって行われている。これは、一定のマイルストーンごとに区切って、その期間内の変更の累積からテスト対象を決定する方法である。

研究内容

テストの実行結果の傾向分析によって、テストの結果がPassからFailに遷移するケースは、テスト全体の0.2%程度しかないことが分かった。

そこで、Googleでは、遷移が起こった箇所に限定して自動テストを実行する、スマートスケジューラーの研究をしている。ただし、これには一定のリスクが伴うので、定期的にマイルストーンスケジューラーによるテストも実行している。

また、Flakyなテスト(コード自体の変更が行われていないのに、テスト結果が変化するもの)を判別するための研究も行っている。

講演の後半では、これらの研究の成果についてMicco氏の解説があった。

まとめ

Googleはさまざまな取り組みでテストを自動化し、イテレーションを高速化している。

筆者感想

基調講演にふさわしい、内容の濃い講演だった。今後、日本でテスト自動化が浸透していく中で、ソフトウェア業界全体が参考にするべき内容が多く語られたと感じた。

A4）
Agile Japan × JaSST
「『開発がスクラム導入するんだって！試験どーしよ！？』-サイボウズQAスクラム奮闘記-」

概要

本セッションでは、Agile JapanとJaSSTのコラボ企画として、Agile Japan実行委員会から、アジャイルなQAプロセスに関する講演が行われた。講演は、主にスクラムの導入事例の紹介が中心となって、グループワークを交えながら進行した。

事例1：
2万社のユーザーを支える共通基盤チームでスクラムをやってみて

cybozu.comの管理者機能の開発事例について、サイボウズの矢引達教氏が紹介を行った。

事例1の開発チームでは、バグの検出が遅い、要件があいまいなまま開発がスタート、開発とQAの隔たり感、などの課題を抱えていた。そこで、課題を解決するために、スクラムに挑戦することとなった。

スクラムを導入するに当たって、以下の準備を行った。

• 『カンバン仕事術』の輪講
• Readyの定義の策定
• スプリント単位での完了の定義の策定
• アジャイルQAの実践者の講演の聴講

スクラムを導入したことで、バグの早期検出、要件の明確化、チームの一体感、といった効果が得られた。しかし、スクラムをやれば必ず生産性が向上する、というわけではなく、スクラムはあくまでも問題発見のフレームワークである、と矢引氏は語った。

ここまで紹介した内容を踏まえ、実際にスクラム移行時に直面した問題を題材にして、グループワークが行われた。皆それぞれのチームで意見を出し合い、さまざまな観点で解決策を考察した。その後、各チームで議論した結果をいくつか取り上げた。

ここでグループワークが終了し、実際の開発チームではどのように問題を解決したか、そしてそこから得られた知見が紹介された。最後に、チームにおける今後の課題が紹介された。

事例2：
複数拠点での大規模スクラムへの挑戦

事例1に続いて、中堅・大規模向けのグループウェアの開発事例について、サイボウズの岡崎一洋氏が紹介を行った。

事例2の開発チームは、一般的なウォーターフォール方式で、日本・ベトナム・中国の3拠点で開発を行っていた。スクラムを導入するに当たって、プロダクトメンバー全員がスクラム未経験ということもあって、まずは日本拠点からスクラムの導入を行うことになった。また、日本拠点のQAが少ないなどの理由から、スクラムの基本に則ることは諦めた、と岡崎氏は語った。

このように不安材料も多い中、数スプリントだけスクラムを実践したが、結果は失敗に終わった。しかし、海外チームからもスクラム導入を求める声が上がったため、課題も多く残る中で、スクラムを海外拠点で導入することになった。ここでは、海外展開時の対策や様子が紹介された。

その後、事例1同様、事例2でも、実際にスクラム移行時に直面した問題を題材にして、グループワークが行われた。事例1の時よりも皆慣れた様子で、それぞれ議論を交わしていた。

まとめ

この2つの事例はどちらとも、スクラムの導入事例とその際に直面した問題を踏まえて、アジャイルなQAプロセスに関する貴重な知見が語られた。特に事例1では、スクラムはあくまでも問題発見のためのフレームワークであり、問題をQAだけでなくチーム全体で解決することの重要性が説かれた。

筆者感想

開発体制を大きく変える際の苦労や、それに伴う失敗、そしてそれを乗り越える過程など、チーム開発に関する貴重な話を聞くことができた。問題はチーム全体で解決する、という教訓は、今後のチーム開発で意識していこうと思った。

B5）
形式手法「ケーススタディで学ぶ仕様の書き方」

本セッションでは、川口順央氏によって仕様に関する講演が行われた。講演の前半では仕様とは何か？なぜ書くのか？について述べられた。後半では、実際に「ウォシュレットに機能を追加する」という題目に沿って、仕様の書き方が述べられた。

仕様とは、そのシステムは何か？を表したものである。そして、仕様を書くのは、システムを作る前にそのシステムは何か？を知るためである。

システムを使う人・売る人・サポートをする人などの、システムに関わる人々は、それぞれシステムに期待していることがある。これらの期待からさまざまな関心や疑問が生じる。仕様を記述する際は、これらの疑問の中でも、特にステークホルダーの疑問に答えられる抽象度で記述する。このことから、『仕様とは、ステークホルダーが観測できる、システムの特性を記述したもの』と定義できる。

仕様を書くのは、システムを作る前にそのシステムは何か？を知るためであるが、なぜ作る前に知りたいのか。それは開発者が早い段階でシステムを理解したいからである。一般的にシステムを作る時間より、仕様を記述する時間の方が短い。そのため、作る前に仕様を確認することで、誤った仕様に基づいて作る無駄を小さくすることができる。

ソフトウェアシステムの仕様では、おもに振る舞いを書く。振る舞いの他には、性能や保守性などの、非機能要求と呼ばれるものも書く。振る舞いは状態遷移モデルで、非機能要求は自然言語で書く。

ケーススタディの前半では、「ウォシュレットに機能を追加する」際の実際の流れに合わせて、仕様の具体的な記述の手順が述べられた。ケーススタディの後半では、前半で作成した仕様書を形式的な仕様に置き換えながら、形式的仕様(数学的な記述で書かれた仕様のこと)についての解説が行われた。

最後に仕様に関するQ＆Aで講演を締めくくった。

筆者感想

仕様の書き方は、分かっているようで意外と分からないものなので、今回の講演で深く知ることができて良かったと思う。

A7）
招待講演「私が経験したソフトウェアテストの変遷」

概要

ソラミツの柴田芳樹氏が、ソフトウェアテストの技術的変遷、私の経験、ソフトウェア開発とQA、という三部構成で講演を行った。

ソフトウェアテストの技術的変遷

パラダイムシフトは2000年前後に起きた。1980年代・1990年代までは自動化されたテストは常識ではなく、テストは手作業で実行され、結果の確認は目視が主流だった。そんな時代の中で、徐々にテストファースト/テスト駆動開発の土壌が出来上がっていった。

また、1990年代までは夜間ビルドが行われていたが、2000年代は継続的インテグレーションへ移り変わっていった。

私の経験

九州工業大学でのHOLENET開発や、富士ゼロックスでのワークステーション開発で得られた経験と教訓を、柴田氏は語った。

また、日本のソフトウェア開発の現状を踏まえ、テスト駆動開発やテストファースト、継続的インテグレーションを定着させるためには、規律が必要であると語った。

ソフトウェア開発とQA

「テストファースト・テスト駆動開発」と「継続的インテグレーション」の時代には早い段階からソフトウェア品質の作り込みが重要である。

QAは開発プロセスの最後ではなく、プロセス全体を通して深く関与していなければならない。一例として、以下の3つが挙げられた。

• 自動化された各種テストがきちんと開発部門でテスト設計されるように協業する
• 開発部門で行われている継続的インテグレーションの状況に関心を持ち、QAへリリースされる前のソフトウェア品質を確認する
• QA向けのリリースビルドが、開発の終盤ではなく、開発の初めから自動化されているよう推進する

まとめ

テストやインテグレーションといった作業をコンピュータに実行させることにより、1990年代と比べて多くの時間を創造的な活動へ費やすことができるようになっている。ソフトウェア開発部門とQA部門は、開発の早い段階から、ソフトウェアの品質を作り込むために協働すべき時代となっている。

柴田氏は、「ソフトウェア開発現場で、人間は作業をするのではない。それらはすべて自動化し、人間は創造的な活動をしてください」と発表を締めくくった。

筆者感想

ソフトウェアテストの変遷を経験してきた柴田氏だからこそ、その言葉には重みがあると感じた。また、柴田氏の経験してきたソフトウェア開発の歴史は、非常に興味深かった。意欲が大いに掻き立てられる良い講演だった。

おわりに(筆者感想)

筆者はソフトウェアテストを専門にしているわけではない。そのため、今回のJaSSTでは不勉強が原因で、セッションの内容が筆者の理解を超える場面もあった。しかし、多くのセッションに参加する中で、ソフトウェアテストに関する興味が強まっていくのを感じた。同時に、今後、継続的インテグレーションや自動テストなどが浸透していく中で、開発者ももっとソフトウェアテストのことを知らなければならない、と強く感じた。また、チーム開発に対する意欲も大いに高まった。

今回のJaSST'18 Tokyoは非常に有意義な2日間だったように思う。今後もJaSSTを通じてソフトウェアテスト業界に触れていきたいと思った。