58-テスト担当者はプログラマの友人

「プログラマが知るべき97のこと」の58個目のエピソードは、テストに関する話です。このエピソードにおけるテストはユニットテストではなく、QA（Quality Assurance:品質保証）やQC（Quality Control:品質管理）と呼ばれる部署が行うようなテストです。会社の規模やプロジェクトの規模がそれほど大きくない場合は、テスト専門の部署がない事が多いですが、プロジェクトの後半にて品質を担保するためのシステムテストや負荷テストは必要不可欠でしょう。そのような品質を保証するテスト担当者とプログラマとが良い関係を保てない状況は珍しい事ではありません。似たような問題として、プログラマと営業担当者の問題もあります。どちらの問題も、それぞれの立場ではお互いに正論を述べる一方で、利害関係が一致しないことに起因します。最終的な利益はユーザの価値であるはずなのですが、何故か上手くいきません。
プログラマはユーザのためにソフトウェアを開発します。困難な問題を様々なソリューションを使って解決する事に価値を見いだします。一方、テスト担当者はユーザのためにソフトウェアの不具合を探します。不具合があるソフトウェアをリリースすることによりユーザの価値が減ることを防止します。それは、プログラマに対して嫌がらせをしているのではありません。勿論、プログラマもテスト担当者が悪意を持って不具合を報告していると思う人はいません。
規模も納期も小さくなりつつあるソフトウェア開発では、どのように品質管理やテストと向き合うかはもう１つの課題です。最近は、品質保証のキーはユーザマニュアルであると考えるようになりました。そのユーザマニュアルの元となるのはユースケースシナリオであり、ユーザマニュアルを元にシステムテストが行われる事が理想です。ポイントは基本設計の頃からユーザマニュアル・システムテスト項目と変化していく事を想定したユースケースシナリオの作成です。ユースケースはユーザとの契約上は重要なものかと思いますが、最終的にユーザ価値をもたらすのはシステムとマニュアルです。そして、それを担保するのはテストであり、設計書ではありません。したがって、最終的に「動くソフトウェア」と「知りたいことの書いてあるマニュアル」を目指すのが最短コースと考えます。作成はフェイズ毎に区切ることはしない方がいいでしょう。開発を進めながらマニュアルとテストを作成していくことで、実装漏れや考慮漏れに気付くことになります。
テスト担当者が独立しているような開発でも同じと思います。なるべく早い段階でソフトウェアを知り、プログラマと同じ環境で開発に参加するべきではないでしょうか？

プログラマが知るべき97のこと

Scenic3 によるRESTサポート

Scenic3はSlim3のController層を薄くラップした拡張ライブラリです。Slim3では1アクション（URL）に対して１つのControllerを作成するシンプルなデザインですが、どうしてもControllerの数が多くなってしまいます。関連するアクションは１つのクラスにまとめ、アクションメソッドを複数定義する設計を好む人にとってはやや窮屈な仕様です。Scenic3ではそんな人達のために、複数のControllerクラスを1つのPageクラスに定義する手段を提供しています。
一方、REST風のAPIを設計する場合は同一URLに対して異なるHTTPメソッドを割り当てる事になります。例えば、あるモデルに対する取得と削除は次のような同じURLとなります。

http://yourdomain/item/{id}

idにはモデルを識別する一意の値が指定されます。同一のモデルに対する操作は同じURLとなり、HTTPメソッドがGET/POST/DELETE/PUTのどれであるかにより振る舞いが変わるようになります。
このようなREST風のAPIをSlim3で実装するには、Controllerのrunメソッド内で、isGet, isPut, isPost, isDeleteメソッドを利用して条件分岐を行えば実現できます。Scenic3を使った場合でもisGet, isPut, isPost, isDeleteが利用できるので同様です。
Scenic3の目的は「見通しの良いコード」を実現することです。0.4.0で実装されるRESTサポートを利用する事で、アクションメソッド毎に、呼び出されるHTTPメソッドを宣言的に指定できるようになります。