オープンソースプロジェクトのQAについて - LibreOfficeのケースから-

榎 真治 (shinji.enoki@gmail.com)LibreOffice 日本語チーム in 品質保証責任者の会

2016-09-02 This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

オープンソースプロジェクトの QA について - LibreOffice のケースから -

自己紹介 : 榎真治（えのきしんじ）● 関西 LibreOffice勉強会スタッフ (2008-現在 )

● LibreOffice日本語チームメンバー (2011-現在 )

● The Document Foundationメンバー (2014/4-現在 )● フリーで LibreOfficeのコンサル /サポート /トレーニング● アイクラフト株式会社と組んで LibreOfficeサポートビジネス（ Collaboraの L3サポートのリセールと、 L1/L2サポート）

セッションのゴール● LibreOfficeを例にオープンソースの QAについて知る● コンテキストの違いを抽象化し、取り入れられるところを考えてみる

アジェンダ● LibreOfficeの概要● LibreOfficeの QAについて● ディスカッション

LibreOfficeの概要● オープンソースの統合オフィスソフト

– ワープロ、表計算、プレゼン、図形描画、データベース、数式エディタ

● マルチプラットフォーム– Linux, Windows, Mac

● 多言語対応 (言語パックは 100以上 )

● Webブラウザで共同編集できる LibreOffice Onlineも開発中● Android版ビューア

自由なオフィスソフトを作ること！

Microsoft Office の互換製品を目指しているわけではない

写真： https://visualhunt.com/photo/8602/

4つの価値観● すべての人々のデジタルデバイドを解消すること● 母語を保護する活動を支援すること● プロプライエタリソフトウェアやプロプライエタリフォーマットのロックインを避けること

● オープンで透明性のある開発を行うことhttps://ja.libreoffice.org/about-us/who-are-we/

誰が？● 世界中のボランティアが開発● ベルリンに The Document Foundation(非営利法人 )を設立

● TDFやサポートベンダでフルタイムで雇用されている人は 20数名くらい？– TDF6 名 ,Collabora10 名程度 ,Redhat5 名 ,Canonical 1 名 ,

CIB3-4 名 ?

歴史（ LibreOffice以前）● 1990年代：ドイツで作られているプロプラソフトウェア（一太郎みたいなもの）

● 1999年： Sun Microsystemsが StarDivisionを買収してオープンソース化を決定

● 2002年： OpenOffice.org 1.0リリース● 2010年： Oracleが Sun Microsystemsを買収● 2010年 9月末に OpenOffice.orgから LibreOfficeが分岐

昨年のデンマークでの国際会議に集まったメンバー

撮影 Dmitri Popov

2016/1/9開催の日本でのミニ・カンファレンス

撮影 Kondo Masataka

LibreOfficeのコンテキスト● デスクトップ・アプリケーション

– ミッション・クリティカルな用途には使われない前提● 他のオープンソースソフトウェアと比べるとユーザと開発者の距離がある– OSS で成功しているものは、ユーザと開発者が近いプロ

ダクトが多い● ユーザも含めて一緒に作っていくもの！

LibreOfficeの品質戦略● フィードバックを素早くもらって、素早く修正する

– （参考）伽藍とバザール：目玉の数さえ十分あれば、どんなバグも深刻ではない

リリース戦略：タイムベース・リリース● フィードバックをもらうため、定期的にリリース

– 年 2 回の機能追加リリース： 2 月と 8 月● 時期がきたらタグをうってリリース

– バグがあるかどうかは関係なし– リリース候補で、クリティカルなバグがあれば修正

最新版と安定版の 2系統● ほぼ毎月、バグフィックスリリース

– 現在は最新版 5.2.x 、安定版 5.1.x

– 来年 2 月に 5.3.0 がリリースされたタイミングで 5.2.x が安定版に、 5.1.x がサポート外に

OpenOffice.orgでは● 主な機能を実装できたらリリース● リリース候補でがんばってバグ修正● テストされていないビルドはリリースされない

– 各言語、アーキテクチャごとにバイナリが別れており、それぞれ簡易なテストが必要だった

今から考えたら、しんどいだけでフィードバックのもらいにくい方法だった

取り組み

ソースコードレビュー： Gerrit

● https://gerrit.libreoffice.org/

Gerrit

● gitと連携した OSSのソースコードレビューツール● Webベースで操作● レビューコメント● 自動でビルドテスト

● 権限のあるレビューア (ベテラン開発者 )が通さないかぎり、 LibreOfficeへコードは入らない– リリースブランチだと、複数人のレビューを通す必要が

あったはず● レビューコメントでの指摘

– 特に新人には丁寧に指摘している印象– 教育 / メンターシップ的な意味合いも

ユニットテスト● ユニットテストを書くことが当たり前に

– 必須の場所もあるようだ● 関数やメソッドのテストだけでなく、シナリオテストも

https://wiki.documentfoundation.org/Development/Unit_Tests

Tinderbox

● 様々なマシンでビルドした結果をブラウザで表示● リアルタイムでビルドが壊れているか可視化● 特定 OS向けだけ、コケていることも多い● http://tinderbox.libreoffice.org/MASTER/status.html

Tinderbox

● 様々なマシンでビルド、結果をブラウザで表示● http://tinderbox.libreoffice.org/MASTER/status.html

Coverity

