libreoffice mini conference 2014 qa
DESCRIPTION
LibreOffice mini Conference 2014 Tokyo/Japanで発表した「品質を高める活動に参加してみよう！」のスライドです（一部修正してます）TRANSCRIPT
品質を高める活動に参加してみよう！in LibreOffice mini Conference 2014 Tokyo/Japan2014/6/7
榎 真治 ([email protected])LibreOffice 日本語チーム
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
2
自己紹介
LibreOfficeコミュニティThe Document Foundationメンバー（最近なりました）LibreOffice日本語チームメンバー(主にイベントで活動)関西LibreOffice勉強会 (2008年-)徳島LibreOffice勉強会 (2014年-)
その他のコミュニティ日本UNIXユーザ会、KOFスタッフ、LILOなど
ビジネスはフリーランスで活動LibreOfficeのサポートなど
3
アジェンダ
品質保証/テストについてLibreOfficeでの不具合対策の現状LibreOfficeでのテストとツールの紹介
今日のゴール
QAやテストがなぜ必要なのか、
どんな効果があるか考えてみる
LibreOfficeでQAをやってみようと思った時に、
どんなことが出来るのかわかる
LibreOfficeの品質に関わる課題
どんなことが気になりますか？
実装されているはずの機能が動かなかった
解決されていた不具合が再発した
翻訳がおかしかった
操作が面倒くさいところがあった
どれもが品質に関わる課題
品質って？
ISTQBの用語集によるとコンポーネント、システム、プロセスが、指定された要求、ユーザ、顧客のニーズ機体を未対す度合い
（私見では）期待したように機能するかユーザが仕事をどれだけうまく片付けられるか
顧客の満足感
不満足
満足
物理的充足状況
不充足 充足
当たり前品質
一元的品質
魅力品質
さらには
品質は不具合だけではない狩野モデル
当たり前品質を満たすだけでは十分ではない魅力的品質の向上が重要だと思う
ただ、今回は不具合対策の話に限定
こんなことも
4.2.0 ではCalcのクラッシュバグなどが発見されるすぐに4.2.1をリリースして対応することになった
すぐに対応できたのはGoodリリーストレインにそった動きただ、使おうとしてトラブルに遭遇したユーザは少なくなかったBeta版で試していれば、リリースする前に見つけて修正できたかも
現状の不具合対策でやっていること
開発者ユニットテストソースコードレビュー
QAバグトリアージ
Bugzillaではレポートがあふれている重複の整理、再現確認、情報が足りないとメッセージなど
バグハンティングセッションベータ版に対して、集中的にテストを行うイベント
リリース前テストリリース候補に対してテストを呼びかけOOoの時のように、テストしないとリリースしないというルールはない
再現確認修正方法の調査
開発とテスト、不具合報告の流れ
コードを書く ソースコードレビュー
ユニットテスト
開発者
ナイトリービルド
ベータ版
リリース候補（RC）
リリース版
バグハンティングセッション
ユーザーからフィードバック
リリース前のテスト
？
不具合報告
どのタイミングで？
予防するリリース前の早い段階で欠陥/問題を発見ユーザーが使っていて発見
早いタイミングで対応出来た方が全体的なコストは少なくてすむ
不具合報告について
バグデータベースのBugzillaでレポートするメーリングリストで相談する
[email protected]自信がないとき、他の環境で確認して欲しいときなど
フォーラムで相談する（日本語版がスタート）ask.libreoffice.org
アンチパターン（よくない方法）twitter、FB、ブログなどで書くコミュニティでは気がつかない気がついても追加情報や確認が取りにくい
Bagzillaの説明
不具合情報などを管理するデータベース
https://bugs.freedesktop.org/
LibreOfficeのバグ報告方法のページ参照https://wiki.documentfoundation.org/QA/BugReport/ja
Bug Submission Assistant (BSA)
BugzillaのフロントエンドLibreOfficeのメニューからアクセスできるWebフォームで手順にしたがってレポートする
メニューの[ヘルプ]-[フィードバックを送る]
BSAの説明2
https://wiki.documentfoundation.org/File:BzLifecycleold.png
バグトリアージ
以前からBugzillaで未確認のままのものが多いQAプロジェクトではバグトリアージに注力する方向
でもやっている人は少ない（私も出来てません）再現確認重複チェック古いバージョンでレポートされたものは、新しいバージョンで確認されない場合は閉じることも
トリアージがまだまだ課題
手動テスト
LibreOfficeを操作して不具合がないかをテストするアプローチ
テストシナリオに沿ってテストする（Moztrap:後述）新機能や変更、不具合修正されたところを試す普段使う機能を試すEtc...
Moztrapの説明
手動テストのテストケースを管理するツールテストケース（シナリオ）を実行し、結果を報告
ログイン、アカウント作成
http://manual-test.libreoffice.org/
項目をクリックするとテストケースが表示される
Bibisect
LibreOfficeを複数バージョンのバイナリをgitで切り替えて起動するツールリグレッションバグを調べるときなど、複数のバージョンで確認したい時に便利
https://wiki.documentfoundation.org/QA/HowToBibisect
Easy Hacks（簡単なハック）
始めたいと思ったときに、最初の一歩として提案されているタスクのリストQAでもEasy Hacksがある
ここのリストからやることを探すのもありメンテはあまりされてない気も...
https://wiki.documentfoundation.org/QA/Easy_Hacks
QAプロジェクト（グローバル）
メーリングリスト：[email protected]：#libreoffice-qa
Webで見るならhttps://webchat.freenode.net/?channels=#libreoffice-qa
電話会議:月２回程度。英語
メーリングリストの入会ページhttp://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
開発、QAの動きをざっくりみる
minutes of the ESC callEngineering Steering CommitteeはLibreOfficeの技術的な調整や決定を行う週1回開催されるESCの電話会議の議事録“QA”や”projects”のMLに流れる
LibreOffice Gerrit News1日１回メール：QA-MLにも
Bugzillaの動きtwitterにも流れてくるがちょっと大変かも...
Most Annoying Bugs(MAB)
リリースバージョンに含まれる最もやっかいなバグバージョンごと（4.2, 4.3など）にBugzillaに追跡用のIssueが立てられる例：4.2のMABは、fdo#65675
https://wiki.documentfoundation.org/QA/Most_Annoying_Bugs
どこから手をつけるか？
やりたいところからがいいのでは？がんばりすぎるとしんどい
やりやすいところから効果はありそうでも、難しくて進まないよりはよさそう
バグトリアージはフルタイムがいないとしんどいTDFでも1人募集していた
みんなでTDFに募金するとと雇えるようになるかも
まとめ
LibreOfficeの不具合修正やQAの現状について説明しましたQAは関わる人が少ないので、興味をもった人はぜひ参加ください
Q&A
Enjoy LibreOffice Life!Thank you!