「GitLabの実践的な運用」聴講レポート #gitlabjp

資料

qiita.com

自己紹介

• @catatsuy
• 会社のアドベントカレンダーで運用方法を公開した

• Pixivで働いている

• 個人的には、以前のJTF2015で登壇している印象が強いです。

nihonbuson.hatenadiary.jp

GitLabのインストール

• インストールはそんなに難しくない

セットアップサーバについて

• グローバルIPを持つサーバー上に立てることが前提
• サーバーは1台であることが前提
• 複数台構成は現実的ではない
  • DBは別IPでもOK

GitLab.comのバックアップ体制

• 今回問題になったのはあくまでもGitLab.comの問題

GitLabの持っているデータ

• Radisは最悪吹っ飛んでも問題ない
  • セッションとかキャッシュしか持ってない

GitLabのデータベース

• PostgreSQL推奨

RailsとMySQL

• MySQLの知見がない限りMySQLを使わないほうが良い
  • ハハパパ問題とか

GitLabのバックアップ

• bundle exec rake gitlab:backup:createでバックアップできる
  • git db create はmysqldumpとかをしているだけ
  • git bumdle createを叩いて保存しているだけ
  • git upload create はファイルをコピーしてtarで固めているだけ
• 最終的には1つのtarファイルに纏められる
• 様々なサーバにバックアップファイルを送ることも可能
  • cronしたり
    • 環境変数でcron=1を設定するとエラーしていない場合にログ出力しないことが可能

MySQLのバックアップ

• dump以外にも、停止してdata_dirをコピーしたりする手段がある
• リストアも可能

バージョンアップ

• バージョンアップにはDBのバックアップを録るように書かれている
• GitLabのバージョンアップで関わるのはDBぐらい
• 一気にVerUpを上げることも可能
• 一部、特殊な作業が必要

無停止VerUp

• ほぼ無理
• master,slaveでも可能だが手間がかかる
• アプリケーション起動中に行うことはできない
• ある程度短くすることは可能だがrakeの時は停止する必要あり

最後に

• ソースコードもシンプルなので動きを追うことは比較的容易
• 昔はGHEと呼ばれた時代もあったが、ソースコード公開によるメリットが大きい

「GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開」聴講レポート #gitlabjp

発表資料

qiita.com

自己紹介

• @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

• RailsベースのソースではGitHubの中でスターが一番だった(2016年)

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のワークで行ったことを共有したいと思います。

テスト分析

最初に仕様書、設計書が配布されたところで、

1. 個人ワーク
2. ワーク結果をマージ（基準にできそうな人のワーク結果を土台にグループとしての分析結果を出す）
3. 各テスト条件に対して、利用できそうなテスト設計技法を選ぶ

という計画を示されました。

私の班が行ったこと

自分達の班は、個人ワークおよびマージした後、

• 「本当にお客さんが要望していることってなんだろう？」
• 「新業務がきちんと行うことができることではないか？」

という結論になり、業務を回すために必要なことは何かということを中心にもう一度個人ワークをすることになりました。

個人的な想い

上記の議論の際、「業務を回すこと」ではなく「一つ一つのチェックがしっかりできること」という結論に持っていくことも可能であり、そちらを取ったほうが色々なテスト技法に触れられるのでは？と思っていました。

しかし、班としての結論・納得は「業務を回すこと」であり、私自身もそちらで納得できたので、この方向で進めました。

ただ、正直、今回のワークとして成功できるのか、そして初参加の方に満足してもらってWACATEを終わらせることができるのか、この時点ではすごい不安でした。

秋山先生の講演

2日目の朝は、秋山先生の講演がありました。

その中で、分解という部分に注目し、前日に出てきた内容についてグループ化を行うことにしました。

発表スライド

20160619 wacate from Kouichi Akiyama

www.slideshare.net

個人的な感想

分解、そしてセミラティスの話とか、JaSST'16 Tohokuでの話と似ているなと感じました。

