外結以降のフェーズで注意することなど。(主に障害発生時の原因切り分け)
エラーの情報伝達に関して
- 発生時間
- 再現動作
- リクエストパラメータ(入力情報)
- 特定度の高いデータ、特異度の高い情報
データ齟齬によるエラーやコミュニケーションが多いため、外結開始時点でデータ作りを一緒に行っておくのが良いと思います。
連絡してくる方はシステムの知識のあるテスターの方のこともあれば、システムの専門知識がない方もいますが、上記の情報に関しては伝えてもらうことができると思うので、伝達時のマニュアルに入れておきましょう。
ログの見方
システムによってはログの量が非常に膨大になるため、開始時間のヒアリングやログのNoなどを明確にしておくことにより、発見を容易にすることが大切。
サーバーに直で入れない、入れてもログ自体を検索することが容易ではない(通常のサーバーのように扱えない)ことも考慮し、ログ検知ツール(AWSでいうCloudWatch, AzureでいうとApplication Insights)やエラー検知ツール(Sentry)などの活用を考えるべき。
普段から詳細なエラーメッセージ(StackTrace)を出すことを考慮しておく。
当たり前だが、ログやエラーメッセージツールにしっかりと情報を吐き出すようにしておく(そのための検証を前もってしておくことが大切。)
デプロイ
CDのようになるべく自動化できるツールを用意しておく。
ありがちな点としては、
設定ファイルごとに切り分けるべき、環境ごとに分ける情報の書き換えが残ってしまった
が多いため、人手を通さずにデプロイできるようにしておくべき。
タスクコミュニケーション(タスク管理ツール) 主にストック系の情報に関して
現状、解決されていないエラーがどの程度残っているかがわかるようにツールで管理するなど、どのプロジェクトでもあるかとは思います。
記録系の情報を残すのでストック系の情報になると思います。
これまでの経験ではRedmine、Backlog、GoogleSpreadSheet、WBS、他独自テスト管理ツール(CAT)など使ってきました。
基本的にプロジェクトに合えばどれでもいいと思いますが、
- 各人の作業進捗などが明確にわかること
- フィルタリング機能(担当者、ステータス、期限、その他のカテゴリー)が容易で豊富なこと
- ID=800のタスクがあった場合、そのページに容易に飛べること(URLの中に入っているなど)。要は目的の情報に早く辿り着けること。
- チャットのようにメッセージのやりとりができること(ストック系の情報が残せること。)
- 更新時にメールが飛ぶ、あるいは更新の検知が容易なこと(気付けないとやばい・・・)
- ファイルの添付ができること。
- その他検索機能が優れていること。
内部ではRedmine、外部も含めるとBacklogがベストかな・・と個人的には思います。
チャット 主にフロー系の情報に関して
ここ１年以上ずっとテレワークなので基本やりとりをチャットでするんですよね・・・外部のベンダーともやりとりをするとどうしても必要になってきますし、タスク管理ツールだけだとやはり限界があるので、リアルタイムで必要になってきます。
Microsoft製品を使っているので私はTeams使っているんですけど、一般的にはSlackですかね。
- ポイントとしては、各人のやり取りがリアルタイムに行えること。
- メンションを付けることができること。
- 当たり前ですが、コミニケーションの中心となっていること
一般的にはフロー系の情報だったりするので、ストック系の情報など(決まった仕様などを話し合った場合は)はそれ用のツール(BacklogやRedmine)にまとめておきましょう。
