Agile Testing Days 2019 で頂いた「テスト戦略ハンドブック」の日本語版を公開しました

はじめに

この記事は ソフトウェアテスト Advent Calendar 2019 の2日目の記事(代打)です。

目次

Agile Testing Daysとは何か?

11/3〜8にAgile Testing Daysが行われました。

agiletestingdays.com

Agile Testing Daysとは、ドイツのポツダムで毎年11月に行われているAgileとテストがメインのカンファレンスです。

私は今年のAgile Testing Days2019に参加してきました。

Agile Testing Daysで印象に残ったセッションの紹介スライド

会期中に行われるセッションの数は100を超えます。当然、すべてのセッションに参加することはできません。

自分が興味を持って参加できたセッションの中で、特に印象的だったセッションを紹介するスライドを作成しました!

speakerdeck.com

上記のスライドではセッション内容を中心に載せてますが、一方で会場の雰囲気もすごい良かったです。

会場の雰囲気については下記のツイートを見れば分かるかと思います。*1

twitter.com

テスト戦略ハンドブック

上記のスライドのp12〜p25で紹介している「Test Strategy Workshop」にて、「Test Strategy Handbook」という付録ファイルを貰いました。

そこで、この付録ファイルの日本語訳をして公開しても良いか講師に聞いたところ、OKと言われたので、公開します!

speakerdeck.com

ぜひ、参考にしてみてください!

おわりに

今回はAgile Testing Days2019を紹介しました。

Agile Testing Daysは毎年行なっており、次回も2020年11月8日〜13日に開催することが決まってます。

Agile Testing Daysは参加費(約30万円)+渡航費+宿泊費と、かなりの額が必要となりますが、行く価値は絶対にあると思うので、興味がある人は会社に申請をしてみてはいかがでしょうか?*2

agiletestingdays.com

*1:これは講演中の様子ではなく、会期中の夜に行われたパーティーの様子です

*2:私は完全に会社のお金で行かせて貰いました

WACATE2019冬でなぜ私は「ソフトウェアテストの7原則」のセッションを行ったのか #WACATE

はじめに

この記事は ソフトウェアテスト Advent Calendar 2019 の16日目の記事です。

目次

WACATE2019冬

12/14,15にWACATE2019冬が行われました。

wacate.jp

WACATEとは、1泊2日で行うテストに関するワークショップです。

私はこのWACATEの実行委員をしています。

今回はほぼ満員の参加者とともに、走り抜けることができました。

私の担当セッション

今回、私は「業務でも活用できるソフトウェアテストの7原則」と「Agile Testing Days 2019 参加レポート」の2セッションを担当しました。

本記事では、その中でも「業務でも活用できるソフトウェアテストの7原則」を行うことにした背景をお伝えします。

なぜ私が「ソフトウェアテストの7原則」のセッションを行ったのか

きっかけは2つあります。

きっかけ1:私がWACATE参加し始めた頃の思い出から

私がWACATE初参加したのは、2015年の夏でした。

私はJSTQB FLを2016年に取得しているので、初参加と2回目の頃はJSTQB FLを取得してませんでした。*1

そんな中、2回目のWACATEの参加時(WACATE2015 冬)、「ソフトウェアテストの7原則」がWACATE内で紹介されました。

その時の↓のツイートがとても印象に残ってます。

と、この頃に明確に思い始め、そこからJSTQBを勉強した覚えがあります。

きっかけ2:ソフトウェアテストの7原則のことを書いたら、意外とニーズがありそうだと思えたから

私は7月ごろにこんな記事を書きました。

nihonbuson.hatenadiary.jp

この記事の反応が思いの外よく、ニーズがあるのだなと感じました。(以下は反応の一例)

そこで、こんな感じで事例を踏まえつつソフトウェアテストの7原則を伝えれば、きっと参加者はより理解してもらえるのでは?と思い、今回のセッションを行うことにしました。

セッション資料

以上のようなきっかけで作った資料はこちらになります。*2

speakerdeck.com

なお、公開用のセッション資料ではワーク題材を非公開としています。気になる方は、お近くのWACATE2019冬参加者に見せてもらってください。

おわりに

今回は私がWACATE 2019冬で行なった「ソフトウェアテストの7原則」セッションを行うに至るまでを紹介しました。

WACATEは半年に1回行なっており、次回も2020年6月に開催予定です。

