QA(テスター)が開発工程の上流に参加して実際に行うこと

はじめに

本記事は、ソフトウェアテストの小ネタ Advent Calendar 2021の24日目の記事です。*1

目次

QAが開発工程の上流に参加する目的はインプット?

近年、単にテストをするだけでなく、「要件定義レビュー」「設計レビュー」「リファインメント」「Planning」といった開発工程の上流(早い段階)にQA(テスター)も参加する話を聞くようになりました。

しかし、その際に下記のようになっていないでしょうか?

f:id:nihonbuson:20211214111429p:plain
レビュー時にQAは聞いているだけ?

レビューをインプットの場ではなく、フィードバックを与える場にすべきだと個人的には思っています。

QAによるフィードバックの例

とはいえ、「レビューの時やリファインメントの時にどういう風にフィードバックすれば良いの?」と疑問に思っている方もいるかもしれません。

そんな方に、参考になりそうな動画を見つけたので共有します。

youtu.be

この動画の4分6秒あたりから、スリーアミーゴスミーティング*2の例があります。

英語の動画ですが、比較的平易な英語なので、理解はしやすいかと思います。また現在、日本語字幕を選択できるようにしてもらう設定追加を動画の管理者にお願いしています。

より価値のあるミーティングにするためのポイント

ここでのポイントは2点あります。

  • 具体的な例を用いて議論する
    • 具体的な例で話さないと、「何となく良さそう」と錯覚してしまいます
  • 何を確認すれば、今回のfeatureがOKなのか意識する
    • 後の受け入れ基準になる可能性があります

特に、2つ目のポイントはQAが得意な分野(のはず)です。

スリーアミーゴスの参加者は、それぞれで注目ポイントが異なります。

  • PO…今回のfeatureで実現したいことに注目している
  • 開発者…今回のfeatureはどのようにすれば実現できるかに注目している
  • QA…今回のfeatureが「完成した」と判断するためには、何を確認すれば良いのかに注目している

これはあくまでも得意分野なだけであり、完全に担当を分けているわけではありません。例えば、開発者が「実現したいこと(POの得意分野)」について考えても良いですし、POが「何を確認すればOKなのか(QAの得意分野)」について考えても良いです。

しかし、QAがこの得意分野を活かしてフィードバックをすることで、会全体がより価値のあるものになると思います。

おわりに

今回は、開発工程の上流でQAがフィードバックをする方法について、動画も踏まえて紹介しました。これからの業務に役立ってもらえれば幸いです。

ちなみに、今回紹介した動画はCucumber Schoolというサイトの第1章をYoutube上に公開しているものになります。

cucumber.io

こちらのサイトでは、CucumberというBDDツールを使う以前に考えておくべきことを動画を使って紹介しているので、CucumberやBDDツールを使わない人や、QA、POなどにもオススメのサイトです!*3

こちらのサイト内の動画も、随時日本語翻訳できればと考えていますので、「まだ英語しかないから…」と思っている方も、日本語字幕がついた際にはぜひご活用ください!

*1:1日遅れましたが、24日目の記事です

*2:開発者、QA、POの代表者が参加する要件定義段階のミーティング

*3:以前の記事でもそうでしたが、BDDツールの前段の部分の重要性をCucumberというBDDツールのコミュニティが積極的に行っていることは非常に価値があると思っています! nihonbuson.hatenadiary.jp

複数条件が関わる題材を用いてテスト設計から自動テストのケース作成まで考える(後編)

はじめに

本記事は自動テスト・テスト自動化 Advent Calendar 2021の24日目の記事です。

今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述します。

後編である本記事では、自動テストに適用した場合の話を書きます。

前編はこちら。

nihonbuson.hatenadiary.jp

目次

  • はじめに
  • 目次
  • 今回のお題
  • 前編での成果物
  • PICTを使ってテスト総数を減らしてみる
    • 欠点1:網羅しているのはあくまでも二因子間だけである
    • 欠点2:有則な条件でPICTを使うと、見逃してしまうケースが出てくる可能性がある
    • 欠点3:テストに失敗した際、何が原因なのか分かりづらくなる
  • テスト設計の内容は自動テストの理解容易性にも影響する
    • このPICTの組み合わせをそのまま自動テストで表現する
    • デシジョンテーブルの例を活用して自動テストで表現する
  • おわりに
  • 参考文献

