Test Smellsが埋め込まれる背景の話はだいたいこのSurveyを参考にしました。
個人の技量不足というのは想像に容易いと思いますが、テストコードの自動生成ツールや会社で標準化された習慣もTest Smellsに寄与するというのはTest Smellsを除去しようと考えていく上で結構大切なポイントかな、と思ったので紹介しました。

他にも、Test Smellsの混入率はドメインによって変わってこないという話も興味深いです。

A. Peruma, K. Almalki, C. D. Newman, M. W. Mkaouer, A. Ouni, and F. Palomba, “On the distribution of test smells in open source Android applications: An exploratory study,”

WebアプリケーションだけではなくモバイルアプリケーションでもTest Smellsって普通に発生するものだよ、という話を紹介する際に使いました。

モバイルアプリケーションがコンテキストになっているSurveyだったので発表ではそこまで触れなかったのですが、非常に面白い論文で、モバイルアプリケーション開発をしていく際にどういうTest Smellsがどういうタイミングで混入されやすいのか？という話をしている貴重な論文です。

Soares, Elvys; Ribeiro, Márcio; Amaral, Guilherme; Gheyi, Rohit; Fernandes, Leo; Garcia, Alessandro; Fonseca, Baldoino; Santos, André “Refactoring Test Smells: A Perspective from Open-Source Developers”

Test Smellsはコードを普段から書いている人の多くが違和感を検知することができる(≒可読性が低いと感じる)という話を紹介する際に使いました。

開発者の主観ではあるものの意外と定量的にTest Smellsの認知に対してデータを取っているSurveyが少ないので、貴重な論文です。

J. De Bleser, D. Di Nucci, and C. De Roover, “Assessing diffusion and perception of test smells in Scala projects”

Test SmellsにまつわるSurveyはJavaやJUnitを用いているものが大多数であり*1、Scalaで調査がされている貴重なSurveyです。

Refactoring Test Smells: A Perspective from Open-Source Developersの論文では開発者がTest Smellsを認知できることが示されていましたが、なんで問題があるのかはほとんどの開発者が言語化できないというのは、Test Smellsについて改めて学ぶ一つのモチベーションになるかな？と思い発表で紹介していきました。

Scalaというコンテキストだったのであまり紹介できなかったのですが、Assertion Rouletteやlazy Testが特に発生しやすいという話などはなかなか興味深いです。

Manuel De Stefano, Fabiano Pecorelli, Dario Di Nucci, and Andrea De Lucia, “A preliminary evaluation on the relationship among architectural and test smells”

アーキテクチャとTest Smellsの関係性について書かれている論文なので、Test Smellsが埋め込まれる背景の部分で簡単に紹介しました。

今回は発表のスコープ上あまり紹介できていないのですが、テスティングフレームワークのバージョンアップをしてもアーキテクチャがひどすぎてTest Smellsが普通に埋め込まれるというのはまあまあある話らしいので、心当たりがある方はぜひ読んでみてほしいのですが、個人的にはあまり内容に共感できませんでした。(論文で言われているアーキテクチャ上の課題がなぜTest Smellsに結びつくのかの説明があまり理解できなかったため)

Dong Jae Kim, Nikolaos Tsantalis, Tse-sun (Peter) Chen, and Jinqiu Yang, “Studying Test Annotation Maintenance in the Wild”

今回の発表をしようと思ったきっかけになった論文です。

開発者はTest Smellsをやむをえないものとして捉えているものの、実はテスティングフレームワークを最新化すると解消できるものだったりするよ、という話が書かれています。

Elvys Soares, Marcio Ribeiro, Rohit Gheyi, Guilherme Amaral, and Andre Santos, "Refactoring Test Smells With JUnit 5: Why Should Developers Keep Up-to-Date?"

上記のStudying Test Annotation Maintenance in the Wildの話が拡張されているものであり、発表中に紹介したTest Smellsの解消例に関してはこちらの論文を参考にしています。

