2020/12/5 - 読み終える時間: 2 分

Here's how Value Stream Management can give you answers faster の翻訳版です。

バリュー・ストリーム・マネジメントを利用することで、より迅速に回答を得ることができます

2020年12月3日

著者: Bryant Schuck / Product Manager for HCL Software DevOps

仕事をしていて、"顧客 XYZ の優先度の高いバグはどこにあるんだろう "と思ったことはありませんか？大きなチームのプロダクトマネージャーとして、このようなことが一日に何度も起こります。HCL Accelerate にフィルタリング機能とバリュー・ストリームの検索機能を持たせる前の他社では、私のプロセスはどのように見えていましたか？

• サポートや利害関係者から更新を求めるリクエストを受ける。
• その後、どのチームがそれに取り組んでいるかを把握しなければなりません。
• チームリーダーに連絡して、彼らのグループがアイテムに取り組んでいるかどうかを確認します。
• チームリーダーは、自分たちのチームがその項目に取り組んでいるかもしれないことを確認する。
• その後、チームの Jira ボードを見てみると、「進行中」であり、開発者 X に割り当てられていることがわかります。
• 開発者に連絡を取って、「このチケットはどこにありますか？カードをアップデートする必要があります。

大規模な、あるいは小規模なソフトウェアチームにいたことがあるならば、このようなことに慣れていないはずはありません。ほとんど通常の仕事の流れのように思えます。上記のようなインタラクションの影響を見てみましょう。開発者には長時間の中断されない時間が必要であることを示す多くの研究があります。非コンテクストの切り替えを長時間行うことで、開発者は問題に深く入り込むことができ、思考の流れを見失うこともありません。上記のステップのハッピーパスは、私の答えを得るために 30 分かかる可能性があり、その間、私は私のチームのリードと開発者に思考の列車を停止させて私のステータスだけを得るようにしました。この小さな気晴らしは私のブロックを解除しますが、彼らの貴重なサイクルを犠牲にしたり、一日の残りの時間を脱線させたりする可能性があります。

気晴らしは常に問題でしたが、私たちのほとんどがリモートで仕事をしていることが当たり前になってきているため、ますます悪化しています。肩たたきの時代は終わりました。今や 100 件の未読メッセージの時代です。ストップ! HCL Accelerate は、会議やチームメンバーへの「クイック」メッセージなしで、必要なときに必要な答えを見つけることを可能にします。バリューストリーム管理では、アイテムがどこにあるのか、誰がアイテムに取り組んでいるのか、そのアイテムが完了するまでにどのくらいの時間がかかるのか、などなど、あらゆるユーザーが求めている答えを見つけることができるように、複雑な関係性を持つようになりました。

上の画像を見ると、単純なSDLCの価値の流れがどれほど複雑なものであるかがお分かりいただけると思います。顧客やチーム（そう、私たちはシャンパンを飲みます！）と一緒に仕事をしていると、データを拡大してこれらの質問に答えることで、コラボレーションが改善され、気が散ることが少なくなったことがわかりました。どのようにしてこれを達成したのでしょうか？HCL Accelerate は、現在、迅速な検索とドロップダウンフィルターをサポートしています。シンプルでありながら、とてもパワフルです。複数のチーム、異なるステージ、異なるタイプの仕事を受けて、上司や顧客のための答えを数秒で見つけられるようになります。また、HCL Accelerateはデータに基づいて構築されており、手動での変更ではないので、あなたが与えるステータスが最も正確であることを確認することができます。複雑なデータの素晴らしいビューを取得したい方のために、DQL検索を変更していませんのでご安心ください。今回のアップデートでは、より高度なクエリでのフィルタリングも可能になります。

この記事の中で私が始めた上記の例を見てみましょう。開発者に連絡してバグフィックスの状況を確認するのではなく、HCL Accelerate の新しいクイック検索とフィルタリングを使ってみましょう。

• サポートや関係者から更新を求めるリクエストがあった場合。
• 私は、いくつかのコンテクストを収集し、フィルターを使用してアイテムを見つけます。
• 顧客向けであることがわかっているので、優先度ドロップダウンを使用します。
• また、レポートと関係があることがわかっているので、それを検索して絞り込みます。
• 見つけました！必要な情報がすべて入っていました。

この手順で何か違うことに気づく？私は自分の時間でこれだけのことができました! 今、もっと情報が必要だったり、この項目がもっと先に必要だったりすると、前置きを飛ばして貴重な会話に飛び込めるようになりました。このような情報を抽出できるようになることで、立ち話からソフトウェアに関する一般的な質問まで、すべてが変わってきます。この中で私が一番気に入っているのは、私たちはグローバルなチームなので、時差があったり、チームメンバーがサインオンしてくれたりするのを待つ必要がなくなり、仕事についての共通の回答を得ることができるようになりました。可視性を確保することは、何の問題もないように見えるかもしれませんが、ソフトウェアのトラッキングはこれまで以上に簡単になりました。チームへの気晴らしを減らし、回答の精度を高め、ステータスの更新から価値を重視した会話へと変化させ、自分の時間で回答を見つけることができます。この機能だけで、HCL Accelerate はすべてのソフトウェアチームの必需品となっています。

HCL Accelerate 2.2 は今月リリースされ、上記の新しいクイック検索とフィルタリング機能に加え、生活をより簡単にするための更なる機能強化が施されています。HCL Accelerate 2.2 の新機能と、バリュー・ストリーム管理がどのように開発の「新しい標準」をサポートするかについては、12月16日午後2時（米国東部標準時）に開催されるウェビナーでご確認ください。ご登録はこちらから。

