私にはスタートだったの、あなたにはゴールでも〜メンテナンス（保守）テスト
良い子のみんなー！
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡
毎日、蒸し暑いけど本格的にビールが美味しい季節になってきたよね。
今回はテストタイプ、テストレベルからハミゴにされたメンテナンス（保守）テストのお話だよ。
（ハミゴは主に関西で「仲間外れ」の意味で使われる言語）
メンテナンス（保守）って何？
メンテナンステストは開発が終わってソフトウェアリリース後に行うんだ。
例えば本番環境にシステムをデプロイ（利用可能な状態に）した後と言うことになるよ。
ソフトウェアをリリースしたら終わりじゃなくて運用期間中にもソフトウェアの変更が発生することがあるんだ。
その変更対応をメンテナンス（保守）と呼んでて以下のソフトウェア変更などの反映して対応していくよ。
・運用で見つかった欠陥の修正
・新機能の追加
・リリース済みの機能の変更、削除など
・非機能的な品質の確保および改善
メンテナンスは、計画的なリリースと非計画的なリリース(ホットフィックス)の両方の一環として行われるんだ。
非計画的なリリースって言うのは今すぐ対処しないとお客さんから怒られちゃう（または既に怒られた）とか、世間一般の流れ的に今すぐに変更の適用が必要な場合に行うよ。
「今、話題のホットなヤツをフィックスしちゃうぜ！」って勢いの緊急リリースだね。
メンテナンス（保守）テストの概要
メンテナンスによる変更が発生した場合に変更が正しく適用されていることを評価し、システムの変更していない部分での副作用を確認するために行うのがメンテナンステストと言うことだね。
メンテナンステストはリリースの範囲に基づいて、複数のテストレベルでさまざまなテストタイプを使用することになるよ。
メンテナンステストの範囲は以下の要因で決定していくんだ。
• 変更のリスクの度合い。例えば、ソフトウェアの変更領域が他のコンポーネントまたはシステムに影響する度合い
• 既存システムの規模
• 変更の規模
メンテナンスが必要になる理由
JSTQBではメンテナンスが必要となる理由を以下のように分類されているよ。
• 変更作業:計画(リリース計画など)に従った拡張、修正や緊急変更、運用環境の変更(計画的 なOS の変更やデータベースのアップグレードなど)、COTSソフトウェアのアップグレード、 欠陥や脆弱性に対するパッチ。
• 移行作業:別のプラットフォームへの移行。この場合、新しい環境や変更になったソフトウェア の運用テストを行う。また、別のアプリケーションからのデータをメンテナンス対象のシステム に移行する場合にはデータ変換のテストを行う。
o 廃棄作業:アプリケーションの廃棄。アプリケーションやシステムを廃棄する際に長期間のデータ保有を要求されている場合、データの移行作業や保管作業のテストが必要となる。
o 長期間のデータ保管後のリストア/抽出の手順のテストも必要となる。
o 残りのサービスが引き続き動作することを確認するためのリグレッションテストが必要となる。
COTS（Commercial Off-The-Shelf）ソフトウェアは主に欧米で使われてる言い方なので、良い子のみんなにも馴染みがないと思うので、説明しておくね。
COTSソフトウェアは一般市場の多数の顧客向けに同一の規格で開発されたプロダクトの一種のことだよ。
システム開発のコスト削減などを目的に機能やシステムの一部をCOTSソフトウェアで賄っていたりするんだ。
そのCOTSソフトウェアに更新があれば、元々、動いていた他の機能への影響とかを考えてメンテナンス、メンテナンステストを行うと解説されてるんだね。
メンテナンスの影響度分析
メンテナンスリリース向けに行った変更を評価し、変更により意図した結果、変更により予想される副作用、および変更が影響するシステムの領域を識別するための分析を影響度分析と呼んでいるよ。
影響度分析によって識別した影響範囲や予想される副作用に対して既存のテスト項目を手直して実行したりリグレッションテストを行ったりするんだ。
影響度分析は、変更箇所以外の機能やインターフェースなどの他領域への潜在的な影響度に基づいて変更を行うか判断するため、変更を行う前に実施することもあるんだ。
影響度分析は、以下の場合に難しくなるとされているよ。
• 仕様が最新版でない、または存在しない。
• テストケースが文書化されていない、または最新版でない。
• テストとテストベースとの間の双方向のトレーサビリティが維持されていない。
• ツールによる影響度分析のためのサポートが貧弱であるか、まったくない。
• ドメインおよび/またはシステムの知識を持つ担当者がいない。
• 開発時にソフトウェアの保守性が考慮されていない。
情報が古い場合やトレーサビリティが確保できてない場合や知識がある人が不在だと変更箇所も曖昧になったり影響度を調べるのが難しくなるよね。
そもそも開発時に保守性を考慮してなかったら変更する箇所が複雑化したり範囲が広くなって開発自体を見直すことにも繋がるよ。
リリース前の開発段階で保守性の確認や関連ドキュメントの最新化ができているかどうかの確認も大事になるね。
ソフトウェアにとってはリリースしたら終わりじゃなくて、そこから始まると言うのを意識しておくのがいいんじゃないかな？
余談だけど転職決まった時に転職エージェントから
「おめでとうございます！」
って言われたんだけど、エージェントにとっては転職成立したらゴールだと思うけど僕にとってはスタートラインに立っただけと言う印象だったんだよね。
実際に仕事に就いて、一定期間が経過して
「転職してよかったー！」なのか？
「やべぇ、やっちまった、、、」となるか？
だと思うから転職自体は通過地点でしかないよね？
良い子のみんなもそこがゴールなのか、それともスタートラインに立っただけなのかを見極めて真のゴールを目指して突き進んでいこうね。
では、今回はこの辺で！
最後まで読んでくれた良い子のみんなー！
さんきゅーすまいる🤡
この記事が気に入ったらサポートをしてみませんか？