ID:60855さん

◆プロジェクト概要 前段として、自社パッケージソフトでEC製品を取り扱っていました。 EC製品ですのでもちろん、テストはブラウザ上で実施され、セレニウムを主に用いた自動テストが実行されていたそうです。 しかし、定期的な実行の度、自動テストが本筋と関係ないエラーを吐き続け、実行よりも修正の方に工数を取られていました。 その対策として、開発側で実行されていた自動テストを破棄し、QA側で手動実行するよう依頼されました。 また、このテスト内容はお客様より「実行しなければ修正パッチを当てさせない」と厳命されているものでした。 ◆担当 社員の担当者は私のみであり、協力会社のテスターメンバーが4~5人当てられました。 協力会社のテスターはテストを実行するのみであり、手動実行のためのテストケースや資料の作成、エラー原因の追究や解消など他の業務をすべて担当しました。 ◆課題とそれに対する取り組み 1.エラーの原因調査と対応 「自動テストではエラーになる」とのオーダーでしたが、それ以上の情報を得られなかったため、自分一人でエラーの調査から実施しました。 お気づきかとは思いますが、すべての原因は自動テスト用の環境で開発者が自分勝手な設定変更を行った影響でした。 環境に影響を与えないように利用してもらうお願いや、設定変更後は戻すなどのお願いもしましたが改善はありませんでした。 結果として、テストに利用するすべての正しい設定を網羅し、テスト実行直前に確認し、変更された点があればすべて強制的に戻す条件を取り付けることで、テスト実行の正常化へ漕ぎつけました。 2.実行速度の計測と予実管理 本定期テストは前述の通り「実行しなければ修正パッチを当てさせない」と厳命されているものであり、テストの完了はリリース日へ影響します。 都度テストの実行前の設定修正や、テスト実行中に行われる開発側の設定変更による影響によって、一概にテスト完了までの工数は安定しませんでした。 結果として、テスト用の設定分離や、問題があった際の平均的な解決工数を求めることで、予実を安定させ、迅速なリリースへ繋げました。 3.定期実行のための手離れ この定期テストは月に一度実行されるものでした。 しかし、本来の業務は他にもあるため、本プロジェクトに付きっ切りになることはできません。 そのため、協力会社のテスターのリーダーに任せられるよう、私の業務内容やチェックリストなどをさらにブラッシュアップし委譲することで、私の手から完全に離すことができました。 ◆工夫した点 本案件では、始めて私が単独で、複数の開発チームと調整を行ったプロジェクトでした。 開発チームはテストや品質に関心が薄く、原因調査や修正可否の確認が滞り、難航した思い出があります。 ルールもなかなか守られず、事象の解決もままなりませんでした。 そこで、こちらを主体にした条件を新たに提示して動きました。 それまでは主に受け身で消極的な動きでしたが、本プロジェクトからは積極的でアグレッシブに関わるスタイルになれたと考えています。

◆プロジェクト概要 前段として、自社パッケージソフトでEC製品を取り扱っていました。 ただ、パッケージソフトとは言えないほど製品が多様化してしまい、個社ごとに評価やテストを実施しなければならない状況にありました。 その状況の最中、法令改正である軽減税率の対応を迫られることとなります。 ◆担当 メンバー構成は、担当者は私を含め社員2名で、各々に協力会社のテスターメンバーが4~5人当てられました。 なお、協力会社のメンバーは、契約料金の問題から法令対応直前に全員入れ替えられ、練度の低いメンバーのみとなりました。 社員の業務は、法令対応の開発内容のレビューと、テストケースの作成、テストのプロジェクトマネジメントが主になります。 ◆課題とそれに対する取り組み 1.法令の理解 日本では初めて実施される法令対応であり、弊社のみならず日本中が大変な時期でした。週次で政府のQ&Aも更新され、弊社でも判断に困る点は問い合わせを行っていました。 開発内容が法令順守できるのか、運用に問題ないのかを判断するためには、自身にも相応の理解が必須ですし、開発者以上の会得が必要です。 そのため、法令内容とQ&Aを確認し、お客様の商品をリストアップして対応が必要なユーザーや商品を洗い出しました。また、日本では初の法令ですが、海外ではすでに施行されている国があります。それらの情報や世論を集め、今後数年、数十年先の展望を予測し、それらをまとめて担当者へ共有しました。 2.製品の機能とユーザーの商品を理解していない開発者 さまざまなお客様の商品を取り扱うため、製品の機能は複雑化していました。 開発者は各機能、またはユーザーごとに縦割りで担当する状況だったため、製品の全体像をうまく理解できていない状態でした。 そのため、1で記載したように、ユーザーごとの状況や、機能を広く横断した視点から指摘を行いました。 3.短納期と最高難易度ユーザーとメンバーの練度不足 テストの実施は、パッケージソフトとしてのテストと、各ユーザーごとのテストの大きく2段階ありました。パッケージソフトなのに各ユーザーごとに行わなければならないのは、特異な機能を利用するユーザーが複数存在していたためです。 私の担当は、それまで幾度か担当してきたからと、全ユーザーの中でも最高難易度のユーザーでした。 さらに難易度が上がったのは、協力会社の共に担当してきたメンバーが全員いなくなったため、そのサイトに慣れている人がいなくなったことです。そもそも、ECサイトというものに慣れていないメンバーになってしまいました。 そのため、私はテストケースの作成以外にも、特異な機能の数々のオペレーションやテスト方法の資料を作成し、OJTも組み合わせることで新規メンバーでもテストケースの消化速度を向上させ、絶対にリリースを延ばすことのできない法令対応のテストを完了しました。 余談ですが、最高難易度ユーザーは、バージョンアップの度に開発は多くの不具合を出し過ぎていて、ユーザー自身もテストを実施していました。 そのユーザーからテストの実施後、「不具合が何もでてなくて逆に怖い」とのお言葉をいただきました。また、しばらく経っても軽減税率対応周りでは不具合が出てこなかったそうです。 ◆工夫した点 ・法令とユーザーの理解 今まで開発者が法令やユーザーの業務に無頓着な機能をリリースし続けており、関係各所に働きかけて、今回初めて評価チームが開発内容のレビューを行うようにしてもらった。 ・絶対に締め切りを延ばせない状況で、新規メンバーの実行速度を向上させた点。 突然高難易度のユーザーにアサインされることはなかったので、今まで存在しなかったアプローチで、迅速に慣れてもらう必要があった。

