うさぎ組

ソフトウェア開発、チームによる製品開発、アジャイル、ソフトウェアテスト

アジャイルでもWFでも共通する「開発やテストのモデル」-全てのソフトウェアテストを再定義する- #SWTestAdvent

はじめに

これはソフトウェアテストあどべんとかれんだー 2014 の17日目の記事です。

id:a-suenamiテストとは開発プロセスそのものである #SWTestAdvent - assertInstanceOf('Engineer', $a_suenami)で僕が考えているモデルについて紹介してくれていたので、ざっくりとですが僕の方から「現状の僕が捉えているソフトウェア開発。そしてテスト。」について紹介します。これはここ数年における僕の最高傑作とも言えるコンテンツに関するエントリです。(言いすぎだ

概要

言い過ぎればプロダクト開発というものは「Define, Build, Explore, Measure」という活動から成立していると言えます。これに知識や手法やプロセスをあてはめると「何をやるべきか」「何が足りていないか」がわかりやすくなります。この記事ではそういった開発やテストを話すときのベースとなるモデルを提案しています。

これに名前をつけてからになるけれど、これに関して講演や書籍執筆など、どんどんアウトプットできたらなーって思っています。ご興味ある方はご連絡いただければ嬉しいです。

kyon.mm at gmail.comまで。

問題提起

ソフトウェア開発やテストにおいてたくさんの分類方法があり、それらは僕の学習に大変役立ちました。だけれど、それは学習に役立ったのであって、根本としての何かを教えるためには少々回り道であったのも確かでした。中には側面ばかりを学んだという感覚が残った思い出もあります。

例えば、テストで言えば、テストレベル、テストフェーズ、テストタイプ、品質特性、アジャイルテストの4象限といったものは、テストのある側面については述べています。また、テストをたくさん勉強する上では必要な知識である事は間違いありません。けれども、そもそも「私達が特定の市場になんらかの影響を与えるためにテストをしている」という感覚とどうやって結びつけるかが難しかったです。

例えば「ユニットテストにおけるそのテストケースがなぜリリースに必要なのか」ということを説明するのは少々スキルがいるのと似ていると言えばいいでしょうか。スキルがある人はなぜ説明できるのか。こういった「ソフトウェア開発における説明しづらいことを説明できること」をつなげると、とってもシンプルに説明し、自分たちでも使う事ができるのではないだろうか?というように考えていました。

ソフトウェア開発自体のモデル

では、ここからが僕が考えているモデルについてです。 まず、ソフトウェア開発の中心は「リスク」になります。このリスクに合わせて「定義、構築、探索、測定」の4つの活動を通すことで価値を提供しています。これらの中心には「達成することやリスク」があります。これらに対して何を行うべきか?で整理できます。

f:id:kyon_mm:20141217164501p:plain

この外側の黒い四角4つをうまくやることで「要求や問題を見つけて自分たちで解決方法を提供する」ということを達成しています。

  • Risk(リスク) : このプロダクトに関わる全てのリスク。マーケットや法律や顧客やデベロッパーやソリューションや時期や様々なものがはいってきます。
  • Define(定義) : 達成すべきことを定義します。それはあるビジネスゴール、あるバグ解決、ある機能改善、あるドキュメント提供、あるパフォーマンス改善、あるメソッドの追加、あるリファクタリング、様々です。
  • Build(構築) : 定義したものを具現化します。それはプログラミング、環境構築、ドキュメント作成、チェック、様々です。
  • Explore(探索) : 定義、構築、測定で未定義な部分や、それぞれの成果のうち疑わしいものや、経験や歴史をもとに、具現化したものがリリース可能であるかを調べます。
  • Measure(測定) : 具現化すべきものは何であるかを調べます。ヒアリングしたり、インタビューしたり、A/Bテストをしたり、問い合わせを受け付けるなり、様々な方法があります。
  • Policy/Culture : リスクに対するこれらの活動をどのように行うかの方針や力になります。パターン・ランゲージだとこれらの一部はフォースと呼ばれることがあるかもしれません。これらは普段の4つの活動によって形が決まってきます。

f:id:kyon_mm:20141217155700p:plain

リスクの形は様々です。これによって、どの活動でどんなことをすればいいのかが変化します。 上記の図ではきれいに中央に小さく収まっていますが、もしかしたらこのような図の時もあるかもしれません。

f:id:kyon_mm:20141217160157p:plain

f:id:kyon_mm:20141217160201p:plain

注意すること

これらは記法を定義するものではありません。イメージ図イメージの1例です。上の5つの四角は四角である必要はありません。例えば次のような図でもいいとは思います。

f:id:kyon_mm:20141217150827p:plain

ただ、いま一番しっくりくるPowerPointのテンプレートが最初のやつだったんです。

テストのモデル

つまり、これらに対して私達はいろんなことをしているわけです。では、テストではこれらの活動にどう関わっているか見てみると次のような例があがります。(紙面の都合上、下記のテストは限定されています。)

f:id:kyon_mm:20141217163449p:plain

  • Define(定義) : BDDやSpecification by Exampleによって、テストによるソフトウェアの要求を定義をしている。
  • Build(構築) : 境界値分析や組み合わせテストなどによって定義とずれていないかを調べたり、静的解析に代表されるメトリクスによって開発をサポートしている。
  • Explore(探索) : 要求と要求の間を調べたり、構築時に確認しにくいところが本当にリリース可能になっているかをテストしている。
  • Measure(測定) : A/Bテストやユーザビリティテストなど、マーケットなどからの反応をもらうテストを行う。

これはプロセスではない

重要なことにこのモデルはプロセスを表現したものではないということです。例えば「Measureから始まるプロセス」ではないです。

ある活動の入力と出力が決まり、活動と活動が連なった時にプロセスと言えます。このモデルで言っていることは「ソフトウェア開発とは4つの活動のいずれかに該当する。」ということだけです。

典型的な例で言えば、システムテストのテストケースはDefineで決まるものもあれば、Exploreで決まるものもあります。これがこの記事のモデルが、テストレベルやテストフェーズといったものと決定的に違うという意味です。

他の例では、あるソフトウェアの目標となる性能(もしくは最低限上回りたい性能)はDefineやPolicyで決まりますが、それを例えば最終的なものとして計測できるのは手段がほとんど構築できたあとになることはよくあります。仮にこのモデルがプロセスであるならば、性能テストはExploreの担当になってしまいます。ですが、実際には「Defineにしたがっているかを調べる行為」なので「予め決まっているような性能要件に関するテスト」は「Define」になります。仮に、「定義されていない性能に関するテスト」であれば、Build, Explore, Measureのどこかでやることになるのだと思います。

2つの大別

DefineとBuildに関するテストというのは、フォーマルメソッドや自動生成によって完結する事が可能な領域です。一方でExploreやMeasureというのは主だって未定義に関するテストや、人とのインタラクションによって決定される領域なので、フォーマルメソッドによる解決が難しいと考えています。

私はこの2つの大別をもって、前者をCheckingの領域、後者をTestingの領域である。と考えています。

さらにさらに。。。

上記のモデルでは、「どれか1つのテストが欠損してもある程度他のテストから復元可能である」という例示や「どのテストが足りていないかがこのようにわかる」という例示などが出来るようになります。

と、いろんなトピックがあるのですが、まだ推敲が足りていないので続きやさらなる詳細や歴史についてはまた別の機会に。。。(続きがどのような形で公開されるのかは未定です。。。