こんばんわ、TF's appsです。
今回の記事は【テスト】について紹介します。
本業でもそうなんですが、実はわたし・・・・
テストが大っ嫌いです（汗）
デバッグレベルで動作確認するのは好きなんですがねぇ
でも【テスト】が十分でなければ、品質は落ち、ユーザーに満足に使ってもらえないですよね？つまりはユーザー離れに繋がります。
そうだから【テスト】はとても大事です！！
でも・・・
一般的に設計者は自分が作成したソフトの評価は弱いと言われています。
個人開発者であれば「なおさら」だと思います。
そのソフトに一番詳しい人がなぜ弱いのか？
それは「一番詳しいがゆえに甘くなる」と言ったら良いでしょう♪
◆中身をよく知っているため
１．テストケースが最小パターン
（こことここを見たら大丈夫と思いがち）
２．客観性が乏しい
（使い方が自分視点となり、自分の操作視点で評価する）
３．品質基準が妥当でない
（自分の品質基準でＯＫと判断してしまう）
・・・などなどが考えられます。
私個人の見解ですが、個人開発者はＱＣＤというと「Ｄ（納期）」最優先で活動していると思います。
ある意味、最小の設計コストで最大の成果物を世に出しているわけで「Ｄ（納期）」視点で考えると最良と言えます（＾＾ｖ）
・・・
しかし
・・・
「Ｑ（品質）」視点で考えると、最悪と言えます。
ここで私なりの評価術を紹介します。
（１）評価にはカバレッジ（コード網羅率）を意識する！！
（２）リリース前に友人や家族に使ってもらい意見を聞く！！
（１）カバレッジ？コード網羅率？
すごく簡単に紹介しますと、if文とelse文の両方を必ずみるという事です。分岐があれば少なくとも両方を通るパターンは最低見るというものです。
（２）第三者評価
レビューはすごく大事です。どんなスーパーマンでも必ず欠陥があります、だからこそ人が造るこの世界は科学が発展してきたとも言えます。色んな人の意見が詰まったソフトは鉄から鋼のように堅牢となり、安心のできる品質になります。
如何でしたでしょうか？
今回は効率的な評価に触れてみました。参考になるところがあればぜひ取り入れて下さい。では次回またお会いしましょう！！
