アプレッソは Agile Japan 2018 のゴールドスポンサーになりました!
こんにちは。開発部の野村です。
このたび、アプレッソは Agile Japan 2018 のゴールドスポンサーになりました!
Agile Japan 2018 のHPはこちらです。スポンサー一覧にアプレッソのロゴがあるのでぜひ見てみてください。 www.agilejapan.org
また、企業セッションで登壇します!
セッションテーマは『開発プロセスだけ「アジャイル」で良いの?~アジャイル導入で変わった人・組織・世界~』です。
アプレッソでは、2年前からアジャイル開発を本格的に始め、様々な変化がありました。 なぜアジャイルなのか、試してきた取り組みとその結果、失敗したこと、などなど、生々しい話をお伝えできればと思います。
ぜひ Agile Japan 2018 のセッションへお越しください!
CSPO 研修でのマナビ
はじめに
品質マネジメント部の伊藤です。
品質マネジメント部のリーダーでありつつ、アプレッソの主力プロダクトであるDataSpider Servista の スクラム開発におけるプロダクトオーナーを担当してます!
本記事は、2/7(水) ~ 2/9(金) に、認定スクラムプロダクトオーナー研修に参加してきて得たものまとめたものです。
※認定スクラムプロダクトオーナー研修(CSPO)は、認定スクラムトレーナー(CST)によって開催される Scrum Alliance 認定研修です。
Scrum におけるPOとは
PO とは ROI を最大化することに責任を持ちます。
「ROI」を最大化するには、Investment(投資)を減らし、Return (効果) を増やす必要があります。
「I」と「R」を考えるとき、「R」を増やす方に注目してしまう人が多いのではないかと思いますが、まず考えるべきは「I」です。
というのも、「I」はコントロールしやすく定義しやすいですが、「R」はコントロールしにくい上、定義しにくいからです。
「I」と定義してみると以下のようなものがあげられます。
- 時間
- お金
「R」を定義してみます。
- お金
- 技術
- スキルアップ
- 効率化
- プロダクト価値の向上
- 喜び
・・・などなど
「R」は、どのような人 (モノ) によっても変わってきますし、影響範囲(※)をどこまでにするかによっても変わってきます。
(※) あるプロダクトの改修を行った場合、プロダクトそのもの価値向上はもちろん、それを使うユーザへのプラスの影響、さらには開発者の技術力向上にもつながるかもしれません。さらにその先・・と考えると影響範囲は無限大になりそうです。
ということもあり、コントロールしやすく定義しやすい「I」から考え、どうすれば「I」を減らせるのかということを考えていくのが定石といえます。
その次に「R」を考えていきますが、前述の通り難しい課題であります。
各プロジェクトやサービスのコンテキストによっても大きく変わるため、どうすればよいかという明確な答えはありませんが、常に意識していくべき課題です。
様々なステークホルダーが気にするポイントでもあるため、プロダクトの価値を明確にしておくというのも PO にとって大事な仕事です。
※ちなみに研修期間中は、ひたすら ROI について深く考えさせられる内容でした。
いかに普段の業務で、ROI を考えていないなぁと痛感・・・(ツライけど充実
印象深かった学び
ここからは特に印象に残ったキーワードを元に、研修を振り返ってみます。
「優先順位はPOが決めるものじゃなく、決まるもの」
スクラムガイドには、バックログの優先順位は PO が決定するとあります。
となると矛盾しているように見えますが、真意は別のところにあります。
ここで伝えたいことは、PO の勝手な判断で優先順位を決めてはならないということです。
PO の勝手な判断とは、以下のようなことです。
- 目先の要望を優先してしまい、本質的にやるべき課題の優先度を下げる
- 技術的負債の影響度は明確ではないが、不安なため優先度を上げる
- 存在しないユーザ像を勝手に作り上げ、求められていないサービスを提供する
などなど...
これらは根拠が弱く、PO の嗜好や思考が大きく影響しています。
これでは、マーケットの ROI を最大化することはできません。
ではROIを最大化するには、どうするべきか。
それには、優先順位を決めるにあたって必要な情報をしっかりと集めることです。
極端な話、情報が完璧であれば、どのPOが優先順位をつけても同じ並びになるということです。(PO がそれなりに優秀であることが前提になるとは思いますが...)
それが 「優先順位はPOが決めるものじゃなく、決まるもの」の真意です。
根拠ある情報が十分そろえば、必然的に優先順位が決まるということです。
「PO のマーケット」
PO のマーケットとは、どの範囲でしょうか。
つまり PO は誰 (何) に対しての ROI を最大化する必要があるのでしょうか。
答えは、「プロダクトに関わる人(もの)すべて」です。
つまり・・・
- プロダクトそのもの
- プロダクトを利用するユーザ
- スクラムチーム
- スクラムマスター
- その他もろもろのステークホルダー
などなど、挙げればキリがありません。
プロダクトのみに注目してしまいがちですが、プロダクトに関わる人たちの ROI が向上すれば、結果的によりよいプロダクトにもつながります。
PO がマーケットと考えるべき範囲は、実はかなり広大なのです。
「ROI を最大化させる際の PO の思考性 」
どの課題を解決して、どのくらいの効果が見込めそうか。
それらを考える上で PO としてはどのように考えたらよいでしょうか。
基本的な考え方としては「ポートフォリオ」で考えます。
課題の特性によって分類し、より多くの分類に属する課題に効果があると考えられる施策を打つようにします。
例えば、A、B、C という特性の分類があり、A、B、C それぞれに課題が 3 つずつあると仮定します。
その際に、以下のどちらの施策を選択したほうがよいでしょうか。
- 特性 A に属する、3 つの課題を解決する施策 X
- 特性 A、B、C に属する課題を 1 ずつ解決する 施策 Y
選択すべきは、「施策Y」です。
特性Aの課題が実現場では課題ではなかった場合など、想定課題が誤っていると「施策X」はまったくの無駄になってしまいます。
その点、「施策Y」は特性Aが外れても、それ以外が外れなければ、まったくの無駄になるということはありません。
これがポートフォリオ的な考え方です。
つまり、似たような課題を多く解決する施策をうつのではなく、より多くの特性の課題を解決する施策をとるほうが得策ということです。
そのためにはまず、多くの課題を見つけておき、その課題の特性の数もより多く持っておく必要があります。
よって、課題を見つける際には、もっとも重要な課題のみをピンポイントで見つけにいくのではなく、重要そうではないものも含めて持っておくべきです。
「リカバリープラン」
冒頭の方で、「Investment(投資)」を減らすことをまず考えるべき、というような話をしましたが、プロダクトを開発して利益を得ることだけに焦点を挙げれば、開発作業は、「I」にしかなりません。
想定どおり物事が進めば、スムーズに開発が進みますが、現実的にはあらゆる場所に落とし穴が潜んでいて、想定外のコストが発生します。
よって、POとしては想定外のことが発生した場合に、いかに低コストで軌道修正できるかが求められます。
そのためには複数のリカバリープランを用意しておく必要があります。
例えば、プロダクトバックログリファインメントにおいて、PBIの内容を開発チームと精査していたとします。
その際、受け入れ条件が開発する上で現実的ではないとなったら、POが持ち帰って再検討しなくてはいけなくなります。
このような想定外の事態に対応するために、PO としてはリカバリープランを複数持っておく必要があります。
この例ですと、例えば受け入れ条件案を複数準備しておけば対応できたかもしれませんし、PBI の内容だったり大きさを変化できるように準備しておく必要があったかもしれません。
いずれにせよ、PO としては様々なことを想定して、様々な対策を考えておく必要があります。
なお、研修中に言われたこととしては、1つの PBI に対して、リカバリープランを3つは用意する必要がある、とのことです・・・。がんばります!
最後に
印象深かった学びを中心に紹介しましたが、いかがだったでしょうか。
これらは研修中に学んだことの、ごく一部です。
しかも、一番印象深かったことはこの記事には載せていません。
なぜならば、一番印象深かったことは研修中の「体験」そのものだからです。
こればかりは体験してもらう必要があり、言葉で伝えることができません。
知識を得ただけではなかなか行動を変えることは難しいものです。
体験によってマインドや考え方に変化が生じ、行動が変わってくるのではないかと思います。
研修受講による ROI を最大化するためにも、得られたものを元にしてこれからの活動に活かしていこうと思います。
リフレインする「ふりかえり」、刻む「カイゼン」のビート
はじめに
こんにちは。花粉症のカイゼンを日々願っています。開発部の野村です。 今年の2月から DataSpider Servista のスクラムチームでスクラムマスターをやっています。
年度末ですが、みなさん「ふりかえり」していますでしょうか?
わたしたちスクラムチームは1週間のスプリントで走っています。 毎週「ふりかえり」を行って、さらに高いレベルのチームを目指して「カイゼン」アクションを決めています。
私がスクラムマスターになってから試したプラクティスを、それぞれよかったことを交えて紹介していきたいと思います。
「ふりかえり」プラクティス
KPT
Keep, Problem, Try を書き出す、定番のプラクティスです。
How to
1週間のできごとを確認*1したあとに、10分程度でKeep, Problem をふせんに書き出してもらい、Keep の中からより良くする Try を出したり、Problem の中からその問題を解決するための Try を出したりして、アクションを決めていきました。
よかったこと
定番なだけあって、わかりやすくて、やりやすいです。また、Keep と Problem を対比することで、チームの気持ちが見えやすい点も良いです。
Team Radar
チームの価値、技術的能力などをチームメンバー同士で確認するプラクティスです。メンバー間の捉え方の違いを共有し、伸ばすこと、克服することを決めていきます。
How to
事前にチームメンバーには「このチームにとって大事にしている4つのこと」を考えてきてもらいました。各自が思う大事にしていることをふせんで貼り出し、似たようなものをまとめて、チームとして大事な要素を4つ選びました。
選ばれた4つの要素はフリップチャートに軸とともに描きます。次にチームがどの位置にいるか 0 ~ 10 で各自考えて、なぜそのポイントにしたのかを添えて発表します。チームのポイントとしては平均値を取りました*2。
最後に、ポイントの低い要素から克服するためのアクションを出し、ポイントの高い要素からより良くするためのアクションを出しました。
よかったこと
チームメンバー同士の要素に対する捉え方の違いが顕在化しました。価値観にフォーカスすることで、普段の KPT では出てこなかったチームのルールに関するアクションが出てきました。
Speed Car and Abyss
メタファーを通して、ふりかえりと将来を見据えるプラクティスです。
上の絵を描き、自分たちの現在置かれている状況と将来を考えます。それぞれのメタファーは以下の通りです。
- スピードカーのエンジン:チームを促進させるもの。
- スピードカーのパラシュート:チームを遅くさせるもの。
- 深淵:チームにとっての危険。チームを危険に陥れるもの。
- 橋:危険に打ち克つためのもの。
How to
ホワイトボードに絵を描き、メタファーのイメージを説明しながら、関連する物事をふせんに書いて貼っていきます。
「わたしたちはスピードカーです。速く前進させてくれるナイスな『エンジン』と、前進を妨げる『パラシュート』を持っています。現状とこれまでをふりかえって、わたしたちの『エンジン』と『パラシュート』に該当する物事を書き出してください。」と説明し、ふりかえりを行います。
次に『深淵』について考えます。「スピードカーの先には、落ちたら2度と上がれない『深淵』が待ち構えています。そこにはどんな危険があるか、何がわたしたちを陥れるのか、書き出してください。」
最後に『橋』についてです。「深淵に打ち克つためには、何がわたしたちに必要でしょうか。わたしたちがゴールに到達するための『橋』を書き出してください。」
貼り出したふせんを見渡しつつ、危険に打ち克つために必要なアクションを『橋』から決めたり、『パラシュート』にある障害を取り除くアクションを決めたり、していきました。
よかったこと
メタファーによって、大局的な意見が多く出ました。また、将来を見据える(Futurespective*3)ことで、立ち向かわなくてはいけない課題が露見し、それらに対処する行動を決めることができました。
WWW
KPTに似た3つのカテゴリでふりかえるプラクティス。Worked well(うまくいったこと)、kinda Worked(うまくいったけど、調整が必要なこと)、didn't Work(うまくいかなかったこと)を出してふりかえります。
How to
事実を確認したあとに、10分程度でWWWをふせんに書き出します。ふせんを分類分けして、didn't Work を解決するアクションや、kinda Worked を Worked well にするためのアクションを出します。 わたしたちが実践した時は、didn't Work から1つ取り扱う課題を決めて、それについて 5 whys(なぜなぜ5回)*4を2人1組のペアで行い深掘りしてました。
よかったこと
「うまくいっている」というキーワードから「やりたい(こうありたい)けれど、できていないこと」が出てきました。WWWはKPTと似ていますが、フォーカスする対象がより明確な状態であるためか、具体的な課題が多くでてきました。
Starfish
KPTの進化系のようなプラクティス。Stop, Less, Keep, More, Start の5つのカテゴリで意見を出してふりかえります。
How to
1週間の事実を確認し、10分程度で5つのカテゴリについてふせんに書き出します。Stop→Less→Keep→More→Startの順に書き出したふせんを発表して貼り出します。
Stop, Less に挙がった活動を辞めたり、減らしたり、More, Start に挙がった活動を次スプリントに始めることにしたりして、アクションを決めていきます。
よかったこと
More, Start というカテゴリがあることから、具体的なアクションがでやすいです。
(よかったことではありませんが)実際にやったときには、メンバーから意見が出しにくいとのフィードバックがありました。Starfishはアクションにフォーカスしたプラクティスですが、スプリントの事象をふりかえったこと、またモヤモヤした感情が募っていたスプリントであったことから、このタイミングに適したプラクティスではなかったのかもしれません。
「ふりかえり」をつづけ、感じたこと
KPTでもカイゼンアクションを出すことができますが、ずっと続けていると見方が膠着してより良い意見を出しづらくなります。さまざまなプラクティスを実践することで、視点や視座が変わり、チーム内だけでなくチーム外に対するカイゼンアクションも出てくるようになりました。一方で、プラクティスを毎回変えていると、ふりかえりの中で扱えない課題が出てきます。それらは Impediment List へ残して、別途対応していくようにしています。
個人としては、ふりかえりの時間配分に苦慮しています。1週間のスプリントのため、ふりかえり時間は1時間に抑えたいのですが、議論が盛り上がったり、アクションを出すのに煮詰まったりすると、1時間以上かかってしまうことがあります。そのため、ふりかえり中の各工程(ふせん書き出し、貼り出しなど)の時間配分を事前に決めて、ストップウォッチでラップを測りながら進行しています。
さいごに
アプレッソでは自分たちのスクラムの型を探すため、日々試行錯誤しています。
スプリントを回すだけでなく、他社のスクラムチームとの交流会の機会を求めています! 実際に協力会社の株式会社アークシステム様のご縁を通じて、交流会を開催しました。
ご興味のある企業様がいらっしゃいましたら、ぜひともお声がけください!
参考にした本、ウェブサイト
- アジャイル レトロスペクティブズ Esther Darby and Diana Larsen 著, 角 征典 訳
- アジャイルふりかえり
- Fun Retrospectives
JaSST2018 Tokyo参加記、という名目のもとスクラムのQAについての話題
はじめに
品質マネジメント部の伊藤です。
品質マネジメント部のリーダーでありつつ、アプレッソの主力プロダクトであるDataSpider Servista の スクラム開発におけるプロダクトオーナーを担当しています。
JaSST ソフトウェアテストシンポジウム内ではアジャイルやスクラム関連の話題も扱っていました。
発表内容をアップするのは基本NGっぽいので、アプレッソのスクラム開発と比較して感じたことを述べたいと思います。
ちなみに、以下でも紹介しているのであわせてお読みいただければと思います。
アプレッソにおけるスクラム開発のスタイル
感じたことを述べる前に、アプレッソの開発スタイルを紹介します。
スクラムのチーム構成は、開発チーム 5 名、SM、PO の計 7 名で、スプリント期間は 1 週間となっています。
デイリースクラムは、朝に実施しており、スプリントレビュー、スプリントレトロスペクティブ、スプリントプランニングの各セレモニーは水曜日に実施しています。
なお、一部スクラムのルールにのっとっていない部分があります。
それは、Done 定義にテストを含んでいない点です。
本来、PBI を完了させるためにはリリース可能な状態にする必要があり、当然テストを行う必要があります。
ただし、ここで言っているテストとは、ユニットテストなどの自動テストではなく、QA が行う手動テストのことです。
※なぜこのようにしているのかは後述します。
では、どのように行っているかというと、テストはスプリントとは非同期で行っています。
↓こんなイメージ
QA が行う手動テストはそのスプリント内には収めず、次スプリント以降に完了させています。
もともとの開発プロセスは、開発フェーズとQAフェーズというように開発プロセスがわかれており、ウォーターフォールチックでした。
また、アプレッソは開発部とQA部のように部署が独立して存在しています。
独立していることによるメリットも当然ありますが、スクラムを導入する上で課題も出てきます。
例えば「スプリント開始直後では、触れるものがないのでQA何するの?」といった課題です。
このような課題も、QA が前のスプリントのテストを行うことで解消されます。
※ただ現在は、QAによるテストもそのスプリント内でほぼ完了できるようになっています。
JaSSTソフトウェアテストシンポジウムを通して思ったこと
前フリが長かったですが、ここからが本題です。
といいつつ、感想しかかけないので前フリより短いですが ^^;
で、参加してみた感想を一言でいうと
「われわれのやってきたことは決して間違っていない」
です!
発表内容では、アプレッソと似たようにスクラムの開発スタイルをとっている事例もありました。
スクラムのフレームワークを無理して適用するのではなく、現実的な落としどころを見つけて、適用しやすい形で運用されていました。
大切なのはスクラムをやることじゃなく、スクラムで何を実現したいかです。
スクラムに縛られすぎるのを scrum slave (スクラムの奴隷)といいますが、
そのようなことがないように、大切なことは何かを忘れないでいたいと思います。
これからも日々のカイゼンを積み重ねて、さらに高いレベルのチームを目指していきたい。
そんなことを改めて思い返せたイベントでした。
JaSST2018 Tokyo参加記
こんにちは 品質マネジメント部のいそです。
3/7, 3/8に行われたJaSST2018 Tokyoに 品質マネジメント部全員で参加してきました。
開催からすこし時間がたってしまいましたが、当日印象に残ったあたりを書いていきたいと思います。
ちなみに講演資料は以下で公開されています。
JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo-レポート
めちゃひとおおい
まず到着してびっくりしたのは入場者数の多さ。
受付にたどり着くまで2,30分はかかったのではないでしょうか。
後々わかったこととして、全ての参加者がQA/テストエンジニアというわけでなかった様なのですが、同士の多さにしばし感涙にむせぶ思いでおりました。
基調講演「Advances in Continuous Integration Testing at Google」/ John Miccoさん (Google)
- googleでのテストはほとんど自動化されている
- 膨大なテストケースがあり、結果が不安定なケースが存在する。
- そういったケースを判定してリスクが少ないケースをSKIPする仕組みを採用している
- ほとんど自動化している理由はそうしないと手が回らないから
- QA部門は存在せず SETIという役割が品質に作り込みを支援する
- 自動化をする文化が組み込まれている
そのほか個別セミナー
「やってみよう!探索的テスト ~ハイクオリティな妄想の高速ループ~」/ JaSST'17 Hokkaido 実行委員会
- 座学は少しで実技メイン
- 探索的テストのメリット
- 短期、柔軟、実動作、暗黙知を活用
- 動作検証ではなく、バグ探しである
- アンチパターン
- 長時間やってしまう → 対策:タイムボックス
- エビデンスが残らない → 対策:スクリプトテストを併用
- ユーザにとって重要で無いところもみてしまう → 対策:真にユーザ視点を持つ
- Explore It! がよいらしいので買う(買った)
「「開発がスクラム導入するんだって!試験どーしよ!?」-サイボウズQAスクラム奮闘記-」
- DEVとQAの協調が重要
- DEVとQAのへだたり
- 職能のカベ
- クロスファンクショナルなチーム
- DEVとQAで一緒に仕様決めをしたり、テスト設計をレビューしたり等
- 「実線アジャイルテスト」を ActiveBookDialog で学習した
- スクラムをやるにあたってはDEVよりもQAの方が影響が大きい
招待講演「私が経験したソフトウェアテストの変遷」/ 柴田 芳樹さん(ソラミツ)
- フィードバックループを短くする!!
- 継続インテグレーションは強みではなくなった
個人的なまとめ
- 以下2点がいろいろなセミナーを受講して感じたあたり
- 欧米ではテスト自動化はすでに前提となっている
- DEVからQAへの距離を短く(もしくは無く)して早期から品質の作り込みをおこなっていく
よくよく学んでいきたいところです!!
そのほかアプレッソ参加者の声
- アジャイルとウォーターフォールについてのディスカッションを聞いて、手段も大事だがチーム全体のマインドが大事なのだと改めて感じた
- DEV、QAというカテゴリわけをせずに、1つのチームとして機能することが重要であると感じた
- TPI NEXTを使ったプロセス改善が興味深かった
- 論文の書き方で、論文を書くのは研究者というイメージが強いが、実例を持っているのは現場の人であり、成功・失敗に関わらず共有することが業界・技術の発展に必要、という話は面白かった
- 製品の品質だけを保証することがすべてではなく、ユーザーからのニーズをヒアリングし、製品に反映させるために開発のポテンシャルを引き出してよい製品を作る。それが QAエンジニアの本の役目だと改めて思った
- 既知のバグからテストケースを起こすやり方として、NGT(Notation for Generic Testing)を流用したやり方が興味深かった
- 最後のセッションでYahooの山口さんが「ゲーティングのためのQAはいらない」と言っていたことが印象的だった
などなどがありました。
現場からは以上です!!
Effective Java 第三版、ゲットだぜ!
皆さんこんにちはこんばんは、開発部の陳です。
この間の大雪の積雪の影響で、首都圏の交通事情が一時期ひどいことになりましたね。 そんな大変な状況でも、物流業の方々はみんなの手元に荷物がちゃんと届くように頑張り続けていました。 おかげで、去年の夏に予約した Effective Java 第三版を無事に入手しました!
というわけで、その気になる内容をかるく紹介して行きたいと思います。
第二版と第三版、構成がどうか変わったか
2008 年に第二版が出版されてから、Java はメジャーバージョンアップを3回もリリースして、第三版では、元の Java 6 向けの内容を Java 9 までの変更を含めて一通り改定しました。
その影響でボリュームが少し増えて、第二版の 11 章 78 項目という構成に対して、第三版では 12 章 90 項目になっていて、新しい章は第 7 章の "Lambdas and Streams" です。(ちなみに、初版は 10 章 57 項目、第二版で第 5 章の "Generics" が追加された)
二刷までの正誤表はこちらになります。
手元の本は誤植全部入っています…初刷ですね!ヽ(`▽´)/
無くなった項目
第二版の項目 73「スレッドグループを避ける」が無くなりました。
どのような経緯で消えたからは分かりませんが、ThreadGroup 自体は想定された目的(セキュリティのためにアプレットを隔離する仕組み)を果たされていないし、他の目的に転用しようとしてもより適任なクラスがあるし、わざわざ取り上げる必要もないでしょうね。
新しい項目
第三版の新しい項目は全部13件です。以下では各項目の概要を、個人的なコメントを交えて紹介していきます。
内容はまだじっくり読んでいないので、鵜呑みせずに「こんな考えもあるよ」という程度で捉えていただければと思います。
ちなみに、日本語の項目名は第二版邦訳のスタイルを真似した適当な意訳です。
項目 5: 固定リソースより依存性の注入を選ぶ *1
カプセル化の力加減についてのアドバイスです。
ロジックの柔軟性、再利用性とテストしやすさを意識するように、コンポーネントの依存先リソースをコード内で直書きしないで、必要に応じて差し替えられるような手段(コンストラクタもしくはセッター)を用意しておこう、という内容です。
項目 9: try-finally より try-with-resources を選ぶ *2
Java 7 で try-with-resources が登場してだいぶ経ったので、既に実践している方が多いでしょう。
try-with-resources はクローズもれを防いでくれるだけでなく、複数リソースを扱う際の読みやすさも try-finally よりはるかに上なので、リソースが AutoCloseable を実装していない場合を除き、実践しない理由はどこにもないですね。
項目 21: 後世のために、インタフェースを設計する *3
Java 8 で登場したデフォルトメソッドのお陰で、インタフェースを拡張する際のインパクトは以前よりすっと小さい程度に抑えられるようになりました。
しかし、デフォルトメソッドによるインタフェースの拡張は、すべての既存実装と上手く共働き協働するとは限りません。
インタフェースの拡張が簡単になったとしても、インタフェースの設計自体はやはり以前と変わらず、慎重に行うべきです。
項目 25: ソースファイルの範囲を単一トップレベルクラスに限定する *4
一つのソースファイルにトップレベルのクラスを複数入れられるが、コンパイル時のエラーの原因になる可能性があるし、読みやすさに悪影響も及ぼすから、一つだけにしょう。
項目 32: ジェネリクスと可変長引数を注意して合わせて使用する *5
Java 7 で登場した @SafeVarargs を使用すれば、メソッド引数でジェネリクスの可変長引数を使用するのは以前より快適になっています。
ただし、@SafeVarargs はメソッドの型安全性を約束していることを示すアノテーションに過ぎないので、安全性を保証できないメソッドにつけるべきではありません。
ジェネリクスの可変長引数の型安全性を保証する実装例と、@SafeVarargs を使用するルールを説明する項目です。
項目 42: 匿名内部クラスよりラムダ式を選ぶ *6
数行のコードなら、ほとんどの場合、ラムダ式は匿名内部クラスより読みやすいので、ラムダ式を使うべきです。逆に、コードのロジックが複雑で行数が多い場合、ラムダ式にしないほうが賢明ですね。
項目 43: ラムダ式よりメソッド参照を選ぶ *7
(自明なメソッド名なら)メソッド参照はラムダ式よりも読みやすいし、メソッド自体もテスト可能なので、メソッド参照が使える場合は積極的に使いましょう。
項目 44: 標準関数インタフェースを使用する *8
多くの場合、標準関数インタフェースだけで事足りるので、自前でインタフェースを定義する必要性はあまりないですが、この項目はその必要性の判断基準と、定義する際の注意点を説明する項目です。
項目 45: ストリームを注意して使用する *9
無闇にストリームを使いまくると、可読性と保守性に悪影響をおよびす恐れがあります。ストリームを上手に使うためのヒントを提示する項目です。
項目 46: ストリームでは、副作用ありの関数より副作用なしの関数を選ぶ *10
ストリームのパラダイム自体は関数プログラミングに基づいているので、ストリームの表現力と速度と並列化の可能性を最大限に活かすには、使用する関数の同じパラダイムに従う必要があります。
副作用のある関数を使用する場合、一つ一つの処理はストリーム内の中間状態だけでなく、外部にも依存しているので、全体の流れが分かりづらくなるかもしれません。速度も並列化の可能性も、外部の依存先による影響が大きいので、ストリームの利点を活かすのは難しいでしょう。
項目 47: 戻り値として、ストリームよりコレクションを選ぶ *11
コレクションはイテレーションとストリームアクセスを同時に提供できるので、シーケンスを取得する public なメソッド戻り値として、可能であればコレクションを利用しましょう。コレクションを利用できない場合は Stream か Iterable を使いましょう。
項目 48: ストリームの並列化は注意深く使用する *12
並列化することによって、ストリームのパフォーマンスが改善されるのは、ストリームのデータソースに大きく依存しているので、手当たり次第ストリームを並列化するのはやめましょう。
項目 55: Optional を注意して返す *13
Optional を返すメソッドで null を返さない、コンテナを Optional でラップしない、プリミティブ型の場合は専用のものを使うなど、Optional を使うにあたって知るべきアドバイスを教えてくれる項目です。
おわりに
新しい項目以外に、元々あった内容も現状に合わせて一通り改定したようです。読みがいありそうですね。
近いうちアプレッソ内で第三版の勉強会は開催されると思うので、その様子と内容を追って共有していきたいと思います。
*1:Item 5: Prefer dependency injection to hardwiring resources
*2:Item 9: Prefer try-with-resources to try-finally
*3:Item 21: Design interfaces for posterity
*4:Item 25: Limit sources files to a single top-level class
*5:Item 32: Combine generics and varargs judiciously
*6:Item 42: Prefer lambda to anonymous classes
*7:Item 43: Prefer method references to lambdas
*8:Item 44: Favor the use of standard function interfaces
*9:Item 45: Use streams judiciously
*10:Item 46: Prefer side-effect-free functions in streams
*11:Item 47: Prefer Collections to Stream as a return type
*12:Item 48: Use caution when making stream parallel
*13:Item 55: Return optionals judiciously
「探索的テスト(Exploratly Testing)」について
こんにちは、品質マネジメント部のいそです。
これはアプレッソAdventCalender10日目の記事になります。
何を書いていこうかとしばし考えていたのですが、ちょうどいい機会だったので「探索的テスト(Exploratly Testing)」についての学びをアウトプットしておこうと思います。
まずは基本的なところから・・・
探索的テストとは
- テスト仕様などのテストソースを作成せずに、様々なインプット(対象の仕様書、過去の経験、勘)から仮説を立ててバグを見つけ出す
- 一つのアクションをとるごとに次にどうするかを検討するため、柔軟にテストを進められる
- 設計→実装された通常のテスト(スクリプトテスト)では、事前に検討されただけに網羅性は高まるが(探索的テストと比較して)重いテストとなる。
- 探索的テストのモデル図
- 探索的テスト研究会が作成したモデル図がわかりやすい
- テスト仕様の作成コストを抑えられるといっても、テストの全てを探索的テストに置き換えるのはやりすぎ。スクリプトテストと探索的テストは補完関係にあるので、適材適所で用いる。
進め方
大きく3つのやりかた(下に行くほど厳格化していく)
- すきにやる
- すきにやる
- チャータを利用する
- 目的やそれを達成する為に必要な指針などを決めて書いておく
- シナリオをチャータとして利用することもあるが、スクリプトテストでの具体的な「手順」とはことなりおおまかな記述とし、実行の幅を持たせたりする
- セッションベースに行う
- チャータを用いつつ1セッション1時間といった区切りを設定して実施する
- 何に対してどこまで実施したかを管理しやすくなる
探索的テストを支えるツール群
- Capture for Jira
- JIRAと連携するCaptureツール
- スクリーンショットに注釈をつけてJIRAにIssueを作成
- そのままチームで議論したりできる
- qTest Explorer
- キャプチャや操作時のTimelineを残せる
- いついつクリックした
- いついつ入力した
- Seleniumのテストシナリが出力できるので即自動化できる模様
- 同社製のテスト管理ツールへとりこんだりJIRAと連携してIssueの作成もできる模様
- キャプチャや操作時のTimelineを残せる
などといったものがあるが、これらはWebアプリケーションのみでデスクトップアプリケーションが対象だった場合には使えない・・。 よさげなものはないかと探してみると↓のツールを発見した。
- Rapid Reporter
- Shmuel氏作成のフリーソフト
- 無骨(シンプルともいう)
- 自動記録はない
動かしてみる
DataSpiderServistaのStudio for Desktopを対象に動かしてみる
起動すると下の画面が出てくる
常に全面に表示される。ウィンドウの透明度を変更することもできる。 このウィンドウに1行程度のメモを書いていく。
ますは最初にReporterを入力、そしてCharterを入力する。
(Enterを入力するとIMEの日本語変換時でも即ログに書き込まれてしまうの悲しみある・・・。)
するとステータスが表示される。 カーソルキーの上下を押すことで、以下の通りに変更できる
- Setup
- Next Time
- Question
- Bug
- Check
- Test
- Note
Noteまで進むとSetupに戻るので、学習や仮説検証のループを行いながら思考を記録できる。 記録したログは↓のような形でCSVもしくはHTMLで出力できる。
まとめ
- 対象に対する知識や同種のものに対しての経験も必要だったりするため、新人がいきなりふられるとつらそう感はある
- とくに意識せず探索的テストをしている場面はちょこちょこある
- 少ないインプットで作成したテスト仕様では、実際のテスト時に探索的なテストをして、元のテスト仕様にフィードバックしていることはある
- そういった意味では普段やっていることの延長でもある
- 改修確認時に周辺の確認をするのにも役立てられそう
そんなわけで・・
- アプレッソではアジャイルな体制で開発を行っており、QAにおいても早さと品質を両立できるように日々スキルを研磨しています。興味があればご一緒しましょう!