実際、グループ化の作業は正にJaSST'16 Tohokuと同じようなワークになりました。

テスト設計技法の実践＆テストケースの作成

私達の班では、以下の4つを利用することに。

• ユースケーステスト
• 同値分割法
• 状態遷移
• デシジョンテーブル

特に、「業務を回すこと」を第一に考えることにしたので、ユースケーステストの作成に3人を投入し、残りの部分に、1人ずつ分担して作成することに。

結果的に、この方針が良かった（気がする）。

ユースケーステストはベテラン1人が若手2人をサポート。

同値分割の人はすぐに終わったので、状態遷移を作っている初参加の人をサポート。

同値分割＆デシジョンテーブル担当は黙々と実施。

そんな形で行いました。

ただし、テストケースについては、時間切れで最後まで完成できず･･･。

そこまで考慮した時間配分にできればもっと良かったかなと。

個人的な想い

ユースケーステストは、他のテスト技法に比べても、作成者の差が顕著に出やすいものになると思っています。

今回も作成した3人で差が出ました。

ただし、今回はベテランではない人のテスト設計結果を採用しました。

これは2つの狙いがありました。

1. 今の自分達チームの結果をきちんと示したい（ベテランの内容をそのまま使ってしまうと、「自分のチームの成果」という意義が薄れてしまう）

2. テスト設計結果の抜け漏れの部分を、他の設計したもので補完できていることを示したい。

特に2つ目の狙いは、ユースケーステストで書ききれなかったケースを、状態遷移側で上手く補完できました。

成果物

以下の写真のようになりました。

全体の進め方

業務フロー

テスト分析結果

ユースケーステスト

ユースケーステストから作成したテストケース

状態遷移

同値分割・境界値分析

デシジョンテーブル

デシジョンテーブルを元にしたテストケース

はっきり言って、成果物は他の班よりも綺麗ではありません。

しかし、班の人全員が納得できるものになったのではないかと感じています。

最後に

2017年夏のWACATEは6/17・18開催予定です！ wacate.jp

JaSST'17 Tokyoに行ってきました #JaSST

先日、JaSSTに行ってきたので、その参加レポートを書きました。

軽く感想を書きつつ参加レポートを紹介します。

基調講演

nihonbuson.hatenadiary.jp

• 裏話がいっぱいで楽しんで聞くことが出来ました。

• そして、国際標準を決めるって大変と感じ、SQuaREって良いものだと再認識しました。

招待講演

nihonbuson.hatenadiary.jp

• 奈良さんのぶっちゃけトークがすごい面白かったです。

楽天トラベルの開発プロセスに関して

nihonbuson.hatenadiary.jp

• プロセス改善の例として参考になりました。

• 他のセッションもそうだけど、如何にしてVモデルでいう左側に関わっていけるのかをテーマにした話が多かった気がします。

【ジャストーーーク】転職芸人が語るテスト／QA技術者としてのキャリアパス

nihonbuson.hatenadiary.jp

• 登壇者は転職芸人という立ち位置で参加していましたが、転職するかどうかは関係なく、テストエンジニアとしてどうしていくのかということに関して参考になりました。

教科書に載らないテストマネジメント

nihonbuson.hatenadiary.jp

• テストマネージャとしてあるべき姿をぶっちゃけトークで話していました。

• 途中参加だったのが悔やまれるぐらい、すごい良いセッションでした。

テスト現場のお悩み相談

nihonbuson.hatenadiary.jp

• あるあるな事例に対して、様々なアプローチでアドバイスしていました。

• もはやテストの範疇を超えて、設計段階の所からどうしていくかみたいな話もありました。

Web.JaSST Web Service QA Meeting in JaSST'17 Tokyo

nihonbuson.hatenadiary.jp

• 様々な企業での事例を話していました。

