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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ひとくちにテストと言っても、その観点は様々です。
今回はそのなかからユーザビリティテスト（以降、UX評価と記載）
を取り上げたいと思います。

弊社のテストソリューション”TESTERA”ではあまり触れない領域の
テストサービスですが、ユーザーの立場に立ってデザインを評価することは、
大変重要な位置を占めると思っています。

どんなに多彩な機能が盛り込まれていても、
「この機能どうやって使うかわかりづらいなぁ」
と思われてしまったら、製品としてはマイナスイメージです。

そこでUX評価が登場するのですが、その手法は以下のようなものがあります。

・実際にターゲットとなるユーザーにスタートとゴールだけ提示し、
　自由に操作してもらいアンケートをとる
・アイトラッカーを付けて目線を可視化する
などなど…

これらの結果をまとめて、製品の仕様にどう反映するかを検討していきます。
バージョンアップ後、製品もしくは後継製品ではすごく使いやすくなっていたり、
他の人に勧められるようなものになっているかもしれません。

コロナ禍でUX評価メンバーを揃えるのも厳しいかもしれませんが、
よりユーザー視点に近い目線で、デザイン設計を行うことについても
優先度を上げたら良い方向に進むのでは？ というお話でした。

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

テストマネージャーのK.Fです。
今回は、当社のテスト自動化アウトソーシング「TESTERA-AT」を
PRさせていただきます。こちらは回帰テストを自動化するものです。

テスト自動化の開発工程は「要件定義」「設計」「実装」「テスト」の４つに大別され、
ウォーターフォール型の流れになります。

「要件定義」では、手動テストでの課題、自動化の目的や範囲、テスト方法と内容などを整理し、
自動化対象の選定、テスト観点、成果物、マイルストーンや作業の進め方を検討します。

「設計」では、具体的なテスト項目、操作手順、テストデータなどを確認し、
「自動化テスト仕様書」を作成します。
仕様誤りがある状態で実装してしまうと、せっかく自動化したのに
「意図したテストになっていない」「アプリの不具合が検出できない」
さらには「自動化テストが途中で止まる」といった不具合が発生しかねません。
ですから、「自動化テスト仕様」は大変重要であり、お客様と充分に詰めます。

次の「実装」と「テスト」は、並行して行います。
自動化テスト仕様書を元に自動化モジュールを実装し、仕様どおりに正しく動作するか、
前述のような不具合が無いかをテストします。

その後、お客様環境に導入して検証いただき、回帰テスト自動化の本番導入になります。

回帰テストを効率化したいとお考えのシステム開発者の皆さん！

テスト自動化では上記のような作業とそれに伴うコスト、自動化ツールの使いこなしなど、
初期導入において高いハードルに直面します。
そんなお悩みは、「TESTERA-AT」が全て解決します。
「TESTERA-AT」は、自動化計画を立案するコンサルティングから自動化テストの導入まで、
お客様のご要望に合わせて幅広く支援いたします。

自動化の手法や自動化ツールの操作方法を、新たに習得する必要はありません。
当社のエンジニアに全ておまかせください。
手動テストにかけていた時間やコストを大幅に削減するだけでなく、
自動化により人的ミスを無くし、テストの品質、効率を向上させます。

どうぞお気軽にご相談ください。

担当テストマネージャー：EY

開発環境や運用事情で変わってくると思うので、明確な正解はないと思うのですが、皆様はどうされているのでしょうか？

問．InternetExplorerのサポートが終了したら・・・

対応策１．EDGEのIEモードで、Webアプリにほとんど手を加えずに運用し続ける

対応策２．マルチブラウザ対応としてアプリに修正を加え、Chromeなどで運用できるようにする

対応策３．１や２以外の秘策があるので企業秘密である