今回のお題

f:id:nihonbuson:20211210233756p:plain
お題:座席順番待ちシステム

続きを読む

複数条件が関わる題材を用いてテスト設計から自動テストのケース作成まで考える(前編)

はじめに

本記事はソフトウェアテスト Advent Calendar 2021の22日目の記事です。

今回はとあるお題に対して、テスト設計からテスト実装、そして自動テストまで作成してみることで、私が普段どんなことを意識しているか記述したいと思います。

前編である本記事では、テスト実装までの話を書きます。

目次

  • はじめに
  • 目次
  • 今回のお題
  • 因子水準を考える
  • 因子水準表を元に全組み合わせを書く
  • 予約番号の印刷を任意にする
  • 名前に関する条件と人数に関する条件を別表に分ける
    • 名前と人数の条件を掛け合わせる必要もあるのでは?
  • 人数の同値クラスを考える
  • 合計人数という因子を追加する
  • ここまでのまとめ
  • テスト観点との関係性について考える
    • 初期のテスト観点
    • 無則な観点を削った場合
    • 人数の条件でまとめた場合
    • 合計人数の条件を含めた場合
  • 別のテスト技法を用いて考える
  • テスト設計の成果物を元に、テスト実装を行う
    • ポイント1:テスト設計番号と対応させている
    • ポイント2:テスト設計とテスト実装は1:1の関係ではない
    • ポイント3:テスト設計では省略している内容(実装実施時要検討事項)がテスト実装では現れる
  • まとめ
  • おわりに
  • 参考文献

今回のお題

f:id:nihonbuson:20211217215407p:plain
お題:座席順番待ちシステム

続きを読む

【翻訳記事】テスト自動化の対象となるテストシナリオの整理に役立つBRIEFの原則

はじめに(翻訳記事の前提となる知識など)

本記事は自動テスト・テスト自動化Advent Calendar 2021の7日目の記事です。

最近、BDDなどでのテスト自動化を行うにあたり、Discovery(発見)*1→Formulation(定式化)→Automation(自動化)という流れが考えられるようになりました*2

f:id:nihonbuson:20211203101535j:plain
記事「Behaviour-Driven Development」内の画像を引用し翻訳

この中の「定式化」では、後に自動化するテストシナリオの整理を考えます。*3

テストシナリオを作成する際に、ただ単にGherkin記法(Given/When/Thenなどを用いた記法)を利用するだけでは、保守性の低いテストシナリオが作られてしまいます。

そこで今回は、保守性の高い状態でテストシナリオを記述する際に役立つ原則「BRIEFの原則」について書かれた記事「BRIEFの原則を保った状態でシナリオを書いてください(原題:Keep your scenarios BRIEF)」を翻訳して紹介します。*4

cucumber.io

具体的なテストシナリオを使った解説は、書籍『Formulation』を読んでください*5

*1:以前に紹介した「実例マッピング」は発見フェーズの具体的なプラクティスの1つになります。 nihonbuson.hatenadiary.jp

*2:個人的には、この考え方はISTQB(JSTQB)の「テスト分析→テスト設計→テスト実装」というテストプロセスの考え方に近いかなと思っています。細かく考えると違いはあるのですが…。どちらにせよ、自動テストを考える前に自動テストの対象となるテストシナリオを整理することが重要だという考え方を主張しているのは良いことだと思います。しかも、「Cucumber」という、「BDDで自動化をどんどんしようぜ!」と言いそうなコミュニティがこういう主張をしていることは非常に価値があります。

*3:なお、仮に「自動化」を行わなかったとしても、「発見」「定式化」をすることは非常に価値があると、オリジナルの記事を書いたSebは自身の著書の中で述べています。私も同じ意見です。

*4:翻訳にあたり、著者本人の許可をもらいました。Thank you, Seb!