もしもこの記事に興味を持って「WACATEに参加したい!」と思った方がいましたら、半年後にWACATEでお会いしましょう!

wacate.jp

*1:今回の参加者は初参加者も含め半数近くがJSTQBを取得していて「すごいなー」と感じてました。

*2:文字フォントが崩れてしまってるので、余裕があれば後で直す

テストレベルに「機能テスト」が入ると困る理由

はじめに

この記事は ソフトウェアテストの小ネタ Advent Calendar 2019 の3日目の記事です。

もはや、「小ネタ」という文量を遥かに超えてしまっている気もしますが、「機能テスト」という1つの単語に対しての小ネタということで…。*1

目次

この記事のきっかけ

こんな記事がありました

先日、テストレベルの種類*2として

  • 単体テスト…関数単位のプログラムのテスト
  • 結合テスト…プログラムを組み合わせて行うテスト
  • 機能テスト…結合したプログラムを使い、1つの機能として行うテスト
  • システムテスト…機能を統合したプログラムを検証するためのテスト
  • ユーザによるテスト…(特に細かい説明なし)

が羅列してあり、「システムテスト」の中身として

  • 回帰テスト
  • セキュリティテスト
  • 負荷テスト(性能テストを含む)

などが書いてある記事を見つけました。*3

これを開発者が話していたので、思わず「テストについては様々な側面で分類することができる」と言った上で、テストレベルとテストタイプの説明をしました。

テストレベル

JSTQBでは「テストレベルは、系統的にまとめ、マネジメントしていくテストの活動のグループである。」と記載されています。*4

また、設計工程に合わせてテストレベルを設定すると分かりやすいとは思います。

ここではJaSST'18 Kyushuでの池田暁さんの資料から図を拝借します。

f:id:nihonbuson:20191129112449p:plain
V字モデルとテストレベル

JSTQBではテストレベルを下記の4つとしています。

テストタイプ

JSTQBでは「特定のテストの目的から見たソフトウェアシステムの特性をテストするための活動を束ねたものである。」と記載されています。*5

有名なものとしては品質特性があります。*6ただし、盲目的にここに乗っている品質特性を当てはめるのではなく、自分たちの製品に必要なものは何か考えることが必要です。

f:id:nihonbuson:20191129125328p:plain
品質特性(JIS X 25010より)

なお、ここに書かれているもののうち、機能適合性を「機能性」、それ以外の部分を「非機能性」と呼んだりします。また、機能性をテストすることを「機能テスト」と呼んだりもします。

素朴な質問

テストレベルとテストタイプの説明をしたところで、QA歴の浅い人から興味深い質問をもらいました。

f:id:nihonbuson:20191202114734p:plain
素朴な疑問

それに対し、様々な知見を元にした回答を複数人で行なったのですが、せっかく良い話なので、ブログにして公開することにしました。*7

「機能テスト」がテストレベルに入っていることによる弊害

さて本題です。どうして、「機能テスト」がテストレベルに入っていると困るのでしょうか?

理由1. 複数人の間で認識齟齬が発生してしまうため

機能テストをテストレベルに入れてしまうと、「機能テスト」と呼んだ時、テストレベルの1つのことを言っているのか、それとも機能性のテストのことを呼んでいるのか混乱します。そして、認識齟齬にも繋がるリスクがあります。

例えば、下記のような会話が発生するかもしれません。

A「機能テストをやっといて」

B「はーい(単体テストレベルの機能性に対するテストを実施)」

A「なんだよ。機能テストをやってないじゃないか(結合したプログラムをテストしてもらう考えだった)」

このような認識齟齬が発生しないためにも、JSTQBで書かれているような内容で進めたいと個人的には考えています。*8

理由2. 不足や重複が確認しづらいため

例えば、「単体テスト、統合テスト、機能テストをします」と言われたとします。

すると、ここでの例は下記のどちらなのか分かりづらくなります。

  • 「システム全体の機能面は機能テストでテストする」と伝えようとしている
  • 単体テスト、統合テストとは別に、機能面の単体部分などをテストする」と伝えている(システムテストが抜け漏れている)

つまり、この例の場合、システムテストレベルは行われるかどうか分からない」という状況が生まれています。

このように、不足しているテストレベルやテストタイプを確認しやすくするためにも、JSTQBなどを使って共通理解をしたいと考えています。*9

理由3. テストできるはずの粒度・タイミングでのテストができるように見えなくなってしまうため