• 目的を持って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％はお金を払っている
  • オーストラリアの4つ星ホテルでランサムウェアにかかってしまい、ホテルのお客が全員締め出される事件があった
  • ロサンゼルスの病院でランサムウェアに感染し、カルテが見れない状態に
  • 最近の標的型攻撃は怪しくない日本語で、怪しくない内容で、知っている人物になりすまして送ってくる
    • しかも実行した後に気付いていない

• 組織のセキュリティ部門の人は、そもそも感染を防げない前提で動いている

• WEBサービスの不正ログイン

  • 日々、脆弱性は見つかってくる
• IoT機器の脆弱性攻撃の顕在化
  • 家のルーターを狙ってくる
  • 家のルーターの初期設定を考えたほうが良い
• AWSのアクセスキーをハードコーディングしているものもあるので危ない

今後の展望

• QA+SECURITY+AUTOMATION=?
• 去年8月にCGCがハッカーカンファレンスの中で行われた。

鶴岡「QAが主導する仕様改善について」

事業紹介

• るくみー
• るくみーnote
• ロボット(MEEBO)

るくみー

• 写真販売サービス
• 保育士が写真撮影→アップロード
• 父母がネットで注文
• BtoBtoCの事業
• 保育士が使ってくれないと成り立たない
• テスト対象はアップロード系と購入管理と社内管理のシステム

保育士の特徴

• 仕事がとにかく忙しい
• 不慣れな人が多い
  • →ユーザビリティが大事

登場人物

• システム開発部
  • WEBエンジニア9名
  • スマートフォンエンジニア3名
  • QA1名
• サポートチーム
  • ユーザー問い合わせ対応
  • システム導入サポート

開発プロセス

• 早くて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の違い」

発表資料

speakerdeck.com

略歴

• 2012年まで組み込み
• 2012年からは現職

狙い

• 組織によっての品質の考え方やQAの働き方の違いを知る

比較

• 開発者との距離
• プロダクトに寄与できる最良
• 品質の重要性の浸透

開発者との距離

組み込み

• 縦割り
• 開発との距離が遠い

  Web

• わいわい
• 如何に開発と協業するのかを求められる

プロダクトに寄与できる最良

組み込み

• ボトムアップからの改善提案は難しい
• ユーザーの意見を取り入れにくい

  Web

• ボトムアップで
• 現場の意見

品質の重要性

組み込み

• とにかく重要視される
• Webは軽視される場合がある。納期や機会利益が品質に勝つことがある。

  Web

• 不具合があってもすぐに直せる特性
• 専属のQAを持たない組織が存在していた。

テストリソース・スケジュール

組み込み

• 同じテストを延々と繰り返す
• テスト実行の厳しい時間制約はあまりなかった

  Web

• リソースまでのサイクルが短い

QAエンジニアの地位

組み込み

• 地位が高かった
• 組織にQAエンジニアの重要性が理解されている

  Web

• 品質を低く見られがち。業界的に。

産業ドメインによるテストのギャップ

現場での取り組み・心がけ（一部願望を含む）

• プラスのブロックは裁量について
• マイナスの部分は品質の意識について

開発者との距離

• 協業の度合いを深める
• 開発だけのコミュニケーションラインを作らない
• 仕様策定段階からコミット
• 技術定例にも参加
• 設計のレイヤーから

プロダクトに寄与できる裁量

• とにかくオーナーシップを発揮する
• QAとか関係なく、色々巻き込んで発揮しよう

品質の重要性の浸透

• 組み込みでは現場に理解があったがどうやって浸透させるのか
• プロダクトに求められている品質を理解し、過剰品質を目指さない
• テストを妥協するのではなく、スケジュールの遅延や機会損失を招かないようにする
• 過剰品質とはPMBoKで書かれている用語

テストリソース・スケジュール

• 軽微な問題は直さないと割り切る
• 当該リリースで必ず達成したいことを最優先に
• できるだけテストを短い時間で敢行、停滞させないような工夫
• できるだけ原因の把握をして、開発に伝えて開発のモチベーションを低下させない

