TestLink

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/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)

2021/06/23

TestRailの感想

人類よ!これがテスト管理ツールだ!テスト管理ツール天下一武道会がついに開催! - connpassを視聴してみて、最近のテスト管理ツールについて興味を持った。
ラフなメモ。

【参考】
人類よ!これがテスト管理ツールだ!テスト管理ツール天下一武道会がついに開催! - connpass

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

そうだ TestRail を使ってみよう。 - Qiita

TestRail 入門 [TestRail Documentation]

10年前にTestLinkを一通りいじくり倒した経験があるので、テスト管理ツールの良し悪しは知っているつもり。
今回のイベントで、有償のテスト管理ツールのTestRailに興味を持った。

TestRailの良い点は、UIがとても使いやすいこと。
マニュアルがなくても、テストケースを作ったり、テスト結果のOKやNGを登録したり、サマリを見る、とか、直感的に操作できる。
テスト管理ツールはどれも、複雑な操作が割と多くて使いにくい。
だから、使いやすいUIはとても重要。

もう一つは、TestRailは外部接続APIが豊富なこと。
デモでは、TestRailsでAutomation機能を有効にした後、mablで自動テストを実行させて、その結果をTestRailに登録し、結果がNGならBacklogに起票して、その通知をSlackに流す一連の操作が、全て自動化されていた。
TestRailのREST APIを使って、Pythonスクリプトで操作したらしいが、こういう一連の自動テストの実行と結果の記録、バグチケットの起票、チャットへの通知はよくある利用シーンなので、とても面白い。

最近は、テスト自動化がかなり当たり前になってきた状況もあるので、ビジネスロジックのxUnitをJenkinsで定期実行して、その結果をTestRailに記録させる、とか、UIテストの自動化ツールmablを使う、とか、色んな利用シーンがある。
テストでは、バグチケットの起票、テスト結果の通知はできるだけリアルタイムに共有したいので、こういう一連の操作が自動化できる方が断然良い。

開発プロセスの改善という観点では、チケット管理システムの分野は既に当たり前になってきているが、テスト管理の部分はまだ未開拓の分野が多いように思う。
だからこそ、数多くの有償ツールが出回って、いろいろアピールしているのだろうと思う。
この辺りは、調べて見る価値はありそう。

| | コメント (0)

2020/11/02

テスト管理ツールに必要とされる機能要件は、欧米と日本で異なるのではないか

テスト管理ツールに必要とされる機能要件は欧米と日本で異なるのではないかという記事を見つけたのでメモ。

【参考】
欧米のテスト管理ツールとCATにおける、要求の違いについて - CAT Tech Blog

TestLink利用に際して参考になるブログ - misc.log

テスト工程の管理をするツール、TestLinkについて - Qiita

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

テストを育てるためにテスト管理ツール「TestRail」を使ってみた | 「世界」旅と子育てを愛するアジャイルコーチのブログ

ちょっと今、テスト管理ツールをもう一度調べている。
10年前はTestLinkを使っていて、それなりにテスト管理の技法は研究していた。
しかし、TestLinkそのものに不満が色々あって、結局使わなくなってしまった。

とはいえ、テスト管理をExcelでやるのは時代遅れ。
テスト管理のように、数千~数万のテストケースの予実管理を行う管理作業こそ、ツールで自動化すべきだ。
なのに、なぜ、特に日本では、テスト管理の重要性は知っているにも関わらず、テスト管理ツールが普及しないのか?

上記の記事では、欧米と日本では、品質に関するリスク管理の観点が異なるからではないか、と指摘している。
欧米では、シェア確保と先行者優位を優先するので、品質よりも市場投入のタイミングを重視する。
よって、品質よりリリースタイミングを優先し、バグがあれば機能制限を設けたりする。

一方、日本では、リリースタイミングよりも、予定されていた機能の品質が担保できていることを重視している。
なぜなら、いくら機能が良くても品質が悪ければ、クレームの嵐になり、ブランド価値が毀損されるからだ。
つまり、日本では、製品の機能と品質は表裏一体とみなす。

