ソフトウェア工学

2023/02/01

ChatGPTにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法を聞いた

15年以上前にEclipseでdjunitでカバレッジを出力していろいろ試していた。

dJUnitでカバレッジテスト: プログラマの思索

しかし、今のEclipseではdjunitはもう使えなくなっていた。
ChatGPTに聞いたら、代わりにEclipseでEclEmmaとJaCoCoからカバレッジを出力する方法がわかったのでメモ。

【参考】
EclEmma - Java Code Coverage for Eclipse

EclEmma - JaCoCo Java Code Coverage Library

EclEmma - Source Code Annotation

ブログエンジン(5) Maven+JaCoCoでカバレッジ計測 - afnf.net

WildFly+jacocoでintegration-testのカバレッジ取得 - Qiita

カバレッジレポートの出し方について書く ・ Issue #10 ・ syobochim/doc

JaCoCo - Command Line Interface

複雑度と単体テストケース数の相関関係: プログラマの思索

【前提条件】
Eclipseの実行メニューに「カバレッジ>Junit」が表示される前提とする。
表示できていれば、EclipseにEclEmma プラグインがインストールされている。
最新版のEclipseであれば既にインストール済み。

Eclipseにカバレッジ・ビューを表示するように設定するには、ウィンドウ>ビューの表示>その他 から、java>カバレッジを 選択して画面下部に表示するように設定する。

JaCoCo のZipファイルをダウンロードしておく。

EclEmma - JaCoCo Java Code Coverage Library

【EclipseにJacocoを設定する方法】
この手順書は、ChatGPTに質問して作成した。

EclipseにJacocoを設定する方法は次のようになります。

Eclipseで、JaCoCoを使用するプロジェクトを選択します。

[Run] -> [Run Configurations...]を選択し、「JUnit」に対して新しい設定を作成します。

「Arguments」タブで、「VM arguments」欄に「-javaagent:path/to/jacocoagent.jar=destfile=path/to/jacoco.exec」を追加します。

path/to/jacocoagent.jarは、JaCoCoがインストールされている場所に置き換えてください。
path/to/jacoco.execは、JaCoCoのエグゼキューションファイルを出力する場所を指定します。
「Apply」をクリックし、「Run」をクリックして、テストを実行します。

実行が終了したら、「Coverage」ビューを開き、カバレッジ結果を確認します。

注意: 上記の設定は、JUnit4を使用している場合の設定方法です。JUnit5を使用する場合は適切なアダプタを使用する必要があります。

【EclipseとJacocoを使って、カバレッジのレポートをHTMLで出力する方法】

Eclipseで、JaCoCoを使用するプロジェクトを選択します。

[Run] -> [Run Configurations...]を選択し、「JUnit」に対して新しい設定を作成します。

「Arguments」タブで、「VM arguments」欄に「-javaagent:path/to/jacocoagent.jar=destfile=path/to/jacoco.exec」を追加します。

path/to/jacocoagent.jarは、JaCoCoがインストールされている場所に置き換えてください。
path/to/jacoco.execは、JaCoCoのエグゼキューションファイルを出力する場所を指定します。
「Apply」をクリックし、「Run」をクリックして、テストを実行します。

実行が終了したら、JaCoCoのアクションツールを使用して、jacoco.execからHTMLレポートを生成します。

JaCoCoのアクションツールは、Javaコマンドラインから次のように実行できます。

java -jar path/to/jacococli.jar report path/to/jacoco.exec --classfiles path/to/classfiles --sourcefiles path/to/sourcefiles --html path/to/report

path/to/jacococli.jarは、JaCoCoのアクションツールを含むjarファイルへのパスです。
path/to/jacoco.execは、JaCoCoが生成したエグゼキューションファイルへのパスです。
path/to/classfilesは、JaCoCoを適用するクラスファイルへのパスです。
path/to/sourcefilesは、JUnit対象ソースコードへのパスです。
path/to/reportは、HTMLレポートを生成する場所を指定します。index.htmlを開けば出力結果が表示されます。

注意: 上記の設定は、JUnit4を使用している場合の設定方法です。JUnit5を使用する場合は適切なアダプタを使用する必要があります。

JaCoCo - Command Line Interface

【感想】
ChatGPTに明確な質問を書けば、的確に回答してくれる。
手順は必ず回答があるから、AIが強いだろうと思う。

WildFly+jacocoでintegration-testのカバレッジ取得 - Qiitaによれば、Missed InstructionsがC0 (命令網羅率) でMissed BranchesがC1 (条件網羅率) を表しているとのこと。
ドリルダウンすると、カバレッジを通過したパスは、
緑:実行された命令。
赤:実行されなかった命令。
黄:分岐において一部のみ実行された命令。
で表示してくれる。

カバレッジ結果のHTMLを開くと、C0/C1カバレッジをいい感じで出力してくれるのでありがたい。

Jacoco_report1

Jacoco_report2

Jacoco_report3

| | コメント (0)

2022/12/13

DDPは品質管理に役立つのか

DDP(Defect Detection Percentage)は品質管理に役立つのか、について考えたことをメモ。
ラフなメモなので、間違っていたら後で直す。

【参考】
資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)|Tech Village (テックビレッジ) / CQ出版株式会社

バグ密度・テスト密度に依存しない品質保証への挑戦 | DATA INSIGHT | NTTデータ

コード行数を用いない品質分析技術と開発速度を落とさない品質管理手法の提案~NTTデータ ソフトウェア品質シンポジウム2021

テスト / 品質関連メトリクスまとめ | Test-Hack | 3分で理解するIT/テスト技術