◆プロジェクト概要 前段として、自社パッケージソフトを自動でアップデートするアプリケーションの開発/保守へ異動しました。 異動の直前、そのアプリケーションを利用していましたが、不具合が再発するなど本当に評価をしたのか怪しい品質でした。 ◆担当 開発/保守のメンバーは6人で、役割分担は無く、全員が開発/保守を実施しています。 開発フローの改善については、私1人で実施しました。 ◆課題とそれに対する取り組み 1.形骸化/無意味な開発フロー 開発フローを確認してみたところ、当時のメンバーは誰もそのフローを守っていませんでした。その開発フローから、各々が必要だと思う箇所だけ実施している状態にありました。 また、対象の開発フローを確認すると、例えば「開発者テストを実施してから内容をレビューする」など手戻りが発生するものがあったり、「テストケースレビューの他にテスト完了レビューを行う」など不要なフローが存在していました。また、本来直列でなくてよい内容も直列にするなどフロー図が不適当な状態でもありました。 また、各フローでは何をすべきなのか、どうなればよいのかといった定義がされていませんでした。 そのため、開発フローを刷新し、手戻りの少なくなるフローへ修正、フロー図も適切な形にしました。同時に、各フローのすべきこと、できない場合の対応も定義し、しばらくの間慣れるよう声掛けをしつつ運用を行い、今日ではそのフローに則った開発を行うことができています。 2.おざなりなテストケース 開発者テストケースと評価者テストケースの2種類が存在していましたが、それぞれの定義がされておらず、開発者も評価者も同じテストを実施してOK、という状況になっていました。また、テストケースのテンプレートが同じものであり、シナリオテストや結合テストを作成し辛い状態でした。 その他、過去のテストケースがきちんと管理されていないために残っておらず、不具合が発生した時の調査が困難になっていました。 そのため、開発者テストと評価者テストの目的を定義し、評価者テストケースのテンプレートを新規に作成しました。 開発者テストと評価者テストはExcelで作成されていたのをGoogleSpreadSheetに変更し、redmineに対象のURLを入力させるようにしました。これで、redmine側でバリデーションチェックを行うことができ、テストケースが作成されていないと先に進めないようになりました。また、絶対に記入されるので、過去の不具合調査を行う時にテストケースが存在しない、といった状況にならなくなります。 3.意義の消滅した自動テスト すべての開発フローを終えた後、出荷の前日に自動テストを実施していました。これには以下の問題点があります。 ・出荷の前日に実施するので、問題があった時は確実にリリースが遅れる ・自動テストのケースが少なすぎる そのため、開発フローを修正した際に、自動テストの実施タイミングを前倒し、自動テストで問題が検知されてもリリースが遅れないようにしました。また、その自動テストを行っていた日程分をバッファとして運用することにしました。すでにこの運用変更から20回程度のリリースを行っていますが、このバッファによってリリースを遅らせずに済んだことは何度かあります。裏を返せば、していなければ何度かリリースは遅れています。 自動テストのケースについては、自動テストの目的がなかったので、それを定義することから行い、当時に比べて現時点では3.6倍のケース数に増やしました。 ◆工夫した点 ・評価者テストケースのテンプレート シナリオテストを作成する際、細かな手順を0から記載するのが面倒で時間がかかる作業である上、人によって表現が粒度がブレてしまい漏れが発生してしまうケースが考えられます。 その問題点を解消するため、予めシナリオの大分類の手順をテンプレートとして記載しておきました。 これによって、コピー＆ペーストでテストケースの手順がほとんど完成するので圧倒的に早く、しかも人によって手順の粒度がばらけることもなくなりました。

