2016/9/2に行った品質保証責任者の会での発表資料に追記したものです。 ハイブリッドPDFにしていますので、LibreOfficeで開くと編集可能です。

1. 榎 真治 (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 のケースから -

2. 自己紹介 : 榎真治（えのきしんじ）
●
関西 LibreOffice 勉強会スタッフ (2008- 現在 )
●
LibreOffice 日本語チームメンバー (2011- 現在 )
●
The Document Foundation メンバー (2014/4- 現在 )
●
フリーで LibreOffice のコンサル / サポート / トレーニング
●
アイクラフト株式会社と組んで LibreOffice サポートビジネス
（ Collabora の L3 サポートのリセールと、 L1/L2 サポート）

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

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

5. LibreOffice の概要
●
オープンソースの統合オフィスソフト
– ワープロ、表計算、プレゼン、図形描画、データベース、数式エ
ディタ
●
マルチプラットフォーム
– Linux, Windows, Mac
●
多言語対応 ( 言語パックは 100 以上 )
●
Web ブラウザで共同編集できる LibreOffice Online も開発中
●
Android 版ビューア

6. 自由なオフィスソフトを作ること！
Microsoft Office の互換製品を
目指しているわけではない
写真： https://visualhunt.com/photo/8602/

7. 4 つの価値観
●
すべての人々のデジタルデバイドを解消すること
●
母語を保護する活動を支援すること
●
プロプライエタリソフトウェアやプロプライエタリ
フォーマットのロックインを避けること
●
オープンで透明性のある開発を行うこと
https://ja.libreoffice.org/about-us/who-are-we/

8. 誰が？
●
世界中のボランティアが開発
●
ベルリンに The Document Foundation( 非営利法人 ) を
設立
●
TDF やサポートベンダでフルタイムで雇用されている人
は 20 数名くらい？
– TDF6 名 ,Collabora10 名程度 ,Redhat5 名 ,Canonical 1 名 ,
CIB3-4 名 ?

9. 歴史（ LibreOffice 以前）
●
1990 年代：ドイツで作られているプロプラソフトウェア
（一太郎みたいなもの）
●
1999 年： Sun Microsystems が StarDivision を買収して
オープンソース化を決定
●
2002 年： OpenOffice.org 1.0 リリース
●
2010 年： Oracle が Sun Microsystems を買収
●
2010 年 9 月末に OpenOffice.org から LibreOffice が分岐

10. 昨年のデンマークでの国際会議に集まったメンバー
撮影 Dmitri Popov

11. 2016/1/9 開催の日本でのミニ・カンファレンス
撮影 Kondo Masataka

12. LibreOffice のコンテキスト
●
デスクトップ・アプリケーション
– ミッション・クリティカルな用途には使われない前提
●
他のオープンソースソフトウェアと比べるとユーザと開
発者の距離がある
– OSS で成功しているものは、ユーザと開発者が近いプロ
ダクトが多い
●
ユーザも含めて一緒に作っていくもの！

13. LibreOffice の品質戦略
●
フィードバックを素早くもらって、素早く修正する
– （参考）伽藍とバザール：目玉の数さえ十分あれば、ど
んなバグも深刻ではない

14. リリース戦略：タイムベース・リリース
●
フィードバックをもらうため、定期的にリリース
– 年 2 回の機能追加リリース： 2 月と 8 月
●
時期がきたらタグをうってリリース
– バグがあるかどうかは関係なし
– リリース候補で、クリティカルなバグがあれば修正

16. 最新版と安定版の 2 系統
●
ほぼ毎月、バグフィックスリリース
– 現在は最新版 5.2.x 、安定版 5.1.x
– 来年 2 月に 5.3.0 がリリースされたタイミングで 5.2.x が
安定版に、 5.1.x がサポート外に

17. OpenOffice.org では
●
主な機能を実装できたらリリース
●
リリース候補でがんばってバグ修正
●
テストされていないビルドはリリースされない
– 各言語、アーキテクチャごとにバイナリが別れており、
それぞれ簡易なテストが必要だった
今から考えたら、しんどいだけで
フィードバックのもらいにくい方法だった

18. 取り組み

19. ソースコードレビュー： Gerrit
● https://gerrit.libreoffice.org/

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

21. ●
権限のあるレビューア ( ベテラン開発者 ) が
通さないかぎり、 LibreOffice へコードは入らない
– リリースブランチだと、複数人のレビューを通す必要が
あったはず
●
レビューコメントでの指摘
– 特に新人には丁寧に指摘している印象
– 教育 / メンターシップ的な意味合いも

22. ユニットテスト
●
ユニットテストを書くことが当たり前に
– 必須の場所もあるようだ
●
関数やメソッドのテストだけでなく、シナリオテストも
https://wiki.documentfoundation.org/Development/Unit_Tests

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

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

25. Coverity
●
ソースコードの静的解析ツール
●
LibreOffice など OSS プロジェクト向けには無償提供さ
れている
●
2013 年ごろ 1 年間で 6,000 以上を修正して、不具合密
度を 0.8 から 0.08 にまで下げたらしい（現在は 0.02)
http://softwareintegrity.coverity.com/register-for-libreoffice-scan-report-jp.html

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