2020/12/5 - 読み終える時間: 3 分

Your VSM questions, answered by experts の翻訳版です。

VSM に関するご質問に専門家がお答えします

2020年12月1日

著者: Allan Wagner / HCL Software Transformation Architect

バリューストリーム管理は、DevOps のホットなトピックであり、すぐになくなるわけではありません。実際、VSM の人気と使用率は来年にかけて高まると予想されています。つまり、競合他社の一歩先を行くためには、VSM に精通し、VSM が提供するメリットを活用する必要があるということです。しかし、バリュー・ストリーム・マネジメントに関するカンファレンス、ウェビナー、eBook、ブログなどが数多くある中で、このトピックに関する情報の山をふるいにかけるのは大変なことです。そこで先日、バリュー・ストリーム管理に関する質問に答えるためのウェビナーを開催しました。

今回のウェビナーでは、VSM の開始、利害関係者への説得、VSM のベストプラクティスの活用などについて、多くの質問をいただきました。バリュー・ストリーム管理の専門家であるスティーブ・ブーン、アル・ワグナー、スティーブ・ペレイラは、1時間に及ぶウェビナーで可能な限り多くの質問に答えましたが、すべての質問に答えることはできませんでした。録画されたウェビナーはこちらからご覧いただけます。残りの質問への回答はこちらをご覧ください。

Q: DevOps トランスフォーメーションのために VSM を実行するためのガイドやベストプラクティスはありますか？

世の中にはたくさんのガイドがありますが、私たちの VSM エキスパートの意見では、以下のようなものがベストです。

• How DevOps Leads the Way to Digital Business Transformation by DevOps.com
• Data-Driven DevOps by Steve Boone
• Value Stream Management Essentials by DZone
• Visible Thinking from Visible Value Stream Consulting

Q: プロジェクトチーム用の VSM を作っています。ユーザーストーリーをバッチサイズとして考えてもいいですか？

バリューストリーム管理のボトルネックの1つは、パイプラインのステージをバッチでロードすることです。私は、スプリント計画を構築し、リリースで導入するストーリーや機能を特定し、フローを最適化することに焦点を当てて作業を次のステージに滞りなく引き込むことで、開発から本番リリースまでのシームレスな作業の流れを作ることを提案したいと思います。バッチングとは対照的に、プルアプローチでは、特定の段階で処理できる以上の作業をチームに押し付けることがないため、人為的なボトルネックの発生を避けることができます。

Q: VSM は、トップダウンで「幹部レベルの完全なバイイン」を得た場合に最も成功すると聞いたことがありますが、現時点ではそれができず、これ以上待つ余裕はありません。経営陣が実際の問題に気づいていないか、実際の問題を掘り下げようとしていないように見える場合に、現場の作業員（開発者）がボトムアップで指揮を執ることは可能でしょうか？

トップダウンのアプローチが最善であるが、多くの DevOps の変革は草の根レベルから始まる。チームは改善を必要とする何かを特定し、変更を実施します。しかし、その規模のイニシアチブを組織全体に拡大するのは難しいでしょう。では、どのようにして彼らの注意を引くのでしょうか？私達はビジネスの利害関係者にとって重要である事を理解することを提案する。それはコストを下げることなのか、新機能を迅速に市場に投入して競合他社を混乱させることなのか、それとも品質レベルを向上させることなのか。次に現在の状態を理解し、それに対して測定するためのベンチマークを作成することです。そして最後に、上述したように、その改善が事業目標にプラスに貢献するような課題を特定し、変更を実施して実験することです。しかし、必ず測定してください。経営陣の賛同を得たいのであれば、ビジネスの成果という観点から正当性を示す必要があります。"ねえ、ボス！」と言ってください。私たちはこれを行い、XYZ のコストを 20% 削減しました。改善のためにもっと多くのことをしたいと思っていますが、あなたのサポートを頼りにしてもいいですか？

Q: フューチャーステート VSM のベストプラクティスへの提案があれば教えてください。

VSM は非常に新しく進化している分野であり、将来的に何が起こるかを予測することは困難です。また、今の DevOps の世界の変化の速度を考えると、何がすぐそこにあるかはわかりません。私が提案したいのは、来るかもしれないものを受け入れ、組織にとって意味のあるものを受け入れることです。 VSM の実践は、より多くの組織が VSM の列車に乗るようになるにつれて、進化し続けていくだろう。

Q: どのようにすれば OKR と VSM を使って相乗効果を得ることができますか？

ご存知ない方のために説明すると、OKR とは、フレームワークの一部として定義され、見直された「目的と重要な結果」のことです。すべての VSM ベンダーのことを言えるわけではありませんが、HCLのバリュー・ストリーム管理ソリューションである HCL Accelerate は、複数のソースからデータを収集する機能を提供し、そのデータを組織の目的や重要な指標に沿ったダッシュボードやレポートなど、さまざまな形で提示します。HCL Accelerate はまた、トレンドも表示するので、組織は、測定値が正しい方向に向かっているかどうか、あるいは何らかのアクションを取るべきかどうかを確認することができます。このように、両者は本質的には似ていますが、完全に同じではないかもしれません。

Q: アジャイルの世界に移行しようとしている会社に参加する際に、既存の製品の価値の流れをどのように識別するのでしょうか？