この違いから生じる、テスト管理ツールへの要件は何か?
欧米では、重要な利用シーン(ストーリー)をベースに品質を評価する。
よって、ストーリー(シナリオ)を分割し、テストケースのタイトルにStep1、Step2の順に確認項目を記載し、テストを実行していくGUIになる。

一方、日本では、機能テストをベースに品質を評価し、全項目で一定の品質を確保する必要がある。
よって、全ての機能を網羅したテスト仕様書がまず準備されて、各テスト項目はかなり詳細に手順や確認項目を書き込み、1つずつ潰していく。

上記記事にあるTestLinkのテストケース編集画面と、CATのテストケース編集画面の違いが面白い。
TestLinkでは、テストケースのタイトルがツリー構造で表示され、その一つを選ぶとポップアップされ、テストケースを編集する。
一方、CATでは、テストケース編集画面はExcelの表形式と全く同じ。

確かに、TestLink、あるいはTestRailsでも、テストケースのタイトルが一覧表示されていて、その詳細はポップアップで編集するイメージだ。
なぜなら、ストーリーベースなので、テストケースの詳細を見なくても、業務のストーリーを元に、その手順を踏めばいい。
テストケースをグルーピングする機能の方が重要だ。
つまり、欧米のテスト管理ツールでは、テストケースの粒度は荒い。

一方、日本のテスト管理では、機能ベースで全てのテストケースを網羅すべきというプレッシャーがあるので、テストケースの粒度はかなり細かい。
テストケースをテスト観点のカテゴリで分ける方が大事だ。
ゆえに、テスト管理ツールでテストを実行する場合、テストケースの詳細をじっくり読み込まないと、テスターはテストできないだろう。

おそらく、日本のテスト管理では、テストケースをグルーピングする機能よりも、テストケースにハッシュタグを付ける、とか、ツリー構造で階層化する機能の方が重要なように思える。
なぜなら、機能ベースのテストケースでは、グルーピング機能を強化しても、ツリー構造が深くなるので、肝心のテストケースを表示させるためのUIの導線が複雑になりやすいからだ。

TestLinkは個人的には好きだったが、テストケースの元ネタとなるテスト仕様書はExcelで作りこんでTestLinkにインポートしたり、テストケースを一括編集する時はTestLinkからExcel出力した後でExcel上で一括編集して再度TestLinkに取り込む、などの作業をしていたのを思い出した。
つまり、TestLinkというテスト管理ツール上でそういう作業はやりにくかったのだ。
すなわち、日本では品質を担保するためのテスト管理の概念が違う点が、根本原因にあったのだろう。

テスト管理ツールの利用、という古くて新しい問題については今後も色々考える。


| | コメント (1)

2017/06/01

TestLinkにExcelのテスト項目書をインポートする方法

TestLinkにExcelのテスト項目書をインポートする方法の記事があったのでメモ。

【参考】
【TestLinkでナレッジ蓄積】Excelからテスト項目書をインポートする方法 | Ques

MrBricodage/TestLink--ExcelMacros: Excel files containing Macros that handle XML files compatibles with TestLink

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク: プログラマの思索

TestLink

(引用開始)
TestLinkはExcelから直接インポートできない

TestLinkのインストール作業手順は、インストール方法の記事や書き込みが多いため、
ここでは省略させて頂きます。

TestLinkを使う上で苦労した点はテスト項目書からのインポート作業になります。

TestLinkへインポートするにはXML形式に変換する必要があります。
弊社のテスト項目書(ナレッジ)の多くはExcelで作成されており、
Excelの内容は直接TestLinkへインポートすることができません。
TestLinkへインポートするには、一度、Excel形式からXML形式に変換する必要があります。
TestLink上にて、テストケースを手入力で入力することは可能ですが、
数あるテスト項目書を手入力で行うと時間がかかるため、
短時間で行うには補助ツールが必要になります。

テスト項目書のインポート/エクスポートを補助する便利ツール