今回の例だと、「機能面のテスト(テストタイプの「機能性テスト」)を実施するには、コンポーネントテストでもシステムテストでもできる」ということが示しづらくなります。

元記事だと「単体テスト結合テスト、機能テスト、システムテスト、ユーザーによるテスト」と書いており、あたかも機能面のテストは単体テストレベルや結合テストレベルでは行わないように見えてしまうからです。

別の例として性能テストがあります。元記事では、性能テストをシステムテストで行うものの1つとして書いています。

しかし、システムテストでのみ性能テストを行うかというと、そうではありません。例えば、SQL単体での性能を測定する場面もあるはずです。この場合、単体テストレベルで性能テストをやっていることが分かります。

これを「性能テストはシステムテストレベルで行うべきだ」という考え方になってしまうと、後行程での不具合発見に繋がることになります。

なお、JSTQBではできるだけ前行程での確認を推奨しています。

本節では、全テストタイプにおける各テストレベルの適用例を示したが、すべてのソフトウェアに対して、各テストレベルで示した全テストタイプを適用する必要はない。

ただし、各テストレベルで適用可能なテストタイプを行うことが重要である。

中でもテストタイプが必要となる最も早いテストレベルで行うことは重要である。

なので、テストにおいてはテストレベルとテストタイプの掛け合わせでテストの対象を考えることが多いです。

(テストタイプだと捉えることもできてしまう)機能テストをテストレベルに入れてしまうと、「テストレベルとテストタイプの掛け合わせ」の表現が難しくなってしまうでしょう。

さらに発展した話

テストコンテナ

「テストレベル・テストタイプを掛け合わせる」という話をテスト設計コンテストチュートリアル(U30)では、テストコンテナを用いて図示しています。

f:id:nihonbuson:20191129194913p:plain
テストコンテナ図

こうすることにより、「困る理由2. 不足や重複が確認しづらいため」を解消することを手助けできます。

テスト計画

「テストレベル・テストタイプを掛け合わせる」という話には、テスト計画にも繋がります。

詳しくはWACATE 2019夏の資料を見ると分かりやすいかもしれません。

f:id:nihonbuson:20191129194647p:plain
テスト計画におけるテストレベルとテストタイプ

テスト計画時にテストレベルとテストタイプを意識することで、どのレベルでどのような特性のテストを行うのか示すことができます。

これはテスト計画とは名ばかりのスケジュール表とは違い、それぞれのタイミングでの責務が見えてきます。

また、開発とも合意を取ることで、「どの部分を開発者自身でテストするのか」もハッキリさせることができます。

テスコンチュートリアル(OPENクラス)にて…

と、ここまで書いてたら、昨日開催された『テスト設計コンテスト'20 チュートリアル』にて、講師のにしさんに、

「まあ、機能テストがテストレベルなのかテストタイプなのか、どっちでもいいんじゃね?」

と、言われてしまいました…w

おわりに

今回は、「機能テスト」という言葉をきっかけとして、テストコンテナやテスト計画についても書いていきました。

自分もまさかこんなところまで議論するとは思わなかったですが、ここまで議論ができたのも、周りの環境が良いからなんだろうなぁ…としみじみ感じてます。

最後に、テストレベルとテストタイプの説明を聞いたQA歴の浅い人と開発者の感想を載せて終わりとします。

QA歴の浅い人の感想(Slackのスクショ)

f:id:nihonbuson:20191129195747p:plain
感想

開発者の感想

「今まで自分たちは、『如何にテストについてなんとなくでやってきたのか』ということを実感しました。

こういう風にして、どんどん皆さんがテストに興味を持って、より深く考えてくれると良いですね。

*1:本当は、「マツコの知らないテスト勉強会の世界(2019年版)」をやろうと思ったんだが、昨年とあまり代わり映えしないなぁ…というのと、どうしてもこのネタを公開したいと思ったので、急遽テーマを変更しました。

*2:元記事では「テストの種類」と書いてありましたが、中身はテストレベルを意識したものだったため、本記事では問題点を分かりやすくするために「テストレベルの種類」と表記します

*3:別に晒すことが本記事の目的ではないので、URLは載せません。ただ、それが400以上の好意的反応を貰っているのは「なんだかなぁ…」とも感じてしまいます

*4:JSTQB FLのシラバスより

*5:JSTQB FLのシラバスより

*6:IPAの資料より拝借