ソフトウェアを含むあらゆる製品の製造には、その製品を製造するために取られるステップのパイプラインがあります。ある程度のレベルの計画、設計、開発、品質チェックが行われ、最終的には消費者へのリリースが行われます。そして、実践された方法論に関わらず、価値の流れは存在します。さて、何かがアイデアから実装に至るまでにどのくらいの時間がかかるのかを理解するために、価値の流れにまたがって、実行されたすべてのプロセスステップと作成された成果物を理解するために、我々は価値の流れのマッピングの練習を提案するだろう。現状を理解した上で、各プロセスのステップや成果物を見て、それが価値を提供しているかどうかに挑戦していきます。価値がない場合は、なぜ何かが行われているのかを疑問に思わなければならず、流れからそれを除去することを検討しなければならない。

Q: VSM の研修会に利害関係者をどのようにして参加させればよいでしょうか。

利害関係者は現在のプロセスを知り、変更を実現させてもいいものであるので VSM の研修会にキーである。彼らやワークショップに参加している人を巻き込むためには、意見を共有し、現在のプロセスに挑戦し、自由に発言できる安全な環境を提供することが重要です。その人がその分野の専門家であれば、その人の意見を求める。物事が実際にどのように機能しているのかを共有してもらいましょう。しかし、彼らが改善に向けて努力する気がない場合や、ワークショップに興味がない場合は、そのような人と入れ替わる必要があります。

Q: HCL Accelerateは、他のソースの GIT REPO（GitLab、BitBucket、GitHub）や JIRA や ARCAD のようなツールから VSM のメトリクスを利用することができますか？どのような形式で HCL Accelerate に持ち込むことができますか？

HCL Accelerate は、多くのソリューションとの統合を提供しており、バリュー・ストリーム内でのプレゼンテーションやレポート内のデータ・ポイントとしてデータを取り込むことができます。各ソースはデータ形式が異なるため、HCL Accelerate はソースのデータモデルを見て、リポジトリにインポートするためにそれを正規化することができます。これがHCL Accelerate の強みです。複数のソースからのデータ形式を理解する能力に続いて、そのデータを意味のある方法で提示する能力があるため、組織は単一のビューでデータに基づいて意思決定を行うことができます。また、統合が容易に利用できない場合は、当社にお知らせください。当社の開発チームは、他の DevOps ツールとの新しい統合を常に提供しています。今、待てない場合は、HCL Accelerate の API を使用することで、組織はコマンドを実行することで HCL のリポジトリにデータをインポートすることができます。

下の HCL Accelerate のプラグインライブラリのスクリーンショットをチェックして、どのような統合がすぐに利用できるかを確認してください。

学習を続けたいですか？ここをクリックして、録画された「Ask the VSM Experts」ウェビナーをチェックしてください。また、1対1の DevOps アドバイスをご希望の方は、ここをクリックして無料コンサルテーションをリクエストしてください。

2020/11/11 - 読み終える時間: 5 分

More on Process as Code, new in HCL Launch 7.1.1 の翻訳版です。

HCL Launch 7.1.1 の新機能 Process as Code の詳細

2020年11月6日

著者: Madhavarao Kulkarni / Associate General Manager

HCL Launch は、プラグイン、徹底した REST API、簡単に設定できる統合機能のおかげで、構成が容易で信じられないほど拡張性の高い製品です。HCL Launch 7.1.1 のリリースでは、新しい Processes as Code 機能とそれに付随するユーティリティ "Processes as Code Compiler (PACC)" により、HCL Software の継続的なデリバリツールは、開発者や統合統合がさらに容易になりました。

PAC は、プロセスを作成するための命令をHCL Launchに提供するためのシンプルな言語を導入しています。このタイプのインターフェイスは、顧客が HCL Launch のプロセス作成を自動化に統合するために使用することができます。PAC の利点は以下の通りです。

• 理解しやすい言語
• 簡単にオンボードできます。以下に説明するように、ダウンロードコマンドを使用して既存のプロセスを PAC ファイル形式にすることで、PAC の理解を始めることができます。
• PAC コードを JSON に変換し、その逆も可能です。これは、PAC ファイルを素早く学習して使用し、コーディングにある問題を修正するのに役立ちます。
• PAC ファイルを使用して簡単かつ迅速にプロセスを作成します。
• このインターフェイスを使用して、必要なステップを持つプロセスをアップロードしてダウンロードすることができます。
• アップロードとダウンロードのコマンドは、許可されたユーザーがいないとプロセスをダウンロードしたりアップロードしたりできないように安全です。
• PAC を JSON に変換するコマンドとその逆のコマンドはパスワードを必要としません。

PACを使い始めるには

• HCL Launch サーバーを 7.1.1.1.0 にインストールまたはアップグレードします。
• ヘルプ->ツール->プロセス・アス・コード・コンパイラからサーバ上の任意の場所に PAC ツールをダウンロードしてください。
• フォルダに展開し、ccap, pacc, upload-, download- などのコマンドを使用して起動します。
• 言語の構文やコマンドの使用ガイドラインについては、readme.md ファイルを参照してください。

JPetstore プロセスを PAC フォーマットに変換する (例)

このチュートリアルで作成された JPetstore コンポーネントプロセスを以下に示しますが、PACC ユーティリティを使って変換した後の PAC フォーマットでどのように見えるか見てみましょう

JpetStore Web コンポーネントのプロセス HCL Launch からのデザインビュー

PAC ファイルに変換するには、このコマンドを使います。

download-component-process admin https://localhost:8443 1751e0fd-9502-e59c-4e93-9018d1ce2515 6 jpetWebProc.pac

それは以下のようになります。

start is
    start "Clean working directory"
end
plugin step "Clean working directory" is
    plugin "File Utils"
    command "Delete Files and Directories"
    property "baseDir" = "."
    property "includes" = "**/*"
    property "excludes" = ""
    property "followSymlinks" = "false"
    property "caseSensitive" = "true"
on success
    start "Download Artifacts"