ExcelからXMLに変換し、XMLからTestLinkへインポートするには、
Excel→XML変換ツールが必要になります。
また、TestLink上のテスト項目書を編集する場合、
TestLink上よりもExcel上で編集できた方が楽です。
TestLinkにはエクスポート機能があり、実行するとXML形式で保存できます。
エクスポートデータをExcelで編集するにはXML→Excel変換ツールが必要になります。

そこで、下記の両方を行うことができる補助ツールを探してみました。

Excel→XML変換
XML→Excel変換

昔は「TestLinkCnvMacro」という補助ツールがありましたが、今はありません。
今回は「TestLinkCnvMacro」の代わりに、
海外のツールですが、「02-ImportTestCasesIntoTestLink.xls」を使います。
(引用終了)

02-ImportTestCasesIntoTestLink.xlsの使い方は、上記の記事にある。

TestLink上からXML出力
→encoding=”UTF-8″を”Shift-jis”に変更して保存
→文字コードを「Shift-jis」にして保存
→02-ImportTestCasesIntoTestLink.xlsへインポート

02-ImportTestCasesIntoTestLink.xlsからXML出力
→encoding=”ISO-8859-1″を”UTF-8″に変更して保存
→文字コードを「UTF-8」にして保存
→TestLink上でXMLインポート

| | コメント (0)

2016/03/12

TestLink Tutorialのリンク

TestLink Tutorialのリンクがあったのでメモ。

【参考】
TestLink Tutorial: A Complete Guide

前文英語だが、画面キャプチャがあるので、操作方法は分かる。
チュートリアルの目次は下記の通り。

(引用開始)
In this tutorial we will learn
・Advantages of TestLink
・Login to TestLink
・Creating a Test Project
・Creating a Test Plan
・Build Creation
・Creating Testsuite
・Creating a Testcase
・Assigning test case to test plan
・Creating Users and Assigning Roles in TestLink
・Writing Requirements:
・Executing a test case
・Generating Test Reports
・Export Test case/ Test Suite
・Importing Test case/ Test suite
(引用終了)

但し、コメントを読むと、SMTPのメール設定、RedmineやMantisとの設定、Jenkinsからのテスト結果の自動登録などの方法は記載されていないので、注意。
あくまでも初心者向けに、TestLinkはこんなことができるよ、という説明。

| | コメント (0)

2016/01/31

TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法

TestLinkで手動テストや自動テストの結果を統合してレポートさせる手法が公開されていたのでメモ。

【参考】
TestLinkで手動テストと自動テストを統合する : Jenkins編 - Qiita

TestLinkで手動テストと自動テストを統合する : JUnit編 - Qiita

TestLink

TestLink Cloud Hosting, TestLink Hosting - Installers and VM

TestLinkOpenSourceTRMS/testlink-code: TestLink Open Source Test & Requirement Management System

TestLinkのdocker imageをdockerhubにアップロードしてみた - Qiita

Unitils ?

TestLink Plugin - Jenkins - Jenkins Wiki

ootaken/TestLinkJenkinsIntegration: sample of integration of TestLink and Jenkins

(引用開始)
そのような徐々に自動テスト化していく中では手動テストと自動テストを同時にリグレッションテストやスモークテストとして行ったりするので、両方をまとめて管理したい、まとめて状況を見たいというお話をマネージャーさんからリクエストされることが度々あります。
私にそんな話が来るぐらいと言うことは世の中でもそういうニーズがあるに違いない、そもそもHPのQuality CenterやIBMのRational Quality Managerのような商用のテスト管理ツールにはそういう機能ありますね。
でも、そのためだけに商用を買うのも・・・っていうことで、俺たちのOSSテスト管理ツールのTestLinkにもそういう機能がありました。
というのでTestLinkの自動テスト統合機能を調査してみましたのでまとめてみます。
(引用終了)

上記の手法は、JUnitでテスト自動化した結果をTestLinkに取り込んだり、Jenkinsのビルド結果をTestLinkに取り込んで、そのテスト結果や分析結果をTestLink上で表示させる手法だ。
方向性としては、TestLinkにはAutomationという設定があり、自動テスト結果を取り込むAPIやUIが用意されているので、それを使うというアイデアだ。

