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

はじめに

この記事は ソフトウェアテストの小ネタ 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年経ちましたが、最近も話題にあがり、発表を依頼した自分にとっては嬉しい限りです。

前回の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:「インスペクション」や「チームレビュー」と呼ばれるレビュータイプです

JaSST Review'19の見どころ紹介3「『違和感のつかまえかた』 ~組み込みシステムの開発者(テスター)としてやっていること~」 #JaSSTReview

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

深谷さん(miwaさん)のセッション紹介

今回紹介するセッションは、miwaさんによる講演「『違和感のつかまえかた』 ~組み込みシステムの開発者(テスター)としてやっていること~」です。

セッション内容として、下記のように書かれています。 *1

みなさんは「なんとなくだるい」「寒気がする」「熱っぽい」というような違和感を感じた時、どうしますか?症状がひどくならないよう行動を変える方が多いのではないでしょうか。

開発の現場で感じる違和感も同じです。違和感は『注目すべきシグナル』です。より良い製品を作るため、みなさんは行動を起こさなくてはなりません。

本セッションでは、私がいつ、どこで、何を見て違和感を感じているのかを紹介します。また違和感をつかまえるために大事なこと、違和感をつかまえやすくするコツや工夫についてもお伝えする予定です。

今よりももっと違和感に敏感になりたい、違和感をもっと製品開発に活かしたい、そんな方の参考になればうれしいです。

見どころ

miwaさんがブログなどでも発信している*2「違和感」に着目して発表する点が見どころです(勝手に思っています)。

普段から違和感を言語化することを大切にしている、miwaさんならでは発表になると思います。

レビューツールだけに囚われない、「現場で感じる違和感」をどのように発表で伝えてくれるのか楽しみです!

おわりに

JaSST Review'19はまだまだ申し込み受付中です!(直球な宣伝)

www.jasst.jp

今まで無意識的に行なってきた内容を改めて考え直すきっかけになると思うので、違和感をつかまえて製品へ活かす方法が気になっている方は、ぜひ11/1に赤坂でmiwaさんの講演を聞きに来てください!

JaSST Review'19の見どころ紹介2「レビューツールの利用とプロセスのあり方」 #JaSSTReview

はじめに

11/1にJaSST Review'19 が開催されます。

www.jasst.jp

そこで、何回かにわたり、JaSST Review'19での見どころを紹介します。

岡野さん(あさこさん)のセッション紹介

今回紹介するセッションは、あさこさんによる講演「レビューツールの利用とプロセスのあり方」です。

セッション内容として、下記のように書かれています。 *1

ソフトウェア開発の中で、レビューは多くのプロジェクトで実施されます。ツールを利用される方もいらっしゃるのではないでしょうか。「なんでこのツールなんだっけ?」のような疑問を持ちながら利用していることはありませんか?

その疑問・違和感は、なぜおきているのでしょう?

利用したいシーン・動機(問題・課題)に合致した目的・用途ごとにレビューツールの強み・弱点をしり、選択・利用する必要があります。

私が所属するSEPGでは、ツール利用の推進も行っております。

その際にどのような点を考慮しているか、現場ではどのような課題が多いのか、についてお話させていただきます。

レビューだけではなく、他のプロセスでも共通する考えでもありますが、レビュープロセスに照らし合わせて、一緒に考えていきましょう!

見どころ

レビュー利用の推進をするにあたり、ただ「このツールを使え」ではなく、どのような点を考慮しているかを言語化して発表する点が見どころです(勝手に思っています)。

去年登壇して頂いた白水さん*2もそうですが、レビュー利用に関して企業で組織的に行っていること言語化して伝えていただく機会は非常に少ないので、貴重な発表だと思います。

私自身もそのような発表を聞くのが今までなかなか無かったので、非常に楽しみです!

おわりに

JaSST Review'19はまだまだ申し込み受付中です!(直球な宣伝)

www.jasst.jp

他のJaSSTでも積極的に発表されている方で分かりやすいと思いますので、レビューツールをどのように考えて導入すれば良いか気になっている方は、ぜひ11/1に赤坂であさこさんの講演を聞きにきてください!