また、JUnit5って2017年のものだけどまだアップデートされていないの！？と驚く人もいるかもしれなかったので、Javaの主要OSSですら15.9%しかJUnit5へのアップデートが完了していないことの説明としても使いました。

*1:今回の発表のテーマをJUnitとしたのもそれが理由

2023-05-21

スクフェス新潟のスライドまとめ

スクフェス新潟のスライドをまとめていくエントリーになります。

ただ、今回スライドまとめのチャンネルがない(?)こともあるのか、スライドが少なめなので、もう少し集まり次第更新し、そのタイミングでTwitterでも再周知しようと思います。

何も無いシステム開発体制を打開する為に取り入れたウォーターフォールとスクラムの仮説と実践について

新潟の日本酒について

アジャイルテストクイズ王 2023

Morning Lean Coffee & Morning Yoga

Reaching the “Big Picture” In Testing and Quality / テストと品質における「全体像（ビッグピクチャー）」への到達

夢に挑むことは難しい、でも、諦めたくない〜あなたの背中を押すセッション〜

徹底的に自分たちのプロダクトを検査する『自分たちでデモをしない』スプリントレビュー

JUnitで学ぶTest smells撃退法

人やチームの関係性について学び始めると待ち受けている罠 2023 -Saga of the psychology the evil-

アジャイルテスター視点で、ユーザーストーリーマッピングを活用した効果的なプロダクト開発

いきいきした受託開発をするためにアジャイルチームができること

speakerdeck.com

PO,SMに送るテスト自動化の8原則に5箇条を添えて

speakerdeck.com

保守 (Ops) の保守改修プロセス構築記

なぜ「聴く」ということは難しいのか

www.docswell.com

慶長三年創業の老舗建材商社でスクラムチームを立ち上げたい！

とあるQAエンジニアが、マイクロサービスの開発チームと、出会ったーー

オレオレになりがちなテスト計画を見直した話

相互理解を目指す対話主体のコミュニケーションで心の負担を軽減し持続可能な組織変革を

QAはチームの外から支援するのか？中から支援するのか？

speakerdeck.com

チームの成長を促すためにふりかえりの改善に本気で向き合った話

「あなたすごい人、私ふつうの人」を乗り越える！経験をプロポーザルにしてみよう

www.docswell.com

Whole-Team Approach (WhTA) for babies

2023-05-20

スクラムフェス新潟2023で登壇してきた

confengine.com

スクラムフェス2023で登壇してきたので、そのふりかえりをしていこうと思います。

登壇準備
登壇中
登壇後

登壇準備

今回は技術面にめちゃくちゃ振り切ったセッションで、自身に取っては初めてのチャレンジとなるセッションでした。

話のベースは「Refactoring Test Smells With JUnit5 Why Should Developers Keep Up-to-Date」というSurveyにある、JUnit5の機能を活用してテストコードのリファクタリングを実施したらOSS開発者から広く受け入れられた(超ざっくりまとめ)という話で、そこに対してそもそもなんでTest Smellsが発生するのかや具体的なリファクタリングコードを肉付けしていくような形での準備になりました。

話の構成としてはプロポーザルを出すタイミングである程度できていましたし、肉付けとして使うSurveyや書籍についても自分の中で見当がついていたので、最初の方スムーズに準備を進めることができていたのですが、具体的なソースコードを書いてみるタイミングで躓くことになりました。

というのも、Surveyで紹介されているリファクタリング事例の幾つかには、JUnit5だからどうこうという話ではないものがあったり、リファクタリングすることで可読性が低くなるリスクもあると思えるような事例があり、適切な事例を考えるのに苦労しました。(実際にSurveyをもとにJUnit5を使ってリファクタリングされたコードのPRを漁ってみたのですが、同様の感想を抱くPRもありました)
例えばException HandlingのTest SmellsはJUnit4でも取り除くことができるのですが、JUnit5から取り除けるようになったように受け取れる例が書かれていたり、@ParameterizedTestを使ってTest code duplicationのTest Smellsを取り除けたもののテストコード自体の可読性が下がったりといったのはその一例です。