【1】
ソフトウェアテスト標準用語集 (日本語版)によれば、欠陥検出率(Defect Detection Percentage (DDP))の定義が書かれている。

欠陥検出率(Defect Detection Percentage (DDP)): あるテストレベルで見つけた欠陥の数をそのテストレベル、及び、以降のテストレベルで見つけた欠陥の総数で除算した値。escaped defects も参照のこと。

テスト / 品質関連メトリクスまとめ | Test-Hack | 3分で理解するIT/テスト技術では、
欠陥検出率(DDP) =検出バグ数÷当初保有バグ数×100
で紹介されている。

DDPの事例としては、コード行数を用いない品質分析技術と開発速度を落とさない品質管理手法の提案~NTTデータ ソフトウェア品質シンポジウム2021が有名なのだろう。

ただし、DDPをよくよく考えてみると疑問がいくつか出てきた。
上記のPDFでは、単体テストで潜在バグをすべて検出できず、後工程である結合テストで流出した単体テストのバグ数を数えて、結合テストフェーズでDDPを算出している。
その内容を見ると、DDP=9/10=90%なのでそれほど流出しておらず問題ないように見える。

しかし、結合テストフェーズでは、3件のバグのうち1件が単体テストから流出したバグなので、前工程から流出したバグの割合は1/3=33%になる。
よって、結合テストでは本来結合テストで見つけるべきバグよりも、前工程から流出したバグが多く見つかっているのではないか、という疑念が生じる。