end

plugin step "Download Artifacts" is
    plugin "UrbanCode Deploy Versioned File Storage"
    command "Download Artifacts"
    property "directoryOffset" = "."
    property "artifactSetBaseDir" = ""
    property "fileIncludePatterns" = "**/*"
    property "fileExcludePatterns" = ""
    property "syncMode" = "true"
    property "handleIncrementalVersions" = "false"
    property "fullVerification" = "true"
    property "setFileExecuteBits" = "false"
    property "verifyFileIntegrity" = "false"
    property "charset" = ""
    property "versionId" = "${p:version.id}"
    property "versionType" = "${p:version.type}"
    property "serverUrl" = "${p:server.url}"
    property "compId" = "${p:component.id}"
    property "resId" = "${p:resource.id}"
    property "envId" = "${p:environment.id}"
    property "maxMemory" = "1G"
    property "label" = ""
on success
    start "Start Tomcat"
end

plugin step "Start Tomcat" is
    plugin "Tomcat"
    command "Start Tomcat"
    property "launcherLocation" = "${p:environment/tomcat.start}"
    property "options" = ""
    property "timeout" = "60"
    property "port" = "8085"
    property "hostname" = ""
    property "catalinaBase" = ""
    property "catalinaHome" = ""
    property "javaHome" = ""
on success
    start "Undeploy Application"
end

plugin step "Undeploy Application" is
    plugin "Tomcat"
    command "Undeploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "tomcat2"
    property "tomcatPassword" = "****"
    property "tomcatContext" = "/${p:environment/tomcat.contextroot}"
on complete
    start "Deploy Application"
end

plugin step "Deploy Application" is
    plugin "Tomcat"
    command "Deploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "tomcat2"
    property "tomcatPassword" = "****"
    property "tomcatContext" = "/${p:environment/tomcat.contextroot}"
    property "warFile" = "./JPetStore.war"
    property "configFile" = ""
on success
    finish
end

今後の複雑なプロセス設計で使用するための様々なステップ、プロパティ、ステップ入力値の必要な PAC コードスニペットを理解するために、コンポーネントプロセスを作成し、以下のコマンドを実行してください。

download-component-process <userid> <server_url> <Component_Template_Process_Id> <testdata.pac>

また、PAC コードでどのように表現されているかを知り、PAC をよりよく理解するために、以下の手順を試してみてください。

• 複数のコンポーネントをインストールする
• 複数のコンポーネントのアンインストール
• 複数のコンポーネントの運用プロセスを実行
• 複数のコンポーネントをロールバック
• 各影響を受けるリソースに対して GenericProcess の実行
• ロックの取得と解除
• Status の設定
• Warning の追加
• Switch
• Join
• Note
• Run Generic Process
• Manual Application Task
• For Each Agent
• For Each Tag

HCL Launch における Process as Code の詳細については、こちらのブログ記事をお読みください。

2020/10/30 - 読み終える時間: 4 分

Accelerating Testing at Reduced Costs の翻訳版です。

より低コストでテストを加速させる

2020年10月29日

著者: Navnit Kumar Singh / Software Test Architect 共著: Shivi Sivasubramanian / Technical Lead

多くの組織にとって、アジャイルおよび継続的なソフトウェアデリバリのトレンドに追いつくためのテストプロセスを定義することは、大きな課題です。

そして、この課題を克服するために、多くのソフトウェアチームは通常、テストの自動化や追加のスクリプトを導入しています。しかし、より自動化された UI テストが必ずしも効率的なプロセスとは限りません。

テストの実行時間は、テストスイートのサイズに正比例します。特にこのようなシナリオでは、テストを自動化する目的は達成されません。この記事では、HCL OneTest UI (HOT UI) が、テストの自動化に関連する最も一般的な問題を克服するのにどのように役立つかを概説します。

このブログ記事では、以下の用語を使用しています。

• ノード - 物理的または仮想的なマシン、Docker イメージ、モバイルデバイス、またはエミュレータ
• Channel - テストが実行されるブラウザーのアクティブなインスタンス

スピードを上げる、遅くするのではなく

テストを高速化する最も強力な方法は、テストを並列に実行することです。すべてのテストスクリプトを単一のノードで実行するのではなく、多くのノードに分散して実行します。例えば、100個のテストを 10個以上のノードで並列に実行すると、実行時間は実際の実行時間のわずか10分の1にまで短縮されます。

時間を節約できるだけでなく、テストの実行を並列化することで、テストカバレッジを大幅に向上させることができます。

自動化されたテストを並行して実行するための準備をする際には、以下の要件を考慮してください。

• アトミックテストと自律テスト
• ノード間の通信が適切に処理されるテスト環境
• テスト実行のための単一の統合レポート
• テストデータを迅速かつ正確に管理する方法

テスト実行の高速化

HCL Software は、HCL OneTest UI と呼ばれるGUI自動化機能テストツールを提供しており、記録することで自動テスト用のテストスクリプトを素早く生成することができます。これらのテストスクリプトは、逐次的にも並列的にも実行することができます。そのシンプルなUIを使用して、並列テスト実行用のアトミック・スクリプトを生成したり (「記録中にテストを分割する」を参照) 、並列テスト実行のためのさまざまな機能を活用したり、テスト・データを自動管理したりすることができます。

HCL OneTest UI は、複数のブラウザーと複数のノードに同時にテスト実行を分散させる方法を提供することで、テストを高速化するのに役立ちます (「分散テストによるテスト作業の高速化」を参照してください)。HOTUI で並列テストを実行するには、加速機能テストアセット (AFT) を設定する必要があります。AFT は、複数の接続されたノードと利用可能なブラウザー上で並列テストを実行するために必要なすべての情報を含む XML ファイルです。