27. バグデータベース： Bugzilla

28. バグライフサイクル
●
図のBugzillaの例と
同じ運用
Bugzilla3.0
buglifecycle
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

29. BugTriage
●
バグトラッキングシステムはこまめな整理が必要
●
UNCONFIRMED( 未確認 ) への対応
– 1500 を超えていた時期もあり、減らすキャンペーンで
300 くらいまで削減。現在は 600 超
– 再現確認できると NEW にする
●
情報が不足しているものを NEEDINFO へ
https://wiki.documentfoundation.org/QA/BugTriage

30. UNCONFIRMED と NEEDINFO の推移
https://bugs.documentfoundation.org/reports.cgi?product=LibreOffice&datasets=UNCONFIRMED

31. Bug Hunting Session
●
世界中で集中的にテストしよう！と呼びかけている期間
– オンラインで IRC でやりとりしつつ実施
– 以前は 3 日間やっていたが最近は 1 日のことも
●
アルファ、ベータ、 RC と６ヶ月間リリースまでに 3 回
●
日本ではオフラインで集まるイベントもほぼ毎回企画

32. QA Easy hacks
● https://wiki.documentfoundation.org/QA/Easy_Hacks
●
これをやってみたらいいよ、リスト
●
コミュニティに入ってきてテストしようとしても、多く
の人は何から手を付けていいかわからないので

33. 手動テスト（ Moztrap 、探索的テスト）
●
ベテランユーザは LibreOffice に詳しいのでバグを見つ
けるのがうまい人も
●
気になるところ、新機能、怪しい所を探索的に
●
Moztrap という手動テストケース管理ツールもある
– ただし、あまり使われていない

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

36. 以前の取り組み： Most_Annoying_Bugs
●
リリースストッパーほどではないが重大なバグをトラッ
キングしていた
● https://wiki.documentfoundation.org/QA/Most_Annoyin
g_Bugs

37. QA チームのコミュニケーション
●
QA-ML/Bugzilla/IRC/ASK( フォーラム )
●
IRC ミーティング（月 2 回くらいのペースでやっていた
が、今年１月を最後に開催されていないっぽい）
●
英語が母語でない人が大半

38. 他のオープンソースコミュニティとの連携は重要
●
Linux ディストリビューションなどでは独自にパッチも
あてている
– バグも各ディストリビューションにレポートされるケー
スも
●
バグ情報の共有や、問題切り分けの協力

39. ボトルネックは？
●
ユーザが利用するところから、バグ報告されて修正され
るまでの、どこがボトルネックになっているか？
●
分析しきれていないが、、
– バグ修正できる開発者が少ないことは課題

40. テスト / バグ報告するのはユーザーなので ...
●
ユーザーに対してどこにどのように報告すればよいか？
をいかに伝えるか
●
テストや、バグ報告するモチベーションをいかにあげる
か
●
ツールの使いにくい部分、手間をいかになくすか

41. ディスカッション

42. 質疑、ディスカッションで出た内容の一部
●
ボランティアでかかわっているのか？
– コミュニティの中ではボランティア
– サポートベンダなどでお金をもらっているフルタイム開
発者などはいる
– 主にヨーロッパでは、行政組織や企業向けに LibreOffice
のサポートビジネスは成立している

43. ●
活動するモチベーションは？
– 私の場合はライフワーク。長期的にはずっとやっているが
、１ヶ月間くらい活動できてないこともある
– オープンソースコミュニティが、最も貢献しやすく楽し
かったので、人生をこれにかけることにした
– 非開発者として自分が使うツールの中で、最も社会的影響
が大きくて当時問題を抱えていたのが OpenOffice.org だった

44. ●
品質目標はどのように決めているのか？
– 決められていない（明確な合意はない）
– ユーザ / 貢献者の各自が持っているとは思うが、人に
よって違うはず
– ユーザは品質に関わることができるので、望む品質目標
に達していなければ、自ら手を動かすか、ベンダに依頼
して品質向上できる（関われる自由がある）

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