QAエンジニアの地位

• 地位を高めるには？
  • 課題解決の領域を広くする
  • 組織の成熟度を高くする

再掲

• 組織による違いを知り、考え方の幅を広げる

視野を広げるには？

• ソフトウェアテスト293の鉄則より
• 社内で最適化された人材にならず、外部で技術や他の現場の事情を知ること
• 組織による品質の考えの違いを知り、QAエンジニアの価値を高めよう。

質問

• 泰楽さんに質問
• 探索的テストはスキルのばらつきがあり、スキルアップが難しいと思うが、スキルアップの方法は？
• QAは開発と同じような仕事をしているが、プログラミング経験が少ないとは思うが、プロダクトコードを読み込む、SSHでログインするなどのエンジニアに近い作業を行うことでスキルアップをした。

テスト現場のお悩み相談 #JaSST '17 Tokyo

登壇者

• 鈴木三紀夫
• 松木晋祐
• 山崎崇
• 藤原洋平
• 長谷川聡

モデレータ

• 江澤宏和

アジェンダ

• オープニングとポジショントーク
• ディスカッションパート1
• ディスカッションパート2

オープニングとポジショントーク

• 炎上しているプロジェクトに入る場合、みなさんはまず最初に何をしますか？

鈴木

• 入るときにはPMとして入るが、表と裏の技がある。
  • 表の技…全てのタスクを洗い出すこと。お客さんのクレームとかも全てタスクにする
  • 裏の技…入ってすぐ、メンバーに「平日のある1日休め」と言う。お客さんの交渉力があるPMだと信頼してもらう

松木

• テストリーダーの立場として入ったら、情報の流通経路を確認し、詰まっているところが無いか確認する。情報を今後共有する時は、その経路を使う。それが無かったらまず構築する
• どうなったら炎上が終わるか確認する

山崎

• 支援とする立場が多い。
• 欠陥管理ツールがあるならば、それを見る。WBSがあれば見る。あとはヒアリング。

藤原

• 体制図を作って可視化する。
• お客さんもいるときは、窓口だけではなく、お客さん先の開発陣や子会社なども確認する。
• 仕様決めの人は？予算決めは？Goサインは誰が？を見る

長谷川

• 現場のテストをしている人と話をする。
• 上の人と現場の人の認識のズレがあるはずなので、そこをまずは解決する。

アンケート

• 候補1…結構いる（2番）
• 候補2…これ多い（1番）
• 候補3…なるほど（3番）
• 候補4…これ少ない
• 候補5…意外と少ない

ディスカッションパート1「仕様書が神様ではない状況」

鈴木

• テスト設計ではなく、QA形式のものを構築する

長谷川

• 実態として、連絡経路とかではなくもうテストしなくてはいけない場合は？

松木

• 私の場合はテストケースのレビューも行う
• 機能仕様書やユーザーマニュアルを作ってからテストする。
• クラッシュなどを中心にテストする。
• 類似製品のテスト設計を当ててみる。
• 質の低い仕様に対してテスト設計をしても効率が悪い

長谷川

• 全部の質が悪いことはあまり無いのでは？

山崎

• 特定のところだけ良いところはあまり無いイメージ

松木

• 機能仕様が無くても要求が無いわけではない

鈴木

• エンプラの場合は、区分コードや種別コードの組み合わせを考えて、ビジネスルールをあたりをつける。
• もしくは画面からビジネスルールのあたりをつける

山崎

• 期待結果に着目して話すが、テストオラクルが無い場合、そもそも期待結果を定義出来ないと思うが、起きたことのリスクを合わせて報告できるようにする。
• 結果がFailだけでなく、影響度からのリスクも示す

松木

• 確かに、これって開発側も分かるようにする

山崎