• テスト スクリプトの詳細。テストスクリプトの詳細： 並列実行するすべてのテストスクリプトの名前と場所
• ブラウザーの詳細 .... テストを実行するブラウザー
• Locations ............... テストが実行されるノードの場所
• グループ ..................... テスト、ブラウザー、ロケーションのグループ

典型的なAFTテストスイートは次のようになります。

2. AFT テストスイート

増速機能テストの設定方法の詳細は、「増速機能テスト・アセットの作成」を参照してください。

テスト実行の分散を制御する

AFT テストスイートを実行すると、そのテストスイートの一部である WebUI テストが複数の接続されたノードに分散され、テストを並行して実行するための複数のチャネル (またはストリーム) が容易になります。ノード上で並列に実行できるテストの数は、Web UI Playback (Desktop) 環境設定 (Window > Preferences > Test > Test Execution > Web UI Playback (Desktop) ) で「配布用エージェントごとの並列チャンネル数」を整数値に設定することで、HOTUI 環境設定で定義したチャンネル数に依存します。

3. HOTUI 環境設定 - 並列テストの実行回数の設定

というわけで、並列チャンネル数を決定する際には、接続されているノードの構成も考慮する必要があります。

HOTUI では、以下の方法で並列テストの実行を配布することができます。

• 自動配布 実行時間を最小化する観点から、実行テストの配分は HOTUI によって完全に制御されています。選択された WebUI テストまたは AFT スイートのテストの一部は、個々のテストの実行時間に基づいて、指定されたチャンネル数に事前に配置され、各チャンネルの合計実行時間のバランスをとります。
• 選択的な配布 グループを作成することで、どのテストをどの接続ノードで、どのブラウザーで実行するかを決めることができます。グループの一部であるすべてのテストは、そのグループに関連付けられているすべてのブラウザー上で実行され、実行はそのグループで定義されているすべてのノードに分散されます。

選択されたテストの数、または AFT テストスイートの一部であるテストの数が、利用可能なチャンネルの数よりも多い場合、各チャンネルは複数の Web UI テストを収容するように構成できます。Web UI テストは、チャンネル間で並行して実行され、チャンネル内では順次実行されます。

並列実行可能なテストの最大数＝（配信用のノードごとの並列チャンネル数）×（接続されたノード数)

注: 複合テストを実行する場合、複合テストの数に選択したブラウザの数を乗じた数がチャンネル数を超えないようにしてください。

レポートの表示

テスト実行の終了時には、テストの詳細、実行環境、状態、場所（ノードの詳細）など、実行の詳細と概要をまとめたレポートが生成されます（スクリーンショット参照）。

4. レポート-並列テスト実行

5. レポート拡張-並列テスト実行

データ駆動型テストをいかに簡単に加速させるかの詳細についてはこちらをご覧ください。

2020/10/30 - 読み終える時間: 4 分

Data-driven Test Acceleration Made Easy の翻訳版です。

データ駆動型テストの高速化による改善

2020年10月29日

著者: Navnit Kumar Singh / Software Test Architect 共著: Shivi Sivasubramanian / Technical Lead

ディストリビューションテストの大きな課題のひとつは、データ駆動型のテストです。同時に実行されているすべてのテストは、データにアクセスできるはずです。

しかし、いくつかのシナリオでは、複数のテストが同じデータにアクセスできるようにすることはできません。HCL OneTest UI (HOT UI) が提供するデータセットを使用することで、分散テストを実行しながらこの課題に簡単に取り組むことができるようになりました。

この記事では以下の用語を使用しています。

• データセットは、スクラッチから作成することも、カンマ区切り値 (CSV) ファイルからデータをインポートすることも可能な、実行中の変数データを持つテストを提供します。詳細については、データセットの概要を参照してください。
• 複合テストは、小さなテストをエンドツーエンドで実行できるシナリオに整理するのに役立ちます。複合テストを実行すると、それに追加された各テストは、定義された順序で呼び出されます。詳細は、「複合テスト」を参照してください。

データセットの作成

e コマースのWebサイトで一般的に起こるシナリオを考えてみましょう。ユーザーがログインし、カートに商品を追加し、注文をします。 したがって、以下の手順で自動テストを行う必要があります。

• ログイン: e-Commerce Web サイトにログインする
• カートに追加: 商品を選択してカートに追加する
• 注文する: 商品内容を確認してから注文する

テストを高速化するために、サポートされているすべてのブラウザーで 3つのテストを並行して実行することを計画してください。しかし、アプリケーションは同じユーザーログインで 3つのセッションを同時に実行することはできません。そのため、各実行ではユーザー ID とパスワードの異なる組み合わせを使用する必要があります。

上記のシナリオのために、HCL HOTUI で以下のデータセットを必要な行データと共に作成します。

• DS_Login: ユーザーログインの詳細をユーザー ID とパスワードの 2つの列の下に保存します。

1. データ集合 - DS_Login

• DS_Product: 3 つの列の下に製品の詳細を格納します - 製品名、ID、販売者 (product name, id, seller)

2. データ集合 - DS_Product

DS_Login データセットをログインテストに関連付け、テストの入力値をデータセットの列に関連付けます。同様に、DS_Product データセットを addToCart テストに関連付け、入力値をそれぞれのデータセット列に関連付けます。詳細については、「テスト値をデータセット列に関連付ける」を参照してください。

複合テストの作成