また、資格認定ISTQBはソフトウェア・テストの何を変えたのか? ―― ソフトウェアテストシンポジウム 2013東京(JaSST'13 Tokyo)|Tech Village (テックビレッジ) / CQ出版株式会社でもそうだ。
ここでは、アジャイル開発でスプリントごとにDDPを算出している。

スプリント1のDDP=40/(40+10)=80%なので、後のスプリントにあまり流出しておらず、スプリント1は品質が良さそうに見える。
しかし、スプリント2では、バグ45件に対し、10件がスプリント1という前のスプリントのバグが見つかっている。
つまり、スプリント2のうちスプリント1が占めるバグの割合は、10/45=22%にものぼる。
前のスプリントで潰しておくべきバグが後のスプリントでたくさん見つかるということは、今実施中のスプリントで本来見つけるべきバグ検出にリソースを集中することができていない疑念がある。

また、スプリント2のDDP=35/(35+25)=58%なので、かなり品質は悪い。
スプリント3でスプリント2のバグが占める割合は、25/80=31%なので、スプリント2の時よりももっと品質が悪くなっている事実を示している。

【2】DDPが高い数値で品質が高そうに見えるが、実は品質が悪かったという状況はどんな時なのか?

それは、前工程や前のスプリントで多数のバグが見つかったケースに相当するだろう。
つまり、たとえば、前工程や前のスプリントで20件、50件、100件のように多数のバグが見つかった場合、後工程で10件流出したとしても、DDPの値は高めに出るので、一見品質は良さそうに見える。
しかし、元々DDPの分母や分子の数値が大きいので、そう見えるだけ。
後工程で、前工程から流出したバグの割合を見れば、多数のバグが流出しているだろうから、前工程ですべてのバグをすべて潰しきれていないことを示しているだろう。

つまり、DDPは前工程のバグの流出を許さないような前提条件で品質を考えている場合、DDPは品質管理に有効とはいえないだろう。
WF型開発やアジャイル開発でも、後工程がお客様という立場であれば、DDPの指標がたとえ高くても、その妥当性は色々分析してみる必要がある。

【3】そんなことを考えると、品質管理に出てくるメトリクスは1つの観点のKPIに過ぎず、品質という抽象的な成果を評価するには多数のKPIをつなげて1つのストーリーを作る必要が出てくる。
したがって、品質に問題がないという説明で納得させるには、いろんなKPIをつなぎ合わせて試行錯誤して、なんとか妥当性の根拠を示すという手間がかかるわけだ。

プロマネはそういう部分で数多くの苦労をしているので、品質管理や不具合分析は胡散臭いと思っているのかもしれない。

【補足】
@sakaba37さんのコメントを追記しておく。
メトリクスには罠が多い。
さかばさんはTwitterを使っています: 「@akipii 開発中は「いつもと同程度なら、いつもと同じようなテストが実施されたと推定できる」以上のことはわからないように思います。」 / Twitter

| | コメント (0)

2022/12/04

組合せテストにおける因子と水準はどちらを最優先で考えるべきか

ソフトウェアテストの組み合わせテストでは、因子と水準の考え方が重要になる。
組合せテストにおける因子と水準はどちらを最優先で考えるべきか、考えたことをメモ。

【参考】
システム開発で組合せテスト技法を使いこなすには? 4つのポイントを紹介| Qbook

組合せテストの考え方 - Qiita

駆け出しテストエンジニアと組み合わせテスト技法:Bugs Life ~テストエンジニアは不具合と戦い共に生きる:エンジニアライフ

ソフトウェアテスト技法練習帳はテストケースの切り方に困っている人向けにおすすめの本だ: プログラマの思索

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

プログラミングしてる時はでっかいピタゴラ装置を作ってるみたいな感じ: プログラマの思索

【1】水準はパラメータの値、因子はパラメータの値をグルーピングしたカテゴリ。
一般に、設計書からテストケースを作成する場合、因子と水準のどちらを最優先で考えるのか?

【2】基本的に考えると、因子を決めて、因子のインスタンスである水準を洗い出すように考えがち。
たとえば、都道府県という因子から、東京都、大阪府のような水準をトップダウンで導き出す。
つまり、因子→水準の順番を考えるように思ってしまう。

しかし、実際の仕様書は、魑魅魍魎な日本語という曖昧な自然言語で書かれている。
因子をきちんと書き出してくれていない場合が多い。
実は、仕様書やユーザーストーリーには、水準だけ記載されていて、因子が明示されていない場合が非常に多い。

たとえば、映画館の入場料金は、学生や老人は20%割引、深夜時間帯は30%割引、水曜はレディースデーで女性は割引、団体客は一括割引などの仕様が書かれていたとする。
すると、水準である実際のパラメータの値はたくさん書かれているが、因子は明示されていない。
因子は年齢、曜日、時間帯、性別などが出てくるが、たとえば、年齢と曜日の組み合わせならどの割引になるのか、が不明確なのだ。

つまり、実際の仕様書、ユーザマニュアル、ユーザストーリーには、水準はあちこちに散らばって記載されているが、因子は明確に記載されていない。
よって、組合せテストを作成する前には、まず仕様書から水準をすべて抽出し整理して、因子を改めて定義し、デシジョンテーブルに落とし込む必要がある。

すなわち、水準→因子の順番で考える場面のほうが非常に多い。

すると、因子の組合せパターンから、仕様書に記載されていないパターンが不明点としてたくさん出てくるだろう。
そんな内容をすべて特定し、ユーザに逐一確認して、仕様を決めていく必要が出てくる。
そういう作業こそが本来のSEの仕事なのだろう。

【3】映画館の入場料金の例のように、因子と水準を抽出してデシジョンテーブルを作成していく研修を実施した時がある。

すると、時間内にデシジョンテーブルを正確に作成できる人と、いくら時間があってもデシジョンテーブルを作成できない人の2つの集団に分かれるように認識した。

デシジョンテーブルを作成できない人は、因子→水準の順番で抽出しようとしているので、いつまで経っても、自分の頭が混乱した状態になっているようだ。
つまり、たくさんの水準のデータを抽出するが、因子と完全に対応して整理できないので、たくさんのデータに混乱してしまっているようだ。
一方、デシジョンテーブルを作成できる人は、まず水準を抽出して、因子でグルーピングする順番なので、水準→因子で作業しているから、漏れなく整理でき、組合せのパターンや関数従属性も考慮して、デシジョンテーブルを作成できているようだ。

どうやら、デシジョンテーブルを作成する能力は、ある人とない人では、作業工数が10倍以上も違うように思えた。
つまり、デシジョンテーブル作成の生産性は、人によって大きなバラツキがあるわけだ。

【4】僕は、水準から因子を定義し、デシジョンテーブルを決めていく作業は、データモデリングの作業にも近いように思う。
なぜならば、それらの因子はテーブルの1項目に普通は対応しているので、項目間に関数従属性が発生し、その制約によってデータモデルが出来上がっていくからだ。

換言すれば、水準から因子を抽出して定義する作業は、組合せテスト技法だけでなくデータモデリングにも通じる技術ではないか、と思う。

しかし、「水準→因子の順番で整理してデシジョンテーブルを作る」という手順さえ理解すれば、新人のプログラマであってもすぐに慣れていくだろうと考えている。
組合せテストのようにテストケース作成の技術は、教科書を習うよりもたくさんの経験をこなす方が重要だ。
まずはたくさん試して、失敗もして、慣れた後に教科書を見直す方が、経験が整理されるので良いと思う。

実践した後に勉強するのがエンジニアの本来の道: プログラマの思索

| | コメント (0)

2022/11/16

XPエクストリームプログラミングは偉大だ~時代がその設計思想に追いついた

XPエクストリームプログラミング入門をオンラインで聞いた。
改めて、XPエクストリームプログラミングは偉大だ、時代がその設計思想に追いついた、と思った。
ディスカッションの内容から感じたことをラフなメモ。

【参考】
XPエクストリームプログラミング入門 - connpass

ITの地殻変動はどこで起きているのか?~チケット駆動開発はなぜ生まれたのか: プログラマの思索

僕は、「XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法 」の第1版の方が好きだ。
理由は、荒削りだが内容はとてもシンプルで、当初考えていた直感的な思いが直接的に表現されているからだ。

- eXtreme Programmingの魅力を探るにある「Embrace Change - 変化ヲ抱擁セヨ」のグラフが一番好きだ。

勉強会の内容は放談会みたいで面白かった。

XPはプラクティスありきではない。
プラクティスは具体的な実践方法。
プラクティスは価値を実現したものの一つ。
しかし、価値は抽象的すぎるので、プラクティスと価値の間に原則を置いて、プラクティスと価値を橋でつなぐ。
そういう絵がXPではよく出るが、その意味がようやく分かった。

XPのプラクティスは、そのテーマ単体だけで一冊の本になる。
たとえば、リファクタリングなら、リファクタリング(第2版)
テスト駆動開発なら、テスト駆動開発実践テスト駆動開発
継続的インテグレーションなら、継続的インテグレーション入門継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化
見積もり手法や計画ゲームなら、アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~
ふりかえりなら、アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き
シンプルな設計なら、エリック・エヴァンスのドメイン駆動設計
つまり、それぞれのテーマはとても奥深いのだ。

たぶん、それらのテーマは重要である、とケント・ベックは直感的に感じていたのだろう。
それを言語化して形式知としてプラクティスで取り上げたのはすごいと改めて思う。

福井さんいわく。
最初はスクラムは好きではなかった。
XPは具体的なのに、スクラムではプロセスはしっかりしているが、実際に実践しようとすると中身が分からない。
でも、今はスクラムは好きですよ、と。
スクラムはスクラムマスターの存在が凄く大きい、と。

アジャイル開発は自動車の運転のようなもの。
到着先は分かっていて、その道順が分かっていても、不確定要素があり、ハンドル操作で変化を受け入れながら進める。
つまり、運転は変化が全くない動作ではないし、変化を受け入れる動作範囲に落ち着くようにする。

時代がアジャイルにやっと追いついた。
アジャイラーは当初は周囲と戦っていた。
いかに導入するか、いかに普及させるか、に注力していた。
しかし、今はお客様からも、アジャイル開発を導入したいと言われる。

WF型開発の権化だったPMBOKがアジャイル開発の考え方を取り入れて、PMBOKの最新版でごっそり変わったのも大きいね、と。
実際、PMBOKは従来の分厚い数多くのマネジメント技法の知識体系だったのに、アジャイル開発の考え方を具現化して、価値や原則が主体のマネジメント体系に変わろうとしている。

アジャイル開発を支える技術が揃ってきたのも重要だろう。
特にクラウドが普及したおかげで、すぐにサーバーを立ち上げて、実際に動かしてみて、動かしながら作っていくのができるようになった。
それもコストをあまり掛けずに、個人ですら開発できるようになった。
つまり、継続的インテグレーション、継続的デプロイ、リファクタリング、テスト駆動、短期リリースなどを支える技術が揃ってきたおかげで、アジャイル開発を実践しやすくなった、と。

一方で、SIがアジャイル開発に追いついていないように思える、と。
発注者は自社で内製開発がしたいので、アジャイル開発を自然に受け入れやすい。
しかし、SIは受託なので、既に自分たちの標準プロセスを持っているし、人月単価のビジネスモデルもあるから、いきなりアジャイル開発に変換するのは難しい。

僕がXPやアジャイル開発に惹かれる最大の理由は、IT業界のきつい仕事から脱出できるための救いとして捉えていた面があったからだと思う。
多重請負の人月単価のビジネスモデルの中で、大量のプログラマや技術者をまるで仕掛在庫みたいに扱って、変動するバッファみたいに扱う手法がどうしても慣れなかった。
アジャイル開発は人重視であり、技術者の専門性を活かしながらチームでアウトプットを出していく、という思想に引かれていたのだと思う。
IT技術者として専門性を高めていくと自然にアジャイル開発に収れんされていくはずだ、と思っていた。
今もその思いは変わらない。


| | コメント (0)

2022/11/06

第23回東京Redmine勉強会の感想~コミュニティは仲間から生まれて続く #redmineT

第23回r東京Redmine勉強会の感想をラフなメモ。
3年ぶりのリアル会場でハイブリッド開催だった。

【参考】
第23回勉強会 - redmine.tokyo

2022/11/5 第23回redmine.tokyo勉強会 #redmineT - Togetter

Redmine Advent Calendar 2022 - Adventar

【1】リアル勉強会で嬉しかったのは、@yukiaさんと@shinyaさんに対面で会えたこと。

yukiaさんとRedmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論したことがあった。

Redmineのトラッカーをヘーゲル弁証法とフッサール現象学の観点で議論してみた - Togetter

Redmineのトラッカーは一般向けに説明が難しいよね、その原因は何か?
yukiaさんはヘーゲル弁証法の観点で、トラッカーは各人ごとの切り口でバラバラに使っているが、弁証法でより一層抽象化ないしもう一段上の抽象化レベルで議論すれば同じ概念だ、と話。
僕の観点では、フッサール現象学やプラトンのイデア論みたいに、トラッカーという概念は客観的に存在すると思われているが、各人の目線では、帳票設計だったり、チケットの種類だったり、ワークフローだったり、いろんな解釈で存在が認識される、という話。

yukiaさんは「強制エポケー」というフッサール現象学の言葉も知っているので、僕が言いたい内容ももちろん理解した上で発言されている。
懇親会ではあまり話せなかったけれど、この辺りももう一度話しみたい所。

shinyaさんの、塩漬けチケットを一気に却下したツイートを以前コメントしていたら、反応が多かった。
他にも退職者ツイートなど、面白いツイートがあったのですごく記憶にあった。

他にもリアル対面の人を認識できて良かった。

【2】前田剛さんの話では、RedMicaのお話と国民年金基金連合会がRedmineで作られていた話。
これには笑った。

Redmineで構築されている国民年金基金連合会の「他年金調査 事業所回答システム」を調べてみた - ファーエンドテクノロジー株式会社

他年金調査 事業所回答システム

実際にログイン画面を見れば分かるが、どう見てもRedmineだ。
日本企業の事業所は約300万と言われているらしいので、その事業所にいる社員数をRedmineで管理していると考えると、相当な数のレコードがRedmineに蓄積されていて、個人情報の観点でも非常にセンシティブな内容があるだろう。
Redmineなら安全に運用できるという判断があったのではないか。
このあたりの話も勉強会で聞けると嬉しいね。

【3】僕の話はチケット駆動開発の昔話。
あの頃は若かった。
なお、2020年頃からRedmineの勢いに陰りが出て、JiraやBacklogの勢いを感じている。
実際Googleトレンドではそんな感じ。

齋藤さんはTwitterを使っています: 「@akipii google トレンドの話に、興味を持ちました。JIRA / backlog 勢がほぼ同じような動きですね。 実際の日本でのシェアは、どんなもんですかね? #redmineT」 / Twitter

akipiiさんはTwitterを使っています: 「@saito0119 #redmineT 詳細は知らないですが、ネットやコミュニティの話を見聞すると、JiraやBacklogの勢いは感じますよね。」 / Twitter

中村さんの話は、Redmineを5.0にVerUpしたお話。
プラグインの互換性確認のために手間がかかったそうだが、@g_maedaさんやプラグイン開発者、パッチ提供者のおかげで無事に乗り切れた、とのこと。
Redmineコミュニティが活発であるからこそ、安心して運用できるわけだ。

@geosanak さんの話は、Redmineプラグインのテスト自動化を頑張っている話。
ビルド管理ツールはJenkinsからCircleCIまで色々あるが、GithubActionを使ったよという話。
詳細をもう少し聞きたかったが時間切れ。

@bowkoba さんのオフショア開発にRedmineを運用した時に、コミュニケーションの問題が発生した話は同感だった。
チーム運営、プロジェクト運営で発生する問題は、結局のところ、プロマネが伝える内容が伝わっていない、指示を仰ぐメンバーが理解できていないことに尽きる。
その問題はコミュニケーション不足の症状として現れるが、その根本原因と再発防止策は、それぞれの現場で異なる。
現在、アジャイル界隈では、DXを実現するための組織論の話が多いが、その観点も、このコミュニケーション不足の問題と同じ構造を持つと思う。
結局のところ、組織文化の問題として出てくるが、本当の真因は、プロセスや組織構造に根っこがあるわけだ。

@t_tsuru さんのRedmineUIの問題点は、従来から問題提起されてきた。
この問題の改善は、今後どんどん重要視されてくるだろうと思う。
他のPJ管理ツールやSaaSでは、チケットのコメントがリアルタイムに表示されたり、UIが今風で使いやすかったりするので、どうしてもその観点から比較されて敬遠されてしまうから。

チケット茶番劇も面白かった。
実際にチケットのやり取りを見るのは楽しい。
チケットを書く人がどんな気持ちでいるのか?
リアルで見えるのはいい。

@yokoba569さんの話では、チケット駆動開発が良かったよ!という話。
チケット駆動が楽しい!
Redmineが実績管理にとても向いていて、実際にデータをメンバー自ら採取して分析し始める。
見積もりと持ち工数の観点でPJ管理をどんどん改善しようとする。

@tohosaku さんはRedmine を railway にデプロイしてみた話。
@agilekawabata さんは、Redmineハンドブックの紹介。
わかりやすくてとても良い本です。

@tkusukawa さんは、Redmineを利用する趣旨のお話。
趣旨を説明するのはいつも大事。

@hiroiwsk6さんは、お役所の問い合わせ管理と帳票出力をRedmineで改善した時に、どんな設計で構築したのか、というお話。
問い合わせチケットのステータスごとに、送信メールが作られるのが面白い。
つまり、ステータスごとに、メールの内容や宛先が微妙に異なってくるので、メールテンプレートをいかに共通化して設計するかが肝なのだろう。

@naitohさんは、勉強会の参加者や利用Redmineの属性分析のお話。
もう8年以上蓄積されているので、Redmineにも波がある。

【3】今回はハイブリッド開催。
会場の参加者は26人くらいで、そのほとんどが常連さんで初めての方もチラホラ来られていた。
その後の懇親会では、久しぶりの再会を皆で喜んだ。

オンライン開催が普通になった今では、確かにZoomでやった方が正直楽だ。
しかし、会場開催の方が、反応を生で感じられるし、いろんな人達と交流できるのが楽しい。
生身の人間と肌感を感じるのがとても久しぶりだったから、本当にそう感じた。

Redmineコミュニティももう11年目で、他コミュニティに比べても古参になった。
スタッフや参加者も入れ替わりがありながら、よく続いているなと思う。
熱量がある人が入れ替わり立ち替わり居続けることで続いているんだと思う。
コミュニティは仲間から生まれて続く。

| | コメント (0)

2022/10/21

Javaのモジュールシステムの考え方をまとめてみた

Javaのモジュールシステムの理解が深まったのでメモ。
Java初心者のラフなメモ書き。

【1】モジュールシステムはなぜJavaで必要なのか?

異なるJarであっても、同一パッケージ名が衝突する問題があった。
モジュールは、パッケージを区別するための仕組み。
パッケージはクラスを包み込み、モジュールはパッケージを包み込む。

Javaはオブジェクト指向言語なので、機能追加したい場合、開放閉鎖原則に従って、既存クラスは修正せず新規クラスを追加する。
Rubyのオープンクラスみたいなもの。
すると、クラスがどんどん増えるので、パッケージでクラスを分類しようとする。
そして、パッケージをまとめたJarを配布して、開発者に利用してもらうようにする。

しかし、Jarファイルもどんどん増えてしまって、異なるJarなのに同一パッケージで衝突する場合がある。
Mavenでこういう依存ライブラリのJarを管理するけれど、名前衝突が多くなるのだろう。

【2】なぜ、無名モジュール、自動モジュールは必要なのか?

Java9以後はモジュールシステムを使う必要があるが、以前のJara8のJarファイルはモジュールに対応していない。
Java8のJarファイルを利用できるような環境としてモジュールが導入された。

基本は、Classpathにある無名モジュールが一般的だが、modulepathにないので、名前付きモジュールから無名モジュールを読み込めない。
そこで、modulepathにJarファイルを置いて、自動モジュールに変更して、名前付きモジュールから自動モジュールを読み込めるようにした。

実際の現場を見ると、Java8までで止まっているWebシステムは割と多いように感じる。
たぶん、Java9以後のモジュールシステムに対応するように、移植するのは難しい場面があるからだろう。

【3】無名モジュール、自動モジュールとは何か?

無名モジュールはJava9以前のJarで、Classpathにある。
以前のコマンドみたいに、java -cp **.jarみたいに使う。

なお、無名モジュールのJarはclasspathにあるので、名前付きモジュールから読み込めない。

自動モジュールはJava9以前のJarで、ModulePathにある。
java --module-path **.jar とか、java -p **.jarみたいに使う。

名前付きモジュール--> 自動モジュール、自動モジュール --> 名前付きモジュールの両方で読み込める。
なぜならば、modulepathに名前付きモジュールも自動モジュールも両方配置されているから。

なお、無名モジュールも自動モジュールも、パッケージのクラスは全て公開されているから、モジュールシステムのように公開の制限はできない。

無名モジュールはJDK9以前のライブラリ。
module-info.javaもMETA-INF/MANIFEST.MFもない。
ClasspathにJarを配置していると、java --module-path **.jarが使えない。

自動モジュールは、META-INF/MANIFEST.MFにAutomatic-Module-Name属性が指定されている or jarファイル。
JDK9以後は、java -p **.jarで実行する。

自動モジュールはできるだけMETA-INF/MANIFEST.MFにAutomatic-Module-Name属性を指定する。
なぜならば、Jarファイル名は書き換えられやすいので間違いやすい。
META-INF/MANIFEST.MFに記述すれば、Jarファイル名が書き換えられても呼び出されるJarは同じになるので安全。

【4】jlinkはなぜ必要なのか?

専用のランタイム用アプリを作りたい。
JDK9以後は、JREがないから。

さらに、クラウドのサーバーレス環境でアプリを実行する時、コンパイルしたアプリのサイズを小さくできる。
クラウドのリソースを抑えられるし、アプリの起動時間(ロード時間)も短くできるメリットが出てくる。
つまり、AWS lambdaみたいに、イベント駆動で多数のプロセスを並行起動するような場面では、アプリサイズが小さいほど性能も良くなるし、デプロイもやりやすい。

たぶん、クラウドの開発に特化するようにJavaも進化してきているのだろう。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

【5】jdeps --jdkinternal はなぜ必要なのか?

JDKの内部APIでクラスレベルの依存関係を検索するためのコマンド。
古いJava8のJarファイルがどんなJDKライブラリを使っているか調べるために使う。
Java9以後は公開されていないJDKライブラリは排除していくべきという考え方。

Java9のモジュールへ移行する時や、jlinkコマンドで小さい専用ランタイムアプリを作りたい時に利用できるだろう。

【6】なぜServiceLoaderは必要なのか?

ServiceLoaderは、Java9以前で依存性注入(DI)を実現する方法に過ぎない。
たとえば、Sampleインターフェイスだけ公開して、SampleImpl実装クラスは呼び出さないように実装したい。
META-INF/servicesに、実装クラスを記載したテキストファイルを作って、ServiceLoaderが読み込んで動的に切り替える仕組みにしただけ。

Java9のモジュールシステムでは、ServiceLoaderを利用する場合、module-info.javaにprovides~with~でIFを書いて公開する。

「公開IFの提供」をmodule-info.javaで宣言する => provides 公開IF with 実装クラス(SPIを実装)
「公開IFの利用」をmodule-info.javaで宣言する => uses 公開IF名(SPIとして使う)

ServiceLoaderはJDBCドライバの実装にも使われているので、わりと一般的。

【7】Javaのモジュールシステムは、Javaの進化でどのような意義を持つのか?

モジュールシステムは、Javaをクラウド開発に適用したり、デプロイしたモジュールやライブラリの移植性を高めるために必要なのだろう。
しかし、Javaは過去の遺産が多すぎるために、どんどん仕様が複雑になってきていると思う。

実際、Jarの依存性のエラーメッセージの種類が多くなっているために、問題解決するのは大変だろうと想像する。

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

一方、Javaはオブジェクト指向言語だけでなく、関数型言語の一面も持つ。
実際、OptionalやStreamなどのモナドのAPIはまさに関数型言語そのものだ。

Javaが関数型言語の特徴を持つようになった理由の背後には、クラウド上で多数のプロセスを並行で動かす時に、MapReduceの仕組みがあれば、負荷分散をより活用できるメリットを活かしたいからだろう。

Javaはオブジェクト指向言語ではなく関数型言語だった~「[増補改訂]関数プログラミング実践入門」はお勧めの本だ: プログラマの思索

Javaはなぜ関数型言語になろうとしているのか: プログラマの思索

JavaSilverの感想~Javaはオブジェクト指向と関数型言語の2つの性格を持つ: プログラマの思索

そんなことを考えると、20年前にUMLやJavaを使って、オブジェクト指向設計に熱狂していた時代はもう古くなっている。
そういう価値観はもはや終わったように思える。
そして、時代は更に進化しているわけだ。

一方、その進化はどんどんソフトウェアの複雑性を増やす。
ソフトウェアの本質は複雑性にあるが、その複雑性をどのように手懐けてコントロールすべきなのか?
今も昔もソフトウェア開発はこの問題から逃れられない。

| | コメント (0)

2022/09/24

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルが公開されていたので自分用にメモ。

【参考】
CATとは? :: CATマニュアル

TestRail ドキュメント

QualityForward マニュアル

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか: プログラマの思索

TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索

2022年現在、日本で有償のテスト管理ツール導入を考えた場合、上記の3つに絞られるのではないだろうか。
理由は、3社ともに日本の開発元、販売元であるので、サポートを受けやすいためだ。

僕としては本来はOSSのTestLinkを使いたいが、やはり使いにくい場面も多い。
上記3つの有償のテスト管理ツールはUIもよく考えられていて、マニュアル無しでもソフトウェア開発チームならばすぐに導入できるだろうと思う。

個人的印象では、CATとQualityForwardはExcelテスト仕様書のUIイメージに近い。
だから、Exccelのテスト仕様書をWebに置き換えただけ、という感覚で使える。

一方、TestRailは、テストケースを全てWeb上で一括管理するためのツールだ、という特徴を強く押し出している。
Web上でテストケースを追加したり更新したり、Redmine障害チケットと連動したりするUIがすごく使いやすい。
Redmineがチケット管理をWebに置き換えたように、TestRailはテストケース管理をExcelからWebへ完全に置き換えたイメージに近い。

よって、僕の感覚ではTestRailが好きなのだが、やはりテストケースは数千~数万も登録する必要があるので、そのままでは現場で使えないと思う。
そこで、事前にCSVやXMLで大量のテストケースを作り込んで一括インポートし、実行フェーズではTestRailで運用する、というやり方が一般的ではないか、と推測している。
つまり、TestLinkを運用する時と同じように、事前にExcelテストケースは準備し、一括インポートした後、テスト実施管理はTestLinkでやる、みたいな感じだ。

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルをより詳しく読んで理解したいと思う。

| | コメント (0)

2022/09/04

「Googleのソフトウェア・エンジニアリング」の感想

Googleのソフトウェアエンジニアリング ―持続可能なプログラミングを支える技術、文化、プロセスを読んだのでラフなメモ。


「Google社内でときに言われるのは、「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」ということだ。」という文章がとても印象的。
ソフトウェアの複雑性は、積分された面積で表現されるとすれば、保守性や移植性などのソフトウェア品質特性を維持するために、それをいかに増大させないようにするか、という問題につながる。

そのために、コーディングルール、開発環境、テスト自動化、継続的インテグレーション、継続的デプロイ、テスト環境のコンテナ化、など色んな技術とそのノウハウが出てくるわけだ。

スケールとトレードオフ:「Googleのソフトウェアエンジニアリング―持続可能なプログラミングを支える技術、文化、プロセス」を読んだ - mamo.memo

Book Talk:『Googleのソフトウェアエンジニアリング』をぼくたちはこう読んだ!(前編)|グロービス・デジタル・プラットフォーム|note


| | コメント (0)

2022/07/30

テスト管理ツールTestRail、CAT、QualityForwardの感想

テスト管理ツールに触った経験が少しだけあった。
TestRail、CAT、QualityForwardの感想をラフなメモ。

【参考】
テスト管理ツール TestRail | ソフトウェア品質保証 | テクマトリックス株式会社

CAT | テスト管理ツール | 株式会社SHIFT

テスト管理ツールQualityForward|ソフトウェアテスト・第三者検証のベリサーブ

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか: プログラマの思索

TestLinkがExcelのテスト仕様書よりも素晴らしい点: プログラマの思索

脱Excel! TestLinkでアジャイルにテストをする:エンジニアがお薦めする 現場で使えるツール10選 - @IT

SEA関西プロセス分科会講演資料「TestLinkのベストプラクティス~日本の品質管理技術を見直そう」

ETWest2009講演資料「TestLinkでアジャイルにテストする」

【1】欧米製のテスト管理ツールと日本製のテスト管理ツールでは、やっぱり発想が全く異なる。

TestRailはドイツ製。
テストケースは全てWeb上で管理する。
Excelのテスト仕様書は完全に廃棄される。

だから、TestRailではWeb上のUIが非常に使いやすい。
テストケースをツリー構造で表したり、Redmineの障害チケットと連携したり、テストケースをフィルタリングするのがやりやすい。
UIはTestLinkよりもはるかに使いやすい。

一方、CATやQualityForwardは日本製。
Excelのテスト仕様書をそのままインポートして、UIもExcel上のテストケースと全く同じ。
たぶん、従来の日本のソフトウェア開発チームならば、普段はExcelでテストケースを管理しているので、運用しやすいだろう。

【2】TestRailとCATやQualityForwardの大きな差は、テスト集計機能の有無にあると思う。

CATでは、SubversionやGitと連携する機能があるのでソースコード行数を保持できる。
だから、テスト密度、バグ密度を表示する機能もある。
また、信頼度成長曲線、PB曲線も表示してくれる。
つまり、日本のSIが品質管理で使いたいと思う機能は、一通り実装されている。

QualityForwardでも、PB曲線は表示される。
またカバレッジパネルという機能もある。
これは、テストケースの項目別集計に対し、テスト結果の割合を表示して、どれくらいテストを消化したのか、バグが多く出ているのか、などを表示する。

一方、TestRailでは、テスト集計機能はほとんどない。
テスト結果の状況を表示するサマリ画面はあるので、テスト状況をさらに細かくドリルダウンすることはできる。
また、バーンダウンチャートもあって、テスト時間を計測すれば、予実で表示されるみたい。
しかし、基本は、REST APIでBIツールに取り込んでもらうか、CSV出力して自分で集計してもらうことが必要。

【3】こういう内容を書くと、日本製のテスト管理ツールの方が良さげに見えるが、僕はTestRailの方が使いやすそうに思えた。

実際に画面に触れてみれば分かるが、TestRailの方がRedmineのようなUIに近い。

TestRailのマイルストーンは、Redmineのバージョンと同じ。
TestRailのテストケースは、Redmineのチケットと同じ。
そうみなせば、Excelのテスト仕様書はいらない。
そもそも、Redmineを使い始めたら、ExcelでWBS管理や課題管理はやらなくなる。
それと同じ。

日本製のテスト管理ツールにはテスト集計機能があるので、色々使えそうと思ったが、罠も多い。

まず、テストケースや障害チケットの粒度を揃えたり、テストケースや障害チケットの分析項目を標準化したり、集計する以前の前処理にすごく手間はかかる。
本来は、テスト作業やテスト成果物は標準化できていればよいが、やはりシステムごと、案件ごとに微妙にカスタマイズされているので、その辺りに規制をかける必要がある。

また、信頼度成長曲線をツール上で表示する時、障害チケットをインポートするタイミング以降でしかグラフを表示してくれない。
つまり、テストを始める前に、テスト管理ツールとRedmineを連携しておく必要がある。
テスト途中でRedmineと連携する設定を行うと、インポートする日以前のバグ発生数のグラフが表示されない事象が発生する。
なぜそんな仕組みなのか分からないが、Redmineチケットのカスタムフィールドをテスト管理ツールに取り込めないケースもあるし、信頼度成長曲線のグラフで表示したい日付情報をチケットのカスタムフィールドで対応できないケースもあるからだろう。

テスト密度やバグ密度も表示されるのは便利だが、結局、そのデータの妥当性を精査する必要があるし、テスト密度やバグ密度が基準範囲から外れていれば、細かく原因分析する必要がある。
よって、ツールで集計されたデータをそのまま鵜呑みにはできない。

そんなことを考えると、テスト管理ツールもRedmineと同じく、テスト管理の予定と実績を蓄積するのに専念し、テスト集計機能はBIツールを使ったり、自分でExcelやRで集計するように、作業を分離した方が良いと考える。
集計して分析する作業はどうしても標準化できないから。

【4】まとめると、TestRailはExcelのテスト仕様書を完全になくしてWeb上で完結する。
Redmineライクな感じ。

一方、CAT、QualityForwardはExcelのテスト仕様書をそのままインポートできるので、ExcelをWeb上で触っている感じ。

たぶん、日本のIT企業のテスト管理や品質管理は機能の網羅性テストを重視していて、欧米のIT企業のテスト管理は機能の充足よりもいちはやくリリースできる品質を担保する観点を重視する、という違いが出ているように思えた。
この辺りに、日本人の品質管理の思想と欧米のアジャイルな品質管理の思想の違いを感じる。

とはいえ、テスト管理ツールは発展途上のツールと思うので今後も見ていく。

| | コメント (0)

2022/06/29

メトリクス分析のコツは良いIssueを見つけること

メトリクス分析のコツは良いIssueを見つけることと思う。
ラフなメモ。

【参考】
DXの本丸は「データ」にあり 「問い」からはじめるデータ分析とその活用法 - ログミーBiz

データ分析から導き出す「強い野球チーム」のつくり方 映画『マネーボール』で学ぶデータサイエンス - ログミーBiz

akipiiさんはTwitterを使っています: 「ソフトウェア工学のメトリクス分析の考え方にも適用できるので参考にする。データ分析から導き出す「強い野球チーム」のつくり方 映画『マネーボール』で学ぶデータサイエンス - ログミーBiz https://t.co/ZmCzuVEIUy」 / Twitter

akipiiさんはTwitterを使っています: 「データ駆動はイシュー駆動。良い問いが解決策を生み出す。メトリクス分析も同じだな。DXの本丸は「データ」にあり 「問い」からはじめるデータ分析とその活用法 - ログミーBiz https://t.co/XRe7ceo6u0」 / Twitter

【1】問題解決を図るときに、定量データを扱うのは有効だ。
最近は、Webログやスマホ履歴のようにビジネスの副産物として簡単にデータを集められる。
すると、溜まったデータをいかに活用するか、が大事になる。

『マネーボール』という映画では、貧乏球団が強いチームを形成するのに必要な問題は、「出塁率の最大化」だった。
そこに問いの価値がある。
選手の人間性、選手の組み合わせ、とかそんな観点の問題ではなかった。
問いを「出塁率の最大化問題だ」と立てられたら、あとは、バッター個人のデータを分析して、確率論に持ち込めばいい。

つまり、良い問い(Issue)を把握するのが大事。
良いIssueは数字で答えたくなる。

良いIssueを探るには何が必要なのか?

顧客行動の理解ならカスタマージャーニーを使う。
お客さんがその商品を購入したいと思うタイミングとか、ファンになるまでのステップごとに定量データを集めて分析する。
そうすれば、どこでユーザが離脱するのか、どこでユーザの満足度が低いのか、が浮き彫りになってくる。
これを業務システム開発に置き換えれば、一連の全体の業務フローを描いて、それぞれのステップごとに分解することになるだろう。

次はこれをどうやって定量化していくか?

KPIツリーによる指標分解を使う。
売上=客数x客単価。
顧客数を=認知人数×購入率、みたいに分解していく。

掛け算か足し算で異なる。
掛け算では、2つの指標を独立だとみなす。
足し算はセグメントに分ける。

基本は、カスタマージャーニーマップのステップごとにKPIツリーで分解していく。
この辺りのプロセスは、ECサイトの分析であるAARRRの手法と全く同じ。

【2】ソフトウェア開発プロセスのメトリクス分析でも、同じような考え方を適用できる。

たとえば、WF型開発のPJであれば、工程ごとにゲートがある。
各ゲートに着目してQCDの観点でメトリクスを作ることはできる。

では良いIssueとは何なのか?
Issueをどうやって解決するのか?

良いIssueを見つけるのが大事。
イシューから始めよ」の通り、質よりも量で頑張ると、生産性が非常に悪い。
大量にアウトプットを出しても、正解にたどり着くルートはせいぜいそのうち5%ぐらいしかない。
そうならば、事前に本来のIssueを絞り込んで、生産性を高めるべき。

メトリクス分析では、良いIssueを立てて、そこからKPIツリーで分解した各要素のどこにインパクトがあるのか、を見るのが大事。

| | コメント (0)

より以前の記事一覧