画面仕様書のチェックをするために，テスト設計について少しかじりました。
テスト設計に関してド素人なのでこちらの
「【この1冊でよくわかる】ソフトウェアテストの教科書」
という超入門の本を読みました。

入門編でもまだ全然難しかったのですが，仕様書のチェックに必要な考え方として，2種類のパターン出しをしてみました。

まずは，機能についてのパターンです。

それぞれ搭載されている機能を画面別に書き出し，その機能がどのような状態になるかを書き出していきます。そこで忘れてはいけないのが０の状態です。こちらについては，このnoteのBlank State（空っぽの状態）を参考にさせていただきました。

そして，次にユーザーストーリーをベースにした体験のパターンです。

これは，このアプリを使うにあたって，どんなユーザーがどんな使い方をするかをパターンとして出してみます。これはかなり想像力を働かせる必要があります。一番簡単な手としては，ユーザーサポートの担当者に相談すると具体的にありそうなシチュエーションとたまに起きるヒューマンエラー的な事象まで幅広く教えていただけます。

ここに関しては失敗したなと思ったのが，ユーザーサポート担当の方と話す機会を仕様書ができあがってチェックの段階で聞いたことです。仕様を検討している段階からビジネスサイドやサポートサイトの担当者と話すことをおすすめします。

今回また新しいプロジェクトを任されることになったので，検討段階から細かい機能に関して，また今まであった機能で今回開発されるものに近い機能について，ユーザーに起こりそうなことを率先して聞きに行くようにしています。今後，全体像が見えてからはサポート側のメンバーを１人か２人仕様・ワイヤー検討チームに参加していただく計画も立てています。

話を戻して，機能のパターンと体験のパターンを出すと，仕様書の不足分がかなり具体的に見えてきます。そこで追記してもらったり，さらなる検討を重ねる，または次の開発へと後回しで検討するなどのアクションを起こします。

ソフトウェアテストは専門的な用語も出てきて，知識がゼロで読むのは難しい部分もありましたが，すべて理解しようとせずその考え方を学び取るように読むと開発しているものを別の視点から眺められるようになります。是非，参考にしてみてください。