また、JUnit5を活用してTest Smellsの一部を消すことができるのは事実ですが、JUnit5の機能を使う前に「xUnit Test Patterns」に書いてあるようなフレームワークのバージョンに依存せずとも消せるTest Smellsを幾つか紹介した方が参加者のアウトカムにはつながるのでは？という想いも資料を作りながら出てきて、どうしたものか頭を悩ませました。
ただ、フレームワークのバージョンに依存せずとも消せるTest Smellsを紹介するとなると、ほぼ間違いなく「xUnit Test Patterns」以上のことは聞けなかった、となりますし、「xUnit Test Patterns」に書かれている内容の整理は他の多くの方々がされていることが分かり、独自性が出ないなあと思って却下しました。

登壇中

タイトルにJUnitを入れたことでセッションを聞きに来る方はある程度限定されるかと思っていたのですが、結構多くの方々が聞きに来てくれた上に、技術に明るい方々も多くいらっしゃったのでいつもとは全然違った緊張感がありました。

序盤で練習では喋れていたことがすっかり飛んだりして、一旦落ち着こうと思って意図的にセッションを止めてDiscordを見る時間を作ったりしたのですが、最後まで緊張は続いていました。*1

緊張がほぐれたのは発表が終わった後にみんなが拍手してくれているのが画面越しで見たタイミングでした笑

お聞きくださったみなさん、どうもありがとうございました！

登壇後

今回はテストがテーマの新潟ということで、JUnitを題材にして技術的なセッションにチャレンジしましたが、また別のテーマで技術的なセッションにチャレンジしてみたいです。

資料は公開しようと思っているのですが、現在ちょっとバタバタしており、もう少々時間がかかるかと思います。

*1:ただ、それでもそのまま話し続けるよりは明らかによかったと思っています

2023-05-19

スクラムフェス新潟2023〜Day1〜に参加してきた

www.scrumfestniigata.org

今日から2日間スクラムフェス新潟に参加しているので、その様子をブログに書こうと思います。

会場に向かうまで

Ryoさんと同じ新幹線で会場に向かいました。新潟駅でRyoさんと合流した後、それぞれホテルにチェックインしようとしたら中さんが現れ、自分と一緒のホテルなことが判明したのでそのままホテルに向かっていきました。

その後は無事にホテルに着き、チェックイン後に会場に行きました。

受付

受付でkobaseさんAckyさんTommyさんと会いました。しっかりとおおひらさんと2ショットを取った後、いづさんにおちょこと缶バッジをいただきました。

main-roomへ向かうまで

Main-roomに向かおうとしたところEmiさんとばったり出会い、軽く会話をしました。
Ryoさんに写真を撮ってもらいましたが、Ryoさんは社内の人に意図的にスクフェス新潟に来ていることを伝えていないと言っていたので無駄にひやひやしました笑(EmiさんはRyoさんが来ることを知っていた模様)

その後、パウリさんと会って会話しました。
昨年のスクフェス札幌以来の再会でしたが、転職活動が無事に成功されたということで何よりです。

オープニング

じゅんぺーさんからオープニングセッションがありました。
アジャイルソフトウェア開発宣言に触発されて作った*1行動規範の説明は非常にわかりやすくてよかったです。

最後にMiroスポンサーであるNRIさんのスポンサーセッションを見たのですが、びばさんが現地にいるのに喋っていないけどびばさんが喋っているという不思議な時間を味わいました。

スポンサーセッション

ウイングアーク1stさんからスポンサーセッションがありました。

以前YoutubeでCTOの島澤さんの紹介は見ていたので自宅の作業場の様子は見ていたのですが、家のDX化などそれ以外のエピソードもあまりにもDS過ぎて驚きました笑

keynote

confengine.com

続いて、坂上さんのkeynoteを聞いていきました。*2

日本酒の歴史的背景や日本酒ができるまでのプロセス、日本酒と環境問題など、これまで全然知る由もなかった話が聞けたので非常に面白い発表でした。