3 つのテストをシナリオとしてまとめて実行するには、HCL OneTest で TC_PlaceOrder という名前の複合テストを作成し、3 つのテストを予想される実行順序で追加します。複合テストの中にループを挿入し、addToCart テストをその中に移動します。これは、実行中に対応するデータセットの行から値（この場合は、商品の詳細）を取得するために必要です。

3. 複合テスト

TC_PlaceOrder という複合テストを実行すると、まずアプリケーションにログインするためにログインテストが実行され、次に addToCart テストがカートに商品を追加します。カートに追加された商品の数は、ループ内で指定された反復回数に等しくなります。最後に、placeOrder テストは、カートに追加された商品の注文を行います。

テストの配布

複数のブラウザーで同時にテストシナリオを実行するには、Distribute_TC_PlaceOrder という AFT テストスイートを作成します。

4. AFT テストスイート

Distribute_TC_PlaceOrder と呼ばれる AFT テストスイートを実行すると、TC_PlaceOrder テストは Chrome と Firefox で並行して実行されますが、複合テスト TC_PlaceOrder の一部であるテストは順次実行されます。

異なるブラウザーでの実行の各ステップで、ログイン・テストは、DS_Login データセットの異なる行から必要なログイン詳細を取得します。このようにして、各並列テストの実行において、単一のユーザー・ログイン・セッションが保証されます。 ログインテストが完了すると、addToCart テストはループ内で（指定された回数分）、異なるブラウザー上で同時に実行されます。addToCart テストの各実行は、DS_Productdataset にアクセスし、データセットにアクセスする1つのテストであるかのように、カートに商品を追加します。

まとめると、HOTUI は、必要に応じてデータへのアクセスを制限しながら、データへの同時アクセスを可能にすることで、テストの並列実行を容易にします。

コストを削減しながらテストを高速化する方法の詳細はこちらをご覧ください。

2020/10/29 - 読み終える時間: 5 分

Processes as Code in HCL Launch の翻訳版です。

HCL Launch における “Process as Code”

2020年10月28日

著者: Hayden Schmackpfeffer / Product Manager

導入とユーティリティー

HCL Launch version 7.1.1.0 で追加されたエキサイティングな新機能の1つは、Web UI の外でアプリケーションやコンポーネントのプロセスを設定できることです。HCL Software の “Process as Code” フォーマットにより、開発チームはプロセスを定義し、簡単に変更可能なフォーマットで保存することができます。

HCL Launch サーバーには、いくつかのコマンドで構成されたユーティリティである Process as Code Compiler がバンドルされています。その主な目的は、Launch サーバーと対話し、PAC フォーマットと Launch サーバーによって理解される JSON フォーマットの間で変換することです。

最も便利なコマンドは upload と download です。これらのコマンドには、download-component-process、download-application-process、upload-component-process、upload-application-process の 4つがあります。

ダウンロードコマンドは、Launch 内のプロセスの特定のバージョンを指し示し、そのプロセスをダウンロードし、PAC 形式に変換して保存します。

download-<process-type>-process <user-name> <server-url> <process-id> [<version>|latest] output.pac

アップロードコマンドは逆のことをします; アップロードコマンドはローカルの PAC ファイルをサーバーが期待する JSON フォーマットに変換し、指定されたプロセスの新しいバージョンとしてアップロードします。

upload-<process-type>-process <user-name> <server-url> <process-id> <next-version | latest> input.pac

pacc スクリプトはローカルに保存されている Launch JSON ファイルを PAC フォーマットに変換し、 ccap スクリプトは PAC から JSON フォーマットに変換します。

基本的な構文

PACC ユーティリティの README には、私たちが定義したカスタム構文の詳細な説明が含まれていますが、ここでは基本的なことを説明します。

• "start" と "finish" は、プロセスの入口と出口を表すために使用されます。
• "start " は、定義されたステップを呼び出すために使用されます。
• "plugin step is" は、ステップを定義し、設定します。この一般的な構文は任意のプラグインコマンドを指定することができ、"shell" のような一般的に使用されるステップのための短縮記号があります。
  • "plugin" は使用するプラグインを指します。
  • "command" は、そのプラグインの中で使用する特定のプラグインステップを指します。
  • "on [success | failure | complete]" は、特定のステップが終了した後に実行されるその後のステップを定義する。
  • "property " = " は、プラグインのステップフィールドの値を指定します。

ここでは、シンプルな Tomcat ウェブアプリケーションのアーティファクトセットをダウンロードし、Tomcat プラグインを使用してアプリケーションをデプロイする小さなコンポーネントプロセスの例を示します。

start is
    start "Download Artifacts"
end

plugin step "Download Artifacts" is
    plugin "UrbanCode Deploy Versioned File Storage"
    command "Download Artifacts"
on success
    start "Deploy Tomcat Application"
end

plugin step "Deploy Tomcat Application" is
    plugin "Tomcat"
    command "Deploy Application"
    property "tomcatManagerUrl" = "${p:environment/tomcat.manager.url}"
    property "tomcatUsername" = "exampleTomcatUser"
    property "tomcatPassword" = "${p:environment/secureTomcatPassword}"
    property "tomcatContext" = "/TestA"
    property "warFile" = "./TestApp.war"
    property "configFile" = ""
on success
    finish
end

この例では、Deploy Application ステップのための特定のプロパティを明示的に定義していますが、成果物のダウンロードコマンドは基本的に空のままにして、ステップのデフォルト値を使用しています。PAC プロセスは HCL Launch に直接アップロードされ、サーバーが理解できる形式に変換されているので、プロパティを参照することができます。

始めるには、既存の Launch プロセスを PAC フォーマットに変換するためにプロセスのダウンロードコマンドを使用し、PAC の変更の出発点として使用することをお勧めします。