◆プロジェクト概要 自社のCI/CDに利用しているオンプレサーバーが老朽化しHDDが破損気味になり、よくダウンするようになったため、クラウド（AWS）移行を行いました。 ◆課題とそれに対する取り組み 1.サーバーやMWの知識に乏しい 紆余曲折あり、私はチームの中で最もサーバーやMWに対する知識が薄い人でした。 そんな私に白羽の矢が立ったのはおそらく、「問題に鼻が利く」QA出身であることと、なんやかんやどうにかできてしまうからでしょう。 聞きかじったサーバーやMWの知識をフックに、ネットやAIに確認しながら対応を進めました。 一部の模様は以下Qiitaに載せています。 https://qiita.com/Syahu_Writer/items/48111f1b5a1e5d0538fd 2.CI/CD以外にも利用している 自社のCI/CDに利用しているのですが、それ以外にも弊チームで利用しているredmineなども入っていました。 CI/CDもJenkinsを利用していますが、弊チームで利用している自動テストのジョブも含まれています。 オンプレサーバーはいつ壊れてもおかしくない状態だったので、リスクを元に優先順位を決めて対応を進めました。 3.正を求める CI/CDは、基本的に他チームが利用しているため、弊チームでは正しく動作しているのかが判別できませんでした。 しかし、判別できないままではリリース物に問題が生じてしまい、一大事になります。 そのため、CI/CDのパイプラインを優先してクラウド側に作成し、オンプレサーバーと並行稼働させて比較することで、正を担保しました。 ◆工夫した点 何よりも「リスクを低減/排除する」ことを念頭に実施しました。 ・いつオンプレサーバーが壊れてもいいように、すべてのファイルや設定をバックアップする ・CI/CDの信頼性を担保する方法を考え、実行する ・「稼働したらOK」ではなく、しばらく稼働後の様子を見続けてから判断を下す など実施しました。

◆プロジェクト概要 前段として、オンプレ上にある自社パッケージソフトを自動でアップデートするアプリケーションの開発/保守を担当しており、約600社程度の環境で利用されていました。 そして、他のチームではオンプレ上の自社パッケージソフトをバージョンアップするツールの新たな開発/保守が行われていました。 つまり、既存のアプリケーションに同じ機能を持たせれば楽ではないか、という白羽の矢が立ったため、それらの統合プロジェクトが実施されました。 ◆担当 開発/保守のメンバーは5～2人で、全員で担当していました。 プロジェクトの開始時点は5人でしたが、中途で3人抜け、残り2人で対応を進めています。 ◆課題とそれに対する取り組み 1.業務内容が変化していく中での要件定義 もちろん初めに要件定義からするのですが、相手方のツールは開発されてから日が浅く日々改善を施している状態でした。 つまり、元となる業務内容がだんだんと変化していく前提で要件定義から始めないといけません。 結果として、弊チームは「相手方の業務内容をすべて理解した上で、本来あるべき業務をこちらから定義し、その状態を正として要件定義から実施する」という手段を用いました。 それ相応の負荷がありましたが、相手方の業務を先導する形で話を進めることができ、業務の変更に強烈に振り回されることはありませんでした。 2.たった一人のQAの矜持 5人のチームでしたが、1人は新卒、3人は開発出身であり、QAを専門としているのは私1人でした。 そのため、自分の役職を評価面に強く色を出して開発にあたりました。 周りは「良いと思ったら突っ走る」傾向が強かったため、 ・その設計では小さいが危険性がある。全員が理解して合意しているか ・デグレード発生時のリスクがこの手法では大きい。対抗策か別案での回避を検討すべき ・この実装ではシステムテストでエラーが起きるから修正が必要 など、ブレーキをかけるだけでなく、予後が円滑になるように務めました。 3.人数低下による対応の圧迫 初めは5人で始まったプロジェクトですが、現在2名にまで低下しています。 本プロジェクトは、プロジェクトと銘打ってますが、通常業務に上乗せで走っているプロジェクトになります。 そのため、保守・サポート業務による差し込みの影響で大きく工数を削られていました。 その際、私がすべてのサポート業務を請け負うことで開発への差し込みを0にし、リリースを間に合わせました。 また、速度を出すために開発と並行して、私はテスト設計を行うことで、実装完了後のリードタイムを低減しました。 ◆工夫した点 ・止めるだけが役割でないQA QAとは一般に「セキュリティゲート」として、つまり関所、開発を堰き止める印象が強いです。 今回は「流れを止めない」「正しい流れに誘導する」「開発後の流れをより早くする」ように動いてみました。 また、作成したテストも、優先度や重要度の設定を行い、エラーを無視してよいものを事前に決定することで、リリースする方向へ後押ししました。 ・QAと開発を掛け持つ人だけができるテスト作成 今回、機能が完成する前にテストケースを作成しました。 「できる！」と考えて実行し、実際に完成しましたが、思い返すとこのテスト設計技法は世に存在しませんでした。 近しいもので言えば「テスト駆動開発」と「チェックリストベースドテスト」ですが、そのどちらにも合致しません。