• 上流側から行うのが王道ですが、テスト側からアプローチする。
• 利用時の品質を訴求して示す。

松木

• テストチームが仕様を書く。そのフェーズはきついが、次フェーズでアドバンテージになる。次フェーズでかならずテストチームに関わることになる

松木

• 分かっている人が限られて属人化しやすい範囲かなと

ディスカッションパート2「結合テストが終わってないのにシステムテストが開始される」

藤原

• 実際に経験あり。結合テストどころか、機能実装が終わってない段階でできるところからやってと言われる。
• PMとの事前合意が大事。
• こういう状況になってしまったら、立て直す方にフォーカスする

山崎

• 決定権がPMにあるように見えるので、無茶ぶりに対するリスクを示してあげることが重要。
• 新しいバグを見つけることも価値があるが、それによるリスクを説明することも価値がある

長谷川

• PMにリスクを説明して聞いてもらえるコツはあるか？

松木

• この段階になると聞いてくれない。

鈴木

• これって手遅れなんだよね。
• 何が問題なのかよくわからなかった。
• 今回の対処なのか、もう一回起こさないためにはなのか。
• おそらく、契約時などでこの状態になる予兆があるはず。
• 隠して第三者検証に発注しようとしてもダダ漏れになるはず。

長谷川

• その意見はAgreeだが、こういうことってよくあるべきでは？

鈴木

• いくつかの握りができるはずなので、システムテストが1ヶ月あったら最初の3日でこれだけバグが出たら相談しませんか？とか

長谷川

• 核心疲れるとへそ曲げちゃうPMは多いハズ。人情派で行きたい

山崎

• 責任を負うあなたに向けてリスクを示したい。それでも行くんだというならばそのPMは責任を負うべき。都度都度ジャッジする情報を示したい。

長谷川

• 数値を出すのって大変だと思うが、すごいと思う

鈴木

• テストチームとリーダーではなく、PMの立場に寄り添っているように感じた

長谷川

• いやらしい言い方をするとそうかもしれない。私はテストのプロなので、その部分については信じてくれと

鈴木

• ということはPMOではなく、テストのアドバイザの立場と。

松木

• 本来、どの段階で出るべきバグかというような数値を出す。
  • 次のプロジェクトもある場合はね。
• 単発の場合は優先度を付けて、優先度の高い部分からやって、7割できるけど、3割できない部分をやりますかやりませんか？と伝える
  • （「冊」の字の話）

鈴木

• 昔の人はT型とかπ型とか言う。
• その状況で何とかやれと言われたら、チームを分けてしまう。
  • 結合テストとシステムテストでチームを分ける。

山崎

• システムテストとしての要員100％を結合テストの要員に分割すると

鈴木

• そういうこと。
  • 場合によって、結合テストが開発者中心になっているならば、そこにテストチームが入る

ディスカッションパート3「影響範囲を適切にテストする方法は？」

鈴木

• テストコンサルタントとして入るとめっちゃ多いが、これはテストの範囲ではない。
• 影響範囲分析をしてくださいと言うしか無い。
• 対象システムによって違うかもしれないが、リソース共有をしている場合、そこのプログラムにリソースに影響を及ぶ可能性がある場合（1次波及）と、そのリソース先も影響を及ぶ場合（2次波及）がある

山崎

• ソリューションの1つはテスト自動化。もう影響範囲を考えない方法。

松木

• 自動化を進める時は、冊の1画目をまずは行う。テストの人が知っておくこととして、開発者は影響範囲を断定するのがすごい怖い。
• 「言ったじゃん」と言われるから。開発者に丸投げするのではなく、テスト担当者もテクニカルレビューに参加する。開発者1人に丸投げしない。

鈴木

• 自動化しようとすると、保守フェーズなので自動化のコストを捻出できなくて断念する。
• そういう場合はデータパトロールを導入する。
• システムテストが終わったら簡単なプログラムバッチを流す。
• テストの自動化というと負荷がかかるが、数値の単純な足し算を作っておく。