なぜそんな手法が必要になるのか?
プログラマとしては、テスト結果は終わった結果なので、そこまで興味があるわけではない。
しかし、マネージャや品質保証部の担当者としては、最新のテスト結果が欲しかったり、日々のテスト結果の履歴から品質分析したいという要望がある。
つまり、マネージャなどの利害関係者向けに、テスト結果のレポートツールが必要なわけだ。

そこで、テスト結果のレポートツールとしてオープンソースのTestLinkがあり、TestLinkの自動テスト結果取り込み機能を使えばうまくいくわけだ。

上記の記事を読むと、設定方法には色々な試行錯誤がいるようだが、利害関係者に見せるには十分な機能だろうと推測する。

TestLinkに一度データが入れば、TestLinkに溜まったテストデータを解析すれば、色んな知見が得られる可能性もある。

最近の僕はTestLinkの情報を追いかけていなかったが、2016/1時点で、Ver1.9.14までマイナーバージョンアップされているようだ。
この辺りの情報も調べてみたい。

| | コメント (0)

2015/03/14

エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること

長沢智治さんの記事がとても素晴らしいのでメモ。
以下は主張のないラフなメモ書き。

【参考】
オピニオン:長沢智治: エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider

(引用開始)
エバンジェリストは、マーケティング活動の一環のため、「市場を作り、成熟させる」ことが求められてしかるべきである。
(中略)
従ってエバンジェリストの活動とは、「自分が携わっている製品や技術の詳細を伝える」ことではなく、「世界観を伝える、つまり市場の変遷であったり、トレンドであったり、その中での製品や技術の立ち位置であったり、コンセプトであったりを伝える」ことが第一だと考える。「世界観」についてのコンセンサスを現場で持てたなら、きっとその現場は、自分たちに合った解を議論と体験の中から導き出せるはずだ。
(引用終了)

akipiiさんはTwitterを使っています: "すごく良い記事。エバンジェリストが訴求するのは製品や技術ではなく市場を開拓すること。オピニオン:長沢智治: エバンジェリストの頭の中 ― 世界観を訴求するわけ - Build Insider http://t.co/mn9H0d4ud3"

【1】僕は、RedmineやTestLink、iDempiere、vTigerCRMなどのオープンソースのツールが好きだ。
自分たちで使いこなすうちに、どんな場面で利用すると効果が出るのか、が分かってくる。
使いこなすうちに、自分たちの世界がグレードアップする感覚が好きだ。

そして、じきに新たな課題を感じ取る。
では、その課題とは何なのか?

それは単に、そのツールだけでは解決できない課題という意味だけではない。
そのツールを使いこなすことで、アウフヘーベンされ、本来の問題の本質が見えてくる、という意味の方が強い。

ツールで得られた現場の経験知をモデル化していくうちに、そのモデルがどんな問題にフォーカスしているのか、そのモデルが対象とする問題解決のスコープとその限界が見えてくるのだ。

【2】そんなことを考えながらツールを使っていくと、そのツールの熱烈なファンになる。
こんな機能が欲しい、もっと使いやすくしたい、他のツールに似た機能があるといいな、とか、色んな欲求が出てくる。
あるいは、このツールはこんなにすごいんだよ、と他の人に薦めたくなる。

エバンジェリストの役割は、そのツールを宣伝することだ。
エバンジェリストの影響力が大きいほど、ツールを使うユーザ数も増える。

しかし、その方向性が行き過ぎると、そのツールのライバル製品をけなしてしまう言動をしてしまう時がある。
熱烈なファンがそのツールしか眼中に無く、他のツールの良さまで見えなくなってしまう危険があるのだ。

パッケージ製品のベンダー、オープンソースのツールやパッケージ製品を販売するエバンジェリストは、そのような落とし穴に嵌る時があるのではないか。
僕自身、そんな時があったなと反省するときもあった。

【3】上記の長沢さんの記事では、エバンジェリストは、単にツールを宣伝する人ではなく、ツールが提供されるマーケットを開拓する役割を持つことを主張されている。
その意見は、思わず、そうだよ、と納得した。