● ソースコードの静的解析ツール● LibreOfficeなど OSSプロジェクト向けには無償提供されている

● 2013年ごろ 1年間で 6,000以上を修正して、不具合密度を 0.8 から 0.08 にまで下げたらしい（現在は 0.02)

http://softwareintegrity.coverity.com/register-for-libreoffice-scan-report-jp.html

https://scan.coverity.com/projects/211

バグデータベース： Bugzilla

バグライフサイクル● 図のBugzillaの例と

同じ運用

Bu

gzilla

3.0

b

ug

lif

ecycle

Possible resolutions: FIXED DUPLICATE WONTFIX WORKSFORME INVALID

NEW

ASSIGNED

REOPENED

RESOLVED

UNCONFIRMED

VERIFIED

CLOSED

Developer takes

possession

Developer takes

possession

Issue is resolved

QA not satisfied with solution

QA verified solution worked

Bug is reopened

Bug is reopened

Bug is closed

Bug is closed

Ownership is changed

Bug confirmed or receives

enough votes

Developer takes

possession

Development is finished

with bug

Development is finished

with bug

Bug is reopened, was never confirmed

New bug from a user with canconfirm or a product without UNCONFIRMED state

https://commons.wikimedia.org/wiki/File:Bugzilla_Lifecycle_color-aqua.svg

BugTriage

● バグトラッキングシステムはこまめな整理が必要● UNCONFIRMED(未確認 )への対応

– 1500 を超えていた時期もあり、減らすキャンペーンで300 くらいまで削減。現在は 600 超

– 再現確認できると NEW にする● 情報が不足しているものを NEEDINFOへ

https://wiki.documentfoundation.org/QA/BugTriage

UNCONFIRMEDと NEEDINFOの推移

https://bugs.documentfoundation.org/reports.cgi?product=LibreOffice&datasets=UNCONFIRMED

Bug Hunting Session

● 世界中で集中的にテストしよう！と呼びかけている期間– オンラインで IRC でやりとりしつつ実施– 以前は 3 日間やっていたが最近は 1 日のことも

● アルファ、ベータ、 RCと６ヶ月間リリースまでに 3回● 日本ではオフラインで集まるイベントもほぼ毎回企画

QA Easy hacks

● https://wiki.documentfoundation.org/QA/Easy_Hacks

● これをやってみたらいいよ、リスト● コミュニティに入ってきてテストしようとしても、多くの人は何から手を付けていいかわからないので

手動テスト（ Moztrap、探索的テスト）● ベテランユーザは LibreOfficeに詳しいのでバグを見つけるのがうまい人も

● 気になるところ、新機能、怪しい所を探索的に● Moztrapという手動テストケース管理ツールもある

– ただし、あまり使われていない

Bibisect：環境を切り替える● LibreOfficeの様々なバージョンで再現確認したい● gitを使って LibreOfficeのバイナリのバージョンを切り替えるツール

● https://wiki.documentfoundation.org/QA/Bibisect

以前の取り組み： Most_Annoying_Bugs

● リリースストッパーほどではないが重大なバグをトラッキングしていた

● https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs

QAチームのコミュニケーション● QA-ML/Bugzilla/IRC/ASK(フォーラム )

● IRCミーティング（月 2回くらいのペースでやっていたが、今年１月を最後に開催されていないっぽい）

● 英語が母語でない人が大半

他のオープンソースコミュニティとの連携は重要● Linuxディストリビューションなどでは独自にパッチもあてている– バグも各ディストリビューションにレポートされるケー

スも● バグ情報の共有や、問題切り分けの協力

ボトルネックは？● ユーザが利用するところから、バグ報告されて修正されるまでの、どこがボトルネックになっているか？

● 分析しきれていないが、、– バグ修正できる開発者が少ないことは課題

テスト /バグ報告するのはユーザーなので ...

● ユーザーに対してどこにどのように報告すればよいか？をいかに伝えるか

● テストや、バグ報告するモチベーションをいかにあげるか

● ツールの使いにくい部分、手間をいかになくすか

ディスカッション

質疑、ディスカッションで出た内容の一部● ボランティアでかかわっているのか？

– コミュニティの中ではボランティア– サポートベンダなどでお金をもらっているフルタイム開

発者などはいる– 主にヨーロッパでは、行政組織や企業向けに LibreOffice

のサポートビジネスは成立している

● 活動するモチベーションは？– 私の場合はライフワーク。長期的にはずっとやっているが

、１ヶ月間くらい活動できてないこともある– オープンソースコミュニティが、最も貢献しやすく楽し

かったので、人生をこれにかけることにした– 非開発者として自分が使うツールの中で、最も社会的影響

が大きくて当時問題を抱えていたのが OpenOffice.org だった

● 品質目標はどのように決めているのか？– 決められていない（明確な合意はない）– ユーザ / 貢献者の各自が持っているとは思うが、人に

よって違うはず– ユーザは品質に関わることができるので、望む品質目標

に達していなければ、自ら手を動かすか、ベンダに依頼して品質向上できる（関われる自由がある）

● テストをやったことをどうやって確認できるのか？– MozTrap では、テスト実施したことを報告 /記録できる– それ以外はテストしたかどうかはわからない– ユーザ同士でテスト /検証した情報を共有できるとよいね、という議論はしたことがあるが実現できていない