実践ソフトウェアエンジニアリング 20章で好きなところ
このエントリは実践ソフトウェアエンジニアリング第9版アドベントカレンダー の23日目（実質29日目）です。
https://www.amazon.co.jp/dp/4274227944
自分が担当した20章「ソフトウェアテストー統合レベルー」にに書かれている良いテストの特性を考えてみようと思います。
1. 良いテストは、高い確率でエラーを発見できるテストである
良いテストは、高い確率でエラーを発見できるテストである
この目標を達成するために、テスターはソフトウェアを理解し、どのようにソフトウェアが失敗するかを頭の中でイメージしなければならない。
個人的に良いと思うのは、「テスターはソフトウェアを理解する必要がある」ということと、「失敗をイメージしないといけない」ということです。「ボタンを連打してみた」ではなく、特定の狙い（イメージ）を持ってテストをするのが良いと思います。もちろんバグが出やすい操作はありますが、「イベントが短時間で連続で発生したときに制御されていないかもしれないので、ボタン連打をする」というところまでイメージしながらテストできると良いと思います。
テストはイメージの世界です。（葬送のフリーレン風）
2. 良いテストは、冗長ではない
良いテストは、冗長ではない
テストの時間とリソースは限られている。2つのテストケースを同じ目的で実行しても意味がない。すべてのテストは、たとえそれが微妙な違いであっても、それぞれが異なる目的をもつべきである。
試験書などに書き起こしても、テストの目的が書かれていないことがあります。これはとても勿体ないですし、レビューなどで重複を取ることが大変になるので常にテストの目的を書いておきたいところです。探索的テストなどでガリガリ動かすときも、テストの目的を考えておくのはいいですよね。一番最初に述べた「失敗のイメージ」にもつながる話だと思います。
3. 良いテストは、「ベストオブブリード（最高の品種）」であるべきである
良いテストは、「ベストオブブリード（最高の品種）」であるべきである
時間やリソースに限りがあるときは、目的の似たテスト群の中から特定種類のエラーすべてを発見できそうな「最高の品種」といえるテストのみを実行するのがよい。
テストというと「網羅網羅」というようなモウラ星人が多いのですが、早くフィードバックし、早くテストを終わらせてプロダクトをリリースするにはテストの網羅も考えつつ、数を減らさないといけないです。なので、ここでいうような良いテストをデザインする力が必要になります。
4. 良いテストは、単純すぎても、複雑すぎてもいけない
良いテストは、単純すぎても、複雑すぎてもいけない
複数のテストケースを1つのテストケースにまとめてることができる場合もあるが、副作用が発生してエラーの存在が隠れてしまうこともある。一般的には、各テストは独立して実行するのが良い。
3つ目からの続きになりますが、色々なエラーを取れるようなテストケースをデザインしてもそれによって隠れてしまうエラーがあっては本末転倒になります。また前のテストが後のテストに影響するようなこともありますので注意が必要です。
クリーンテストの５つの規則でF.I.R.S.T（Fast Independent Repeatable Self-Validating Timely）と言われるように、どのテストでも独立性は重要になってきます。
まとめ
こんな感じでチームの中で「自分達の考える良いテスト」って何だろう？って話ができれば良いと思っています。 ちょっとずつでもチーム全体で品質のことを考えていければよいですね！
探索的テストの「オポチュニティ」を意識する
探索してますか？
最近は色々なところで探索的テストの話を聞くようになりました。個人的に少し気になることがあるので、書いてみようと思います。
このエントリはテストの小ネタアドカレ 20日目です。
気になっていること
気になっていることはずばり、
「チャーターだけに沿った探索的テストをしていませんか？」
ということです。
探索的テスト≠チャーターを使ったテスト
探索的テスト＝チャーターを使ったテストみたいな認識になっている気がしていて、それはちょっと違うかなと思っています。探索的テストはあくまで目の前にあるソフトウェアから得た情報をもとにテスト設計、実行をしていくテストだと思っています。 慣れていないと事前に記述するチャーターを細かく設定することが多く、それはほぼ抽象度の高いテストケースになります。そしてそれがある程度網羅されていると、それをなぞるのに精いっぱいになったり、網羅することで満足してしまいます。
「チャーターに沿って探索しましたが、バグは出ませんでした。」
そんな報告が聞きたいんじゃない！バグを見つけたいんですよ！！我々は！！ 手順がないテストケースだけを実施して満足したいわけじゃないんです。
オポチュニティ
そこで重要になってくる考え方が「オポチュニティ」です。 Rapid Software Testing(RST)に記述されている探索的テストの1つであるセッションベースドテストの報告項目には以下が含まれています。*1
チャーター/オポチュニティ（トータルセッションに対する割合。オポチュニティはチャーターには当てはまらないが、有用なテスト作業である）
チャーターに80％、チャーターに沿わない時間（＝オポチュニティ）が20%の場合は80/20みたいな形です。 このオポチュニティと全体に対する割合が定義されていることが重要だと考えています。 図で書くとこんなイメージです。
チャーターに沿った場合は、チャーター付近のバグ（小赤星）は気付くと思いますが、奥深くにあるバグ（大赤星）を見つけることはできません。一方、チャーターから外れて奥を探索することで（＝オポチュニティ）奥深くに存在するバグを見つけることができます。
「じゃ どうやって奥に続く道なき道を見つけるか？」についてはまた別の機会に！
追記
秋山さんから質問があったので、自分なりの答えを書いてみます。
質問①： 「チャーター/オポチュニティ」という指標の測定結果の数値の妥当性はどう判断したら良いのですか？
nemorine的回答： 常にオポチュニティが0（図でいうと緑のところが一つもない）というのは避けたほうがよいと思っています。すなわち、100/0 というより90/10や80/20みたいな形がいいのだろうと思っています。 割合はソフトウェアの作り、テスターのスキル、チャーターの抽象度などによると思っているので、理想は80/20みたいなものはないと思っています。ただ、「2割くらいはチャーター外れていきましょう！」というようなチームの目標値は個人的にはありだと思います。
質問②： この式に「検出したバグの数や種類」が現れていないのも気になります。
nemorine的回答： RSTにはバグの報告の記述はありますが、チャーター/オポチュニティによるバグの数や種類の分類はないです。やってみると面白そうな気がしますが、実務的には単純にソフトウェアの機能で分類する方が有益そうだと思います。
*1:これ以外の報告項目に関しては セッションベースドテスト を参照のこと
アジャイルジャパン札幌サテライト2021（年度）
本エントリはAgile Japan 2021アドカレ！の19日目のエントリです。
2021年も残りわずかになりました。
来年2022年3月5日に11年目のアジャイルジャパン札幌サテライトを実施します！
いやー 11回とはなかなかですね。アジャイル札幌と共に歩んで来たと言っても過言ではないアジャイルジャパン札幌サテライトだと思っています。
- 2011-04-15 Agile Japan 2011 サテライト<札幌>
- 2012-03-16 Agile Japan 2012 サテライト<札幌>
- 2013-05-24 Agile Japan 2013 サテライト<札幌>
- 2014-06-27 Agile Japan 2014 サテライト<札幌>
- 2015-04-18 Agile Japan 2015 サテライト<札幌>
- 2016-06-26 Agile Japan 2016 サテライト<札幌>
- 2017-07-22 Agile Japan 2017 サテライト<札幌>
- 2019-03-16 Agile Japan 2018(年度) サテライト<札幌>
- 2020-03-07 Agile Japan 2019(年度) サテライト<札幌> コロナにより中止
- 2021-03-06 Agile Japan 2020(年度) サテライト<札幌>
- 2022-03-05 Agile Japan 2020(年度) サテライト<札幌> ← NEW！
ここで企画の一部をお伝えします。
まずは今年はオンサイトで実施します。久しぶりの対面でちょっとドキドキしますね。 ゲストは日本版JOY INCことクリエーションラインの社長の安田さんです！！ 札幌に足を運んでもらい、JOYを広めてもらいたいなぁと考えています。 安田さん、お待ちしています♪
皆さん、久しぶりにリアルで会えることを楽しみにしています。 コロナが落ち着いていることを願っています ＞人＜
実践ソフトウェアエンジニアリング 16章で好きなところ
このエントリは実践ソフトウェアエンジニアリング第9版アドベントカレンダー の16日目です。
https://www.amazon.co.jp/dp/4274227944
自分が担当した16章「レビューの推奨手法」における好きなところを3点書こうと思います。
レビューへの向き合い方（P243）
- 作成者ではなく成果物をレビューする。
FTRには、人とエゴが関与している。適切に実施されたFTRは、すべての参加者が達成感を感じるものでなければならない。一方、不適切なFTRは審問のような雰囲気を醸し出すことがある。エラーを指摘するときは優しく、ミーティングのトーンはゆるやかで建設的なものにし、恥をかかせたり、貶めたりすることを意図してはいけない。レビューリーダーは、レビューミーティングにおける適切なトーンと態度が維持されるよう努め、レビューが制御不能になった場合は直ちに中止の判断をすべきである。
読む前はエンジニアリングということで手法の紹介がメインかと思っていたのですが、レビューへの向き合い方がガイドラインとして書かれています。ともすると人格攻撃になったりするので、ビューの場だけではなく、日常的に気を付けないといけないことだと思います。
自分が何かをレビューするときに気にしているところも書いてみます。（できてないときもあるけど意識しようとはしてますｗ）
- 根拠のない高い期待をしない
- まず全体を見て、いいところを探す
- 問題を提示する箇所は理由を言う（可能な限り言語化する）
- 好みの場合はオプションとして提示するが決定は任せる（後で文句は言わない）
レビューは時間を…するもの（P239）
「レビューは時間を奪うものではなく、時間を節約するものである。」
言われてみると当たり前なのですが、レビューに時間を奪われていると感じる人が多いのも事実だと思います。 大抵、「レビュー工数が組み込まれていない」とか「レビューが一人に集中する」とか「定型的に10人が見るようになっている」とかではないでしょうか？自分達のプロセスに合わせて柔軟に変えていきたいところです。
図を見るとレビューの有無によって工数に違いがあります。マズいものは早めにフィードバックする。アジャイルテスティングの本質にも通じることだと思います。
アジャイルのレビュー（P244）
スクラムのフレームワーク（3.4節）を詳しく見ると、非形式的レビューと形式的レビューが行われる場所はいくつかあることがわかる。スプリントプランニングでは、次のスプリントに含めるユーザーストーリーをレビューし、優先度にしたがって順位付けをする。デイリースクラムは非形式的レビューの1 つと見ることができ、（後略）
インスペクションレビュー以外はレビューとして認めないという原理主義みたいな方もいますが、あらゆるところにレビューはありますよという話がここにキチンと書いてあります。インスペクションの良さを否定するつもりはありませんが、日常的に対話をしながら、問題が小さいうちに摘み取ったり、チームとしての共通認識を育てていく方が自分は好きです。
まとめ
今回はレビューの章を紹介しました。 分厚くて堅い本と思われますが、結構いいこと書いていますので是非ご一読ください（宣伝
レビューの向き合い方に関してはこの記事もおススメです。
マスに翻訳で叱られた話
先日12月1日に『実践ソフトウェアエンジニアリング 第9版』が発売されました！
https://www.amazon.co.jp/dp/4274227944
ワイワイ！！
このエントリは実践ソフトウェアエンジニアリング第9版アドベントカレンダー の9日目です。（1日間違ってた。。。）
お叱り！
翻訳をやり始めると悩みが出ます。そうDeepLとどう付き合うかです。
最近のDeepLはかなり精度がよく、日本語もしっかりしているため、翻訳時にかなり使っていました。自分の訳がDeepLを越えられないことも多く、結構な部分をdeepLの翻訳に頼っていました。
そうしたところ、レビューアのマスから「DeepL臭がプンプンするぜっ！！（JOJO風）」というお叱りを受けました。。。
マス、カズさんの最強コンビからの指摘を受け、自然な日本語になるようにかなり検討しました。
今のところ、「DeepLはいい訳を出すけど、自然な日本語になるにはもう少しかかりそう。また頼りすぎると、自分で日本語を考える力が奪われそう」というのが自分の結論です。
翻訳時に気を付けたポイント
自分が翻訳時に気を付けたポイントBEST3を書き留めます。
① 受動態と能動態 英語だとWe / Youを省略したいため、受動態が多いですが日本語だとちょっと違和感があります。 例えば、「レビューは実施される」みたいな訳です。日本語としてもあっていますが、ちょっと違和感がありますよね。 自分の中では、使い分けをしていて、自チームや自組織などコントロールできる箇所は能動態にしました。 一方、アンダーコントロールなものは受動態にしています。
②主語と述語のズレ これはカズさんに多く指摘されましたが、主語と述語がねじれていることが多くありました。 一文を主語、述語のみで読んでみると違和感を感じることができます。
③ テンポ 日本語にしたときのテンポを気にしました。 助詞や動詞も含めて音がまどろっこしいところなどはスッキリするように直しました。 関係代名詞で繋いである長文は、前から訳しつつ、途中で切って長くならないように修正しました。
せっかくなので自分が翻訳でかなり悩んだ個所を載せておきます。下記の例文は第16章のレビューの推奨手法の章の一文です。
原文
We have known this for decades, and yet there are still many developers who do not believe the time spent on reviews is almost always less than the time required to rewrite bad code [Yad17].
deepL訳(2021/12/10翻訳)
このことは何十年も前から分かっていたことですが、未だにレビューに費やす時間はほとんどの場合、悪いコードを書き直すのに必要な時間よりも短いと信じていない開発者がたくさんいます[Yad17]。
nemorine訳
このことは何十年も前から分かっていたが、多くの開発者は「レビューに費やす時間は、ほとんどの場合、悪いコードを後から修正する時間よりも少ない」ということを信じていない[Yad17]。
ここは「短い」「信じていない」「たくさんいる」と続き、なかなか上手い訳になりませんでした。カッコを付けるとスッキリしたのを覚えています。
ということで、組版ができてからも何度も読み返し、ギリギリまで頑張った甲斐があって、自分として納得できる日本語訳ができたと思っています。 またいつか翻訳に挑戦したいと思いました！
流れ弾
ちなみに翻訳が終わりそうなときにこんなTwitterが流れてきて、あやうく死にかけました。マジで危なかった ＞＜
この翻訳は、翻訳ソフトを使った翻訳ではないかという疑いです。
— 石田英敬 (@nulptyx) 2021年10月11日
私自身も英語論文を書くときなどに使っていますが、一般的に使用できる翻訳サービスに、google translateよりも自然な翻訳ができるといわれる人工知能の機械学習を活用したサービス Dがあります。
https://www. D
この場を借りて、キチンと言ってくれたマスとカズさん、誘ってくれたみずのりに感謝したいと思います。 またギリギリまで付き合ってくれたオーム社の石田さんにもめちゃくちゃ感謝しています。
小学生の子が勉強にハマる方法読了
Twitterで見かけて買って読みました。
難しすぎる問題（パニックゾーン）をやらせても成長しない。これは大人も同じだと思う。子育てと職場の両方で思い当たるフシがあり、反省しすぎて死にそうです。https://t.co/VgrioXJYxP pic.twitter.com/ODHezc9e7v
— 良太郎 (@ryota_hnk) February 6, 2021
子供に対する親の間違ったやり方を優しく指摘してくれる本だと思います。
そして理論がキチンとしているので納得感が違います。
言語化できていなかったところや、心理学、ゲーミフィケーション、アンガーマネジメントなどが簡潔に述べられているのでとても良い本だと思いました。
リファレンスがガッチリついているのも嬉しいですねー
これは新人育成とかに悩んでいる方にも必要な本だと思います。
自分がグッときたところ
「人は自分の力を大幅に超えるものにチャレンジしても成長できない」
これは以前のチームのときからずっと思っていました。自分は「人が学ぶには段階」があるという認識をしていたのですが、それと同じことが書かれていました。 この本では3つに分けています。パニックゾーンは学習できないとのことです。
- 快適ゾーン・・・ストレスなし
- 成長ゾーン・・・適度なストレス ← ここがいいところ
- パニックゾーン・・・過度なストレス
パニックゾーンは会社の業務のみならず、スポーツも同様で、スノーボードで自分の力量を超えた斜度で滑っても全く上手くならないんですよね。実体験としてイメージできます。
脳は2階建て
川口さんに教えてもらったファスト＆スローに載っている脳のシステム1、システム2の話が出てました。
- 2階の脳：意識的な領域、思考、メタ認知
- 1階の脳：無意識的な領域、本能性処理
子供の2階の脳は建設中なのでときどき不具合を起こすのは当然なので大目に見ること。 以下の「す・い・さ・つ」のときは2階の脳は働きにくくなるとのことです。
- す：お腹がすいている
- い：いらついている
- さ：さびしい
- つ：つかれている
お腹すいてるとホントに無理です。。。
結果ではなく、行動に注目すること
コントロールできない結果ではなく、コントロールできる行動に着目してくださいということが書いてました。結果はどうあれ、行動ができていればまずはOK、褒めるときも行動を褒めるというスタンスがとても良いと感じました。
自分はKPTなどのふりかえりのTryで結果系と行動系を意識するようにしています。
上から降ってくる半期の目標なんか効率xx%アップみたいなの多いですよねｗ
まとめ
ぜひ読んでください♪ （回し者じゃないけどｗ）
人類よ！これがテスト自動化だ！プロの自動化エヴァンジェリストの技術を一緒に学ぼう！ 参加報告
JaSST東北で一緒に活動している伊藤さん（ぷっちゃん）がエバンジェリストとして登場するということで途中から参加しました。
いいことが沢山あったので、メモを書き残しておきます。
何か間違ってたら指摘お願いします～
Q. 自動化で工数削減できますか？
- 工数削減をメインにすると変な方向に進む。
- どこをターゲットにするか明確にできれば削減自体はできる。
- 自動化によってテスト実行を削減できたぶん、メンテに人がかかることがある。
- テスト実行工数は夜間実施や並列実施で時間が減る。
- 無駄がいっぱいあるようだと見た目の工数削減はできる。
Q. 自動化で品質が上がりますか？
- テストで品質が上がりますか？と同じ質問。
- 現状認識するところが自動テスト。その後で開発が頑張ることで品質が上がっていく。
Q. E2Eの場合、WebDriverとテストSaaSではどちらが強いでしょうか？
Q. テストピラミッドから考えて、単体テストが充実している場合はAPIテストを飛ばすのもありでしょうか？
- 正直ケースバイケース
- テストピラミッドはたたき台と思っているので、自分達で納得感を持ったピラミッドを作ることが重要。
Q. SaaSが普及した場合は、テスト設計するより、SUTを操作しながら探索する方法が優位になるでしょうか？
- 優位になるかは必ずしもそうではないと思う。
- テスト設計をすることで、チームの品質に対する共通認識が得られる。
- 探索的テストがやりっぱになっている場合は安心感が得られない可能性はある。
Q. mablのオンプレ版のリリース予定はありますか？
- いまのところなし。[藤原さん]
Q. ツールは手段でしかないと思いますが、ツールを使うことが先行してしまう場合もありませんか？
- 個人レベルでは手段先行もありかと思う。例えば全く使ったことがない人とかには効果的だと思う。
Q. アジャイル開発と自動テストの関係性についてどう思いますか？
（会場内のアジャイルテスター比率は2/150）
- 名乗っていないだけではないか？
- マルチロールで大変なイメージ。
- 自動化エンジニアもアジャイルテスターの一つではないか。[藤原さん]
- 海外で一番人気なのはコンサルさんとそれを利用する会社のセッション。[藤原さん]
- 前職で手動でも早くテストを実施して、開発と一体化していたのはアジャイルテスターだと思った。[藤原さん]
Q. テスト自動化が上手くいくのはどういうケースでしょうか？
- 時間をしっかりかける。
- リーダーシップを取る人が少なくとも一人は必要。
- 運用にのせたらメンテをする。
- プロジェクトの最初から自動化の算段を立てる。
Q. QAが自動化するのとエンジニアが自動化するのとどちらがいいでしょうか？
- ユニットはエンジニア、E2EはQAがいいかも。
- 理想の形が組織ごとにある。
- 人数比も影響ありそう。
Q. 自動化の比率はどれくらいが適切なのでしょうか？完全自動化はありますか？
- 操作しやすい比率なので気を付けないと恣意的になる可能性がある。
- 体感の参考値は既存テストケースの3～4割が自動化すると一段落する感じ。
Q. テスト全体の中のスコープやテスト目標をどう決めていますか？
- リーン開発の現場より、テストのリスク、手動テストのコスト、自動化のコストを考え、優先順位をつけてどこまでやるかを考える。
Q. 手がけるテスト自動化と手動テストや他の自動テストとの相乗効果を生み出すためには？
- （技術的なレベルでは）CIパイプラインを構築する。
- 人のレベルでは、ユニット → E2Eの流れを考えて重複を避け、前のレベルでできていないところをカバーする。
Q. 大きなソフトウェアに対し、自動テストがすでに構築されているとき、変更にはどうやって対応しますか？絞るのも自動でやっていますか？
- どこかの会社で自動で絞るのもやっているのを見た *1
- 手動で影響範囲を出すか機能的に重要なところか。
- 実行を効率化して、変更ごとにすべてのテストをやるという方向もある。
Q. 自動化の上手くいっている評価基準は？
- 自分達で決めるのが一番大事
- 自動化の上位目標が守られているかどうかで確認する
Q. 自動化テストチームと手動テストチームを繋げるのもエバンジェリストの仕事ですか？
- あまり意識したことはないけど、仕事の過程でつながったことはあると思う
Q. 新規開発のときは動くものが後ろになるため、E2Eの自動化が難しいと思います。
- SaaSを使って、書き捨てでもいいから対応してしまうというのは一つの手だと思う。
- 1回目は手動、2回目は自動。[藤原さん]
- 自動化をする過程のときに、探索的な手動テストをやってしまう。
Q. 自動化エバンジェリストになるために必要なスキルは？
- 色々な対象の自動化を知るのが第一歩。事例としてもっておくだけでも良い。
- エバンジェリストは実装技術でトップである必要はない。
感想
タイトルからハンズオンみたいなイメージかと思って参加しまいたが全然違いました（笑 でもとっても勉強になりました。どうもありがとうございました！
*1:たぶんGoogleの話。JaSST’18東京でJohn Micco氏が回帰テストの自動選択の話していました。 http://jasst.jp/symposium/jasst18tokyo/pdf/A1.pdf
