本記事内で紹介した講座の詳細はこちら。
変わり始めたテストと開発者の関係性
「テスト」という言葉にどのような印象を持っているだろうか。「テスト段階で手戻りが生じ、予定よりもスケジュールが押してしまった」「開発が終わってから不具合が見つかってしまった」。こうした、自分のタスクが終わった後に起こる何らかのアクシデントとセットで想起する開発者も少なくないのではないだろうか。
これまで、開発者の仕事は実装であり、テストについてはQAやテスターの領域とされてきた。それゆえテストは、開発者のタスクが終わった後に待っているバグを発見するためのプロセスであり、ある種ボトルネックのように感じられてしまうことも多い。
それが近年では、「シフトレフト」「アジャイルテスティング」「自動テスト」といったキーワードとともに、開発者側からのテストに対する注目度が高まっている。
この背景には、何か開発者とテストの関係性が変わる大きな転換が始まっているのではないだろうか？
テストやQAに関わってきた経験を活かし、現在は開発者への啓蒙活動や、上流工程から品質を作り込むことの大切さの発信を行っており、書籍の出版などアジャイルテスティングにも造詣の深い風間 裕也（ブロッコリー）氏に話を聞いた。
継続的な開発には、継続的なテストが不可欠
──まずはご自身について、これまでのご経歴について簡単にお聞かせください。
新卒入社した会社では社内ツールの開発を担当していたのですが、もともと大学で品質について学んでいたこともあり、その後はテストエンジニアとして活動しています。
テストエンジニアとして働き始めた当時、エンジニアがテストや品質について学ぶ機会が少ないということに課題を感じていました。一般的に、大学でプログラミングの授業を受けた経験があっても、テストについて学んだことがある人は少ないのではないでしょうか。
そこで、部署内での勉強会を開催したところ新卒研修としても採用されるようになり、そうした機会を社外にも広げていった結果、現在に至ります。
──従来、品質に関してはQAやテスターが担う、あるいはテスト会社に外注するといったことが一般的だったと思います。それが現在では、開発者自身がソフトウェア品質に注目するようになりました。これはなぜなのでしょうか？
大きな理由としては、世間的に開発を内製化する流れになっており、「製品を納品して終わり」ではなくなってきているからだと思います。
開発を外注する場合、納品した時点での品質が大切なので、一時的に工数をいっぱい使ってテストをするのは理にかなっています。
一方で開発を内製化すると、開発が終わってテストをしたら、その次の1、2週間後にもまたテストを行わなければならない。継続的に開発をするということはテストも継続的に実施する必要があるのに、そこで毎回工数をかけてテストをするのはコストが高いですよね。
そして継続的に開発をするとなると、製品のメンテナンスも同じ開発チームで行うので、テストで見つかったバグはその次のリテレーションで新機能を作る前に修正しないといけない。そこで工数がかかってしまうと新機能を作る余裕がなくなってしまう。よって開発者自身も品質を意識しなければならなくなっているのだと思います。
もちろん中には、バグはテスト会社やQA、テスターが見つけてくれるもので、自分たちはどんどん実装してテストは任せておけばよいという意識の人もいるかもしれません。しかし、結局その見つかったバグで苦しむのは開発者自身なんですよね。
当講座の講師をつとめる、風間 裕也氏
TDDや自動テストでは不十分なのか
──開発者ができるテストにはどのようなものがありますか？ おすすめの方法があれば、お聞かせください。
「開発者ができるテスト」と聞くと、テスト駆動開発（以下、TDD）や自動テストが想起されやすいと思います。これらはもちろん開発をするうえで非常に効果的で、おすすめの方法だと思います。しかし、継続的に開発するうえで、TDDや自動テストさえ実施すれば品質が担保できるという認識は持たないほうがよいと考えています。
というのも、これらはテストの実行方法でしかなくて、継続的なテストを実施していくためにはテストの「目的」や「意図」が重要になってくるからです。例えば、ある会員登録システムのテストをしたときに失敗する原因としてはさまざまなものが考えられます。「名前が適切でなかった」「メールアドレスが適切でなかった」「パスワードが条件に合わなかった」「入力したパスワードを確認するための再入力のときに、入力と違う値を入れてしまった」……など。
テスト手順を作った瞬間は、その中のどれをテストするためのテスト手順なのかが分かっているので問題ないのですが、3カ月後や半年後、1年後に何らかのエラーが出て見直したとき、何をテストするのか分からないまま手順だけを見て原因を探ろうとするとすごく大変です。
皆さんも、テスターに「テストケースをレビューしてください」と言われて、500行ぐらいのテスト手順の中から不足している部分を見つけるのは大変ですよね。でも、テスト手順を作成する前に「こういう意図でテストをしたい」と聞いて、テストの意図をレビューするところから始めると分かりやすい。
そうしたテストの意図を整理するときは、チームでテストの設計を行うのがおすすめです。日本におけるソフトウェアテスト技術者資格認定の運営組織、JSTQB（Japan Software Testing Qualifications Board）が提唱しているテストプロセスにもあるのですが、実装の前に要件定義や設計があるように、テストにも実装の前にテストの意図を考える段階（テスト分析）や、テストの意図に従ってテスト内容を整理する段階（テスト設計）が必要なのです。テスターやQAがいない場合でも、それは同じです。
バグを予防する、実装前にできるテスト方法
──一方で、テストによる手戻りや工数増加は避けたいところだと思います。何か良いテスト方法はありますか？
そうですね。特に、アジャイル開発のように素早く継続的な開発を実施している現場ほど、テストの工数が大きいとそれだけ開発全体の負担も大きくなります。
テストに関わる工数を減らすには、大きく分けて2つの考え方があります。一つは、テストケース数の削減やテストの自動化といった、テスト工数自体を減らすという考え方。もう一つが、バグの予防によってテスト実施時のバグ発見＆修正のコストを減らすという考え方です。
テスト実施工数を減らすと言うとシンプルですが、テストを素早く行うには限度があります。手動テストの場合、マウスを操作するスピードには限界があります。自動テストの場合でも、一つ一つの操作のスピードには限界が来ます。
そこで、テストケース数の削減を考える必要が出てきます。しかし、ただ単純にテストケース数を減らしてしまうと、品質が担保できなくなる可能性もあるので、それを「ちゃんと減らす」ためにはテスト設計が大切になります。
さらに、工数を減らすためのもう一つの方法があります。それは、開発の実装前にテストをすることです。「テスト」と言うと開発の実装後の工程を思い浮かべる方が多いと思いますが、実装に取り掛かる前にできるテストがあるのです。
それは「レビュー」です。これは「コードレビュー」だけでなく、「設計などのドキュメントに対してのレビュー」も含みます。実は、JSTQBではレビューもテスト活動に含めています。テスト活動には2種類あり、一つは「テスト」という言葉からよくイメージしがちな、実際に製品を動かしてテストをする「動的テスト」、もう一つが、製品がまだできてない段階で製品を動かさずにテストをする「静的テスト」です。静的テストの一つとしてレビューがあります。
この「静的テスト」の活動であるレビューを行うことで、事前にバグの予防を意識して開発を行うことはもちろん、各機能がどのように動くべきかという認識のすり合わせを行うことができます。
この認識合わせを行うと、開発者が実装する際「レビュー時にこんな話をしていたな」と意識しながら開発できるのでバグが発生しづらいです。結果として、バグが発生した後に行う「バグチケットを起票する」「実装を思い出す」「修正する」「再度のテスト実施をする」「デグレードがないことを確認するためのリグレッションテストを実施する」「バグチケットのステータスを完了に変更する」といったことを行わずに済みます。
よって、実装前のレビューといったバグの予防を行い、テスト設計によってテスト実施数を効率よく減らしたうえで、その実行を素早く行うために自動テストなどを組み合わせることが大事です。
開発者が「開発を加速するためのテスト」を行えるように
──「開発を加速するためのテスト講座」にはどのような課題感を持つ人に参加してもらいたいですか？
最初に触れたように、開発や要件定義、設計といった部分を学ぶ機会は多い一方、テスト設計や素早い開発の中でのテスト方法を学ぶ機会は、今のところなかなかないと思います。そこに課題を持っている人はぜひ参加をしてほしいと思っています。
講座名にもなっているのですが、私自身テストの精度を上げる方法を伝えたいのではなく、「開発を加速するためのテスト」の方法を伝えたいので、テストがボトルネックに感じられている人はぜひ。
──そういった課題を解決するために、講座で工夫しているポイントについて教えてください。
座学だけでなく自分で手を動かしてもらうのはもちろんですが、こちらで用意したお題に対してどのように考えたのか参加者同士でお互いに見せ合ってそこから何か学んでもらえるような工夫をしたいと思っています。
認識合わせの話にも繋がるのですが、書いている単語は同じだけど認識が異なっていたり、同じドキュメントを見てもそこからくみ取った意図が異なったりといったことを体験してもらえればと思います。
──最後に、この記事を読んで講座に興味を持った読者の方にメッセージをお願いします。
この記事を読んで、人によっては、「自分が今まで考えていたテストと違う」と感じる人も居るかもしれません。そうした違和感がきっかけとなって良い結果に繋がることも多いと思うので、そう感じた人ほどこの記事で語ったことを一度試してみてほしいです。そのうえで具体的な手法が分からなかったり、上手くいかなかったりしたら講座を受けるというのもアリだと思います。
──本日はありがとうございました。
「開発を加速するためのテスト講座 〜アジャイル開発にも適用できるシフトレフトなアプローチ〜」参加者募集中！
- 受講料金：55,000円（税込）
- 場所：Zoom（オンライン）
▼詳細・申込はこちらから