特に、コロナの拡大や価値観の変化に対応して日本酒を売るターゲット層を見直して、がんがんお酒を飲むための人たちではなく、ちょびちょびマイペースに飲む方を対象にした店をオープンした話は、非常に興味深かったです。

スクフェスのkeynoteと言うとスクラムの話/アジャイルの話というイメージがこれまでは強かったですが、Learning Outcomeにある通りこの後のNetworkingで飲む日本酒をめちゃくちゃ楽しめるセッションで、良い意味で既存概念が覆される発表でした。

たのしいスクラム〜何も無いシステム開発体制を打開する為に取り入れたウォーターフォールとスクラムの仮説と実践について〜

confengine.com

こちらの発表を聞いていきました。
ただ、ご飯を食べるためにブースを移動した結果ほとんど音声が何も聞き取れずで、スライドをなんとなくの雑感で追う程度しか聞けずでした...

Markさんと会う

Markさんと会ったのですが、Markさんとはオンラインでの接点が多すぎて、いきなり話しかけてきたけれど誰だこいつ状態になってしまいました笑

アジャイルテストクイズ王

confengine.com

えわさんおめでとうございます！

前回のスクフェス福岡と同じで、書籍の内容は記憶をたどりながらなんとかついていけたのですが、タイトルとか人名は問題文を見てもカンニング無しで答えられないものばかりだったので全然わからずでした。
謙虚な気持ちを持って次回以降機会とテーマが合えば頑張ろうと思います。

アジャイルテストクイズ王の感想戦

アジャイルテストクイズ王の感想戦をえわさんやいくおさん、おーのAさん、ばやしさん、その他周りにいらっしゃった何名かとしていきました。(他の方々、名前伺うタイミング逃してしまいすみません...)
ツーショットを撮らせてもらいました。

変なキャラづくりをしていたせいで答えに窮してしまう場面があり、反省しました。

moriyuyaさんと話す

現地にmoriyuyaさんがいらっしゃり、お話をしていきました。

なんと名刺を名札にされていたので、自分が名刺を持っているわけでもないのに名刺を懇願し、ゲットすることに成功しました！

名刺は相当古いものだと話をしていたのですが、認定スクラムプロダクトオーナーの資格が印刷されていたりしたので、以前からプロダクトマネジメント関連の話に興味を持っていたのかを聞いたり、プロダクトマネジメント関連の知識に関して森さんがソフトウェアコミュニティと他のコミュニティでどのような違いを感じているのか？という話や、森さんが名刺に印字されていた認定資格の研修にまつわる話などを聞いていきました。

びばさんいくおさんえわさんと話す

moriyuyaさんと話をしていた際に近くにいたびばさんいくおさんえわさんと話をしていきました。

「実務に役立つと自分が考えている知識しか覚えようとしていない」という趣旨に受け取られる発言をしてしまい反省しました。

にのみやさんと話す

3月にあったアトラクタさん主催のコーチングリトリートでお話をしたにのみやさんと再会したので、話をしていきました。

にのみやさんはコミュニティ歴がまだ浅くてRSGTも含めてスクフェス初参加なうえに、会社の人や知り合いの人と一緒に来たりしているわけでもないということでその行動力に驚きましたが、近況の話やにのみやさんがスクラムコミュニティに感じること、話の輪に入る難しさ...本音で色々な話をできたので楽しかったです。

びばさんぽめさんと話す

にのみやさんと話し込んでいたら、びばさんが社内でスプリントレビューに呼んでいるというぽめさんを連れてきてくれて、4人でお話をしました。

明日自分が登壇するセッションの時間帯がびばさんと被っているので、びばさんの話気になるのに聞けないんですよね...と言ったところ、「自分もaki.mさんのセッション気になるからお互いに明日何を話すのかこの場でお互いに会話しましょうよ」と言ってくれて、最高の展開になったと心底喜んでいたのですが、自分のセッションの内容を話し終えた後にぽめさんがセッション内容に関して質問をしてくれたタイミングで、びばさんがいなくなってしまい、自分だけネタバレしてびばさんの話は聞けないという事態に陥りました(おとなしくあとで録画みます笑)