私は現在、開発用 Launch サーバー上のデプロイメントプロセスを Processes as Code とカスタム githook を使って管理しています。サーバー上で管理したいプロセスは、以下のディレクトリ構造を使って「deployment-processes」リポジトリに格納しています。

Deployment-processes/<processType>/<nameOfComponentOrApplication>/<ProcessID>.pac

これにより、変更した .PAC ファイルのパスには、コミット時に処理をアップロードするために githook が必要とするすべての情報が含まれていることが保証されます。この例では、ブランチにコミットしたらすぐにアップロードするために post-commit フックを使用していますが、toy 以外の例では、git サーバー側の pre-receive フックや post-receive フックのほうが適切です。

下の githook の例は python で書かれたもので、pexpect ライブラリを使用しています。現在のバージョンの PAC ユーティリティでは、Launch サーバーとやりとりするときにパスワードを手動で入力しなければならないという事実を回避しています。

#!/usr/bin/env python3 
from subprocess import check_output
import pexpect
import json
TYPE = 0
NAME = 1
ID = 2
username = ''
password = ''
serverUrl = ''
# returns tuple of type, name, processId
# assumes files are appropriately structured
def parseTargetsFromFile(filepath):
    #component/testComponent/175427f6-0a8b-93b4-d73a-6a8ba534b060.pac
    targets = filepath.split('/')
    filename = targets[ID]
    return targets[TYPE], targets[NAME], filename[:filename.index(".")]
def uploadProcess(cmd):
    child = pexpect.spawn(cmd)
    try:
        i = child.expect([pexpect.TIMEOUT,'password:'])
        if i == 0:
            print("Got unexpected output: %s %s" % (child.before, child.after))
        else:
            child.sendline(password)
        child.read()
    except:
        print("Problem encountered: ")
        print(str(child))
def uploadChangedProcesses():
    # git diff-tree -r --name-only --no-commit-id HEAD
    changedFiles = check_output(['git', 'diff-tree', '-r', '--name-only', '--no-commit-id', 'HEAD']).decode()
    lines = changedFiles.splitlines()
    for line in lines:
        print(f"uploading pac file: {line}")
        line = str(line)
        targets = parseTargetsFromFile(line)
        cmd = buildCommand(targets, line)
        uploadProcess(cmd)

def buildCommand(targets, filename):
    return f"upload-{targets[TYPE]}-process {username} {serverUrl} {targets[ID]} latest {filename}"
if __name__ == "__main__":
    with open('conf.json') as confFile:
        conf = json.load(confFile)   
        username =  conf['username']
        password = conf['password']
        serverUrl = conf['url']
    uploadChangedProcesses()

上記のスクリプトをポストコミットフックとして保存し、私のPACファイルに修正をコミットすると、それらのファイルは、以下のように私のLaunchサーバー上で同じIDを持つプロセスの最新バージョンとしてアップロードされます。

HCL Launch 7.1.1.1 の他のアップデートと一緒に、新しい "Processes as Code "機能が実際に動作しているのを見たい方は、こちらから登録してウェビナーに参加してください。

2020/10/28 - 読み終える時間: 2 分

What's new in HCL Launch 7.1.1.0 の翻訳版です。

HCL Launch 7.1.1.0 の新機能

2020年10月27日

著者: Hayden Schmackpfeffer / Senior Developer

HCL Launch バージョン 7.1.1.1.0 では、これまで以上にデプロイメントの経験を向上させるために、信じられないほどの新しい機能と強化が追加されています。このリリースに含まれている機能セットは、デプロイメントの表示と設定がこれまで以上に簡単になり、QOL を向上させます。

HCL Launchアプリケーションとコンポーネントのプロセスを人間が読みやすい速記法で定義できる新しい言語を作成しました。当社の "Processes as Code" 言語を利用するために、"Tools" セクションに Processes as Code コンパイラが含まれており、既存のプロセスをダウンロードしてPACフォーマットに変換したり、指定したLaunchサーバに直接PACファイルを翻訳してアップロードすることができます。より詳細な情報は、近日中に詳細なフォローアップ記事でご紹介します。

新しい "Get Started" ページでは、HCL Launch と HCL Software DevOps に関する膨大な情報のリポジトリを、あなたの指先に置いています。アプリ内のチュートリアルの代わりに、このページでは、HCL Launch のチュートリアルのほか、ドキュメント、リリースノート、ビデオコンテンツ、そしてこのブログへのリンクが用意されています。ナビゲーションバーの "HCL Launch" セクションをクリックするか、ヘルプドロップダウンの "Get Started" オプションをクリックして、いつでもこのナレッジストアにアクセスしてください。

このリリースでは、便利なメールリンクを介して承認タスクに対処する機能を使用して、チームのデプロイメントを外出先でも管理することができます。バージョン7.1.1.1.0に含まれているデフォルトの通知テンプレートには、電子メールを受信したユーザーに関連付けられた応答URLが埋め込まれています。

このリンクをクリックすると、ユーザーは割り当てられたタスクを承認または拒否するためのモバイル応答ページに移動します。このリンクは、添付されたタスクへの応答にのみ使用でき、5日後に有効期限が切れます。既存のメールテンプレートはアップグレード時に保存されるため、お使いのサーバーがv7.1.1.1.0以前にインストールされていた場合は、承認とタスク通知のテンプレートXMLを変更して、応答URLを含める必要があります。この設定方法については、サポートチームまでお問い合わせください。

設定タブの新しいページでは、すべてのタグ付け可能なオブジェクトを俯瞰的に見ることができます。オートメーション設定の下の "タグ "ページには、エージェント、アプリケーション、コンポーネント、またはリソースのために作成されたすべてのタグを一覧表示するテーブルがあります。