山崎

• 自動化というと重いものを考えがちだが、チェッキングの部分だけでも自動化する

質問

Q. システムテストをやっている途中に結合テストやっているということについてどのように交渉するのか？

鈴木

• システムテストとして請け負っているが、結合テストのバグが出るのであれば、システムテストは工数がかかるので、裏ワザとして結合テストを行うべき

江澤

• やはりPMとネゴるべき？

鈴木

• ケースバイケース

江澤

• PMとネゴると裏という感じではなくなる

Q. 候補1に関連して、藤原さんが言ったように製造が終わってないのにテストしてくれと言われる。製造が終わってないので受け入れテストが始まる場合は？（作りかけのビルドが提出されてるとか）

藤原

• 仕様書のレビューとか出来ないのでは？

山崎

• そこまでいくと、政治で解決しないといけない

松木

• お客さんに「本当にやりたかったことはこれですか？」と要求の方からアプローチする

鈴木

• 質の高いテストケースを書くようにする

長谷川

• これが全部通ったら嬉しいですか？というテストケースを作る

Q. 松木さんが、仕様をテストチームが書いてしまうと言ったが、設計チームも書いているので、2つ出来ると思ってしまうが？

松木

• システムチームが書いている権限を乗っ取ったほうが良い。

鈴木

• 派生開発は差分だが、テストで欲しいのは全体なのでそれをこっちで書く

江澤

• 仕様書を書く技術はテストチームが持っているのか？

松木

• 期待結果を元に作れば仕様書に出来ると思う

山崎

• 状態遷移テストとかデシジョンテーブルとかは本来設計段階で書くべき

江澤

• 動かないと仕様が確定できないものがある

山崎

• それはテストオラクル問題で、実際に今後出てくる。分からないものに対してはかなり煮詰めておく必要がある

Q. コンシューマに所属しているのですが、設計との交渉になる。どこまでだったら直さなくても良いよというような知見があれば教えてほしい

山崎

• バグレポートに対して直す直さないのかの判断はPMが行うべき。なのでPMにエスカレーションすべき。

松木

• それはチームが目指すべき品質レベルの共有が出来てない。
• 優先度高中低とその都度考えて付けているチームはきっと合意できていないはず。
• パフォーマンスを重要とするのか、セキュリティを重要するのか。

山崎

• いくつ以上のものはすぐに直すなどの判断をする

Q.探索的テストと記述テストをやったあと、スーパーテスターがバグをいっぱい出した結果、バグが収束しなかった。どのように記述テストにフィードバックさせるのか？

長谷川

• 探索的テストを欠陥ベースにやっているはずなので、欠陥と見つけ方を管理するのが1つのアプローチ。何のバグを想定してテストを行おうとしているのかを共有する。

松木

• 共有すべきなのは思考過程やテスト観点。探索的テスターが語りだした最初の10秒が重要

長谷川

• 感覚派のテスターもいるのでは？

山崎

• 説明が出来ないテスターは探索的テストではなくアドホック。

鈴木

• 感覚派の感性に合わせられる説明をすることも大事。

教科書に載らないテストマネジメント #JaSST '17 Tokyo

おことわり

• 最初から参加することが出来なかった＆携帯でメモしていたため、発言者や発言内容が合っていない可能性があります。
• ご了承下さい。

お題1

• テストマネージャは何が重要なのか

小山「知ること ※ただし制約の中で」

• そして知らせることも重要

佐々木

• 調整の方法は？

小山

• 知りたいことって何か？というスコープマネジメントする。ヒアリングをする。
• 事前にネゴっておく。

佐々木

• 明日リリース判定でダメだよというときは？

小山

• これだけリスクがあるのでオススメしませんと言う
• 信頼して貰っているのが大切

中野「チームの柱…ではなく、テストの答えを持つこと。」

• 第三者的視点で見れること。

