【News】10月5週のニュース（ITトレンドEXPO 2021,テスト自動化,データベーステスト）

皆さん、こんにちは。
今週もソフトウェアテスト、テスト自動化に関するニュース記事をご紹介していきたいと思います。
今回は国内ニュース2記事、海外ニュース1記事をご紹介回したいと思います。

■記事内リンク

「国内ニュース」
・「ITトレンドEXPO 2021 Autumn」にバルテスが登壇決定
・なぜテスト自動化は当たり前にならないのか？

「海外ニュース」
・データベーステストの基本

■国内ニュース

□「ITトレンドEXPO 2021 Autumn」にバルテスが登壇決定

こちらは、バルテス社がオンライン展示会「ITトレンドEXPO 2021 Autumn」に登壇する内容となります。
前回ご紹介しました「Japan IT Week秋」に引き続き、オンライン展示会出展、登壇となるようです。

【News】10月4週のニュース(T-DASH,テストレポート)

「ITトレンドEXPO 2021 Autumn」は、2021/11/9(火）～12(金)に開催され、バルテス社は、9日、12日に登壇されるようです。

尚、「ITトレンドEXPO 2021 Autumn」では、バルテス社意外にも様々な企業が参加されています。
いずれも参加費は無料とのことですので、お時間が取れる方はいかがでしょうか。
https://it.expo.it-trend.jp/

□なぜテスト自動化は当たり前にならないのか？ アジャイル・DevOps時代のスピードと品質の考え方

https://codezine.jp/article/detail/14882
こちらは「codezine.jp」に掲載されていた内容となります。
アジャイル開発やDevOps時代に求められるテストや品質について述べられていましたので、ご紹介したいと思います。

◇アジャイル開発・DevOps時代のテストと品質

なぜ今テスト自動化が重要なのでしょうか？

従来型の開発であれば、要件を定義し、設計・開発を行い、テストを行ってリリースする形が一般的でした。
作るものが決まっていた時代であれば、このやりかたはとても効率的です。

しかし、何を作ればいいかわからなかったり、リリース後にビジネスを育てていかなければならなかったりする場合だと、従来型の開発方法はリードタイムが長く、作ってはみたけれど「誰にも使われなかった……」となってしまう可能性があります。

最近では当たり前のように使われている「アジャイル開発」や「DevOps」は、どちらも直線型の開発ではなく、開発と運用を繰り返しながら、斬新的に繰り返し開発をすすめる手法です。

これらによって小さくリリースし、ユーザーのフィードバックを受け取りながら、サービスやシステムを徐々に大きく育てていきます。
何を作ればいいかわからないなら、少しだけ作って、ユーザーに試してもらいながら改善する作戦が有効です。

スクラムなどのフレームワークの普及により、この10年でアジャイル開発は「当たり前」になってきたように感じます。
では、テストや品質はアジャイルになったでしょうか？
開発はアジャイルだけど、テストや品質がウォーターフォール。
そういった現場もまだまだ多いのではないかと思います。

アジャイル開発がテストや品質を置き去りにしてしまっていたとしたら、これからの10年でその遅れを取り戻さなければなりません。

◇アジャイルテスティングとテスト自動化

アジャイルテスティングをより具体化するために、有識者をお招きして、具体的なプラクティスを質問した際、以下のようなキーワードが登場しました。

・ユーザー視点での妥当な継続的フィードバック
・迅速なフィードバックためのテスト自動化、探索的テストの活用
・チーム全体で品質保証できる仕組みづくり

特に、探索的テストとテスト自動化は、アジャイルテスティングを支える重要なプラクティスと言えるかもしれません。

アジャイルテスティングを実現するためには、すべてのソフトウェア開発活動において、継続的テストを行うしかありません。
筆者がアジャイルテスティングを目指す現場を支援するときには、いつも最初にこう伝えています。

・イテレーション・スプリントの最後にまとめてテストしない方法を考えてください
・テストをする以外の活動を増やしてください

「最後にまとめてテストしない」ためには、イテレーションやスプリントの最後に自動でリグレッションテストを流すだけでリリースできる状態を目指さなければなりません。
そうしなければ、「テストがボトルネック」という問題と永遠に付き合っていかなければなりません。

特にバグ原因が「仕様不備」だとすれば、すぐに手を打つ必要があります。
最後の最後で仕様不備に気がつくと、大きな手戻りが発生します。
つまり、多くの時間を失っているという意味になります。

よって、自動化できるものは自動化して、最後にまとめてやっていたテストを、それ以外の活動（自動テストコードではカバーできない要件定義、設計、リリース、モニタリングなど）で行っていく必要があります。

ここでいうテストは、「テストコードを書く」や「手動でテストする」ではなく、設計をレビューしたり、モニタリングしているデータの意味を推測したり、従来の「テスト」とはちょっと異なる活動になるはずです。
そういった「ちょっと異なる活動」が増えていくことで、「テストをする以外の活動を増やす」ことが可能になってきます。

しかしながら、「意見を言うだけのご意見番」にならないように注意も必要です。
例えば仕様検討という活動で品質保証活動を行う場合、仕様矛盾を指摘するぐらいであれば、専門知識がなくてもできるかもしれません。
しかし、「ユーザーの利用データを見る限りXXXしたほうがいい」というような周囲が意思決定しやすい情報を踏まえてフィードバックができるなら、「意見を言うだけの人」から「データをもとにフィードバックできる人」に変わります。
その活動の価値がより高まります。

◇テスト自動化が「当たり前」にならないのはなぜか

テスト自動化は新しいテーマではありません。
テスト自動化フレームワークは、世の中にたくさん登場していますし、世界を見渡せば、30年以上前からソフトウェアテストツールを販売する企業もあります。

しかし、テスト自動化が「当たり前」になっているかといえば、そうでもない気がしています。

実際にテスト自動化に関わる友人や、自動化ツールを販売する方から聞いた情報をもとに、その要因を推測すると、いくつか課題が見えてきました。

・自動化スキルの問題

海外のイベントに参加したときに、「Automator」という言葉を何度も聞きました。
テスト自動化を専門とするエンジニアの総称のようです。
QAエンジニアからのキャリアアップとしてAutomatorは注目されているようでした。

筆者は、国内で次世代品質組織の立ち上げに取り組んだ経験がありますが、たくさんの人材データベースをのぞいてみても、テスト自動化の経験や知見があるエンジニアは少数です。
採用をかけてもなかなか見つからず、育成するにも時間がかかるので、組織の立ち上げには本当に苦労しました。

・開発手法の問題

テストを実施する側から見ると、後半のテストフェーズにまとめてテストするのは効率的です。
しかし、この方法だと、成果物を最後の最後のフェーズでチェックするので、問題や課題の発見を軸として考えれば非効率だと言えます。

さらに、リリースが1回こっきりのプロジェクトだと、リリース後、運用フェーズに入るため、テストを自動化するメリットがあまりありません。
自動テストは繰り返し実行することで効果を発揮します。
一方で、繰り返さないのであれば、マンパワーを生かして一気にマニュアルでテストするほうが効率がよいとも言えます。

・自動化の難易度

筆者はAIを活用したノーコード・ローコードによるテスト自動化サービスmabl（メイブル）の仕事もしているのですが、mablは海外のツールですので、海外の導入事例を調べたことがありました。
そのときにわかったのは、海外ではテスト自動化が「当たり前」になってきており、大企業であっても、たくさんの自動テストを運用しているようでした。

よって、彼らはさらなるコスト削減や運用改善のために、自分たちの自動テストをmablのようなサービスにマイグレーションして成果をあげようとしています。
自動化にかかるコストの半減も夢ではないからです。

しかし、日本国内を見ると、多くの企業にはたくさんのマニュアルテストがあり、自動化する場合は、マニュアルテストから自動テストを作成しなければなりません。
ただでさえ難しいテスト自動化の難易度が、さらに数段階上がってしまうため、失敗する現場もたくさんあるように思います。

・コスト削減 VS スピードへの投資

海外の企業は、テスト自動化を「スピードへの投資」と捉えています。
テスト自動化は彼らにとってスピードのための必要経費なのです。
しかし国内では「自動化」という言葉がそう連想させるのか「コスト削減」を意識しがちです。

将来はAIの力でさまざまなものが自動化されるかもしれませんが、現状を見るとその道のりはまだ遠く感じます。
ノーコード・ローコードであっても、「テストを作成し運用する」のには変わりがないため、安易にコスト削減できるとは限りません。

◇テスト自動化のコスト分解

コストの話が出たところで、誰もが気になるテスト自動化のコストにも触れておきましょう。
コストにもいろいろあるので、もう少し分解が必要です。

・環境構築コスト： テスト自動化をはじめるときに必要なイニシャルコスト
・自動テスト作成コスト： いきなり全部を自動化するのは難しいため、まずは全体の10％などの目標を立てて継続的に実装するのがおすすめです。
・自動テスト環境メンテナンスコスト：ブラウザアップデート、ライブラリ更新、機能追加などの運用コスト
・自動テストのメンテナンスコスト： 日々リリースされていく機能に自動テストが追随するための運用コスト

mablのようなSaaS型サービスの場合、イニシャルコストはほぼかかりません。
よって、いくつかの設定を行うだけですぐにテスト自動化に取り組めるのが特徴です。

自動テスト作成コストは、ノーコード・ローコード型のサービスが登場したため格段に下がってきていると言えます。
もちろんテストコードをプログラミングするほうがはやい場合もあるかもしれませんが、シナリオ形式の自動テストは、人間の単純な操作を繰り返し実装する作業です。
単純で繰り返す仕事なら、機械に任せてしまうのも手です。

メンテナンスコストは、見落としがちなコストです。
新機能のたびにテスト追加が必要でしょうし、環境のアップデートも継続して必要です。
サービスやシステムの変化に合わせて自動テストのメンテナンスも必要です。
初期段階ではテストを安定実行するためのコストも考慮しておく必要があります。

大きくサービスを利用するか自前で実装するかと判断が分かれますが、mablの導入事例を見ていると、うまくサービスを活用されているお客さまのケースだと

・イニシャルコストは40%削減
・メンテナンスコストは75％削減
という数値が出てきています。
テストコードを事前に実装するのと比べて、イテレーションやスプリント型の開発であれば、期間ごとにリグレッションテストを数回実行するだけで元が取れる試算もあるようです。

注意したいのは、コストはゼロにならないという点です。
うまくやれば、ある程度まで下げられますが、継続的にテストを作り、メンテナンスしていくため、コストはゼロになりません。

◇まとめ

本記事では、テスト自動化が求められる時代背景や、アジャイルテスティング、自動化の課題について解説しました。

開発するシステムやサービスによって開発手法は変わってきますが、徐々にメインストリームになりつつあるアジャイル開発において、アジャイルテスティングは避けては通れないテーマです。

次回は、この時代背景を踏まえた「テスト自動化戦略」を探っていきます。テスト自動化を成功させるための計画を立て、優先順位を決め、具体的なアクションを考えていきましょう。

■海外ニュース

□データベーステストの基本

https://searchsoftwarequality.techtarget.com/tip/Tips-for-database-testing-from-the-cloud

こちらは「searchsoftwarequality.techtarget.com」に掲載されていた内容となります。
データベーステストについて、述べられていましたので、ご紹介したいと思います。

◇初めに

データベースは通常、移行、保護されますが、IT組織がデータベースを完全に放棄することはめったにありません。

したがって、データベースのテストは重要なタスクになるはずです。
組織は専門のデータベーステスターを雇う必要はありませんが、チームは特定の手法を使用して、アプリケーションの統合とともにデータベースの正確性と一貫性を検証する必要があります。

たとえば、データベーステストは、アプリケーションがコレクションからタイムリーな応答を取得することを確認するのに役立ちます。
データは安全で正確であり、常に利用可能でなければなりません。
そこで、データベーステストが役立ちます。

◇機能データテスト

機能データベーステストは、データベースがエンドユーザーの観点から機能することを確認します。
つまり、このようなテストでは、アプリケーションが期待どおりにデータを保存し、値を変更して保存しても失敗しないかどうかを確認します。
テスターは、チームがすでに実行しているテストにデータベーステストを組み込むのが難しいと感じるべきではありません。
データベース検証ポイントを追加するには、最小限の編集が必要です。

データの機能テストの別の例には、ユーザーが無効なデータを入力したときにアプリケーションとデータベースがどのように応答するかが含まれます。
チームは、文字フィールドのオーバーロードを含むテストを設定して、データが修正または破損されないことを確認できます。

・最大50文字を受け入れる姓のデータフィールドに50を超える文字が入力されているか、句読点が正しくない場合
・ユーザーが英字の代わりにいくつかの数値を入力した場合

テストは、ユーザーがこれらの問題に遭遇する前に、これらの問題を解決するのに役立ちます。

QAの専門家は、アプリケーション側からテストを実行しますが、データベース自体を操作したり、データベース自体をテストしたりすることもできます。
テスターは、基本的なSQLスキルとデータベースへの表示専用アクセスのみで、データベース自体とアプリケーションの両方でデータ列と値が適切に表示されることを検証できます。

◇ネガティブテスト

ネガティブテストは、データベーステストのもう1つの重要なコンポーネントです。
これらのテストは、アプリケーションのエラーメッセージング機能を評価するだけでなく、不良または無効なデータがデータベースに到達しないことを確認します。
たとえば、ユーザーが無効なデータ文字を入力した場合、アプリケーションは入力をエラーとして示し、このデータがデータベースに保存されないようにする必要があります。

テスターは、比較的単純なSQLステートメントを開発して、データをアドホックな方法でクエリし、不規則性をチェックできます。
テスターは、トリガーを実行し、ビューとインデックスを検証することもできます。

QAの専門家は、アプリケーションの保存、キャンセル、削除タイプの機能のテストに時間を費やす必要があります。
また、データを変更してから、入力を保存またはキャンセルして、アプリケーションの応答を確認する必要があります。
このテストのほとんどは、アプリケーションを介して実行できます。
可能な場合はデフォルト値を確認することが重要です。

データに名前、住所、その他の個人を特定できるデータが含まれる場合は、アクセント付きの文字やその他の特殊文字を含めてください。チームは、データベースが文字を理解できないために、アプリケーションが表示、計算、または保存でエラーを引き起こさないことを確認する必要があります。
アポストロフィを付けた姓のような単純なものを使用すると、データベースがロックされ、アプリケーションがクラッシュする可能性があります。

◇データの整合性のテスト

チームのデータベーステスト機能と理解が深まるにつれて、次の論理的な包含はデータの一貫性と統合テストです。
このタイプのテストにより、QAの専門家は、データベースでデータがどのように編成され、保護されているかについて詳しく知ることができます。

データベースは、多くの場合、無効なデータが保存された初期開発フェーズから、または無効なデータが保存ではなくアプリケーションエラーをもたらすはずだったネガティブテストから、ジャンクデータを保存します。

そこに到達した方法に関係なく、問題のあるデータは注目に値します。
データ整合性テストはそのデータを識別でき、このプラクティスは厄介なパフォーマンスの問題、アプリケーションの不整合、および潜在的な機能の問題に役立ちます。

重要なデータベース整合性テストオプションの1つは、データを正常にロールバックできることを確認することです。
データのロールバックは、アプリケーションとデータベースの間に切断が存在する場合に発生します。
これは、データベースが不良データまたは無効なデータを保存する原因となる分離です。
テストの結果、チームがこの問題に気付いた場合、無効なデータがなくてもデータベースがクリーンな状態に戻ることが保証されます。

■最後に

今回は、国内ニュース、海外ニュース3記事を取り上げてみました。
次週も、ソフトウェアテスト、テスト自動化に関するニュースをご紹介したいと思います。

最後まで見て頂き、ありがとうございました。

ソフトウェアテスト自動化の教科書　〜現場の失敗から学ぶ設計プロセス

詳細はコチラをクリック！

SQL 第2版 ゼロからはじめるデータベース操作

詳細はコチラをクリック！