発表資料
自己紹介
- @sue445
- ドリコム
- 絶対にフォローしないで下さい！
GitLab関連でも色々と作成した
- gitlab_awesome_releaseとか作成
「GitLabコミュニティへのコントリビュート」聴講レポート #gitlabjp
発表資料
自己紹介
- @hiroponz
- (株)ルビー開発
- 勤務地は仙台
- 今日はこれのために出張してきた
GitHubとの違い
- GitLab ECは開発に参加できる！
類似のOSSとの違い
- 似たようなものがあるが、それぞれ開発言語が違う
- 開発リソースが違う
- GitLabは営利企業が開発を主導
- マシンスペック
- 他よりもマシンスペックをくう
- Gogs < GitBucket < GitLab
- 他よりもマシンスペックをくう
- 大規模利用
- GitLabはGitLab.comで利用されているので、スペックを上げれば大丈夫（数千人単位も可能）
コントリビュートの話
きっかけ
- 前職でGitLabを導入したらバグを踏んだ
- ShiftJISのバグ
- わかりそうだったので修正してPRを投稿
- すんなりマージされた
- You are Welcome!
わーい、たのしーっ
- いっぱいPRを出した
- GitLab MVPに選ばれた
- 毎月22日に新バージョンがリリースされる
- 各リリースのブログポストで発表される
- 基本的には栄誉賞
コントリビュートのメリット
- GitLabが便利になる
- 効果的な使用方法を学べる
GitLabが便利になる
- 仕事の効率が上がる
- EEに追加予定の機能をCEにも追加できる
- EEのissueで見て、実装してCEにMRを送れば良い
- EEに追加された後のMRはリジェクトされる
- 社内のGitLabを魔改造しなくてよい
- GitLabはVerUpのサイクルが早いので辛くなる
GitLabの効果的な使用方法を学べる
- GitLab社自身がヘビーユーザー
- 使い方を学べる
- リリースサイクルの仕方とか
- 6000を超えるissueの捌き方
- 多分捌けてない
- 高速な機能追加の実現方法
- 開発者間のコラボレーションを眺められる
- GitLab社はフルリモートチーム
- 効果的なコードレビューの方法
実践的なRailsの開発知識が身につく
- Gem fileの参考
- メンテナンスしやすいコードの書き方
- コミットログを眺めるだけでも学べる
- テストコードを書くことをルールとしている
- 比較的モダンなJS開発ができる
英語でのコミュニケーション能力が身につく
- ソフトウェア開発の共通言語
- 応用範囲が広い
- キャリアにも繋がる
その他諸々
- 転職の時にプラス
- 執筆依頼が来る
- スピーカー依頼が来る
コントリビュートの方法
- ガイドラインを熟読して下さい
- 3回ぐらい読めばなんとなく分かる
- Community Contributionのラベルを貼られた他人のMRを参考にする
- 社員以外の人
マージされやすくなるポイント
- Issueがあるかどうか
- なければ起票してから
- バグ修正の方がマージされやすい
- 機能追加の場合、簡単なテストを追加する
- 1個の正常系のテストだけでも良いので…
- UIの修正の場合、修正前後のスクリーンショットを貼る
- パフォーマンスの場合はベンチマークの結果を載せる
注意点
- DBマイグレーションが必要な場合はダウンタイムを発生させないようにする
- カラム削除とか
- パフォーマンスを著しく悪化させない
- アクセスを著しく増加させるのはNG
- コードのライセンス
- CEのマージはEEのマージもされるので、商用利用を認めていないのはNG
- 機械翻訳のコピペはNG
- 近々多言語対応されそう
- 礼儀正しく
英語の壁
- 高校レベルの英語でもOK
- 分からなかったらGoogle翻訳で
- 相手も慣れてる
- GitLab社社員は親切
GitLabIssueBash
- IssueのCloseキャンペーン
- 3月4日 9:01〜3月8日 8:59
- Tシャツとか貰えるかもしれない
- https://about.gitlab.com/2017/02/10/gitlab-issue-bash-march-2017/
「GitLabの実践的な運用」聴講レポート #gitlabjp
資料
自己紹介
- @catatsuy
- 会社のアドベントカレンダーで運用方法を公開した
Pixivで働いている
個人的には、以前のJTF2015で登壇している印象が強いです。
GitLabのインストール
- インストールはそんなに難しくない
セットアップサーバについて
- グローバルIPを持つサーバー上に立てることが前提
- サーバーは1台であることが前提
- 複数台構成は現実的ではない
- DBは別IPでもOK
GitLab.comのバックアップ体制
- 今回問題になったのはあくまでもGitLab.comの問題
GitLabの持っているデータ
- Radisは最悪吹っ飛んでも問題ない
- セッションとかキャッシュしか持ってない
GitLabのデータベース
RailsとMySQL
GitLabのバックアップ
- bundle exec rake gitlab:backup:createでバックアップできる
- git db create はmysqldumpとかをしているだけ
- git bumdle createを叩いて保存しているだけ
- git upload create はファイルをコピーしてtarで固めているだけ
- 最終的には1つのtarファイルに纏められる
- 様々なサーバにバックアップファイルを送ることも可能
- cronしたり
- 環境変数でcron=1を設定するとエラーしていない場合にログ出力しないことが可能
- cronしたり
MySQLのバックアップ
- dump以外にも、停止してdata_dirをコピーしたりする手段がある
- リストアも可能
バージョンアップ
- バージョンアップにはDBのバックアップを録るように書かれている
- GitLabのバージョンアップで関わるのはDBぐらい
- 一気にVerUpを上げることも可能
- 一部、特殊な作業が必要
無停止VerUp
- ほぼ無理
- master,slaveでも可能だが手間がかかる
- アプリケーション起動中に行うことはできない
- ある程度短くすることは可能だがrakeの時は停止する必要あり
最後に
「GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開」聴講レポート #gitlabjp
発表資料
自己紹介
- @tnir
- Takuya Noguchi
- Git利用歴10年
- GitLabはパブリック公開した日から使っていた
- 所属していた会社で2013年から使っていた
- 2014年から管理者として利用
- 2015年からはGitlab.comの混んとりビューア
なぜMeetupを開くのか
- 日本語の情報がなかったから
- あっても古い
- Gitlab.comが話題になったから…ではなく、準備していたら事件が起きた
GitLab.JP
- 仙台で発足して、3,4回やっていた
- 鹿児島でも勉強会が開催されていた
- 東京でもやろう
よく聞くGitLabのイメージ
- インストールが大変
- ウェブアプリが遅い
- GitLab.comでデータがロストした
GitLabの歴史
- GitLabは後発のサービス
- 後発の製品でどうやって優位性を持たせるか
GitLab.comの競合
- GitHub + ecosystem
- BitBukket + ecosystem
GitLab CE/EEの競合
- GitHub Enterprise
- GitBucket
- Gogs
- GO言語で出来ている
GitLab CE/EE
4種のGitLab
- CE
- 一番ユーザーが多い
- EE
- 有償版
- .com
- GitHust.io
- Saasではなくプライベートで運用したい
- デジタルオーシャン上で
- アップグレードやセキュリティを担保
- $80/月
GitLabマイルストーン
- 半年ごとにVerUpしていた
- Ver6からは1年半に1回ぐらいのVerUp頻度
- 現在はVer8
- その間に4回資金調達して40億円調達した
- 3/22のVer9が出る
2016年を振り返る
- 8.4〜8.15をメジャーリリース
- 機能がどんどん追加されて
パフォーマンス面
- 2014から2015年あたりにパフォーマンス劣化が著しくなった
- 2016年はパフォーマンス改善した
- 1月にInfluxDBを利用したモニタリング開始
- 後半はPrometheus導入
管理面
- omnibus-gitlabが一番手軽なインストール
- 色々な個人ブログではソースでのインストールも書かれているけど、オススメしない
- Dockerでもサポート
- まだまだ巨大なイメージなので、デフォルトの状態だときついかも
PostgreSQL
- 登壇する人はMySQLユーザーが多いみたい
Radis
- 現在、2.8から3.2に上げるMRを出しているところ
コンテナレジストリ
- これもGitLabが提供している
モニタリング
- 改善はしているがGithub.comに比べるといまいちな部分も
Docs
- ドキュメント大事
- docs.gitlab.comがリニューアルされた
- 英語さえできれば貢献は可能
開発
- OSSなのでGitLab.com上でコントリビュート可能
- 日本人は少なそう
- GitLab Development Kitで簡単に構築可能
Backend
- 普通のRailsアプリだが、一部GOで書かれている
Frontend
- jqueryが多い
- テストはJasmine+Karma
UI/UX
- 最初はデザイナーが少なかったが、最近増えた
- GL社員がちょっと多すぎる気がする
パッケージング
- chef/omnibusパッケージを使用している
コミット以外の貢献方法
- イイねを押すことも貢献の一つ
- GitLab Pagesもいいねが100を超えて実現した
個人的な野望
- Cloud-native
- Server-less
- 現状だと難しいかも
250人のチームで運用してみてわかったこと
- Gitの習熟度がバラバラ
- 高品質化のためにトレーニングが有効的
- GitLab Docsが有効
- ただし日本語訳がない
バグフィックス
- 昼、起票
- 夜、修正
- 時差があるので、夜活動が他国の人にとって良いみたい
今後に向けて
- 組織の方針とGitLab.incの方針（技術選択）が合致したのでうまくやってこれた。
- 組織毎に主体的な開発戦略が必要
今日伝えたかったこと
- かなり改善されてきた
- OSSに貢献してよりよいツール・プラットフォームを使いましょう
- 社内でパッチを当てるとかではなくMRを！
宣伝
- 第2回を開催決定しました。
- 4/11にリクルートでやります！
WACATE 2016夏 ～走りきるテスト設計～ #WACATE
昨年、WACATE 2016夏に参加してきました。
今回は1つの題材を元に、テスト分析・テスト設計を行おうという趣旨のものでした。
WACATE2016のワークで行ったことを共有したいと思います。
テスト分析
最初に仕様書、設計書が配布されたところで、
- 個人ワーク
- ワーク結果をマージ（基準にできそうな人のワーク結果を土台にグループとしての分析結果を出す）
- 各テスト条件に対して、利用できそうなテスト設計技法を選ぶ
という計画を示されました。
私の班が行ったこと
自分達の班は、個人ワークおよびマージした後、
- 「本当にお客さんが要望していることってなんだろう？」
- 「新業務がきちんと行うことができることではないか？」
という結論になり、業務を回すために必要なことは何かということを中心にもう一度個人ワークをすることになりました。
個人的な想い
上記の議論の際、「業務を回すこと」ではなく「一つ一つのチェックがしっかりできること」という結論に持っていくことも可能であり、そちらを取ったほうが色々なテスト技法に触れられるのでは？と思っていました。
しかし、班としての結論・納得は「業務を回すこと」であり、私自身もそちらで納得できたので、この方向で進めました。
ただ、正直、今回のワークとして成功できるのか、そして初参加の方に満足してもらってWACATEを終わらせることができるのか、この時点ではすごい不安でした。
秋山先生の講演
2日目の朝は、秋山先生の講演がありました。
その中で、分解という部分に注目し、前日に出てきた内容についてグループ化を行うことにしました。
発表スライド
www.slideshare.net
個人的な感想
分解、そしてセミラティスの話とか、JaSST'16 Tohokuでの話と似ているなと感じました。
実際、グループ化の作業は正にJaSST'16 Tohokuと同じようなワークになりました。
テスト設計技法の実践＆テストケースの作成
私達の班では、以下の4つを利用することに。
特に、「業務を回すこと」を第一に考えることにしたので、ユースケーステストの作成に3人を投入し、残りの部分に、1人ずつ分担して作成することに。
結果的に、この方針が良かった（気がする）。
ユースケーステストはベテラン1人が若手2人をサポート。
同値分割の人はすぐに終わったので、状態遷移を作っている初参加の人をサポート。
同値分割＆デシジョンテーブル担当は黙々と実施。
そんな形で行いました。
ただし、テストケースについては、時間切れで最後まで完成できず･･･。
そこまで考慮した時間配分にできればもっと良かったかなと。
個人的な想い
ユースケーステストは、他のテスト技法に比べても、作成者の差が顕著に出やすいものになると思っています。
今回も作成した3人で差が出ました。
ただし、今回はベテランではない人のテスト設計結果を採用しました。
これは2つの狙いがありました。
今の自分達チームの結果をきちんと示したい（ベテランの内容をそのまま使ってしまうと、「自分のチームの成果」という意義が薄れてしまう）
テスト設計結果の抜け漏れの部分を、他の設計したもので補完できていることを示したい。
特に2つ目の狙いは、ユースケーステストで書ききれなかったケースを、状態遷移側で上手く補完できました。
成果物
以下の写真のようになりました。
全体の進め方
業務フロー
テスト分析結果
ユースケーステスト
ユースケーステストから作成したテストケース
状態遷移
同値分割・境界値分析
デシジョンテーブルを元にしたテストケース
はっきり言って、成果物は他の班よりも綺麗ではありません。
しかし、班の人全員が納得できるものになったのではないかと感じています。
最後に
2017年夏のWACATEは6/17・18開催予定です！ wacate.jp
JaSST'17 Tokyoに行ってきました #JaSST
先日、JaSSTに行ってきたので、その参加レポートを書きました。
軽く感想を書きつつ参加レポートを紹介します。
基調講演
裏話がいっぱいで楽しんで聞くことが出来ました。
そして、国際標準を決めるって大変と感じ、SQuaREって良いものだと再認識しました。
招待講演
- 奈良さんのぶっちゃけトークがすごい面白かったです。
楽天トラベルの開発プロセスに関して
プロセス改善の例として参考になりました。
他のセッションもそうだけど、如何にしてVモデルでいう左側に関わっていけるのかをテーマにした話が多かった気がします。
【ジャストーーーク】転職芸人が語るテスト／QA技術者としてのキャリアパス
- 登壇者は転職芸人という立ち位置で参加していましたが、転職するかどうかは関係なく、テストエンジニアとしてどうしていくのかということに関して参考になりました。
教科書に載らないテストマネジメント
テストマネージャとしてあるべき姿をぶっちゃけトークで話していました。
途中参加だったのが悔やまれるぐらい、すごい良いセッションでした。
テスト現場のお悩み相談
あるあるな事例に対して、様々なアプローチでアドバイスしていました。
もはやテストの範疇を超えて、設計段階の所からどうしていくかみたいな話もありました。
Web.JaSST Web Service QA Meeting in JaSST'17 Tokyo
様々な企業での事例を話していました。
目的を持ってQA活動をしているところが多い印象を持ちました。
Web.JaSST Web Service QA Meeting in #JaSST '17 Tokyo
登壇者
- 泰楽
- 西脇
- 鶴岡
- 福沢
- 鈴木
泰楽「メルカリでQAプロセスを最速で構築したトリアージ術」
自己紹介
- 泰楽
- メルカリ
- WebQA歴10年
メルカリとは
- 日本最大のフリマアプリ
メルカリQAの創生期
- QAプロセスが存在していなかった
- USリリースに向けて検証対象の拡大
- QAプロセスを構築しないといけない
- このままだと2倍のリソースが必要になる
絶対的なリソース不足
- 1人で行う検証作業の限界
- 開発スピードに追いつかない（開発15名に対しQA1人）
- このままではリリースできない
属人化の許容
- 細かいゴールを多く設定し、QAに関わる業務の全てをゼロベースで見直し、小さな改善を繰り返し実施していく
- プロダクトとしての成長に向けて、小さなゴールを決める。
- QA活動としてモデル化や属人化の排除をすることが多いが、そうではなく属人化の許容をしていく
- 変化に対応していく
QAプロセスの高速化1
- やらないところを決めた
- テストケースを作らないことにした
- 10年の経験のキーワードは3つ
- 正常系は不具合の検出率が低い
- アドホックテストが不具合の検出率が高い
- テストの質はテストの対象物に比例する
- その代わり、仕様の背景や目的の理解に時間を割いた。
- テスト結果やエビデンスはどうやって出すのか？
QAプロセスの高速化2
- 品質ばらつき問題の懸念
- 検証結果を第三者レビューすることで解決
- WEBサービスのリリースに対しての制約は多くない
- 逆に言うと、いつでもリリースできる環境が用意してある
QAプロセスの高速化3
- 不具合の当たりをつけ、システムを理解する
- エンジニアと外部設計レベルのコミュニケーション
- 仕様変更に対してのテストケースの改修コストがほぼ0に
検証結果の精度向上
- テストの結果に対して本当にそれで良いのか？
- 検証結果にアクセスログを最大活用することで検証結果の妥当性を向上
不具合報告の精度向上
西脇「QAエンジニアからセキュリティエンジニアに転職した話」
自己紹介
- 前職はグリー
- サーバーサイドエンジニア→QAエンジニア
- テスト設計からテスト実行まで
- 現職はサイバーディフェンス研究所
- 分析管
転職してみて感じたこと
- 転職できるとは思っていなくてダメ元で。
- 意外とあり。セキュリティエンジニアとQAエンジニアは親和性あり
どんなスキルでも自分を裏切らない
- 入社前はわけが分からない状態
- 意外と前職の知識が役立った
- 同じチームの方々が上手く仕事を振ってくれた
- @ITで記事を書くときも既にあるスキルが役立った。 ** ボットネットの解説記事
- 「どうしてこういう書き方をしているのか」というところの研究は、QA時代のスキルが役立った
思っていたよりも脅威は身近に潜む
- 情報セキュリティの10大脅威
- 組織に対しては標的型攻撃が猛威を振るっている
- ファイルを暗号化＆身代金（ランサムウェア）のウイルスにかかっている48％はお金を払っている
組織のセキュリティ部門の人は、そもそも感染を防げない前提で動いている
WEBサービスの不正ログイン
- 日々、脆弱性は見つかってくる
- IoT機器の脆弱性攻撃の顕在化
- AWSのアクセスキーをハードコーディングしているものもあるので危ない
今後の展望
- QA+SECURITY+AUTOMATION=?
- 去年8月にCGCがハッカーカンファレンスの中で行われた。
鶴岡「QAが主導する仕様改善について」
事業紹介
- るくみー
- るくみーnote
- ロボット(MEEBO)
るくみー
- 写真販売サービス
- 保育士が写真撮影→アップロード
- 父母がネットで注文
- BtoBtoCの事業
- 保育士が使ってくれないと成り立たない
- テスト対象はアップロード系と購入管理と社内管理のシステム
保育士の特徴
- 仕事がとにかく忙しい
- 不慣れな人が多い
- →ユーザビリティが大事
登場人物
開発プロセス
- 早くて1週間、長くて半年
- 企画→要件定義（※）→基本設計（※）→実装→テスト（※）→リリース
上流工程での仕様チェック
- 要件を満たした仕様になっているか
- 影響する機能の考慮漏れが無いか
- ユーザビリティが良いか
上流工程での仕様改善
- UI変更
- 機能変更、追加
- 機能削除（開発工数に見合わない機能の削除）
- QAが承認するまでは何回か繰り返す
実装フェーズ
テストフェーズでの仕様チェック
- チェックする内容は上流工程と同じ
- 実際に使ってみると気づきがある
- 次どうしていいか迷うなーとか
テストフェーズでも仕様改善している
- 仕様に基づく権限はQAが握っている
どう動くか
- 発生頻度、影響範囲をもって改善案を出す
- ユーザビリティが向上されるか精査する
- 場合によってはサポートチームの方が分かっていたりもする
- 工数を算出する
どう対応するか
- リリースに間に合う
- すぐに対応
- リリースに間に合わない
- リリース日をずらす
- 今回のリリースでは見送る
- 見送られた改善は開発プロセスの2周目へ
狙い
- 保育士が使ってくれないと機能しない
- ユーザビリティを向上させ続けないといけない
保育士の作業負担が減るといろいろな写真をさらに録る→写真が増える→売上が増える
QAはサポートチームに話を聞きに行って、ぐちを聞いたり問い合わせの状況を聞いたり…
QAがやりたいこと
- 利用してくれる保育士の作業負担の軽減
- 保護者が購入写真で家族とのコミュニケーションに役立ててもらうこと
福沢「About “Pair work"」
なぜPair workをスタートしたのか
色んなタスクが振ってくる
- HOME'sに関するプロジェクトが年間数百あるが、それらのサポートをしたり、HOME's以外の新規プロジェクトのQAに行ったり…
- スキルの属人化が増えていった
スキルの属人化を防ぐために行うのがPair work
- タスクに対して2人以上で行う
- タスクの割当は朝会で決定する
- タスクに詳しい人1人と詳しくない人1人を割り当てる
Pair workの振り返りについて
- 1習慣のサイクルをKPTで振り返る
- 隣同士でやった方が良いよね→フリーアドレスへ
Pair workの詳細
- タスクのゴールとTODOをきちんと話す
- 役割を決める
- 設計は2人で
- 開発はAさん
- 開発サポート、調査、レビューなどはBさん
Pairのパターン
- アクティブ＆サポート
- 1人が不慣れな時にこうなる
- アクティブ＆アクティブ
- より速く処理できる
結果
- Pair workを元々期待していた効果は属人化防止
- 自分が知らなかったTipsを教われた
- トラブル時にすぐに気付ける。
やりづらかったこと
- 他のペアチームがやっていることが見えづらい
- ペアワークをやっていてもいなくても起こること
- 朝会などで対応
- ペアを変えるタイミングが難しい
- 本当は1つのタスクが終わったタイミングで変えたかったが…
- タスクではなく1つのプロジェクトが終わったタイミングで（1ヶ月〜2ヶ月程度）
まとめ
- 作業効率の向上
- スキルの属人化防止
- 良いTipsの共有ができる
- 問題点については、ペアワークの運用で何とかなる
- おエアワークのメリットは大きいと思う
鈴木「現場から見るWebと組み込みのQAの違い」
発表資料
略歴
- 2012年まで組み込み
- 2012年からは現職
狙い
- 組織によっての品質の考え方やQAの働き方の違いを知る
比較
- 開発者との距離
- プロダクトに寄与できる最良
- 品質の重要性の浸透
開発者との距離
組み込み
- 縦割り
- 開発との距離が遠い
Web
- わいわい
- 如何に開発と協業するのかを求められる
プロダクトに寄与できる最良
組み込み
品質の重要性
組み込み
- とにかく重要視される
- Webは軽視される場合がある。納期や機会利益が品質に勝つことがある。
Web
- 不具合があってもすぐに直せる特性
- 専属のQAを持たない組織が存在していた。
テストリソース・スケジュール
組み込み
- 同じテストを延々と繰り返す
- テスト実行の厳しい時間制約はあまりなかった
Web
- リソースまでのサイクルが短い
QAエンジニアの地位
組み込み
- 地位が高かった
- 組織にQAエンジニアの重要性が理解されている
Web
- 品質を低く見られがち。業界的に。
産業ドメインによるテストのギャップ
現場での取り組み・心がけ（一部願望を含む）
- プラスのブロックは裁量について
- マイナスの部分は品質の意識について
開発者との距離
- 協業の度合いを深める
- 開発だけのコミュニケーションラインを作らない
- 仕様策定段階からコミット
- 技術定例にも参加
- 設計のレイヤーから
プロダクトに寄与できる裁量
- とにかくオーナーシップを発揮する
- QAとか関係なく、色々巻き込んで発揮しよう
品質の重要性の浸透
- 組み込みでは現場に理解があったがどうやって浸透させるのか
- プロダクトに求められている品質を理解し、過剰品質を目指さない
- テストを妥協するのではなく、スケジュールの遅延や機会損失を招かないようにする
- 過剰品質とはPMBoKで書かれている用語
テストリソース・スケジュール
- 軽微な問題は直さないと割り切る
- 当該リリースで必ず達成したいことを最優先に
- できるだけテストを短い時間で敢行、停滞させないような工夫
- できるだけ原因の把握をして、開発に伝えて開発のモチベーションを低下させない
QAエンジニアの地位
- 地位を高めるには？
- 課題解決の領域を広くする
- 組織の成熟度を高くする
再掲
- 組織による違いを知り、考え方の幅を広げる
視野を広げるには？
- ソフトウェアテスト293の鉄則より
- 社内で最適化された人材にならず、外部で技術や他の現場の事情を知ること
- 組織による品質の考えの違いを知り、QAエンジニアの価値を高めよう。