ライバル製品との機能比較、製品の持つ新しい技術や仕様などの細部の話が全てではない。
むしろ、エバンジェリストが持つ世界観を世の中に提示すべき。
では、その世界観とは何なのか?

それは、市場の変遷や技術の変遷の中で、そのツールがもたらす新しい価値とは何なのか、を提示すること。
つまり、製品や技術のような枝葉末節の話ではなく、ツールがもたらす価値が現場のどんな問題を解決し、どんなステージを提供するのか、という価値観を提示することだ。

そんな世界観や価値観をエバンジェリストが世の中に提示することで、現場で従来は解決できなかった課題がクリアされる。
あるいは、ツールを導入する前はそもそも、そんな課題すら認識しておらず、問題意識も持っていなかった人もいるに違いない。

そんな人達に、ツールがもたらす価値やメリットを提示して、潜在的なニーズを掘り起こし、問題意識すら持っていなかった新たなユーザ層を獲得し、市場をどんどん広げていく役割がエバンジェリストに求められるわけだ。

市場を開拓し広げていくことで、ユーザから製品へのフィードバックも増えて、製品もどんどん改良されていく好循環も生まれる。

オープンソースの製品もパッケージ製品と同様に、利用ユーザが集まるコミュニティが活発に活動するほど、コミッタと利用ユーザの間で有意義な議論が行われ、製品のあるべき姿が見えてくる。
製品がどんな場面で有効に使えるのか、という利用シーンが明確になるだろう。

更には、製品がもたらす価値のスコープが見えてくることで、製品の新たな課題も見えてくるだろう。
その新たな課題は、製品がどんな方向に進化すべきか、というロードマップに大きく影響するだろう。

個人的な妄想としては、オープンソースの製品群を連携させた一連の「プロジェクト管理サーバー」のような概念を提示し、それがソフトウェア開発プロセスを進化させていることを明示したいなあ、と思っている。

| | コメント (0)

2015/02/22

「実験的アプローチによる改善活動」の記事のメモ

「実験的アプローチによる改善活動」の記事がとても参考になるのでメモ。

【参考】
第162回 実験的アプローチによる改善活動(全4回の第1回)|SQiP:Software Quality Profession

第163回 実験的アプローチによる改善活動(全4回の第2回)|SQiP:Software Quality Profession

パイロット開発にAgile開発のアイデアを適用した事例~実験的アプローチ #JaSST_Kansai: プログラマの思索

実験的アプローチによる現場改善~JaSSTソフトウェアテストシンポジウム-JaSST'13 Kansai

akipiiさんはTwitterを使っています: "同感。手段が問題を具現化する。特にITはそう。「ある手段を知らない状態では、課題と感じないような部分が、実は大きく改善できるポイントがあるケースが多いから」第163回 実験的アプローチによる改善活動(全4回の第2回)http://t.co/oya8EMekoB"

【1】(引用開始)
よく、「手段を目的化してはだめだよ」と言われます。私は、それは正しいと考えていますが、「最初にまず目的を考えて、それに合った手段を考えなければならない」か、と言うと、必ずしもそうではないと考えています。
なぜかというと、ある手段を知らない状態では、課題と感じないような部分が、実は大きく改善できるポイントである場合があるからです。

実験的アプローチによる改善活動では、日常的になるべく多くの「筋が良い手段」を効率良く収集することと、反復活動の中で小さな課題を抽出することで、日々の活動の中で、「あ、前に収集した手段で改善できる課題がありそうだ」「あ、今課題になっていることに、あの手段が使えそうだ」というように、なるべく小さな粒度で課題と手段を相互に結び付けます。
(引用終了)

新しいツール、道具、手法を知ることで、新たな問題や課題を感じ取り、その課題を解決できるように手段を適用していくやり方は、僕は好きだ。
IT業界の技術革新の流れを振り返れば、このパターンによる解決がかなり多いのではないか、と思う。

【2】僕の経験としては、RedmineやTestLinkを使いこなすことで、アジャイル開発やテスト管理で感じていた諸問題に適用できる!と気づいて、色々試すことができた。

