システムを把握する3つのコツ
こんばんわ、なそです。
この記事はソフトウェアテスト Advent Calendar 2018 - Qiitaの9日目の記事です。
指摘を受けて、その通りでしたので、修正しました。
- システムを把握する
↓
- システムの目的を把握する
みなさんは、仕様書や設計書を元にテストを実施したのに、リリース後に障害発生させて、一生懸命にテストしたのに...... という経験ありませんか？
100％防ぐことができなくても、少しでも減らしたいと思います。どうしても「仕様書」や「設計書」に記載しきれないことが多くて、『それ聞いてないよorz』ってちゃんと書いてよって思うことはしばしば。それ以外に回避するためには、テストするシステムの理解を進めるという方法が1つあります。システム全体をイメージできると機能間の矛盾や行方不明になるデータ、隠された機能を見つけやすくなります。
今回はシステム把握する時に気にしていることを3つのコツを説明します。
- システムの目的を把握する
- 業務を理解する
- データの流れを意識する
システムの目的を把握する
自分がテストするシステム全体で何をしたいのかの目的を把握し、その目的をどう実現しているのかを把握していきます。業務によって必要なシステムの構成がある程度決まります。ECサイト等は普段使用することが多いと思います。いくつかのサイトを利用しているのであれば、その経験を参考にできます。
自分が知っている知識との差分を考えることで、どこで何をしているかを把握できてシステムの把握が進んでいきます。
機能から徐々にボトムアップしていく方法と、システム全体から徐々にトップダウンで降りていく方法がありますが、初めて触るシステムの場合、ボトムアップの方が考えやすいかもしれません。複数のシステムを見たことがある人ならシステム全体の構成を意識することができるため、トップダウンで考えていく方が考えやすいです。最終的には両方を意識することになります。
誰が使うのかという視点も意識してください。ECサイトでは購入者となることが多く、そこに対する意識はできると思いますが、出店者側の視点が抜けやすくなります。いろんな人が関わるシステムですので、1つの面だけではなく複数の面を意識することが必要になります。
業務を理解する
システムを把握してくると機能と機能の繋がりが見えてきます。そうすると見落としやすいポイントが「いつ」システムを使用するのかということです。
ルーチン：「日」「週」「月」「年」etc.....
アクション：「購入ボタンクリックした時」「間違えた登録した時」etc......
テスト設計していると仕様書や設計書に目がいってしまい、1週間に1回しかやらない処理、間違えた時などの処理が記載されていなくて、リリース後に運用できないとかのトラブルが発生します。書いてない仕様を探すために、システムの矛盾や想像していない業務の流れを探していく必要がトラブルを減らすコツですね。
基幹システムの業務知識は、イメージしにくいと思います。下記の本である程度の知識を得ることができます。(基幹システムは普段触れることは少ないので本から得られる知識でも結構重要になります)
データの流れを意識する
システムで使用するデータはシステムの中で流れる血のようなものです。流れ続ける場合もあれば、どこかで止まる場合もあります。
止まるデータは、何かしらの分析に使用されることが多いです。分析には流れているデータも使用します。
システムや業務を知っていてもデータの流れは出てこないです。特に履歴や内部で監査のために保持している等のデータは上記2つのコツからは見つけられないです。その辺を意識しないといざ使おうとした時に使えないなどのトラブル時の対応でトラブルに発生することもあります。異常系のテストであることが多く、重要度が低くくされることが多いです。
不自然に止まるデータは、仕様の矛盾が発生していたり、同じような項目が多い場合は障害の温床になったりします。(A列を更新するはずなのに似たようなB列を更新してしまったためにステータスが更新されずにいつまでも修正できるとか)
システム化するときに、以前は手動でやっていたやり方をそのまま取り入れられる場合があります。不思議なところにデータがあったりして、話を聞いてみると以前の業務を聞くことができ、使う人たちをさらに意識できる場合もあります。(昔話に花が咲いて藪蛇の場合もありますがw)
まだまだコツはありますが、今日は3つ紹介させてもらいました。システムを広く知っておくと、レビューの時の矛盾点の指摘だったりと活躍の場面は多いです。少しずつ理解して知識を増やしていきましょう！
それでは、なそがお送りしました。