佐々木

• こんなん教科書に載せられない。「リファレンスとか」とはなんなのか

湯本「ブレない心。対等に渡り合う精神力。メンバーがやっていることが正しいと信じること」

• テストが最後の砦になりがちな所なので、元々と変わってくる。それで残業が増えたり…。
• そこで変わってくるのはおかしいと言い張ることが大事。

佐々木

• もっと具体的な話が聞きたい

長谷川「説得する材料はどんなものがあるか」

• いつ何を聞かれても、テストプロダクト状況を説明できる
• メンバーにはテストに集中させて、常に説明できること

湯本

• アカウンタビリティーとか言われるところ

佐々木

• どうやってその説明する材料を集めるんだろう？

長谷川

• テストの状況をなんでも、というが、その中で何が大切だと思うか？
• テストの何%とか本当に聞きたいんですか？

• 経営層なのか開発陣で説明する内容は異なる。

  • テストリソースの話なのか、テストしないことのリスクの話なのか？

• 最終的には経営層がジャッジするので、出荷をどうしても止めるということはない

お題2

• テストメンバーに今回のテストの1週間頑張らなくちゃいけないとき、どういう説明をするのか？
• だいたいステークホルダー側の話になりがちだが、現場の人にどのように伝えるのか？

小山「ゴールの話」

• ゴールを達成するために困ったことが無いか
• 人って目的とかゴールとか分からないまま進みがち。

佐々木

• スケジュールだけでなく、内容を把握して説明している

湯本「なにをどこまでやれば終わるか。可視化、残テスト数、バグ数…」

• 朝礼とかでやることを全部話して、目標達成したら喜び、達成していなければ残業したりする。
• その可視化の情報に嘘を含めないようにお願いする

小山

• メンバー信用してないじゃないですかー

湯本

• 基本的には信用してるよ。それでも間違えることがあるから

佐々木

• 計画通りで、ではなく優先順位をつけて朝会でやるって重要なこと

神田「I message ヘルプミー」

• 緊急事態が発生したときは何をすべきか、やりたいことを伝えて、みんなで考えていく

佐々木

• みんなに嫌われずにいることは大事
• 黙ってやるのではなく、共有することが必要

長谷川「平鍋さんから聞いた話『スコアボード』」

• 9回2アウトの時に、みんなが走れますか？
• ステークホルダーもテストメンバーも同じ状況を理解して走り出せますか？

佐々木

• 進捗とかがエクセルにまとめられて「ここに置いてあるから見てね」と言ってませんか？
• かんばん方式とかみたいに、見える場所にあることが重要

お題3

• テストマネージャーはテストプロジェクトを成功を導くたまにあらゆる活動を実施する。
• そのためにテストプロジェクトを成功に導く秘訣を話しやがれ。当然その理由も説明しやがれ
• テスト計画ではここを注意しようとか、テスト実施時にはここを注意しようとか。

中野「逆算のイメージ。」

• 自分の中で計画もそうだが、実際のリリース日から逆算してイメージとの乖離を照らし合わせる
• 数値だけ見てると多分違っている。メンバーの疲労度とか

佐々木

• 自分だけ？チームメンバー全体が持てているか？

中野

• 共有はするが、自分が一番見えているはず。詳細までは共有してない。

佐々木

• スケジュールを立てる時は足し算して期間が無いから頑張って圧縮しがち。
• そうではなく、引き算をできると、要素を理解しているはず。答えから引いていく。

中野

• 答えから引いてくるとは？

佐々木

• 全体で40とか見えていないと逆算出来ないですよね？
• 積み重ねて終わりではなく、工程が結果に繋がるが、結果を見えてないといけない。

小山「完全性。※データの整合性」

• テストの成功ってなんだ？と悩んだが、5Wをしっかり残すことが成功だと思っている。

佐々木

• 現状の品質を知りたいという場合もあるが、出荷できる状態を示すことが必要

