code refactoring what you need know about it
コードリファクタリングを理解する：テスターの視点
「リファクタリング」という用語は、主に必要なコードのクリーンアップ/再設計を示すために使用されます。
このチュートリアルでは、リファクタリングの定義を理解し、コードリファクタリングの必要性について説明し、さまざまなプロジェクトチームメンバーに対するリファクタリングコードの影響を確認します。また、最も重要な質問に対する回答についても説明します– テスターとして、なぜリファクタリングについて知る必要があるのですか？
さらに、概念を明確にするために、いくつかのケーススタディについても説明します。
学習内容：
リファクタリング入門
まず、実際にリファクタリングとは何かを理解しましょう。
リファクタリングは、基本的に、既存の機能を維持しながらコードやデータベースを改善するための実践またはプロセスです。アイデアは、非効率的で過度に複雑なコードを、より効率的な、できればより単純で簡単なコードに変換することです。
コードのリファクタリングも、アジャイルソフトウェア開発アプローチに従うことで、より多くのチームで勢いを増しています。プロジェクトチームは、多くの場合、新しい機能を実装したり、既存の機能やコードの機能をクリーンに拡張したりする時間が限られています。理解と保守が容易なコードは、反復の期限を守るのに確かに大いに役立ちます。
コードリファクタリングの必要性
アプリケーションまたはモジュールの元の機能を維持している場合、なぜリファクタリングさえわざわざするのかという疑問が生じます。そうですね、特定のモジュールまたはコードの一部をリファクタリングする必要がある理由はたくさんあります。たとえば、次のようになります。
- コードの臭い
- 技術的負債
- アジャイルソフトウェア開発アプローチなど。
これらの点については、次のセクションで詳しく説明します。
＃1）コードの臭い：
食べ物の匂いがし始めたら、それが悪くなっている可能性が高いことを示していることは誰もが理解できます。これはコードにも当てはまります。コードの臭いは、コードに非常に深刻な問題が存在する可能性があることを示しています。
以下は、いくつかの一般的なコードの臭いです。
- 冗長または同一のコードの存在。
- コードの残りの部分で使用されていない宣言された変数。
- 過度に複雑なコード設計。
- 実行が少なすぎて、定義されたクラスの存在を正当化しないコードクラス。このようなクラスは、レイジークラスまたはフリーローダーとして知られています。
- 分解されて単純化される可能性のある条件とループが多すぎます。
- コードの一部を変更するには、他の場所でも変更を実装する必要があるようにコードを構築します。
コードの臭いは、時間の経過とともに明らかになります。アプリケーションまたはシステムが成長するにつれて、最終的にこれらのコードの臭いがコードの開発、保守、さらには極端なシナリオでのシステムのパフォーマンスに影響を及ぼし始めます。
＃2）技術的負債：
ソフトウェアを開発している間、限られた時間と利用可能なリソースの間に、私たちはしばしば望ましい結果を達成するために近道をとることがあります。
既存のモジュールに追加する必要がある機能について考えてみます。話し合いの後、チームはこの機能を追加するために2つのアプローチを絞り込みます。アプローチAは、2回のスプリントで配信され、承認された長期的なアプローチになります。アプローチBの配信には、わずか5日しかかかりません。これは、モジュールを短期間で保守するように設計された、厄介なハードコードされたハックです。
チームが限られた時間内に機能を提供するよう圧力をかけられている場合、チームは今のところアプローチBに従い、将来のバックログにアプローチAを追加することに同意する可能性があります。これを行うことにより、このチームは自分たちのために技術的負債を作成しました。
簡単に言うと、ソフトウェア開発における技術的負債とは、適切な修正を実施したり、「正しい方法」で物事を行ったりするために必要な追加のやり直しやオーバーヘッドを指します。
レガシーシステムは、時間の経過とともに莫大な技術的負債を獲得する傾向があり、その結果、アプリケーションが障害の影響を受けやすくなり、サポートと保守が困難になる可能性があります。
続きを読む=> 技術部とは
＃3）アジャイルソフトウェア開発アプローチに従う：
アジャイルソフトウェア開発アプローチは、インクリメンタル開発を提唱しています。クリーンで、適切に構造化され、保守が容易なコードがなければ、チームが反復ごとに既存のコードを拡張することはできません。適切なリファクタリングなしでコードが変更された場合、コードの臭いや技術的負債の原因となる可能性があります。
この関係を下の図に示します
おすすめの読み物 => トップコード分析ツール
QAがリファクタリングについて知る必要があるのはなぜですか？
このチュートリアルでこれまで説明したことは、コーディングに関連しているようで、開発者が心配すべきことのように見えます。
それでは、なぜソフトウェアテストヘルプコミュニティでこの無関係な概念について議論しているのでしょうか。 この質問への回答については、このチュートリアルの残りの部分を読み続けてください。
＃1）ユニットテスター/開発者向け
コードのリファクタリング中に、新しいコードが挿入されると、古いクラスが更新され、新しいクラスが追加され、既存の単体テストが失敗する可能性があります。さらに、レガシーシステムの場合、単体テストがまったく実装されていない可能性があります。ほとんどの場合、この新しい単体テストは最初から作成して設定する必要があります。
＃2）テスター向け
機能がリファクタリングされている場合（新しい機能を追加していないことを考慮して）、必要な変更が行われた後も、エンドユーザーの機能の大部分は同じままである必要があることを理解しています。
- テスターとして、コードのリファクタリングは大まかに=詳細なテスト+回帰テストに変換されます。詳細なテストでは、すべての機能が以前と同じように機能していることを確認するために、既存のすべてのユーザーフローを含める必要があります。 回帰試験 モジュールのアップグレードによって他のモジュールの機能が意図せずに損なわれないようにするには、アプリケーション全体（または影響を受ける領域）を把握する必要があります。
- ユーザー受け入れテストは重要であり、ビルドがリリースの準備ができていると宣言する前に、これらのテストに合格する必要があります。
- さらに、負荷テストなど、その他の必要なテストは、 セキュリティテスト 必要に応じて、なども実装する必要があります。
＃3）自動化テストエンジニア
コードのリファクタリングにより、機能的および非機能的な自動化スクリプトが失敗する可能性があります。
これは、次の理由で発生する可能性があります。
- リファクタリング作業の一環としてページオブジェクトが変更され、Selenium自動化スクリプトがページオブジェクトに依存している場合、スクリプトは失敗するため、更新する必要があります。
- マイナーな変更があった場合、リファクタリング中に追加または削除されたものをリダイレクトし、既存の自動化スクリプトは失敗し、更新する必要があります
機能自動化テストは、機能が安定したときにのみ設定することをお勧めします。そうしないと、機能が進化するにつれて多くのやり直しが発生します。
自動化テストの開発者である自動化テストエンジニアは、開発者のように考え、クリーンで保守しやすいコードの作成を目指す必要もあります。 IntelliJ IDEA、EclipseなどのほとんどのIDEには、簡単に参照できるように、一般的に使用されるリファクタリング方法を備えた組み込みのリファクタリングメニューが含まれています。
以下は、IntelliJ IDEA（Community Edition）のリファクタリングメニューのスクリーンショットです。
Webサービスは経験豊富な人のための質問と回答をインタビューします
＃4）テストリード/ QAリードの場合
- テストリード/ QAリードは、開発者、製品アナリスト、さらには利害関係者を含むチームの他のメンバーと協力して、そのようなプロジェクトのテスト計画が慎重に行われるようにする必要がある場合があります。
- 既存の機能を理解することが重要です。既存の機能に基づいて、ビジネスケース、ユーザーフロー、およびユーザー受け入れテストを文書化する必要があります。リファクタリングされたコードをテストするときは、影響を受ける領域の回帰テストとともに、これらすべてのシナリオを検証する必要があります。
- テストアプローチを計画する際は積極的に行動し、 テスト計画 。複数のテスト環境または新しいテストツールの要件が予想される場合は、テストフェーズの開始後の遅延を防ぐために、要求を早期に送信してください。
- プロジェクトチーム以外のメンバーやエンドユーザーをテストに参加させることを躊躇しないでください。
ケーススタディ
ここで、直接取り組むか、間接的に貢献する機会があった実際のケーススタディについて説明します。
ケーススタディ＃1
仕事： モジュールをリファクタリングして、ハードコードされた値を変数に置き換え、新しい自動化された技術文書生成ツールのコメントを追加します。
課題 ：大きな課題はありません。このモジュールは新しく、機能要件とユーザー受け入れ要件、ユーザーフロー、テストケースが文書化されていました。ユニットテストは、最初の起動時に設定されました。
テストアプローチ ：リファクタリングされているモジュールと比較的既知の影響を受ける領域のテストケースが実行されました。リリース前に欠陥が報告され、解決されました。
ケーススタディ＃2
仕事 ：アプリケーションのスケールアップを容易にするために、既存のストアドプロシージャをリファクタリングします。
このシナリオのストアドプロシージャは、アプリケーションが10未満の同時セッションを持つ内部アプリケーションとしてストアドプロシージャを使用しているという要件を念頭に置いて、数年前に設計された古いストアドプロシージャでした。
現在、同社はこのアプリケーションをサービスとしてのソフトウェア（SaaS）として販売したいと考えており、当初は300の同時セッションが予想されていました。
チームはいくつかの初期負荷テストを行い、25の同時セッションの負荷でシステムが壊れると結論付けました。チームはコードを確認し、アプリケーションをスケールアップして最大500の同時セッションを中断することなくサポートできるようにする既存のコアストアドプロシージャをリファクタリングすることを推奨しました。
このストアドプロシージャで特定されたいくつかの問題は、単一のクエリ内の複数のサブクエリ、テーブルの代わりにビューを使用した大量結合、特定の列を選択する代わりにselect *を使用するなどでした。これらのコーディングの問題により、アプリケーションはそれよりも多くのデータをフェッチしていました本当に必要だったため、アプリケーションの速度が低下し、最終的にはクラッシュしました。
課題：
＃1）プロジェクトマネージャー/製品アナリスト
- 要件の収集 –このストアドプロシージャはレガシーコードであったため、モジュールが最初に設計されたとき、ドキュメント化された要件はありませんでした。また、過去数年間に行われた反復では、モジュールに追加またはモジュールから削除されたビジネスルールとロジックを示す変更ログはありませんでした。
- プロジェクトスケジュール –要件が明確に定義されておらず、コードの依存関係がまだ完全に特定されていないため、暫定的なスケジュールを伝えることが困難でした。
＃2）開発者向け
- 明確な要件とビジネスルールの欠如。
- 機能を失うことなくコードをクリーンアップします。
- 影響を受ける領域やコードの依存関係が不明です。
- 具体的な開発時間の見積もりを提供できません。
- 新しいユニットテストを作成する必要があります。
＃3）テスター向け
- 明確な要件とビジネスルールの欠如は、テスト計画に影響を与えます。
- 未知の影響を受ける領域は、特に回帰テストのテスト計画に影響を与えます。
- 具体的なテストの見積もりを提供できません。
＃4）利害関係者
- 明確に文書化された要件やユーザーフローの欠如+厳しい締め切り=失敗のリスクが高い。
リスクを軽減し、課題を回避するためにチームが従うアプローチ ：
（i）チームは、要件を収集するために共同アプローチに従いました ：プロジェクトマネージャー/プロダクトアナリストおよびテスターは、内部エンドユーザーと緊密に連携して、主要な機能とユーザーフローを理解および文書化しました。
開発者はまた、コードを確認し、要件ドキュメントに関連情報を追加しました。これはスプリント開始日の前に行われました。
（ii）実装されている変更をテストするために、代替テスト環境が作成されました ：これらの環境をガンマとファイと呼びましょう。 Gammaには古いコードがあり、Phiには常に最新のリファクタリングされたストアドプロシージャがデプロイされています。
2つのテスト環境を並行して実行し、アプローチの前後でほぼ再現することで、チームはこれら2つのテスト環境の動作を比較することで、より詳細で探索的なテストを実行でき、考えられるバグを特定できました。
チームは、スプリント開始日の前に提供された代替テスト環境の要件を提供しました。
（iii）早期のテストに関与するエンドユーザーと利害関係者 ：明らかな問題は早期に発見され、報告され、チームが必要な修正を展開してテストするための時間を増やすことができました。
（iv）終了基準を定義し、それを順守する： 終了基準は、初期の計画段階で定義されました。80％のユーザーフローがテストされ、重大なバグは未解決ではなく、リリース前に関係者からデモとサインオフが行われました。
（v）暫定リリース日の設定： リリース日を調整し、チームが共通のエンドポイントに向けて作業するように動機付けます。プロジェクトの範囲に基づいて、チームがプロジェクトを実行するのに十分な時間を確保するために、通常の2週間のスプリントではなく3週間のスプリントに従うことがチームによって推奨されました。
結論
要約すると、コードのリファクタリングは、モジュールの機能を変更せずに、モジュールの設計をクリーンアップ/簡素化するプロセスです。リファクタリングプロセスは、コメントの追加、正しいインデントの追加、静的変数の削除などの単純なものにすることも、複雑なレガシーシステムの場合は複雑にすることもできます。
コードの臭い、技術的負債のため、またはアジャイルソフトウェア開発アプローチに従うことにより、特定のモジュールまたはコードの一部をリファクタリングする必要がある場合があります。
テスターにとって、コードのリファクタリングは、大まかに=詳細なテスト+回帰テストに変換されます。
既存のすべてのユーザーフローをテストして、すべての機能が以前と同じように機能しているかどうかを確認するには、詳細なテストが必要です。モジュールのアップグレードによって他のモジュールの機能が意図せず破損していないことを確認するには、アプリケーション全体（または影響を受ける領域）の回帰テストが必要です。
テストリード/ QAリードは、開発者、特にレガシープロジェクトの製品アナリストを含むチームの他のメンバーと協力する必要がある場合があります。テストアプローチとテスト計画を計画するときは、積極的に行動してください。複数のテスト環境または新しいテストツールの要件が予想される場合は、テストフェーズの開始後の遅延を防ぐために、早い段階で要求を送信してください。
著者について： この有益なチュートリアルはNehaBによって書かれています。彼女は現在、品質保証マネージャーとして働いており、社内およびオフショアのQAチームの指導と管理を専門としています。
コードまたはモジュール/アプリケーションのリファクタリングを含むやりがいのあるプロジェクトに取り組んだことがありますか？もしそうなら、私たちの仲間のテスターが学ぶためにコメントセクションであなたの経験を自由に共有してください。
推奨読書
- 最高のソフトウェアテストツール2021 (QAテスト自動化ツール)
- TOP 40静的コード分析ツール（最高のソースコード分析ツール）
- ユニットテストを成功させる秘訣-開発者は自分のコードをどのようにテストしますか？
- 開発者とテスターのためのトップ10の最も人気のあるコードレビューツール
- ソフトウェアテストテクニカルコンテンツライターフリーランサーの仕事
- PrimereBookダウンロードのテスト
- Androidアプリケーションをテストするための11の最高の自動化ツール（Androidアプリテストツール）
- 単体テスト、統合テスト、機能テストの違い