[UT, IT, ST] 開発時のテストフェーズについて
システム開発においては、バグは必ずあるものとして考え、それをより早い段階で発見するこが望ましい。そういった意味では、テスト工程はコーディングを行うよりも重要であると思う。
プロジェクトでは以下のようなフェーズでテストを行っていくことが多い。
なお、以下は経験上の話であることをお断りしておく。
ページ単位、画面単位で完結している。
ここでは基本的なバグについて注意を払わなければならないのだが、この段階で徹底的にバグをつぶしておくことが理想であると思う。
見積もりの段階でテスト込みの工数算出を行うべきであり、(経験から言うと) この部分をないがしろにしている (充分な期間を取っていない、テスト方針が定まっていない等) プロジェクトは、後のフェーズで炎上する確率が非常に高い。
データの出入力がある場合、最小値と最大値の入力を行って、データベースアクセスの部分はデータ型によるオーバーフローや NULL のチェック、想定した通りの登録や更新・削除が確実に行われているかどうかは特に気をつける。
異なるシステム (古いシステムの移行等) からのデータ移行がある場合は、文字コードによるバグなどもよくあるので、どのようなデータが入っているのか確認しておいたほうが良い。
このテストでは、テストを自動化している場合も多いだろうが、
基本的な観点を理解していないと成果が出ない。
それぞれがどういった影響を及ぼすかの検証を行う。
ここからは、テスト時に「シナリオ」を作成するだろう。
シナリオとは、いわばユーザーの振る舞いであり、システム稼動後にユーザーがどのような操作をするのか、今回修正対象となった部分はどのような動作を想定しているのかを具体的なイメージをもってテストケースを作成する。
プロジェクトの方針によってシナリオの書き方は変わってくるだろうが、特にデータベースへの登録や更新、削除などの一蓮の流れに重点を置いてシナリオが書かれることが多い。
ウェブシステムの場合は、ページの遷移が肝となるが、
セッションの管理なども特に気をつけてテストしなければならない。
新規のシステムを作っている場合を除き、修正を行っていない部分に新たなバグが発生していないか気をつけなければならない。今回修正したことによって新しいバグが生まれてしまっている場合も多いからだ。
今回対象となる A システムで登録したデータなどを B システムでも参照していたりする場合には、その部分の連結にバグがないかどうかをテストする。
結合テストと同じくシナリオに沿ってテストが行われ、内容的にも近いものがあるが、より実稼働環境に近い動きを想定しテストを行う。
ただし、このフェーズではユーザーにテストをしてもらうというよりも、ユーザーが想定している要望通りの動作をしているかどうかのチェックの意味合いが強い。
また、ここまでくると外部の人間はプロジェクトから離れることも多々ある。
ユーザーは操作性やデザインなどの細かい部分について要望を出してくる場合もあるが、要望をすべて聞いているとシステムが完成しない。また、実装を根底から覆すような要望もよくある。
期限を設けることや、バグ以外の要望は次のプロジェクトが立ち上がった際の課題とするように検討するべきだ。
このあたりは契約によって異なるが、リーダーがイエスマンだったり、立場上 断りにくいポジションにある会社の場合は、無理な注文でもさらに対応しなければならず、結果として炎上する話もよくある。
テストは実際の現場の方針によって左右される部分が大きいが、
できるだけ初期の段階で不具合をつぶしていくことが大事である。
プロジェクトでは以下のようなフェーズでテストを行っていくことが多い。
なお、以下は経験上の話であることをお断りしておく。
UT (Unit testing) = 単体テスト
プログラミングによって手を入れた部分のみを対象としたテスト。ページ単位、画面単位で完結している。
ここでは基本的なバグについて注意を払わなければならないのだが、この段階で徹底的にバグをつぶしておくことが理想であると思う。
見積もりの段階でテスト込みの工数算出を行うべきであり、(経験から言うと) この部分をないがしろにしている (充分な期間を取っていない、テスト方針が定まっていない等) プロジェクトは、後のフェーズで炎上する確率が非常に高い。
データの出入力がある場合、最小値と最大値の入力を行って、データベースアクセスの部分はデータ型によるオーバーフローや NULL のチェック、想定した通りの登録や更新・削除が確実に行われているかどうかは特に気をつける。
異なるシステム (古いシステムの移行等) からのデータ移行がある場合は、文字コードによるバグなどもよくあるので、どのようなデータが入っているのか確認しておいたほうが良い。
このテストでは、テストを自動化している場合も多いだろうが、
基本的な観点を理解していないと成果が出ない。
IT (Integration testing) = 結合テスト
修正を行った部分をシステムに組み込んでみて、それぞれがどういった影響を及ぼすかの検証を行う。
ここからは、テスト時に「シナリオ」を作成するだろう。
シナリオとは、いわばユーザーの振る舞いであり、システム稼動後にユーザーがどのような操作をするのか、今回修正対象となった部分はどのような動作を想定しているのかを具体的なイメージをもってテストケースを作成する。
プロジェクトの方針によってシナリオの書き方は変わってくるだろうが、特にデータベースへの登録や更新、削除などの一蓮の流れに重点を置いてシナリオが書かれることが多い。
ウェブシステムの場合は、ページの遷移が肝となるが、
セッションの管理なども特に気をつけてテストしなければならない。
新規のシステムを作っている場合を除き、修正を行っていない部分に新たなバグが発生していないか気をつけなければならない。今回修正したことによって新しいバグが生まれてしまっている場合も多いからだ。
ST (System testing) = システムテスト
プロジェクトによっては結合テストと一緒になっていることも多いが、今回のプロジェクトの対象となるシステムが、他のシステムと相互に影響を与えている規模の大きなシステムの場合は、このテストを行う。今回対象となる A システムで登録したデータなどを B システムでも参照していたりする場合には、その部分の連結にバグがないかどうかをテストする。
結合テストと同じくシナリオに沿ってテストが行われ、内容的にも近いものがあるが、より実稼働環境に近い動きを想定しテストを行う。
UAT (User acceptance testing) = 受け入れテスト
納品先のユーザーにシステムを操作してもらうフェーズである。ただし、このフェーズではユーザーにテストをしてもらうというよりも、ユーザーが想定している要望通りの動作をしているかどうかのチェックの意味合いが強い。
また、ここまでくると外部の人間はプロジェクトから離れることも多々ある。
ユーザーは操作性やデザインなどの細かい部分について要望を出してくる場合もあるが、要望をすべて聞いているとシステムが完成しない。また、実装を根底から覆すような要望もよくある。
期限を設けることや、バグ以外の要望は次のプロジェクトが立ち上がった際の課題とするように検討するべきだ。
このあたりは契約によって異なるが、リーダーがイエスマンだったり、立場上 断りにくいポジションにある会社の場合は、無理な注文でもさらに対応しなければならず、結果として炎上する話もよくある。
テストは実際の現場の方針によって左右される部分が大きいが、
できるだけ初期の段階で不具合をつぶしていくことが大事である。