びばさんがいなくなった後は、口ではアジャイルを実践するかのようにいうんだけれど実際にものづくりはせずに"上流工程"だけやりきってしまう会社への問題意識やコンサルティング業界に風向きの変化が起きているように感じる話など、生々しい話を多数しました。
ぽめさんの熱いパッションがすごく素敵で、今日もたくさん話ができたのですがさらにまた話をしてみたいです。

クロージングを聞く

川口さんとじゅんぺーさんのクロージングを聞いていきました。

もちろんお酒が入っていたというのはあると思うのですが、やり取りが巧妙すぎて会場が爆笑していて、さすがだなあと思いました。

区長と会う

オンライン区長と会いました。(区長はいたら絶対に気がつくだろうと思っていたけれど全然気が付かなかった...)
昨年のRSGT以来の再会だったので、葛飾の話や今日これまでどんな話をしていたのかを聞いたりしていました。

区長がぱいんさんと話をしていたと言っていたので、それはぜひとも話をしたいですとお願いし、ぱいんさん探しの旅に出ました。

ぱいんさん小島さん三輪さんと話す

ぱいんさん探しの旅に出たところ、見事にぱいんさんと落ち合い、その場にいた小島さん三輪さんとお話をしていきました。

ぱいんさんから間違っているような合っているようなアジャイルの例(?)を聞いたり、小島さんや三輪さんからはSigSQAの活動の近況や今後やりたいと思っていることの話などを聞いていきました。*3
色々な勉強会や資料でお見かけする方々なので、皆さんのことはもちろん存じていましたが、区長が小島さんのことを自分に紹介してくれようとしてくれて、「小島さんは...頭がいい」と言ってくれたのがハイライトでした。

あと、ぱいんさんにはパイン飴をもらいました。

全体を通した感想

普段から仲良くさせていただいていると自分が勝手に思っている方や、久しぶりに会う方、今まで会いたかったけれどタッチポイントが全然なくて会えていなかった方、思わぬ方々に会えてお話ができたので、めちゃくちゃ楽しかったです。

ただ、Networkingを中心とした時間で色々な方とお話をしたときに、Discordでのコメントや、その場で一緒に話していた知り合いの方に対しての発言で、悪い方向に勘違いされてしまうことが何度かあったのは大きな反省点でした。

*1:もしかしたらテストマニュフェストかも？

*2:鈴木さんのセッションと順番前後しました

*3:本人はこれをアジャイルと言ったら川口さんに怒られると言っていました笑

2023-05-18

Qiita Conference2023のセッションまとめ〜サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版）〜

※予約投稿が効いていなかったので、再度の投稿になります。

increments.connpass.com

こちらのイベントで、基調講演である「サバンナ便り - 自動テストに関する連載で得られた知見のまとめ（2023年5月版）」を聞いてきたので、会の様子と感想を書いていこうと思います。

学習用テスト
偽陽性と偽陰性
テストサイズ
テストダブル
テストピラミッド
テストピラミッドのサイズ変更戦略
その他(t_wadaさんの失職危機)
全体を通した感想

学習用テスト

まず、学んだことを自動テストとして書いていく学習用テストの話がありました。

あの時調べたことが今でも正しいのか？というのを担保することができるため、他の人が書いたコードやふるまいが不明なテストに対して活用することが多いということです。
学習目的で使用するテストのため、不要になる場合も多く、@learningなどといった何かしらのタグで管理しておくと便利だということでした。*1

また、驚きをテストすることにも有効であるため、例えばPHPでコンストラクタをもう一度呼ぶことでイミュータブルなクラスに破壊的変更を起こして、それをテストに落としておくことも有効だということでした。

こういった学習用テストは、バグレポートとして報告したりすることもできるため、Issueをたてるときにも

偽陽性と偽陰性