小山

• データが残ってないとやり直しになっちゃうので、ちゃんと残しましょうということ。

佐々木

• 一番最初から考えておかないと、説明は出来ないですよね。残っているデータから状況を管理しておく。
• そして、すぐに戻って管理しておくのが重要。

長谷川「テスト実行に入ったら自分達が主役。バクが直らないなら直せるようにしてあげる。」

• これをさせてもらえる伝達をする

湯本

• テストを終わらせるには最終的には開発者が直して動くようにならないといけない

佐々木

• 検出率はよく出されたりするが、修正率は出していますか？そこで修正率が高い人は能力が高い。
• これをマネージャーがリードしてあげる。重箱の隅をつつくと、開発者が「もういいよ」とモチベが下がる。
• どれぐらいバグがあるか求められたらいっぱい出すが、そうでない限りは、その方法はしない。

湯本「計画時と実行時で秘訣が異なる」

• 計画時①…必要なものの調整。特に自分達で出来ないこと。
  • 環境とか。
  • 他社とのネゴシエーションとか。
  • 貰ってくるデータとか。
• 計画時②…ゴールの握り。
  • 品質的なゴールとか。
• 実行時①…正直になる。
• 実行時②…バグの修正を停滞させない。
• 実行時③…他テストレベルのと調整。
  • 「これだけ品質が悪かったら単体テストをやるべきでしょ？」とか

佐々木

• なんかまともな回答ですね。
• 他のところも見なくてはいけない。
• 正直になることだけでなく、嘘をつかなくちゃいけないような環境を作らない。
• 「オンスケです」と嘘を付いていると、8割ぐらい終わってからダメだとなる。

神田「臨機応変、ブレないゴール。」

• 計画時点でゴールを握るが、基本的には線通りに行かない。

湯本

• WBS通りにはだいたい行かない。

神田

• その時の臨機応変に合わせて小さなゴールを決めたりする。

---

お題4

• テストマネージャーは日頃から研鑽しているはず。
• 後輩のお手本になるためにどんな努力をしているのか話しやがれ。

小山「とりあえずやってみる。※興味を持って楽しむ」

• とりあえずやることが大事

佐々木

• やってみるのは重要。
• メンバーに働きかけるだけでなく、自分でもやる。
• 失敗したからダメだではなく、その経験を使ってフォローしてあげる。

神田「社外→社内」

• 10年前にjasstを知って、全国回った時は、それをすぐに実践したりしている。

長谷川「JSTQBシラバスを読んで自分のものにする。」

• ラーニングオブジェクトを読む。オプションが変わっていく。
• 自分の実力を知る。

中野「開発を学ぶ。」

• WEB系は組み込み系と違って分かりやすいので、学ぶことが大事。
• なんとなく経験で工数を増やそうか、ではなく、実際に学ぶ。

佐々木

• テストって開発をどれだけ知っているの？とかはこれだけで1テーマになる話題

湯本「テストの知識は必要。（JSTQBのTM）」

• 大事なのは、良いエッセンスを自分のところに適用させる。
• 多くの人と協同で仕事をする訓練をする（WBSのような上っ面の部分だけではなく。）
• テストマネージャーに限ったことではないが、いつも考えてトレーニングにするとか。

実行委員からのフィードバック

• 神田さんへ…組み込み系をやっているので共感できる
• 湯本さんへ…とにかくすごい。多くの人を動かしている
• 小山さんへ…私もMなんだな。みなさんも是非やってほしい
• 中野さんへ…逆算するイメージが出来てないことに気づいた
• 長谷川さんへ…コメントを断言できているのがすごい。

MVP

• スコアボードの話がMVP。

• 状況を全員に伝えることの大切さを感じた。

• 今の状況を共有する、嘘をつかずに言う。

• うわべだけの共有になってないか気をつける。

• 打ち合わせをやっていても中身が無ければ意味がない。