*7:ここまでが前置き

*8:別に「JSTQBが正しい」と言いたいわけではなく、JSTQBという共通言語にしやすいものがあるのでそれに従うと楽だよねというだけです。開発チーム内で「結合したプログラムをテストする=機能テスト」という考えが統一できているならば、使っても良いとは思います。

*9:もちろん、開発チーム内で用語の定義が統一されており、その理解を皆がしているならば使っても良いとは思います。

前回のJaSST Reviewってどんな感じだったのか紹介(パネルディスカッション編) #JaSSTReview

はじめに

2018年12月8日に、ソフトウェアレビューのシンポジウムである「JaSST Review」が東京で初開催されました。本記事はJaSST Review'18でどのようなパネルディスカッションになったのかを紹介します。

パネルディスカッション

講演いただいた白水様、及部様、鈴木様をパネラーとし、私がモデレータになってディスカッションを行いました。 ディスカッション内容は、私が予め用意したテーマの他、会場の皆さんの質問に回答していただく形をとりました。

その中で印象的な話を紹介します。

レビューでの深掘り対象を見つける手がかりは人である

レビュアーがレビュー対象物を見るにあたって、満遍なく対象物を見るという方法が取られがちです。 しかし、その人がどのような背景で書いているのかこそが大切なことです。

例えば、発表者の自信がなさそうな部分を見つけて深掘りします。自信がなさそうな部分は、曖昧な言葉になり、きちんと思考して書かれていないことが多いからです。特に、「なんとなく」や「◯◯さんが言ったから」という発言が出てきた場合は、書いた人自身が思考できていない可能性が高いです。 また逆に、自信満々になっている部分も深掘りすることがあります。これは、自信満々な部分ほど、詳しい内容を省略してしまっている可能性が高いからです。

時間軸を意識する

時間軸を意識してレビューをするという話が、すべての登壇者から出てきました。 それは、現時点では良くても、将来気になる点がよく出てくるからです。

特にレビューイにとっては、今を解決する傾向になりがちだと思うため、時間軸を意識するやり方は有効だと私も感じました。

レビュー中に「指摘」は行わない

レビューというと、「指摘を行う会」と捉えられがちです。 しかし、登壇者は「指摘する」ということはあまりなく、「質問する」ことで、中身を深掘りすることが多いようです。

質問することで、レビュー対象物を見るだけでは分からない、レビューイの思考を引き出すことができます。 そして、足りない部分や誤っている部分があれば、その部分を話し合うという形を取ります。

レビューをどこまで行うか

レビューの終了条件については、会場の皆さんにとって悩みの種だったようです。これもパネルディスカッションの中で話し合いました。

レビューは時間をかければかけるほどより良いものが出てきます。しかし時間は有限です。なので、「費やした時間の中でどこまで到達したか」で判断します。 チェックリストを満たしたかどうかなどよりも、参加者全員が安心、納得が得られるかこそが大事です。

おわりに

本記事ではパネルディスカッションの一部を紹介しました。 今回登壇していただいたお三方も含めて、「レビューの専門家」はほとんど存在しません。

この文章をご覧になっている方は、普段の業務の中で何らかのレビューをされているのではないでしょうか。 業務の節目などにレビューの知見をお互いに共有したり、ディスカッションしたり、振り返ってみたりしてはいかがでしょうか。 JaSST Review'19への参加も、もちろんお待ちしております。

www.jasst.jp

前回のJaSST Reviewってどんな感じだったのか紹介(発表内容編) #JaSSTReview

はじめに

2018年12月8日に、ソフトウェアレビューのシンポジウムである「JaSST Review」が東京で初開催されました。本記事はJaSST Review'18でどのような方々をお呼びして、どのような発表になったのかを紹介します。

今回のJaSST Reviewの狙い

前回の記事に書いたとおり、一言に「レビュー」といっても、皆さんが思い描くレビューは十人十色です。そのため「レビュー」の取り組み方はバラバラな現状があります。

そこでJaSST Reviewでは、分野が異なる以下のお三方を、発表者としてお招きしています。

JaSST Review'18は下記の3名に発表をお願いしました。

さらに、このお三方をパネラーとして、パネルディスカッションも行いました。「レビュー」という共通の単語に対して、どのように捉え⽅・普段の取り組み⽅が違うのか、もしくは同じなのかを感じる内容を⽬指しました。