これらのテーブルは、特定のタグのセットを表示するためにフィルタリングしたり、既存のタグ定義を変更したりすることができます。既存のタグの名前、説明、および色を変更することができ、そのタグは、タグが与えられたすべてのオブジェクトで更新されます。

また、ライセンス設定をシステム設定ページの外に移動し、ライセンスサーバー接続に特化した新しいページに移動することで、ライセンス設定を刷新しました。このページでは、接続の詳細を入力し、HCL Launchがライセンスサーバーへの接続に成功すると、ライセンスの使用状況に関する情報が表示されます。

11月5日（木）午後3時（米国東部標準時）に開催されるウェビナーでは、これらの新機能を実際にご覧いただけます。ライブ・ウェビナーに参加できない場合でも、ご登録いただければリプレイへのリンクをお送りします。ウェビナーに登録するには、ここをクリックしてください。

HCL Launchがあなたの生活をどのように楽にするかについて、他にもアイデアがありますか？こちらのアイデアポータルに投稿してください。

2020/10/28 - 読み終える時間: 4 分

Enhancing Test Results Via Unified Reports の翻訳版です。

統一されたレポートによるテスト結果の改善

2020年10月26日

著者: Eshita Gupta / User Experience designer for HCL Software

ソフトウェアでは、製品の最適な品質が常に優先されています。

予期せぬ状況や期待される状況下でのソフトウェアコンポーネントの評価は非常に重要です。そのため、テストチームは製品の品質を評価することで、ビジネスの成長に大きな役割を果たしています。

テスターであるあなたは、レポートに迷い、メールボックスに書類をダンプしてしまうことが何度あるでしょうか。それはよくあることで、テスターはゼロからスタートしなければならないことが多いです。

HCL OneTest Server の新しい統一レポートにより、テスト結果を簡単にアクセスして分析できるようになりました：このレポートは、機能テストとWeb UIテストレポートの機能を統合し、HCL OneTest UIのすべてのテストタイプをサポートしています。広範囲で直感的なデザインを使用することで、統一レポートはテスト結果を分析するための以下の機能を提供します。

テスト実行の包括的な詳細を表示することで、テストの問題点を素早く深く掘り下げることができます。

• 複雑な複合テストから特定のテスト反復の詳細までのドリルダウン
• テスト実行からキャプチャしたスクリーンショットをカルーセル形式で表示します
• テスト実行からのライブレポート
• レポートからテスト結果をHTML形式でエクスポートすることができます

クイックビューアプローチ

レポートの最初のセクションでは、実行された結果が一目でわかるようになっています。これは、資産の健全性を素早く分析し、チーム内で同じことを伝えたいマネージャーやテスターに最適です。

結果レポートを素早く表示する方法について詳しく説明します。

• ドーナツチャートは、結果の新鮮で迅速なビューを提供します
• テストの合格・不合格の相対的な割合をカラーコードで表示する
• 大規模データの要約に役立つ
• 解析時間の短縮
• さらなる調査のために報告書を掘り下げるためのアンカー

サマリーとリソースタブ:新しい統一されたレポートで、重要な情報が前面に出て、ユーザーの体験を向上させるのに役立ちます。

サマリータブ

階層的アプローチ

階層構造により、作業と依存するテスト資産の明確な権限が確立されます。複雑なアセットをシンプルな構造で見ることができます。

視覚的な階層構造は、ユーザーの流れを簡単かつ直感的にナビゲートします。

イテレーション: 各データセットをイテレーション形式で見ることができます。

結果比較 - あらゆるタイプのデータの実際の結果と期待される結果の比較が、これまで以上に簡単になりました。さまざまなタイプのデータについては、次の表の例を参照してください。

フィルター: 資産の状態をフィルタリングすることで、故障の原因を簡単に掘り下げることができます。

差分だけを表示: チェックボックスを使用して、無関係な情報を除外することができます。

マイクロスコープ的詳細

ユニファイド・レポートは、データの拡大率がはるかに高く、誰でも階層の各レベルで資産の詳細を検出することができます。アコーディオンを拡大しなくても、関連するアイコンにカーソルを合わせることで、個々のアセットの微細な詳細を確認することができます。

アイコンにカーソルを合わせると、以下のような詳細を見ることができます。

• テストステップが何回失敗したか？
• 実行中に使用されたブラウザは？
• どのホストが関連付けられていたか？
• テストの実行にどれくらいの時間がかかりましたか？

スクリーンショットのキャプチャ。記録および再生中に、スクリーンショットがキャプチャされ、各テストアセットに添付されます。キャプチャしたすべてのスクリーンショットを説明とともにカルーセルで簡単に見ることができます。

ライブレポート

ライブレポート機能の助けを借りて、あなたはレポートを見るために実行するための完了を待つ必要はありません、リフレッシュせずにライブレポートを実行していると、経験がシームレスになります。

エキスポート

あなたの都合に合わせてレポートをエクスポートし、チームで共有することができます。レポートとエクスポートのカスタマイズされたビューは、統一されたレポートのために長い間要求された機能です。今、あなたは希望する形式でレポートをエクスポートすることができます。エクスポートされたテストレポートは、インタラクティブなHTML形式とPDF形式で利用できます。将来のリリースでは、他のフォーマットもサポートしています。

オートヒーリング

オートヒーリングは本製品の最も奥深い機能です。統一されたレポートでは、「オートヒーリング」タグでレポートの状況を知ることができます。

HCL OneTest は、リリースのたびにレポートを継続的に強化しています。