Test IOのQAサービスに、開発ツールJiraからの直接アクセスが可能に

現代の「急げや急げ」アジャイル開発環境の中では、ソフトウェアの品質保証テストは控え目な場所に追いやられることもある。この不協和な状況に対してTest IOのようなオンデマンドテストスタートアップが参入してきている。開発者たちが有能なQAテスターたちに​​簡単にアクセスできるようにするサービスだ。

このたび同社は、Test IOサービスを、Atlassian Jira開発ワークフローツールに直接組み込む、新しいプラグインを発表した。このツールはAtlassian Marketplaceで入手できる。

インストールしたなら、開発者たちは単にJiraインターフェイスにあるTest IOボタンをクリックして、テストパラメータを選択し、ワークフローを開始するだけだ。するとサービスは、開発者が要求する必要な専門知識と機器を持つテスターを選定する。と、Test IOのCEOであるPhilip Sofferは説明した。

Sofferによれば、3万人の審査済みソフトウェアテスターからなるチームを擁していて、テスターたちは人間のスーパーバイザーによってある安定したテストレベルに達するまでクロスチェックを受けた者たちということだ。それぞれのテスターは、その品質、可用度、その他の要素によってランク付けされる。プログラマーが特定のスキルと機器を持っている人を問い合わせると、それらは要件に合致する、現在オンラインで対応可能な最も有能な人物にルーティングされる。2つ以上のスキルが必要な場合には、テストリクエストは同時に複数のテスタにルーティングされる可能性がある。ここでのアイデアは、実世界のテスト条件下で、可能な限り迅速かつ正確にQAを完了させることだ。

レビューが完了すると、問題を示すスクリーンショットとスクリーンカムムービーを添えたレポートが、問題のリストとともにプログラマーに直ちに送り返される。開発者は、レビューに関する質問があれば、インターフェースの中でテスターと直接コミュニケーションを取ることができる。

スクリーンショット2017-09-11 14.53.51.png

写真:Test IO

Test IOの顧客の70%がJiraを使用していることを考えれば、同社がサービスにアクセスするためにできるだけシンプルにすることは理にかなっている。Jiraプラグインがない状況では、開発者はブラウザを開いてTest IO Webサイトにアクセスし、サインインし、テストパラメータを選択し、テストする材料をアップロードする必要がある。プラグインを使えば、そうしたものの多くは組み込みツールによって処理され、プログラマたちはテストのリクエストや結果のレビューを行うために、Jiraから離れる必要はない。

Test IOは2011年にベルリンで創業し、現在もそこにオフィスを構えているが、現在の本社はサンノゼに置かれている。Sofferによると、スタートアップは毎年収益をほぼ2倍に伸ばしており、2015年には500万ドルの資金を調達している

[ 原文へ ]
(翻訳:Sako)

FEATURED IMAGE: HERO IMAGES/GETTY IMAGES

JIRAに死を

death-to-smoochy

Atlassianのバグトラッカー/機能プランナーJIRAは、今や至るところで使われているし、ぼくも長年、ソフトウェアビジネスの重要な目的に奉仕する製品、と考えていた。重要な目的とは、プロジェクトチームが共通の敵を見つけて共同で立ち向かうことだ。でも、そうではなかった。JIRAの設計は基本的に、良質なソフトウェア開発とは正反対のもので、単純なバグトラッキングぐらいにしか使えない。では、もっと良いやり方とは、なんだろう。

ライターでないときのぼくはソフトウェアエンジニアで、ソフトウェアコンサルタント企業のHappyFunCorpに籍を置いていろんなクライアントの仕事をしている。だからJIRAのいろんな違った使い方を、見る機会がある。一部の企業はそれをBugzilla++として使っているが、それで十分だ。でも最近ますます多いと思われる使い方が、要求の定義だ; プロジェクトを多数のJIRAチケットに分解すれば、それらを使って、評価もコミュニケーションも進捗管理も変更管理も、何でもできる、という考え方だ。

でも、この考え方には深刻な欠点がある。JIRAのチケットは、絶対的で不可避な想定とそれらの結果を表現している。それが記述している機能やビヘイビアは、離散的でない。それは絶対的な二択、すなわち完全か、無か、だ。しかもそれは、個別に評価できる、とされる。つまり個々に、それだけを孤立的に扱える、と想定される。そしてその、他のチケットとの結びつきは、JIRAの子どもっぽい概念、“リンクされた”チケットという言葉で表現される。