また、「レビューミーティング(以下、レビューMTG)の運営方法」「プロセスの中におけるレビューの設置方法」などといった管理面の話は極力対象外にしました。一方で、「どのような思考をもってレビューに取り組んでいるのか」「レビューの指摘内容はどのようなものか」といった技術面の話を中心に発表をお願いしました。

当日の内容

前回の記事で、どのような狙いをもって準備をしたか書きましたが、当日は狙い以上のお話を伺うことができました。

それぞれの発表でもともと依頼していたこと、期待していたこと、実際の発表で得られた予想外のお話を紹介していきます。

なお、本記事を読む際にはJaSST Review レポートページも参考にしてください。

www.jasst.jp

日立製作所 白水様

依頼内容

リリースまでの期間が長い、重厚な開発プロセスでのレビューについてお聞きしたいと思い、白水様に講演を依頼しました。品質を重要視されている日立製作所さんならではの取り組みや思考が聞けると期待しました。

予想していた発表内容

上流の品質を確保するようなレビューをより重視しているのではと予想しました。

リリースまでの期間が長い場合、テストなどの実装後工程で不具合が散見されてしまうと修正コストが非常に高くなります。 高くなるコストを防ぐ一つの方法として、レビューがあると考えました。

実際の発表内容

発表資料は下記です。

設計作業が全体の作業の約5割を占めているというデータから、レビューを重要視されていました。特に大切にしていたことは、各工程でのレビューを繰り返し実施し、工程間(例:機能設計書と詳細設計書)のズレが発生していないか確認することです。 さらに工程以外にも、レビューの位置づけとして「書いてない事を見つける」という考えを持っていました。これは、社外発生不具合の86%は仕様書に記載が無かったというデータから、書いてない内容を見つける目的を重要視していました。

設計レビュー時に気を付けていることについての紹介もありました。 まず、レビュアーが自ら気付くようになるために、「俯瞰する」「先見する」「想像する」の3つを大切にしていました。

  • 俯瞰する…対象機能だけでなく連携する機能についても考える
  • 先見する…その機能が動いた瞬間だけでなく使い続けた将来はどうなるのか考える
  • 想像する…レビューイが想定していなかった使い方をした場合にはどうなるのか考える

レビューイだと対象物のみについて考える狭い思考になりがちです。ここで挙げた3つは、どれもレビューイとは違う視点を持つためのポイントでした。

これらの話は、レビューを大切にしていると予想して講演依頼した私にとって、しっかりとデータや文章にして表現してくださったので非常に参考になりました。

楽天株式会社 及部様

依頼内容

Agile開発でのレビューについてお聞きしたいと思い、及部様に講演を依頼しました。最近盛り上がりを見せている、「モブワークでどのようにレビューが行われているか」を特に聞きたいと期待していました。

予想していた発表内容

「レビュープロセス」が存在しないモブワークで、実はレビューと同じような会話をしているのではと予想しました。

また、純粋に指摘についての話が聞けるのではないかと予想しました。レビューの発表といった時には、よくMTGの参加者構成など、どのようにしてレビューMTGを開催するのかという話になりがちです。ただし、モブワークの場合はレビューMTGが存在しないため、レビューMTGの形式について議論する余地がないと考えました。

実際の発表内容

発表資料は下記です。

speakerdeck.com

レビューMTGだと「設計上は良くないけど、忙しいだろうし、動くから今はとりあえずこのままでいいか」「今回は指摘が多いから、これ以上の指摘はやめよう」といった忖度が発生するというお話がありました。 逆にこのような忖度が発生しないようなレビューになれば、価値のあるものになると感じました。

また、「モブワークはチーム全体の活動である」という話も印象的でした。チーム全員で立ち向かってダメなら仕方ないという考え方です。また、暗黙知を無理に形式知化させるのではなく、暗黙知暗黙知のまま共通体験で伝えるようにしていました。これもモブワークがチーム全体の活動だからこそできることかなと感じました。

一方で、モブワークの中でもレビューが必要になってきた、という話は予想外でした。 必要となったレビューは設計レビューのようなものではなく、自分たちの仕事の成果を自分たちで見直すためのレビューでした。 その中で、レビューという言葉を改めて考えるという話がありました。レビューは「Review」というスペルです。つまり「Re(再び)view(見る)」からレビューなのです。一方で、普段行っているレビューは「Re view」ではなく「First view(初めて見る)」になっているのではないか、という発表でした。この発表は、レビュアーはレビュー時点で初めて対象物を見ることが当然だった自分にとって、シンポジウムの中で一番の衝撃でした。

