BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース eBay Denmarkにおけるソフトウェア品質保証の取り組み

eBay Denmarkにおけるソフトウェア品質保証の取り組み

原文(投稿日:2020/08/27)へのリンク

品質とは、単に運用環境へバグを流出させないということだけではない。その他にも多くのことがある。品質とは、プロダクトがユーザフレンドリで、アクセスや利用が容易で、高いパフォーマンスと短いロード時間を実現していることだ。コードが安定していて、メンテナンスが容易なことも必要だ。

Jette Pedersen氏はSwiss Testing Day 2020で、優れた品質のプロダクトを実現する方法について講演した。

eBay Denmarkでは、ユーザエクスペリエンス向上のためにさまざまなテストを行っている、とPedersen氏は説明した。

ユーザのもとへ出向いて話をし、プロトタイプの確認と試用を依頼するようなユーザテストは、ユーザのニーズや考え方、プロダクトに対する私たちの考えを理解してくれているかどうか、といった点において、より深い洞察を与えてくれます。パフォーマンステストを行えば、サイトのパフォーマンスが私たちの期待の範囲内であるかどうかが分かります。A/Bテストをすれば、どのようなものを作ればユーザが最も気に入ってくれるかが分かるのです。

適切なテストを行っていることを確認するためにPedersen氏らが用いているのは、テストデザインのテクニックである。例えば、同等性テストと境界値分析を組み合わせて使用する。これにより、すべての有効/無効パーティションを1回のみテストすることと、各パーティションのすべてのバウンダリが有効/無効パーティションの適切な値でテストされていることが保証される。

最初から完全なソリューションを求めるのではなく、eBay Denmarkでは、プロダクトを構築する適切な方法を見つけるために数多くの試験を行っている。例えば、仮説を立てる。

新たなプライバシ製品をユーザに提供すれば

セラー(seller)のNPSが向上するだろう

ホームアドレスの公開を望むかどうか、選択が可能になるからだ。

次に氏らは、ユーザがそのプロダクトを購入するかどうかを確認するために、フェイクドア(fake door)テストを行った。ユーザがそのプロダクトを望んでいることがテストで分かったので、プロダクトを作成した後、適切なレイアウトを確認するためにA/B分割テストを実施したのだ。

eBay DenmarkのシニアQAソフトウェアエンジニアであるJette Pedersen氏にインタビューして、品質の保証、品質に影響するリスクへの対処、品質から学んだもの、プロセス全体を通じた品質思考の実現などについて聞いた。

InfoQ: プロダクトの高品質を保証にするには、何をすればよいのでしょう?

Jette Pedersen: プロジェクトやタスクの開始時点から、品質について考えておくことが必要です。ユーザが使える、使ってくれるものを構築するには多くの経験が必要ですが、その前に、別のことについて考えなければなりません。

  • 誰のために作るのか?
  • パフォーマンス上の特別な要求はあるか?
  • 要件は何か、現在のプロジェクトのステージでそれが分かっているか?
  • UIの変更はあるか?
  • 開発領域におけるリスクアセスメントは何か?
  • セキュリティ上の新たな予防措置も考慮するべきである。

このすべてを、プロジェクトの最初に行うキックオフで一通り説明しました。

プロジェクトの開発中には、TDDやペアプログラミングを頻繁に使用します。知識の共有や、開発中に発生する障害を克服する上で、これが役に立っています。

運用中に発生した問題に対してフィードバックを迅速に得るために監視システムをセットアップする必要性や、必要なテストオートメーションの種類などについても話し合っています。

経験則から言えば、リスクの高いものすべてと、中程度のリスクのいくつかについては、(可能であれば)何らかの自動テストでカバーできるべきだと思います。

InfoQ: 品質に影響するリスクはどのようなもので、それをどう扱えばよいのでしょうか?

Pedersen: プロダクト開発に関わるリスクには、さまざまなタイプのものがあります。

  • 開発中のプロダクト領域に関する知識を十分に持っているか?そうでない場合、有識者へのアクセスや回答を見つける場所があるか?
  • プロダクト開発で使用するフレームワークにどの程度習熟しているか?
  • このコード領域で以前にも開発をしているか?
  • 期限はあるか?そうであれば、品質が低下する可能性は大きい。(幸いにも私たちは、期限のあることはほとんどありません。)

私たちはリスクに対して、タスクをスタートする時、例えばタスクのキックオフ時に、できる限りたくさんのリスクを認識しておくことで対処しています。タスクに影響するリスクはどれか、ということに関しては、そのタスクがリスク的に高い領域、中程度、低い領域のいずれにあるかを確認することで、リスクを軽減するアクションを取ることが可能になります。ペアプログラミングもソリューションのひとつになります。プログラミングやテストに関して、あるいは取り組んでいる領域の知識を持った人たちによる、より多くの支援が必要になる場合もあります。

InfoQ: 長期にわたる取り組みの中で、品質について学んだことは何ですか?

Pedersen: プロジェクトの最初から品質を考えておく必要がある、ということです。プロジェクトの早い段階で問題を発見すれば、対処に必要な費用はずっと小さくなります。

リスクベースのアプローチを使用したことも、十分な品質を確保する上で何をすべきかという、優れた指標を与えてくれています。必要がなければ、品質に関して過度に時間を費やさなくてもよい、ということも分かりました。

今日、品質の保証は、QAの役割だけに依頼するものではありません。チーム全体が品質に責任を持つことで、ユーザに高い品質を提供するという面において、はるかに大きな成功を収めることができるようになります。QAがボトルネックになるという問題を抱えることもありません。

パフォーマンスとユーザビリティがプロダクトの基本である、ということも学びました。プロダクトが機能しなかったり、あるいはユーザがプロダクトの使い方を理解できなかったりすれば、プロダクトが高品質であっても意味がありません。ユーザはそのプロダクトを二度と使わないでしょう。

継続的デリバリを早いペースで可能にするための自動化にも注目しています。

InfoQ: プロセスを通じた品質思考を実現する上で、何かアドバイスはありますか?

Pedersen: 品質とは何かという点で、同僚と意見を合わせてください。QAとしてのマインドセットを作り上げる支援をするのです。答を与えるのではなく、質問してください。

プロジェクト全体を通じて、お互いにコミュニケーションしましょう。コードにせよテストにせよ、お互いがより多くのコミュニケーションを持って支援することで、プロダクトの品質を向上させることができるのです。リスクベースのアプローチを使って、保証の必要な品質の量とレベルを理解しましょう。リスクアセスメントのために何をすればよいのか、同僚に理解させてください。

彼らもあなたと同じように品質を保証できるのだ、ということを信じましょう。

この記事に星をつける

おすすめ度
スタイル

BT