*5:現在は英語版しかありませんが、日本語翻訳版も検討しています

続きを読む

TDDサイクルは戻ることも大事

はじめに

本記事はテスト駆動開発 Advent Calendar 2021の1日目の記事です。このアドベントカレンダーはスカスカなので、テスト駆動開発経験談などをエントリーしてもらえると嬉しいです!

qiita.com

目次

  • はじめに
  • 目次
  • 本記事で伝えたいこと
  • 今回のお題
  • 新しいテストケースを考えて対応する
    • サイクル2周目の「3.そのテストを実行して失敗させる」
    • サイクル2周目の「5. 2で書いたテストを成功させる」
    • サイクル2周目の「6. テストが通るままでリファクタリングを行う」
      • 関数を呼び出す形に変更する
      • テストケースを1つ削除する
      • メソッドをインライン化する
  • おわりに

本記事で伝えたいこと

TDDをやっている皆さんは、下記のサイクルをご存知の方が多いと思います。

f:id:nihonbuson:20211201110545p:plain
見てわかるテスト駆動開発 / TDD Live and Workshop 2019 Spring - Speaker Deckより引用

この中の「4. 目的のコードを書く」がうまくいかない時に、「3.そのテストを実行して失敗させる」よりも前まで戻ることがよくあるよ、というお話です。

続きを読む

JaSST Review'21で講演依頼をしたきっかけ 〜ソニックガーデン/ベリサーブ編〜 #jasstreview

10月22日にJaSST Review'21(ソフトウェアレビューシンポジウム)を開催します!

www.jasst.jp

本記事では、JaSST Review'21でなぜ「ビジネスの成長に合わせてソフトウェアを進化させ続ける秘訣」という講演を依頼したのか、その経緯を紹介します。

今回のイベント全体の主旨については、以前書いた記事をご覧ください。

nihonbuson.hatenadiary.jp

目次

今回のJaSST Reviewのテーマ

今回のテーマは「価値を実現するためにレビューができること」です。

前回までのJaSST Reviewでは、「どういうアプローチでレビューしていこう?」という話が多かったです。JaSST Reviewに参加して持ち帰った結果、実のあるレビューに変わっていった現場もあったと思います。