自動テストの信頼性の高さ*2は企業の業績にも直結しているということで、自動テストの誤検知の話として、偽陽性 *3と偽陰性 *4の話がありました。
このうち特に、テスト対策ロジックのテストコードへの漏れ出しはt_wadaさんが色々な現場で見ているそうです。

偽陽性と偽陰性は、プロダクトコードとテスト結果の関係性から、

テスト結果が成功×プロダクトコードが正しい...期待値通り
テスト結果が成功×プロダクトコードが誤っている...偽陰性
テスト結果が失敗×プロダクトコードが正しい...偽陽性
テスト結果が失敗×プロダクトコードが誤っている...期待値通り

と整理できるということです。

テストサイズ

テストスコープの問題は、DBのテスト/NWアクセステスト/ファイルアクセステストをどこまでやるのか？という話があったり、そもそもUnit testのUnitにも古典派とロンドン学派があったりと、定義や考え方にかなりばらつきがあるため、テストのスコープよりもテストのサイズで考えようという話が続いて紹介されました。*5

そのため、テストサイズとテストスコープもパターンごとに整理するのが有効ということで、以下の内容が紹介されていきました。

Unit × Small Size...大いに推奨
Integration × Small Size...書けるならコスパ良い
E2E × Small Size...実質不可能
Unit × Midium Size...避けるべきだが仕方がないときもある
Integration × Midium Size...普通
E2E × Midium Size...小さいシステムなら可能
Unit × Large Size...最悪(ただしよく見かける)
Integration × Large Size...できれば避けたい
E2E × Large Size...普通(CUJにしぼりたい)

テストダブル

続いて、テストダブルの話がありました。

テストダブルもテストスコープと同じように用語の混乱があったそうですが、X Unit test patternsで統一されたということで、今回はこの定義に沿って話が進んでいきました。

テストダブルはテストしにくいものがテスト可能になったりテストの速度と決定性を向上させる一方で、テストが脆くなったりテストの偽陰性を招くリスクがあるため、注意が必要だということでした。

テストピラミッド

最後に、自動テストの信頼性を中長期的に保つためのテストピラミッドの話がありました。
テストピラミッドは、コストが高い速度が遅いE2Eテスト < コストも速度も普通なIntegration test < コストが安く速度が速いUnit testとテスト量を整理しようというアイデアですが、これは個々人がUnit testをどう考えているかによって解釈の混乱が起きがちなので、ここまで説明してきた内容を活用しようというアイデアの紹介がありました。

テストピラミッドのサイズ変更戦略

最後に、テストピラミッドの形に戻していくための戦略に関して話がありました。

まず、Large sizeのテストをMedium sizeのテストに移植する方法ですが、これはFake Objectが有効だということです。

次に、Medium sizeのテストをSmall sizeのテストに移植する方法ですが、これはテストにできるようにテスタブルな設計にしていくことが重要だということでした。

その他(t_wadaさんの失職危機)

「単体テストの考え方/使い方」という本の登場、ChatGPTはt_wadaさん的に失職の危機を感じるほど正確だという余談が紹介されていきました。

全体を通した感想

基本的には先日Forkwellさんであった講演と同じような内容だったので、二度目の講演を聞いていくような感覚でしたが、それでも十分に楽しかったです。

最後のテストピラミッドに近づけていくような戦略に関しては、今回が初めてだったので、次回の連載(一旦最終回となる予定)にもつながってくる話なのかな？と思いながら聞いていました。

*1:詳細な内容はPHPカンファレンスで書いたDateTimeとDateTimeImmutableの違いを参照

*2:Googleのソフトウェアエンジニアリングによれば、信頼不能性が1%に接近すると価値を失い始める

*3:Flaky test、脆いテスト

*4:空振り、カバレッジ不足、テスト対策ロジックのテストコードへの漏れ出し

*5:Googleのソフトウェアエンジニアリングに乗っているアイデア。t_wadaさんが支援している現場でも単体テストとUnit testが違うという現場が非常に多い