担当テストマネージャー　K.F.

　私がIT企業に入社して2～3年目くらいの頃、
先輩エンジニアから、テスト工程での心得をいくつか聞かされました。
　かなり前のことなので全ては思い出せませんが、
今も忘れずに心がけていることがいくつかあります。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・

1. バグはあるものと思え。　　　
2. 1つ2つうまくいったからといって3つ目もうまく行くとは限らない。
   　　全て確認せよ。
3. 先入観や思い込みでテストするな。
4. おかしいけど仕様なので良いか・・・はダメ。
5. 再現しないからと言って放置するな。
6. PCL*1）消化が目的ではない。不具合の摘出が目的。
7. 類似不具合がないか確認しろ。
   ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
   　職場では、検査部門は開発部門より強い立場にあり、
   検査部門でのテスト合格が、開発チームの最後の難関でした。
   　「全体の2割を検査して10件のバグが出た場合、あと50件バグ
   摘出してから持ってこい」
   と突き返され、バグ摘出ノルマを課せられ、たとえソース一行の修正
   でも、デグレ防止や類似不良がないことの確認を求められました。 　そうした環境や習慣が、その後の私の品質重視の考え方の基礎に
   なっています。
   　ですから私は、QCD*2）の中ではQが一番優先かな－と思います。
   ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
   　次回の私の担当では、QとCとDの兼ね合いについてコラム
   できればと考えています。

＜編集者注＞
*1）PCL：プログラムチェックリスト Program CheckList
　　　　出来上がったプログラムが仕様通りに動作するかを調べるために
　　　作成する検査項目のリスト。様々なテストケースを想定して、
　　　どのような値や条件を与えるとどのような出力が得られる
　　　べきかを記述します。
*2）QCD：Quality(品質), Cost(コスト), Delivery(納期)

次回のコラム更新は12月24日を予定しております。

担当テストマネージャー　E.Y.

今回は本番での運用の前に、本番に限りなく近い環境で行う
テストをとりあげます。

Windows では Insider Preview の提供を受けてテストを
実施したり、iOSアプリだと TestFlight を使ってリリース前の
テストを行ったり、呼び方や方法は様々ですが、
「本番により近い環境で評価する」という目的は一緒です。

ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
リリース前に少しでも問題点を解決することが目的で、
開発者だけではなく実際にユーザーが参加できるところがポイントです。

割と昔から行われている手法だと思いますが、完成度を上げるには
至って効果的なやりかたでしょう。それだけにこの時点でバグが
多発していると逆効果になるリスクもありますね。

この段階でのテストにおいて、インフラ周りの知識が豊富なメンバーが
いると心強いことがあります。
単体や結合でプログラムが完成されていても、インフラの仕様に
よって起こる不具合は意外と多いと感じています。

多少乱暴な言い回しになるかもしれませんが、この場合
・運用で逃げられるパターン
・インフラに合わせてプログラムに修正が必要なパターン
・制限事項としてそのまま運用に回すパターン
などの調整が必要になってきます。

ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
製品としてプログラムがちゃんと動くことはもちろんですが、
マニュアルにあらかじめ記載しておいて正しい運用を促したり、
リリースされてからのサポートを円滑に進めるためには、
そのようなプログラム以外の動向についても、
常にアンテナを張り巡らせておきたいところです。

担当テストマネージャー：E.Y.

以前の番外コラムで新しいOSに触れましたが、
11月になって徐々に情報も増えてきました。

Windows11
macOS Monterey
iOS15
android12

やはり最初はUIの変更に踊らされる感じでしょうか。
鋭い勘の持ち主であれば「あ、こうなるのか」と気づけそうですが、
知らないと割とハマってしまうんじゃないかなと思います。

でも最近の人は順応性高いから大丈夫！
・・・とは限らないと思いますので、
慣れるまでにはもうしばらく時間が必要かもしれません。

担当テストマネージャー　M.M.

　「ソフトウェアのテストチームが必要である理由」について、
テストマネージャーである私の考えを述べたいと思います。
　結論から述べると、「開発担当者は開発だけをしたいからである。」
と言うことです。
　ここで言う開発担当者とは、要件定義、基本設計、詳細設計、
コーディングの各担当者を指します。

　殆どの開発担当の方は、ソフトウェアの開発がしたくて、この仕事に
従事しているはずです。
　しかしながら、ソフトウェアには欠陥がつきものです。
その原因は、仕様レベルであったり、実装レベルであったりしますが、
いずれのフェーズの開発担当者も、欠陥と向き合う必要があります。
そして常に新しいものを開発したい人ほど、既存の欠陥と向き合うのが
苦手ではないかと考えています。

ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　そこで、「開発担当者が欠陥と真摯に向き合えるよう仕向ける」のが、
テストチームの役割の一つだと思っております。
　また、開発担当者が欠陥と真摯に向き合ってもらう為、テストチームは
開発担当者の心に寄り添うことも大事だと考えています。
何故なら、開発担当者は、欠陥を故意に埋め込んだ訳では無い
からです。

しかし、人によっては多量の欠陥を知らず知らずのうちに埋め込んで
しまい、修正作業でメンタルをやられてしまうのも現実です。
そこで、少しでも修正作業が楽になるよう、様々な工夫をして支援
するのが、テストチームの大切な付加価値だと考えています。

ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　私が考える具体的な工夫ポイントは、大きな視点では次の５つです。
１．業務に直結する欠陥はリリース前に見つけ、リリース後の負荷を
　　　軽減する
２．テストフェーズに入ったら、少しでも早く欠陥を見つける
３．大規模なシステムでは、機能を横断して一斉にテストし、軽微な
　　　欠陥から重大な欠陥に至るまでバランスよく見つけ、
　　　開発チーム内メンバーの修正負荷を平準化する
４．欠陥を見つけたら、分かる範囲で仕様が原因なのか、
　　　実装が原因なのかを調査する
５．欠陥の内容は、修正の必要性も含め具体的に分かりやすく
　　　開発チームに伝える

　開発チームにとって、頭の痛い存在でありつつも、負担を分かち合い、
応援してくれる存在。
それが理想のテストチームなのだと私は考えます。