しかし、一見実のあるレビューができたとしても、こんな風になってしまう経験はありませんでしょうか?(JaSST Review'21のページから抜粋)

「こうして欲しい」とお客様に言われた通り作ったが、「欲しいのはこんなものではなかった」と言われてしまった。

つまり、そもそも作ろうとしているものが、顧客が本当に必要だったものに合っていなかったという経験です。

これをレビューで解決できないか模索したいというのが今回のテーマです。

講演依頼をするきっかけ

今回のテーマにするにあたり、プロダクトオーナー(PO)と開発者が「顧客が本当に必要だったもの」について話していたなと感じたイベントとして、「Veriserve - WebQA FunNight!! #01」を思い出しました。

veriserve.connpass.com

このイベントの中で、今回のJaSST Reviewで登壇する、POの松木さんと開発者の遠藤さんがこんな会話をしていました。

f:id:nihonbuson:20211012162159p:plain
Veriserve - WebQA FunNight!! #01聴講報告記事より抜粋

この内容で興味深いのは、「○○ができるようにしたい」と要望を伝えるPO(松木さん)に対して、「それは大変になるから止めよう」と伝える開発者(遠藤さん)という構図です。

一般的に、POは「プロダクトの価値を最⼤化することの結果に責任を持つ。」*1はずです。

しかしお二人の会話からは、そんなロールの関係性を超えて、「顧客が本当に必要だったもの(プロダクトの価値)」について一緒に考えているように感じました。

講演依頼の内容

上記のイベントのように、「顧客が本当に必要だったもの」について常日頃話しているようなので、そのことについて是非話してほしいと講演を依頼しました。

また、我々からの依頼時に、「1人ではなく、2人一緒の登壇でも良いですか?」とリクエストされ、是非その方向でお願いすることにしました。というのも、上記のイベントでの2人の掛け合いが印象深く、かつリアリティのある内容だったと記憶しています。

JaSST Reviewでは、理論的な話よりも、イキイキとした事例を求めています。というのも、レビューはまだ体系だった形にできていないと思っており、まだまだ事例を集める段階だと思っているからです。

そんな中、遠藤さんと松木さんによる2人の登壇はおそらくイキイキとした事例を我々に聞かせてくれるのではないかと期待しています!

おわりに

今回は、JaSST Review'21で「ビジネスの成長に合わせてソフトウェアを進化させ続ける秘訣」の講演を依頼する経緯と依頼内容について書きました。

なお現在、JaSST Review'21では聴講者を募集しております。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp

JaSST Review'21で講演依頼をしたきっかけ 〜三越伊勢丹ホールディングス/IM Digital Lab編〜 #jasstreview

10月22日にJaSST Review'21(ソフトウェアレビューシンポジウム)を開催します!

www.jasst.jp

本記事では、JaSST Review'21でなぜ「三越伊勢丹におけるデジタルサービスのつくりかた(仮)」という講演を依頼したのか、その経緯を紹介します。

今回のイベント全体の主旨については、以前書いた記事をご覧ください。

nihonbuson.hatenadiary.jp

目次

今回のJaSST Reviewのテーマ

今回のテーマは「価値を実現するためにレビューができること」です。

前回までのJaSST Reviewでは、「どういうアプローチでレビューしていこう?」という話が多かったです。JaSST Reviewに参加して持ち帰った結果、実のあるレビューに変わっていった現場もあったと思います。

しかし、一見実のあるレビューができたとしても、こんな風になってしまう経験はありませんでしょうか?(JaSST Review'21のページから抜粋)

「こうして欲しい」とお客様に言われた通り作ったが、「欲しいのはこんなものではなかった」と言われてしまった。

つまり、そもそも作ろうとしているものが、顧客が本当に必要だったものに合っていなかったという経験です。

これをレビューで解決できないか模索したいというのが今回のテーマです。

講演依頼をするきっかけ

上記の内容でテーマは決まったときに、思い浮かんだのがDevelopers SummitでのIM Digital Lab様の発表でした。

event.shoeisha.jp

この発表の資料も公開されているのですが、その中でも特に注目したスライドが2枚あります。

f:id:nihonbuson:20211005093759p:plain
発表資料「三越伊勢丹が目指すNew Normalの購買スタイル」より抜粋

f:id:nihonbuson:20211005100924p:plain
発表資料「三越伊勢丹が目指すNew Normalの購買スタイル」より抜粋

この2枚のスライドで特に注目した点は下記の部分。

  • 三越伊勢丹という大企業にもかかわらず、初期開発が3ヶ月という短い期間で新しいアプリを作成した点
  • 「その機能じゃ足らない」問題が発生し、それに対しての解決しようとしている点

特に「その機能じゃ足らない」問題は今回のJaSST Reviewで気にしている部分「そもそも作ろうとしているものが、顧客が本当に必要だったものに合っていなかったという経験」にフィットするのではないかと思い、講演を依頼することにしました。

講演依頼の内容

この「その機能じゃ足らない」問題は、初期開発をしている時にはよく発生すると思っています。

上記の発表資料の他ページを見ると、うまく要件整理をして、優先順位を決め、調整していったことが書かれています。ただ、どのように「うまく」行い、どのように「調整」を行っていったのでしょうか?

これらの内容は、実装を始める前に「価値」を見つめ直し、各関係者とMTGを行い、内容に対してレビューしながら進めていったはずです。「そのときに頭の中で考えていったことを聞きたい!」と講演を依頼しました。

現在、講演内容案をいただいていますが、上記の依頼内容にマッチした素晴らしい講演が期待できるものになっていました!

おわりに

今回は、JaSST Review'21で「三越伊勢丹におけるデジタルサービスのつくりかた(仮)」の講演を依頼する経緯と依頼内容について書きました。

なお現在、JaSST Review'21では聴講者を募集しております。気になる方がいましたら、参加申し込みをお願いします!

www.jasst.jp