オープンソースのツールは、簡単に試せるし、中身のソースも読めるから自分なりに改造もできる。
また、ツールのコミッタと議論すれば、自分が抱えている問題を解決するような機能改善を実現してくれる場合もある。
さらに、オープンソースのツールを使う人達と議論すれば、新たな利用シーンで別の問題を解決してくれる事例に気づかせてくれる。

実際、RedmineやTestLinkのコミュニティで議論して、色んな機能が改善された場合もあったし、Redmineをこんなシーンで使うのか!という気付きを得た時もあった。

僕は、オープンソースのツールを使って、業務プロセスやソフトウェア開発プロセスを改善ないし変革する手法が好きだ。
ソフトウェアは単なるツールではない。
ソフトウェアを導入すれば、運用が変わり、不要な人員や役割が削除されて組織も変わり、人の行動すらも変わっていく。

プログラミングだけでなく、作ったシステムが人に影響を与えて、人の行動や価値観すらも変えてしまう所にすごく興味がある。

【3】そんな経験を踏まえて、僕が今考えているアイデアはいくつかある。
一つは、Redmineというツールを色んな角度で分析することで、どのような方向へ発展すべきか、という問題意識を持っている。

Redmineが今後発展する方向のアイデア: プログラマの思索

もう一つは、ERPやCRMのオープンソースのツールを使いこなすことで、中小企業向けの業務に適用して、業務の効率化や業務改革を行えないか、という問題意識がある。

オープンソースの業務アプリケーションを組合せてERPを構築するアイデア: プログラマの思索

ERPはなぜ難しいのか?~オープンソースERPで業務改革を試したい: プログラマの思索

オープンソースCRM「vtigerCRM」の資料: プログラマの思索

この辺りも試してみたいと思っている。

【追記】
残り2回の記事も公開されている。
第3回の記事では、原因結果グラフとテスト駆動開発の組合わせに関する実験結果も書かれていて、非常に興味深い。

第164回 実験的アプローチによる改善活動(全4回の第3回)|SQiP:Software Quality Profession

第165回 実験的アプローチによる改善活動(全4回の第4回)|SQiP:Software Quality Profession

| | コメント (0)

2014/11/16

TestLinkのインポート用ExcelマクロImportExcelMacroのリンク

TestLinkのインポート用ExcelマクロImportExcelMacroのリンクをメモ。

【参考】
MrBricodage/TestLink--ImportExcelMacro

TestLink Open Source Test Management

TestLink - Open Source Test Management - Gitorious

TestLinkの資料リンク: プログラマの思索

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

以前は、日本のTestLink有志がTestLinkCnvMacroを公開していて、そのExcelマクロを使えば、テストケースの一括登録&一括修正、テスト実績や要件の一括登録&一括修正ができた。
このツールがなければ、TestLinkの画面上で数百~数千のテストケースを逐一手作業で登録しなければならないから、非現実的だった。

しかし、そのマクロも公開されなくなり、TestLinkのバージョンも上がってしまい、テストケースを一括登録する方法がよく分からなくなった。
TestLinkの1.8以降では、ExcelからXML出力したファイルを読みこませれば良かったらしいが、時々うまくいかない時があったから。

だから、TestLinkのインポート用ExcelマクロImportExcelMacroには期待している。
使い方のPDFを読むと、Excelでテストスイートで階層化したテストケースも読み込めるようだし、要件とテストケースを紐付ける機能もあるみたい。

テスト管理は、Excelとテスト管理ツールの連携が一番重要だと思う。
やはり、テストケースの元ネタはExcelで作り、実際のテスト実行履歴はTestLinkで管理し、顧客向けの資料はTestLinkからExcel出力すればいいようにしたい。
つまり、Excelは、ある時点のテスト実績のスナップショット。
したがって、Jenkinsのようなビルドツールで、TestLinkからテスト結果をレポート出力するように、定期的にキックする仕組みがあれば、なお良いだろう。

また試してみる。

| | コメント (0)

より以前の記事一覧