グロース・アーキテクチャ&チームス株式会社 鈴木様

依頼内容

アーキテクト観点でのレビューについてお聞きしたいと思い、鈴木様に講演を依頼しました。特にAgile開発では、コード中心のレビューになることが多いと想像しており、もっと基盤寄りのアーキテクチャの話を聞く機会が重要だと考えました。

予想していた発表内容

アーキテクチャは開発をする上での最上流工程だと考えていました。なので、そのようなまだ開発方針も定まりきっていない状態での物事の決め方が聞けるのではないかと予想しました。

実際の発表内容

発表資料は下記です。*1

www.slideshare.net

アーキテクチャの良さは非機能で判断する必要がある、というお話がありました。非機能要件は「こうあるべき」という絶対的なものがありません。それを見るためには、工程完了の確認のためではなく、相談に乗る形でレビューに参加することが多いようです。 また、バランスが取れた判断も考えていました。アーキテクチャ設計が100点満点になることはありえません。そこで、松竹梅の複数プランを示して、落とし所を決めることを重要視していました。

アーキテクチャ設計レビューの難しさも話していただきました。 アーキテクチャ設計は常に事前的であるため、将来性が考慮されているかも重要です。その将来性を考えた上で、どのようなリスクがあるか、そのときにどのようにしてリスクを回避するかを考えていました。 その中で、「◯◯については今は考えない」といった情報も記録に残すように心がけていました。記録に残さないと、「意図的にその時点では考えなかった」「そもそも考慮していなかった」のどちらなのか、将来的に分からなくなるからです。

今回はアーキテクチャのレビューについて話してもらいました。ただし、最上流工程だからこそ難しさが顕著になっているだけで、話していただいた内容はすべてのレビューに当てはまる考え方のように感じました。

おわりに

本記事ではJaSST Review'18での発表内容について紹介しました。

JaSST Review'18の様子を読んで、「面白そう」と感じた方は、11/1開催のJaSST Review'19にもぜひ参加してみてください!

違った方向で新たなレビューに対する考え方を得ることができるはずです。

jasst.jp

*1:発表から1年経ちましたが、最近も話題にあがり、発表を依頼した自分にとっては嬉しい限りです。

第1回JaSST Reviewってどんな感じだったのか紹介(開催の経緯編) #JaSSTReview

目次

はじめに

2018年12月8日に、ソフトウェアレビューのシンポジウムである「JaSST Review」が東京で初開催されました。本記事はJaSST Reviewをどのような想いで開催したのか、どのような発表や議論がされたのかを紹介します。

JaSSTとは

日本では2003年からソフトウェアテストシンポジウム(JaSST)が全国各地で開催されています。これまでの15年間で約90回開催されてきました。 様々な方がテストに関する知見を社外に発表していることから、業務でのテストの経験が言語化されてきました。結果として、テスト技術として整理もされてきたと感じています。

なぜJaSSTでレビューを取り扱うのか

前述の通り、JaSSTはソフトウェアテストを扱っているシンポジウムです。そんなJaSSTでなぜレビューを取り扱うのでしょうか。

実は、JSTQBソフトウェアテスト技術者資格認定)には、「静的技法でテストできる方法の一つ」として、レビューが紹介されています。 つまり、テスト計画、テスト設計、テスト自動化などがJaSSTで扱っているのと同様に、レビューもまたJaSSTで扱うべき分野の一つだと考えています。

なぜJaSST Reviewを開催したのか

JaSSTは全国で開催されており、東京では毎年二日間にわたってJaSST Tokyoが開催されています。 そんななか、JaSST Tokyoとは別枠でJaSST Reviewを開催しました。これには理由があります。

過去3年間(2016年-2018年)における全国のJaSSTでは、合計で約240セッションが実施されました。 その中でレビューを題材としたセッションは6セッション(全体の約2.5%)のみでした。*1 これはとても少ない数字ですよね?

つまり他のテスト技術に比べ、レビューに関してはあまり広がりを見せていないという現状が分かります。 そうした状況を打破するためにも、レビューについて真剣に考える機会を作るためにJaSST Reviewというシンポジウムを新たに立ち上げました。

レビューの分類

一言に「レビュー」といっても、様々な分類を行うことができます。

