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

　昨今はIT系の人材不足が深刻化しており、AIに置き換わって
しまうなんて予測もあります。
　実際、現場のエンジニアの減少により、教育や引継ぎも満足に
できず、昔以上に自分で技術を吸収しなければならないケースも
多々あると思います。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　近年はインターネット環境も充実し、専門書籍を使った学習の
ほか、ITサイトの記事として公開されているものや、個人が備忘録
として残しているものも情報源となりますので、容易に検索することが
できるようにはなっています。

　しかし、本当に欲しい情報はそうそうそのへんに転がっているものでは
ありません。
　あの時はうまくいった、たまたまうまくいった、ということだけではなく、
実はウソ情報だった、・・・なんていう経験はザラにあります。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　それと、「サポートの窓口」ってたくさんあって、実際どの窓口に
連絡したらよいかわからず、時間がかかってしまうケースもあります。
　担当窓口が管轄グループ毎に異なっていて、自分の管轄外の
サポートはしてくれず、解決したい内容に行きつくまで、たらい回しに
なることも少なくありません。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　上述したことはIT分野に限らず、調べている際に様々な情報に
遭遇するのは、誰しもが経験することだと思っています。
大切なのは、得た情報を次に生かせるように咀嚼し、吟味して
情報の取捨選択ができるようになることだと考えます。

　間違った情報を信じて失敗してしまっても、必要以上に落ち込む
必要はありません。
　同じ失敗を繰り返さない、同じ失敗を他人にさせないための情報を
残すことはできます。
　そういった次への努力を惜しまない人が、やがて成長し成功する
のだと信じています。

担当テストマネージャー　A

　皆様はノートの取り方について、お悩みはないでしょうか。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　私のような受託でテストを行う者にとって、毎日の業務が新しい
業界や技術への挑戦です。それが刺激となり、モチベーションにも
繋がったりしております。
それと同時に仕様や要件の理解力が求められる立場でもあります。
　資料の確認や、打合せの際、いかに素早く的確に仕様や要件を
理解するか？…というところにおいて、3色ボールペンを使った
情報整理術を使っております。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　具体的には、お客様との打合せの前に、モジュールの構成図や
画面レイアウトを白黒で事前に印刷します。
　そして打合せの時、そこに3色ボールペンで丸囲みしたり、メモを
書き込んだりします。
　そうすることで、お客様の何気ない一言を拾ったり、資料と比較して
自分が感じた疑問点を書き込み、その回答を書き込んだりできる
ので、普通に議事を取った議事録よりも遥かに濃い情報を手元に
残すことができるのです。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　技術評論社出版の「ソフトウェア・テストPRESS」に掲載されていた
3色ボールペンの色のルールを採用しています。
・赤…客観的に見て、非常に大事なところ
・青…客観的に見て、それなりに大事なところ
・緑…主観的に見て、大切なポイントと感じたところ

　ただ、現在の新型コロナウィルスによるテレワークでは、セキュリティの
観点から印刷もままならず、印刷物に書き込むという手法は使い
づらい状況で、手元のノートにメモする時のみの活用に留まって
います。
ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・ー・
　昨今のDXを背景にした技術革新により、このような不利な点も
徐々に解消されていくのでは？…と期待しております。
　例えば、ペンタブレットを用意し、そこで情報を書き込み、
OneNoteで保存するなどは、既に実践されている方もいらっしゃる
のではないでしょうか。

　もし、実践されている方がいらっしゃいましたら、使い勝手等
ぜびご意見、ご感想を賜りたく存じます。　

担当テストマネージャー　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(納期)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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