ざっくりと、知りたいこと別にリンクを貼ってみました。
JaSST Review'22の公式サイトを知りたい人へ
JaSST Review'22内容を簡潔に1枚の画像で伝えて欲しい人へ
【翻訳記事】BDDの考案者が執筆した記事「テストについて話し合わなくてはならない」を翻訳しました！
目次
- 目次
- はじめに（本記事の見どころなど）
- テストについて話し合わなくてはならない
- テストの目的
- 「うまくいかないかもしれないものは何ですか？」
- なぜテストをするのですか？
- この場合に限り……
- テスト駆動開発 〜テストについて語る前に説明が必要です〜
- テストについて話しましょう
- なぜすべてのテストを自動化しないの？
- テストカバレッジは有用な指標ですか？
- 「テストをシフトレフトする」とはどういう意味ですか？
- いつ、どこでテストすべきですか？
- 十分なテストとはどれくらいですか？
- おわりに
はじめに（本記事の見どころなど）
今回は著者本人の許可をもらった上で、「テストについて話し合わなくてはならない」（原題は「We need to talk about testing」）を翻訳したので紹介します。
本記事はDaniel Terhorst-North(Dan North)が書いた記事です。Dan NorthはBDDの原典ともいえる記事「Introducing BDD」（日本語訳の記事「BDDの導入 - Dan North」）を書いたことでも有名です。
本記事では、Danが考えたテストの目的を提示した上で、自動テストやTDDに対する誤解について語っています。そしてテスターに対する本当の価値についても、敬意を持って語っています。
Danはテスターではなくプログラマーでありながら、ここまでテストのことについて語っていることが素晴らしいと思い、翻訳することにしました。
これ以降は元記事を翻訳したものになります。
続きを読むレビューのワークショップを行います！ #JaSSTReview
10月28日にJaSST Review'22（ソフトウェアレビューシンポジウム）を開催します！
今年は、JaSST Reviewでは初めてワークショップを行います。
ワークショップの内容
「レビュー」というと、個々人の今までの経験に頼るという面が非常に多い分野だと感じています。JSTQBでも、レビュープロセスは存在していますが、「個々のレビュー」という表現しかしておらず、その中でどのような思考プロセスを行うかは記述していません。
一方、テストプロセスについては具体的な思考プロセスを記述しています。
そこで、テストプロセスを真似ることでレビュープロセスも具体的なプロセスを記述できるのではないかと考えました。
これをワークショップ形式にして皆さんに体験しながら学んでもらおうと考えたのが今回のセッションです。
※なお、ここまでに描いたプロセスの記述と、当日のワークショップで区分けしている記述は異なっています。あくまでも、分かりやすさ重視のため、本記事ではテストプロセスに当てはめた場合で記述しています。
ワークショップに参加される方々へ
今回のワークショップは（おそらく）初めて、レビュープロセスを体系的に体験して学んでもらうコンテンツとなります。
そのため、今までレビューに慣れているかどうかは関係ありません。むしろ、今までレビューで悩んできた人に向けて少しでもヒントになればと考えております。
なので、ワークショップに参加できる時間を確保できる方は、ワークショップの参加をご検討いただければと思います。
なお、ワークショップ参加にはレビューの経験の度合い以外にいくつか条件があります。以下の条件に当てはまらない方はワークショップ見学を推奨いたします。
- ワークショップの開催中（10月28日 13:00〜16:15）、時間を確保できる方
- 今回はグループワークも行います。そのため、ワークショップ参加中、他の用事で一時的に離席されてしまうと他の方にご迷惑がかかります。一時的な離席の予定が既にある方はご遠慮をお願いいたします。
- Google Meetを使うことができる方
- miroを使うことができる方
- セキュリティ上の問題でアクセス制限がかかる方はご遠慮をお願いいたします
- 事前に資料をご確認いただく時間の取れる方
- 今回は時間の都合上、事前に資料を確認いただきたいと考えております。当日までに確認する時間が一切取れない方はご遠慮をお願いいたします
ワークショップを見学される方へ
今回、ワークショップに参加できない方向けに、ワークショップの見学枠も設けております。見学される方は、Google Meetやmiroに接続できる環境でなくても十分楽しめると思います。
ワークショップに参加ができない方は、見学もご検討くださいませ。
おわりに 〜参加をご検討いただいている皆様へ〜
参加登録はこちらになります。
また、ワークショップ以外の部分も含めて、今回のシンポジウムでお伝えしたいことをスライドにまとめました。参加に悩んでいる方はご参考にしてください。
皆様のご参加をお待ちしております！
実例マッピングを考案したMattさんが講演します！（同時通訳付き） #jasstreview
10月28日にJaSST Review'22（ソフトウェアレビューシンポジウム）を開催します！
今年は、JaSST Reviewでは初めて海外講演者をお呼びすることにしました。
今回の海外講演者について
今回お呼びしたのはMattさんです！
Mattさんは私が翻訳した『Agile Testing Condensed』や『The BDD books - Discovery』でも登場する「実例マッピング」を考案した人です。
実例マッピングについて
実例マッピング自体は本ブログや私の発表でも度々紹介してきました。
また最近は、実例マッピングを導入した人/企業も増えていっているように感じます。
今までは、書籍などから学ぶことが多かった実例マッピングですが、今回ついに考案者自ら話していただくことになりました。講演自体は英語ですが、同時通訳もご用意しておりますのでご安心ください。
実例マッピングに興味がある方もぜひご参加を検討してください。
実例マッピングとレビューの関係について
もちろん、JaSST Reviewはレビューシンポジウムなので、レビューの話にも繋げたいと考えています。
実例マッピングは会話を大事にする手法です。そしてレビューも会話が大事だと考えています。その共通部分をきっかけに、議論を深めていければと思います。
おわりに 〜参加をご検討いただいている皆様へ〜
参加登録はこちらになります。
また、Mattさん以外の部分も含めて、今回のシンポジウムでお伝えしたいことをスライドにまとめました。参加に悩んでいる方はご参考にしてください。
皆様のご参加をお待ちしております！
先日のイベント「リーダブルなテストコードについて考えよう」の動画と文字起こしが公開されました #vstat
タイトルの通り、7月に行ったイベント「リーダブルなテストコードについて考えよう」の動画と文字起こしが公開されました。
既に公開されているスライドも含めて、改めて公開場所をお伝えします。
スライド
動画
CONNPASSの本イベントページにて公開されています。
なお、この動画は、本イベントに予め登録していた方限定となります。ご了承くださいませ。
文字起こし記事
ログミーさんのご協力により、文字起こししていただきました。本当にありがとうございます！
イベントに参加登録しておらず、動画を視聴できない方は、こちらの記事も参考にしてくださいませ。
『The BDD Books - Discovery (Japanese Edition)』が紙媒体で購入いただけるようになりました！ #bddbooks
先日、電子書籍を公開しました『The BDD Books - Discovery (Japanese Edition)』が紙媒体でもご購入いただけるようになりました。
実物はこんな感じ。
本書籍のご購入方法を、場合分けしてご紹介します。
紙媒体でご購入を検討している方へ
以下のAmazonページから、ペーパーバックの形でご購入できます。*1
電子書籍でご購入を検討している方へ
Paypalのアカウントを所持している場合
Leanpubからご購入ができます。
価格は$15〜となっています。
Paypalのアカウントを所持していない場合
Amazonからご購入ができます。
価格は3168円と、Leanpubに比べて少し割高になっています。
ご購入を検討していただいているみなさんへお伝えしたいこと
どの媒体であっても、ご購入を検討していただいているみなさんは、「どんな本なのか？」というのが一番気になると思います。
そこで、本書籍について書いていただいた記事をご紹介します。
クリエーションラインの中村さん（ikikkoさん）による紹介記事
本書籍の推薦文も書いていただいた、Yoshiki Itoさんによる紹介記事
私が以前書いた記事（訳者まえがきに補足内容を加えて紹介しています）
購入検討のご参考にしてください！
*1:本のタイトルが日本語でないので若干分かりづらくてすいません。タイトルの変更について問い合わせ中です…
「テストコードにはテストの意図を込めよう」の発表報告＆補足説明＆質問回答 #vstat
先日、「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」というイベントで登壇してきました。
今回は発表内容に対する補足と、発表に対していただいた質問に回答します。気になるところだけでも読んでもらえればと思います。
目次
- 目次
- 発表内容
- 発表に対する補足
- いただいた質問の回答
- 【質問1】リーダブルなテストコードの勉強方法はありますか？
- 【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？
- 【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか?
- 【質問4】どれが非効率な自動テストなのかが分からない状態（自動化したテスト仕様とマッピングがない）の場合、何から管理すれば良いか。
- 【質問5】テストファイルの構造について。1つにまとめる？複数作る場合はどんなファイル構造？
- 【質問6】レガシーな巨大リポジトリにテストを追加しようと思って二の足を踏んでいるのですが、どういったファイルからテストを書いていますか?また、どうすればレガシーコードにテストを導入しやすいでしょうか?目的や優先度、テストの書き方など、考慮すべきポイントがあれば教えて下さい。
- 【質問7】テストを書いた時に、テストのコード量に応じて仕様変更に対して動きが重くなると思いますが (テストを沢山直さないといけない)これは仕方がない事なのでしょうか?何か工夫はありますか?
- 【質問8】意図が伝わるという観点で、テストコードには積極的に日本語を含めたほうが良いのでしょうか?コメントで補足するくらいなら日本語を含めよう、みたいなポリシーはありますか?
- 【質問9】そもそもテスト設計はどのように管理されていますか?システムもしくはExcelやMarkdownなど。
- おわりに
発表内容
私の発表スライドはこちらです。
他2人の発表スライドはこちらになります。
伊藤さんによる登壇報告の記事はこちら
申込者数は驚異の1000人超え！*1
当日も多くの方に来ていただき、これぐらいの人数の前で発表するのが久々すぎて緊張しました。
そんな中、私が発表して思った感想はこちら
昨日の #vstat に登壇して良かったと感じたのは、開発者にも響いてくれたように見えたこと。
— broccoli (@nihonbuson) 2022年7月28日
昨日のイベントは、私が普段登壇しているイベントよりも開発者の割合が多めでした。（具体的な割合は公表して良いか分からないので書きませんが、相当開発者が多かった）
特に、私の発表を聞いて、こういう風に思ってくださった方がいたのは嬉しかったです。
すごい失礼かもしれないけどQAエンジニアってかっこいいなって思った
— Masaki Okamoto (@masa_okamoto1) 2022年7月27日
#vstat
発表に対する補足
発表に対しての補足が2点あります。
【補足1】都道府県のテストについて
こちらのスライドについての補足です。
イベント当日には口頭で補足しながら発表したのですが、このスライドの前提として、どの都道府県がどの地方に属しているかのテストは別にあるとしています。
今回、このような前提にしているのは、あくまでも開発者が話している「地方ごとに送料が変わるのを確認」を表現することを目的としています。
もちろん、送料計算を47都道府県分書いても構いません。ただし、例えば同様に「地方ごとに配送日数が変わるのを確認」という別のテストが必要になった場合、
@Test public void _青森県の場合送料が1000円 { } @Test public void _広島県の場合送料が1000円 { } ...（同様に残り45都道府県分行う）
というテストに加え、
@Test public void _青森県の場合配送日数が2日 { } @Test public void _広島県の場合配送日数が3日 { } ...（同様に残り45都道府県分行う）
というテストも行うことになります。（47+47=94通りのテストが必要）
実際にテストコードを作成する場合は、「都道府県と地方の紐付けに関するテスト」と「地方と送料の紐付けに関するテスト」と「地方と配送日数の紐付けに関するテスト」で分けて表現することになると思います。（47+7+7=61通りのテストが必要）
テストの意図が複雑に絡み合っていると、テストケース数が必要以上に多くなったり、将来テストコードを見返した時に何をテストしたいのか分かりづらくなっている可能性があるので、やはりテストの意図を改めて見つめ直してほしいかなと思います。
【補足2】Parameterized Testsへの利用について
こちらのスライドに対しての補足です。
「このような表で整理したならばParameterized Testsにそのまま活用できるのではないか？」という意見がありました。
私としても活用できると考えています。
しかし、その際には同じテストの意図のものだけでParameterized Testsのケースをまとめることを考えた方が良いと思います。
具体的には、表をそのまま移して以下のようなParameterized Testsを作成するのは止めた方が良いです。
@ParameterizedTest @CsvSource({ "'テスト太郎', 0, true, false", "'テスト太郎', 1, true, true", "'テスト太郎', 4, true, true", "'テスト太郎', 5, true, false", "'', 2, true, false", "'テ', 2, true, true", "'最大文字数テスト太郎', 2, true, true", "'最大文字数を超えた太郎', 2, true, false", "'テスト太郎', 2, true, true", "'テスト太郎', 2, false, true" }) void _予約可否のテスト(String reservedName, int numberOfReservations, boolean isPrint, boolean expected) { assertEquals(expected, isReserved(reservedName, numberOfReservations, isPrint)); }
元々整理していた表は、「予約人数に関するテスト」と「予約名の文字数に関するテスト」と「予約番号の印刷に関するテスト」の3つが合わさった表現されています。
そのままParameterized Testsに持っていってしまうと、実施しているテストケースは、これらの3つのどれをテストしたいのか、テストの意図は何なのかが見えなくなります。
なので、Parameterized Testsに持っていこうとする場合も、テストの意図を意識してほしいなと思います。
例えば、こんな感じに一つずつテストの意図を分けた上でParameterized Testsに持っていくのは良いと思います。
@ParameterizedTest @CsvSource({ "0, false", "1, true", "4, true", "5, false" }) void _予約人数が1名以上4名以下の場合予約できる(int numberOfReservations, boolean expected) { assertEquals(expected, isReserved("テスト太郎", numberOfReservations, true)); }
また、先ほど示した送料の事例の場合、仮に東北地方と関西地方で同じ送料500円だったとしても、東北地方と関西地方の都道府県をまとめて1つのケースにしてParameterized Testsに変換しようとするのは良くないです。
テスト設計技法の言葉で言えば、同値分割法における同値クラスが何なのか考えてみるのが大事だと思います。
いただいた質問の回答
今回は参加者が多かったこともあり、事前や当日にたくさんの質問をいただきました。そちらにも回答していきます。
【質問1】リーダブルなテストコードの勉強方法はありますか？
例えばTDDBCに参加してみるのはいかがでしょう。
このイベントではTDDの体験も重要ですが、コードレビューを貰えるのも貴重です。
私がTAとして参加している場合は、今回の発表のようにテストコードやテストメソッド名についての指摘が多めになりますので、機会があればぜひ。
【質問2】テストコードのメンテナンスをするにあたってのリファクタリングの頻度はどれくらいか？
個人的には、「さあ、リファクタリングをしよう」と思っていたら負けだと思っています。
特にUnitテストの場合、常にリファクタリングして、テスト実行してる習慣になっていることが大事かなと思います。
リファクタリングの頻度を学べる動画はいくつかありますが、TDDBC Online #1 でのt_wadaさんの基調講演と、TDDBC Sendai Xのペアプロデモは特にオススメです。
【質問3】レビューをする際、機能自体のレビューにかけた時間に対してテストのレビューにかける時間はどのくらいの割合で行っていますか?
レビューの目的によります。
例えば、私の場合はテストコードがほぼ100%に近いぐらいの割合で見ると思いますが、それはレビュアーが私だけでないため、他の人がプロダクトコードのレビューをしているから実現できているだけだと思っています。
全ての人を合わせて見たときの割合というのは計測したことが無いので分かりません。申し訳ないです。
【質問4】どれが非効率な自動テストなのかが分からない状態（自動化したテスト仕様とマッピングがない）の場合、何から管理すれば良いか。
まずは管理云々の前に、それぞれの自動テストが何をテストしたいものなのか明らかにするところからではないかと思います。
【質問5】テストファイルの構造について。1つにまとめる？複数作る場合はどんなファイル構造？
E2Eテストの場合、featureごとにまとめたいです。
ファイル構造については、『The BDD Books - Formulation』に案が載っているのでそちらも参考にしてください。現在、鋭意翻訳中です。
【質問6】レガシーな巨大リポジトリにテストを追加しようと思って二の足を踏んでいるのですが、どういったファイルからテストを書いていますか?また、どうすればレガシーコードにテストを導入しやすいでしょうか?目的や優先度、テストの書き方など、考慮すべきポイントがあれば教えて下さい。
まずは、「一番外側の振る舞いをテストで抑える」やり方と「内側の中で一番リスクがありそうな部分（例えば金額計算）からテストを書く」やり方があるかと思います。具体的にはケースバイケースだと思います。
レガシーコードに対してどのように書いていくかについて詳しくは、手前味噌になりますが、技術同人誌を以前に書いたのでそちらも参考にしてください。
【質問7】テストを書いた時に、テストのコード量に応じて仕様変更に対して動きが重くなると思いますが (テストを沢山直さないといけない)これは仕方がない事なのでしょうか?何か工夫はありますか?
仕方のないこと、というよりも良いことだと思います。
なぜなら、そのようなテストがない場合、成功するかもしれないテストも含めて手動でテストを実行しなければいけなかったり、テストしなかった結果リリース後に大きな問題に発展するかもしれません。
それらに対して、「失敗したと判明したテストのみを対象としてテストもしくはプロダクトコードを直す」という作業は比較的コストが安い行動であり、幸せなことかと思います。
【質問8】意図が伝わるという観点で、テストコードには積極的に日本語を含めたほうが良いのでしょうか?コメントで補足するくらいなら日本語を含めよう、みたいなポリシーはありますか?
発表中にもお伝えしましたが、難しい英語で書いて伝わりづらいのであれば、テストメソッド名は日本語にした方が良いと考えています。
あとはプロジェクトでのチーム構成によります。全員日本語話者であれば日本語で良いと思いますし、OSSのように全世界でメンテナンスされていく場合は英語で書いた方が良いと思います。
【質問9】そもそもテスト設計はどのように管理されていますか?システムもしくはExcelやMarkdownなど。
現在の所属での話ではなく、今までの経験上の話になりますが、
という感じです。これらの成果物のURLをJiraのチケットに貼っておくような運用を取ることが多かったです。
おわりに
今回は「リーダブルなテストコードについて考えよう～VeriServe Test Automation Talk No.3～」のイベントの補足的なことを書きました。
この記事を見てさらに聞きたいことがありましたら、Twitterにリプライを投げてください。よろしくお願いします。
*1:しかも私はほぼ宣伝をしてない…！