これは、ソフトウェアの最良の作り方ではない。ソフトウェアは、反復的(iterative)である。サブシステムAを作る、次にサブシステムBを作る、そしてABをインタフェイスする…という単純な過程ではなく、デベロッパー間には最初にA-AB-Bの全体を見通した情報の流れ〔プログラム中の情報の流れ、フロー〕が共有されていて、それから(あるいはその前に)最初の方のデータでその流れをテストし、その過程を通じて何かを発見し、何かを学ぶ。そして次は、そこで現れた想定外や、システムのどこかにあった地雷原に対策することが多い。ときにはその作業に数週間を費やし、その後本流に戻って、情報の流れを拡大する、…以上の過程を、A、AB、Bの三者が完成するまで反復する。

しかしJIRAでは、進捗はまだ残っているチケットと、クリアしたチケットの数で計られる。そう明示されているわけではないけど、必然的にそうなる。“To Do”(未着手)や“In Progress”(作業中)のチケットが並ぶでっかいカラムは、誰も見たくない。みんな、できるだけ早くそれらをそこから外して“QA”(品質管理中)や“Shelved”(保留中)へ移したい。だからJIRAのチケット方式では、デベロッパーが一度に一つのチケットだけを扱いがちになり、それは多くの場合に非効率であるだけでなく、開発の後段における重大な、その時点ではもはや手遅れの、エラーを招きがちだ。

さらにまずいのは、デベロッパーが考えるソフトウェアのアーキテクチャが、知らず知らずのうちに、JIRAのチケットにマップしやすい構造になることだ…それが技術的最適ではない場合でもだ(そういう場合の方がむしろ多い)。もちろん、完全に最初に戻って、プロジェクトのメンタルモデルの全面的な再構築を求めることはできる。だが、そんな重い社会的および資本的負担を、すでに進行中のプロジェクトに関して誰が引き受けるのか? ときには非技術系の管理職が片手間で拙速に作ることもある、暗黙にチケットを前提しているアーキテクチャを、黙って受け入れる方が楽である。

しかし最悪なのは、プロジェクトを複数のチケットに分解するこのやり方では、システム全体を展望する場がどこにもないことだ。最良のソフトウェアは、細部の緻密な実装に集中できると同時に、システム全体の大きな目的や狙いをつねに心にとめているデベロッパーから生まれる。JIRAでは後者が、異様なほど、そして不必要に、困難になる。

ここで強調したいのは、悪いのは必ずしもJIRA自身ではない、ということだ。ここまで書いてきたことはすべて、ソフトウェアのアーキテクチャと開発を“チケット”の集合に還元する、という考え方に由来している。JIRAの最大の罪は、それが、もっとも成功し広く普及しているチケットシステムであること、それだけだ。ソフトウェアプロジェクトをチケットの集合で表す、という考え方そのものが、真の敵だ。

そしてぼくが提案するもっと良い方法は、びっくりするほど単純だ。複雑なシステムを定義/表現できて、そこに曖昧性や不確定性、互いに絡みあった関係性、成功のための反復レベル、そして大きさと細部が不特定に幅広いスペクトル、などなどを記述できる強力なシステムが、すでにある。それは、“散文(prose)”と呼ばれる。

何らかの理由で今日の企業の多くが、明快でシンプルな長い散文(2パラグラフ以上)を書くことを、疫病のように恐れて避ける。でも、上手に書けた8ページのドキュメントなら、複雑なシステムのニュアンスを、互いにリンクし合ったJIRAのチケットの扱いにくい小艦隊よりもずっと見事に、定義できる。

しかも今なら、シンプルなテキストドキュメントを、文や箇条書き、パラグラフ、節、章などに分解して、それらの要素の評価や進捗を記録する自動化システムを、容易に作れる。チケットと違って、各要素の大きさは制限されない。散文をJIRAのチケット集合に自動的に変換することも、必要ならできるだろうが、その場合もプロジェクトを主導する仕様は、単一の、一貫性のある散文ドキュメントだ。

機能のプランニングには、コミュニケーションが必要だ。JIRAは、複雑なシステムの要求をコミュニケーションする方法としては基本的に劣悪である。言葉の並びは、それが良く書けていれば、つねにベターである。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))