JaSST Reviewの発表内容をお伝えする前に、レビューの種類にはどのようなものがあるか紹介します。 そして、読者の皆さんはどこに位置づけられるのか、他の組織ではレビューがどのように使われているのか知っていだければ幸いです。

レビューの対象物

レビューの対象物も組織によって様々です。対象物によって、レビューは大きく以下の3つに分けられます。

f:id:nihonbuson:20191024013937p:plain
レビュー対象物

レビューを行うタイミング

レビューをどのようなタイミングで行うかについても組織によって違います。大きく以下の3つに分けられます。

f:id:nihonbuson:20191024014420p:plain
レビューを行うタイミング

レビューで用いるリーディング技法

ドキュメントなどをレビューで読むときに用いる技法も様々あります。例えば、以下のようなリーディング技法があります。

f:id:nihonbuson:20191024014449p:plain
リーディング技法

レビューの開催形式

開催形式については、公式的なものと非公式なものに大きく分かれ、その中でもいくつか方法があります。

f:id:nihonbuson:20191024014212p:plain
レビューの開催形式

「レビュー」に対する考えは十人十色

ここまで書いたように、一言で「レビュー」と言っても、その言葉からの捉え方は十人十色であることが分かります。

そこで、色々な分野の方のお話を聞くことで、「レビュー」に対する考え方を広げてもらいたいと考えています。

おわりに

本記事では、JaSST Review開催の経緯について書きました。

この経緯は、11/1開催のJaSST Review'19でも同様の考えを持っています。

もしも、この考えに共感を持ってもらえる方がいましたら、ぜひJaSST Review'19にも参加してみてはいかがでしょうか?

www.jasst.jp

*1:そのうち5セッションは、JaSST Review実行委員の2人による発表でした。

「相談」もレビューである #JaSSTReview

「レビュー」に対するイメージ

皆さんは「レビュー(特に設計レビューなどのコード以外のレビュー)」と聞いてどんなイメージを持ちますか?

  • 大きな会議室に有識者と呼ばれる人が多数集まる
  • 色々と指摘を言われ、それに対して納得する返答が求められる
  • 完璧なドキュメントを用意して、指摘が無いクオリティにしてからレビューに臨む

こんなケースもレビューです

一方、普段の業務でこんなことはありませんか?

  • 「ちょっとここの部分、どうすれば良いのか分からないんで、教えてもらって良いですか?」
  • 「方針を考えてみたんですけど、ちょっと見てもらって良いですか?」

一見すると、「ただの相談じゃないか」と思うかもしれませんが、これも立派なレビューです。*1

「レビュー」というと堅苦しいイメージがあるかもしれませんが、こういう普段の業務でも実はレビューを行っているのです。

f:id:nihonbuson:20191021091535p:plain
「「超」やさしいレビュー ~開発とQAに壁はない!~」より(JaSST'18 Kansaiにて発表)*2

MTGのやり方以外のレビューの話がしたい!

一般的に「レビューの方法」について調べてみると、「どのようにMTGを開くのか」「MTGにはどんな人が参加していると良いのか」という話題ばかり出てきます。

しかし、これらの情報はこの記事の最初に書いた「レビューとは有識者と呼ばれる人が多数集まる」というレビューに限定している可能性が高いです。*3

しかし、「MTGの開催方法」ではない部分にも色々と考えることはあります。

レビューを行っている人は「相談を受けるときに、どのような部分を気にして会話をしているのか」「レビュー時にどのように対象物を読んでいるのか」「レビュー中はどんなところを気にしているのか」など、会議のやり方以外で考えたり工夫したりしている部分があるはずです。

そんな内容について議論をしていきたいと考えています。

JaSST Reviewでレビューの中身について考えてみませんか?

11/1に「JaSST Review'19」という、レビューについて考えるシンポジウムが行われます。

www.jasst.jp

レビューMTGの開催方法ではなく、「レビューでどのようなことを考えればよいのか」について、このシンポジウムで一緒に見つめ直してみませんか?

レビューの内容を考えたい方々のご参加を待ってます!

*1:「ピアデスクチェック」や「ペアレビュー」と呼ばれるレビュータイプです

*2:元資料は JaSSTソフトウェアテストシンポジウム-JaSST'18 Kansai-レポート に載っています

*3:「インスペクション」や「チームレビュー」と呼ばれるレビュータイプです