読者です 読者をやめる 読者になる 読者になる

WACATE 2016夏 ~走りきるテスト設計~ #WACATE

wacate 技術 勉強会

昨年、WACATE 2016夏に参加してきました。

今回は1つの題材を元に、テスト分析・テスト設計を行おうという趣旨のものでした。

WACATE2016のワークで行ったことを共有したいと思います。

テスト分析

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

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

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

私の班が行ったこと

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

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

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

個人的な想い

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

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

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

秋山先生の講演

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

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

発表スライド

www.slideshare.net

個人的な感想

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

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

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

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

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

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

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

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

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

そんな形で行いました。

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

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

個人的な想い

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

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

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

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

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

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

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

成果物

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

全体の進め方

f:id:nihonbuson:20160622224028j:plain

業務フロー

f:id:nihonbuson:20160622224039j:plain

テスト分析結果

f:id:nihonbuson:20160622224048j:plain

ユースケーステスト

f:id:nihonbuson:20160622224056j:plain

f:id:nihonbuson:20160622224103j:plain

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

f:id:nihonbuson:20160622224114j:plain

状態遷移

f:id:nihonbuson:20160622224122j:plain

同値分割・境界値分析

f:id:nihonbuson:20160622224127j:plain

デシジョンテーブル

f:id:nihonbuson:20160622224133j:plain

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

f:id:nihonbuson:20160622224139j:plain

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

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

最後に

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

勉強会 技術 JaSST

登壇者

  • 泰楽
  • 西脇
  • 鶴岡
  • 福沢
  • 鈴木

泰楽「メルカリで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エンジニアは親和性あり

どんなスキルでも自分を裏切らない

  • 入社前はわけが分からない状態
  • 意外と前職の知識が役立った
  • 同じチームの方々が上手く仕事を振ってくれた
  • @ITで記事を書くときも既にあるスキルが役立った。 ** ボットネットの解説記事
  • 「どうしてこういう書き方をしているのか」というところの研究は、QA時代のスキルが役立った

思っていたよりも脅威は身近に潜む

  • 情報セキュリティの10大脅威
    • 組織に対しては標的型攻撃が猛威を振るっている
  • ファイルを暗号化&身代金(ランサムウェア)のウイルスにかかっている48%はお金を払っている
    • オーストラリアの4つ星ホテルでランサムウェアにかかってしまい、ホテルのお客が全員締め出される事件があった
    • ロサンゼルスの病院でランサムウェアに感染し、カルテが見れない状態に
    • 最近の標的型攻撃は怪しくない日本語で、怪しくない内容で、知っている人物になりすまして送ってくる
      • しかも実行した後に気付いていない
  • 組織のセキュリティ部門の人は、そもそも感染を防げない前提で動いている

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

発表資料

speakerdeck.com

略歴

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

狙い

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

比較

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

開発者との距離

組み込み
  • 縦割り
  • 開発との距離が遠い
    Web
  • わいわい
  • 如何に開発と協業するのかを求められる

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

組み込み

品質の重要性

組み込み
  • とにかく重要視される
  • Webは軽視される場合がある。納期や機会利益が品質に勝つことがある。
    Web
  • 不具合があってもすぐに直せる特性
  • 専属のQAを持たない組織が存在していた。

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

組み込み
  • 同じテストを延々と繰り返す
  • テスト実行の厳しい時間制約はあまりなかった
    Web
  • リソースまでのサイクルが短い

QAエンジニアの地位

組み込み
  • 地位が高かった
  • 組織にQAエンジニアの重要性が理解されている
    Web
  • 品質を低く見られがち。業界的に。

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

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

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

開発者との距離

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

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

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

品質の重要性の浸透

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

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

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

QAエンジニアの地位

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

再掲

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

視野を広げるには?

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

質問

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

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

勉強会 技術 JaSST

登壇者

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

モデレータ

  • 江澤宏和

アジェンダ

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

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

鈴木

  • 入るときには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型とかπ型とか言う。
  • その状況で何とかやれと言われたら、チームを分けてしまう。

山崎

鈴木

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

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

鈴木

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

山崎

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

松木

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

鈴木

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

山崎

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

質問

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

鈴木
江澤
  • やはりPMとネゴるべき?
鈴木
江澤
  • PMとネゴると裏という感じではなくなる

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

藤原
  • 仕様書のレビューとか出来ないのでは?
山崎
  • そこまでいくと、政治で解決しないといけない
松木
  • お客さんに「本当にやりたかったことはこれですか?」と要求の方からアプローチする
鈴木
  • 質の高いテストケースを書くようにする
長谷川
  • これが全部通ったら嬉しいですか?というテストケースを作る

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

松木
  • システムチームが書いている権限を乗っ取ったほうが良い。
鈴木
  • 派生開発は差分だが、テストで欲しいのは全体なのでそれをこっちで書く
江澤
  • 仕様書を書く技術はテストチームが持っているのか?
松木
  • 期待結果を元に作れば仕様書に出来ると思う
山崎
江澤
  • 動かないと仕様が確定できないものがある
山崎
  • それはテストオラクル問題で、実際に今後出てくる。分からないものに対してはかなり煮詰めておく必要がある

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

山崎
  • バグレポートに対して直す直さないのかの判断はPMが行うべき。なのでPMにエスカレーションすべき。
松木
  • それはチームが目指すべき品質レベルの共有が出来てない。
  • 優先度高中低とその都度考えて付けているチームはきっと合意できていないはず。
  • パフォーマンスを重要とするのか、セキュリティを重要するのか。
山崎
  • いくつ以上のものはすぐに直すなどの判断をする

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

長谷川
  • 探索的テストを欠陥ベースにやっているはずなので、欠陥と見つけ方を管理するのが1つのアプローチ。何のバグを想定してテストを行おうとしているのかを共有する。
松木
  • 共有すべきなのは思考過程やテスト観点。探索的テスターが語りだした最初の10秒が重要
長谷川
  • 感覚派のテスターもいるのでは?
山崎
  • 説明が出来ないテスターは探索的テストではなくアドホック
鈴木
  • 感覚派の感性に合わせられる説明をすることも大事。

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

勉強会 技術 JaSST

おことわり

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

お題1

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

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

  • そして知らせることも重要
佐々木
  • 調整の方法は?
小山
  • 知りたいことって何か?というスコープマネジメントする。ヒアリングをする。
  • 事前にネゴっておく。
佐々木
  • 明日リリース判定でダメだよというときは?
小山
  • これだけリスクがあるのでオススメしませんと言う
  • 信頼して貰っているのが大切

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

  • 第三者的視点で見れること。
佐々木
  • こんなん教科書に載せられない。「リファレンスとか」とはなんなのか

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

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

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

  • いつ何を聞かれても、テストプロダクト状況を説明できる
  • メンバーにはテストに集中させて、常に説明できること
湯本
佐々木
  • どうやってその説明する材料を集めるんだろう?
長谷川
  • テストの状況をなんでも、というが、その中で何が大切だと思うか?
  • テストの何%とか本当に聞きたいんですか?
  • 経営層なのか開発陣で説明する内容は異なる。

    • テストリソースの話なのか、テストしないことのリスクの話なのか?
  • 最終的には経営層がジャッジするので、出荷をどうしても止めるということはない

お題2

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

小山「ゴールの話」

  • ゴールを達成するために困ったことが無いか
  • 人って目的とかゴールとか分からないまま進みがち。
佐々木
  • スケジュールだけでなく、内容を把握して説明している

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

  • 朝礼とかでやることを全部話して、目標達成したら喜び、達成していなければ残業したりする。
  • その可視化の情報に嘘を含めないようにお願いする
小山
  • メンバー信用してないじゃないですかー
湯本
  • 基本的には信用してるよ。それでも間違えることがあるから
佐々木
  • 計画通りで、ではなく優先順位をつけて朝会でやるって重要なこと

神田「I message ヘルプミー」

  • 緊急事態が発生したときは何をすべきか、やりたいことを伝えて、みんなで考えていく
佐々木
  • みんなに嫌われずにいることは大事
  • 黙ってやるのではなく、共有することが必要

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

  • 9回2アウトの時に、みんなが走れますか?
  • ステークホルダーもテストメンバーも同じ状況を理解して走り出せますか?
佐々木
  • 進捗とかがエクセルにまとめられて「ここに置いてあるから見てね」と言ってませんか?
  • かんばん方式とかみたいに、見える場所にあることが重要

お題3

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

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

  • 自分の中で計画もそうだが、実際のリリース日から逆算してイメージとの乖離を照らし合わせる
  • 数値だけ見てると多分違っている。メンバーの疲労度とか
佐々木
  • 自分だけ?チームメンバー全体が持てているか?
中野
  • 共有はするが、自分が一番見えているはず。詳細までは共有してない。
佐々木
  • スケジュールを立てる時は足し算して期間が無いから頑張って圧縮しがち。
  • そうではなく、引き算をできると、要素を理解しているはず。答えから引いていく。
中野
  • 答えから引いてくるとは?
佐々木
  • 全体で40とか見えていないと逆算出来ないですよね?
  • 積み重ねて終わりではなく、工程が結果に繋がるが、結果を見えてないといけない。

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

  • テストの成功ってなんだ?と悩んだが、5Wをしっかり残すことが成功だと思っている。
佐々木
  • 現状の品質を知りたいという場合もあるが、出荷できる状態を示すことが必要
小山
  • データが残ってないとやり直しになっちゃうので、ちゃんと残しましょうということ。
佐々木
  • 一番最初から考えておかないと、説明は出来ないですよね。残っているデータから状況を管理しておく。
  • そして、すぐに戻って管理しておくのが重要。

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

  • これをさせてもらえる伝達をする
湯本
  • テストを終わらせるには最終的には開発者が直して動くようにならないといけない
佐々木
  • 検出率はよく出されたりするが、修正率は出していますか?そこで修正率が高い人は能力が高い。
  • これをマネージャーがリードしてあげる。重箱の隅をつつくと、開発者が「もういいよ」とモチベが下がる。
  • どれぐらいバグがあるか求められたらいっぱい出すが、そうでない限りは、その方法はしない。

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

  • 計画時①…必要なものの調整。特に自分達で出来ないこと。
  • 計画時②…ゴールの握り。
    • 品質的なゴールとか。
  • 実行時①…正直になる。
  • 実行時②…バグの修正を停滞させない。
  • 実行時③…他テストレベルのと調整。
    • 「これだけ品質が悪かったら単体テストをやるべきでしょ?」とか
佐々木
  • なんかまともな回答ですね。
  • 他のところも見なくてはいけない。
  • 正直になることだけでなく、嘘をつかなくちゃいけないような環境を作らない。
  • 「オンスケです」と嘘を付いていると、8割ぐらい終わってからダメだとなる。

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

  • 計画時点でゴールを握るが、基本的には線通りに行かない。
湯本
  • WBS通りにはだいたい行かない。
神田
  • その時の臨機応変に合わせて小さなゴールを決めたりする。

お題4

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

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

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

神田「社外→社内」

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

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

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

中野「開発を学ぶ。」

  • WEB系は組み込み系と違って分かりやすいので、学ぶことが大事。
  • なんとなく経験で工数を増やそうか、ではなく、実際に学ぶ。
佐々木
  • テストって開発をどれだけ知っているの?とかはこれだけで1テーマになる話題

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

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

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

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

MVP

  • スコアボードの話がMVP。
  • 状況を全員に伝えることの大切さを感じた。

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

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

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

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

JaSST 勉強会 技術

登壇者

  • 大西健児(以下、大西)
  • 柿崎憲(以下、柿崎)
  • 山本くにお(以下、山本)
  • 山本健(以下、番長)
  • 湯本剛(以下、湯本)
  • 吉澤智美(以下、吉澤)
  • 安達賢二(以下、安達)
  • 福田里奈(以下、福田)
  • KENさん
  • 越中谷郁美(以下、越中谷)

キャリアアップで芸人紹介

大西

  • 1人2分ぐらいで話すので早口で。
  • QAエヴァンジェリスト。社内では「エヴァンゲリオン」と言われてる。
  • 英語喋れるとかっこいいかも→外資へ転職。
  • テスト勉強しなきゃ→テスト技術者交流会へ
    • 翻訳を頼まれる
    • JaSSTを始めた1名
  • ASTER作ったり
  • JSTQB作ったり
  • 今日はけんさんが5人いる

柿崎

  • QA始める前に5回転職してる
    • 今回の芸人はみんな5回以上転職してます。
  • 肌色の多いみんながアクセスしていたサイトとか。
  • 市役所の臨時職員とか。
  • 黒い何とかVitaとかからQAの世界へ
  • mixiの業績不振が今の私を作った

山本くにお

  • 転職前の部分は割愛。平成元年に社会人に
  • 転職してSONYに入ってから高品質を求められた
  • TEFとかWACATEとかに参加
  • より早いサイクルの会社に転職
  • 現在はKDDI

番長

  • 僕、怖い人じゃないです
  • 最初は芸術を志して、水道がとまったりしていた
  • 最初はSIでテストして、リーダーへ
  • ベンチャーに転職
  • ソーシャルゲームで波に揉まれて
  • 現在はmixi
  • スライドには収入の変遷も載せた

湯本

  • 1991年に社会人に
  • メーカー系に入社
  • 海外に住みたいので休職しようとしたらダメと言われたので退職した。
  • ソフトウェアベンターに参加
  • TEFに参加
  • 東京に行くためにコンサルに転職
  • そんな感じでばーっとやって、今に至る

吉澤

  • 自分の場合は社内転職芸人ということで出させていただいている
  • 前半戦は基礎的な知識を溜め込む。開発→リーダーへ
  • 子供が生まれて、育休が終わった当たりから社外活動へ。
  • 出向先で色々あった
  • 社内異動を拒否したこともあった
  • 社内異動で研究職へ。標準化を行い始めるように

テーマトーク

  • KEN「15分前倒しで進んでおります」

転職した同機は何か?

山本「パフォーマンスを発揮できる戦場を求めて」

  • 整っていない会社さんのところに言って1,2年で回り始めると、「そろそろかな…」と思って、社外からも誘いがあって転職する
    • 安達「パフォーマンス発揮できると言ってるけど、繰り返していると同じところ回っている感覚はないの?」
    • 福田「これってどっかから声がといってるけど、結構なスパンなので、そんなにこないのでは?」
      • 山本「業務が落ち着いて情報を見ていると、『どう?』と言われたり、コミュニティ活動している中で『手伝って』とか。『飲みに行かない?』とか言われる」

湯本「テストの仕事をもっと価値の高いものにしたい」

  • 自分で何を書いたか確認します。
  • ソフトハウスに転職して、7,8年ぐらい立つと、気に入らないこととして、市場に出た後のバグでテストのせいにされた。
  • 「なんでもテストのせいにするのは良くない」といったら、上司の人が呼び出された。
  • 同時期にTEFで面白く思えた。
  • 清水さんの話を聞いて良いなと思った。テストコンサルの求人にひかれて。
  • あ、価値の高いものにしたいと話が変わっちゃった。
    • 山本「価値が上がった?」
      • 吉澤「湯本さんの給料が?」
      • 上がった。給料とかで愚痴っていたら誘われて次の会社に。
    • 安達「テストの仕事の価値って?」
      • 誰でもではなく、技術力のある人でないとできない仕事に。
    • 安達「上司にテストの価値をどのように伝えるか?」
      • バグが出る・出ないの段階だと難しいが、そもそもテストで何を見つけるかを予め定めておこう。なんでもテストで防ごうとすると、いっぱいチェック項目が増えて収拾がつかなくなる
        • ここで時間切れベルが鳴らされる

番長「ニーズがあるところに」

  • ベンチャーにいると、起業する人が多い。
  • そういう元同僚が企業に成功するとQAが必要になるので。
  • そこをコバンザメのようについていく。

柿崎「スタープレイヤーの仲間入りしたい」

  • mixiからサイバードに転職した時にこの考えを持った
  • mixiの社員は、mixi以外の現場でも活躍する人がいる。そういう人はだいたいエンジニアとかインフラとか。それをQAエンジニアとして成し遂げたい。モデルケースになれれば良いと思う。
  • ソフトウェアテスト業界も恩返ししたい
    • 番長「僕が追い出したわけじゃないよ」
    • KEN「2人は入れ違いでmixiに入ってます」
  • KEN「誤解を招かないように説明しておくと、このセッションは転職を煽るわけではない」

これまで転職して新しい会社に言って、一番驚いたことは何か?

大西「給湯室でおでんを似ているおばさんがいた」

  • 転職の面接時にそうめんゆがいてた
  • そこに入社したら、同じ人がおでんを煮ていた
  • ベンチャー会社だとトイレ当番とかあった

番長「テストチームの立ち上げからやることになった」

  • チームを作っていけばいいやと思ったら、「来週、デグレッシェンドテストやって」と言われたぐらい、テスト文化が無かった。
    • KEN「最初、そういう状況を聞いてた?」
      • 認識はしてなかった。
    • KEN「そこからテストって大事だねと思わせるのにどれくらいかかった?」
      • 1年半ぐらいかかった。ひたむきに、努力した。バグがないと思っているところに指摘した
    • 「番長がいないとダメ?って思われなかった?」
      • 部屋が暑くなるので、
    • KEN「同じように、先陣を切ってテスト文化を育てた人は?」
      • そこそこ出来ていたが、そこからさらに一段上げることはした。フルで立ち上げるときは、JCOMのインターネット部門のときは、テスト部門の外国人の人が退職することになって、社内で1年半ぐらいテストの営業活動をやり続けた
    • 安達「その過程で一番苦労したところは?」
      • やる気のあるメンバーに「テストって楽しいよね?」という話を伝えた。あとは、実際にやる対象について話して、リスクベースドの話をして、具体的にツッコミを入れた。
    • 安達「味方をどんどん増やしていくのは良いね」

湯本「結局みんな似たようなことで悩んでいる」

  • KEN「隣の芝生は青い状態ということだったのでしょうか?」
  • 長野県では出来なくて東京だったらなんとかなるだろうと思っていたが、どこも同じだった。
    • 福田「驚いたけど、慣れるものか?自分も福岡から来ているので、東京って進んでいるというイメージがあるが。」
      • すごいなと思う会社もあるけど。え?東京だといいこと?無いよね。いいこととしては、自分が技術力を磨けばどこでも通用する。

吉澤「同じ言葉が違う意味で使われている」

  • ソフトウェアグループからハードウェアグループに社内移動したが、言葉が違った。
    • 例えば、リターンキーの解釈が違っていた。DOSではないオペレーティングシステムに慣れていた同僚は、リターンキーは確定だけで送信は行わないと思っていた。まずはズレがあるのがどこかを確認する
    • 湯本「転職しなくても、大規模なプロジェクトだとそれぞれの会社で作っていると、統合テストの段階でズレがあったりする」
    • 山本「子会社の単体・結合・総合、親会社の単体・結合・統合があって、何回統合やるんだよ?と思ったことがあった」

転職後に「あー、転職しなきゃよかった、マズった」と思うことがあった?

湯本「誘った2人がいなくなった」

  • ある会社に入社したときの話。その会社の社員2人に「製品を日本で売れるようにしてほしい」と説得されて転職したら、入社した後に色々あってその2人は退職しちゃった。けど、そこからポジティブになって楽しくやっている。
    • 安達「立ち直るのは大変だったのでは?」
      • 大変でした。ただ、社内転職で別の人に誘われて社内転職できた。(その人も辞めちゃったけど)
      • 結果的に色々と携わって社長賞も取った
        • 安達「社長賞の写真は湯本さんがかっこいい格好して飾られてる」
        • 福田「今日の格好は…w」
    • 安達「人で苦労しているけど、技術で打開してきた?」
      • 良い人との出会いがあった
    • 大西「今会場に来ている同僚は良い人ということ?」
      • そうですよ

なぜ同じ職種(テスト/QA)に転職するのか?

大西「定め」

  • なりゆきって書こうとしたら言われそうだったので定めとかいた。
  • 転職時には、これまでやってきたことを続けると給料が下がらないから。
  • yasuharu_nに誘われたり、会社の社長と喧嘩したり…
  • コミュニティに入っていたので、仲間が出来る
  • 結果的に他の職種に就いたことは無かったが、Vモデルの右側が出来るから左側もやってみたりもした
    • 福田「左側にずっといようとは思わなかった?」
      • 「とある会社で売ったら、上手く売れなくて事業を畳まれたので、左側を続けなかった」
  • 要求仕様書を書いている立場のときには、QAの人が指摘したときに、あなたが合っているよと言えた

山本「面白いし、求められているから」

  • 狭く深くも見れるし、広く浅くも見れるので、また相談されることが多くなるので色々出来る
    • 安達「思わぬ収穫になった技術とかはあった?」
      • BTSがあまりなかったときに、BI系のことをやりつつ会計系を学んだ経験が、プロジェクトマネジメントで役立った

番長「学びが付きないから」

  • WEBの領域にいるので、色々な製品・サービスが出来て、ごちゃごちゃ戦っているうちに、色々とタメになっていっているので。

吉澤「入社して間もなく、テストで身を立てると宣言した」

  • テストでやるぞ!といった手前、気になったことをどんどん勉強した。
  • 2回の育休の間にガラッと変わっていく。OSが変わったり。
  • テストを学んでいると、沢山の人に頼られるし
  • 開発よりも応用しやすい。
  • 周りにちゃんといって、自分もやっていく
    • 福田「そういうポジションはいないからやっていたと思うのですが、産休の間、会社は同対応した?」
      • 1回目は後輩に押し付けた。2回目はちょうどプロジェクトの境目だった。マネージャになってからは、フルタイムでない人ばかりのチームになったので、2人体制にした
    • 福田「会社がそういう方針にした?」
      • 私がそういう体制にした

柿崎「理由なんかない」

  • 転職エージェントや面接相手の会社に聞かれたが、「この仕事を愛しているから」と答えている。
  • 自分はテスト好きなので、本当はテストし続けてバグ表を書き続けたいが、マネジメントをやらせてもらうことが多い。
    • 安達「今は?」
      • 今もマネジメントですね
    • 安達「つまらない?」
      • つまらなくはないけど、ウズウズはする。ただし、マネージャの仕事をしないといけない
    • KEN「好きって言ってないとやってられない仕事ですよね?」
      • 一同「えっ?」
    • 湯本「私の場合、転職したいもう一つの動機は、係長とかで部下を持ちたくなかった。一緒に仕事してないのに評価する役職になりたくなかった」
      • 山本「テストをやっている人を正しく評価できる人はテストのマネージャでは?」
        • 湯本「わかった。やるよ」

学生「新卒・転職(一般)はつまらなそう。転職芸人は楽しそう」

柿崎「いろんな会社、人、志向、課題をディスカッションしてみるだけでも楽しい」

  • 何らかの課題を解決したいから転職している。転職先の悩みを聞くだけでも楽しい。どういう風に解決しているか想像できるので。どういう悩みがあると調査できると、それってただの面接ではなく、課題を共有・ディスカッションできるから。
    • 湯本「新卒だとそういうことを言えないのでは?」
      • だから新卒の面接官はクソ
    • 安達「私、面接官をやってるんですが」
      • 本当は悩みを打ち明けた方が良い。圧迫面接とかやっているから日本はダメになる
    • KEN「採用の立場に立っている人がいると思うが、どんな場所を重視している?」
      • 番長「ストレス耐性のない人が好き。自分の好きな人を見つけてとことんやる人が欲しい。テストを募集しているのに、「企画もやりたい」と言ってる人はパフォーマンスを出せない」
    • 福田「短時間の面接でどれくらい出せば良い?」
      • 番長「私の場合はどれくらい打ち解けるのかを基準にしている」
    • 福田「採用する方も楽しんでいる感じ?」
      • 番長「そうです」
    • KEN「他には?」
      • 湯本「圧迫面接してないよね?」
        • 柿崎「私が採用時にやったような相談を、面接官の立場になってもやってる。こっちから投げた相談に対して、熱く語れる人が来て欲しい人。もう一つ基準にしているのが、(やばいな、テクニックで取られる…)過去にやった工夫とかを喋っているときに、感情が乗っているかどうかを観る。他の人のをパクった話は感情が乗らないことが多い。心情を吐露することで、暑いディスカッションが出来る。」

転職を薦めない場合はどんなときか?

柿崎「嫌な環境だから転職するとか、有名な所入って箔をつけてやろうとか」

  • 体調に悪影響を起こしている場合はすぐに転職した方が良いです。転職によって課題を解決したいという場合は転職したほうが良い。

転職に関わらず、技術者として意識しておくことは何か?

吉澤「好奇心、向上心、あと人脈を少しでも広げておくと役立つかも」

  • 知らないことはとにかく調べる、聞く
  • セミナーを進められても、「お金もらえなかったら行きません」とは言わないで、自己投資する
  • 人脈を社内・社外で作っていく。転職にも役立つかもしれないし、悩みも解決できるかもしれない

    • 福田「これって難易度が高いのでは?パワー使うと思うが。そういう人にはどうすれば良い?」
      • 無茶してます。それでもやってみることが大事。出ていっても、出続けるのも人次第。ゼロベースで考えると色々と気が楽になる
    • 山本「レポート、稟議…の大変さとか、偏見とかがあるかも」
      • 稟議は書いてあげます。上の方はそれを誘導してあげる
  • KEN「これ、なかなかイベント参加の報告書に書きづらい内容が多いですよね。publickeyさんも手を止めて諦めてる所があったりする」

大西「技術を磨いて、不得意領域の人的ネットワークを構築する」

  • 世界の最前線を知るためには英語が必要だけど、ICSTなどの機会を用いて欲しい。
  • この辺の年になると、自分の苦手な場所を分かっている。しかし、それは恥と思わず、自分の苦手な場所を助けてくれる人を作る
    • 湯本「その代わり、自分の得意なところを作ったほうが良い」

柿崎「スキルや得意なこと、それがビジネス上の価値にどう結びつくかを記録、整理する」

  • 日々のTODO一つ一つをどのようにやってのかを記録する。それをビジネス上の価値を生み出したかを記載しておくと良い。
    • 安達「どこ言っても通用するよとすれば良いよいうこと」
      • いつ転職しても良いように
  • KEN「転職だけでなく、新しいサービスを行うときにも重要になる」

湯本「自分はどうしたいのか?を考えるようにしましょう」

  • 技術者として極められない環境になったら転職を考え始めれば良い
  • やりたいことがやれないときには…(ED音が鳴り始める)

まとめ

  • 福田「皆さん、探究心のある人達だなと分かりました」
  • 安達「自分の好きなことをやって、過ごしている人だと分かりました」
  • 山本「転職芸人ブラックの番長です。人生の棚卸しに転職が良い機会だった。」
  • 柿崎「光のジョブホッパーの柿崎です。あまり話す機会をもらえないと思っていたが、いっぱい喋れて良かったです。私はあまり先のことを事を考えないタイプ。やっていった後にできるだけ。課題が無くなったら取りに行くことも大事。」
  • 番長「コバンザメ芸人の番長です。STAFF募集中です。」
  • 吉澤「社内転職エージェントの吉澤です。テスト設計コンテストもあります。3/13〜ICSTがあります。どちらもチラシが入っています」
  • 大西「よーくかんがえーよー♪おかねもだいじだよー♪ということで、バランスも考えて。」
  • 湯本「このセッションは山本と私でJaSST九州の飲みの場で決まった。技術を磨くには勉強だけでなく実戦も必要。それが出来ないなら会社を変われ。」
  • KEN「どう考えてもネタセッションにお集まりいただきありがとうございます。アンケートで好印象があれば来年もやれるかもしれません。」

楽天トラベルの開発プロセスに関して #JaSST '17 Tokyo

勉強会 技術 JaSST

自己紹介

楽天トラベルについて

  • 国内外の旅行を扱っている

開発体制・案件について

  • トラベル事業は楽天の中でもトップの方を位置する規模
  • セールス、マーケティング、開発が同じフロアで行っている。
  • 開発はさらに3つに分かれている
    • PDM
      • 未来を考える人
      • 30人程度
    • 開発
      • 100人程度
    • QA
      • 30人程度
  • 基本的には全て内製

  • 2016年の新規の開発案件が209件。

  • BugFixなどのPDM以外の案件はQAが関与していない

案件の内容比率

  • 2016年の各サービスごとの改善割合。
  • 国内宿泊サービスのBugFixが8割強
  • 改修のプライオリティを5段階に分けている。毎回のプロジェクトで行っている。

QAのプロセス改善について

以前のフロー

  • ウォーターフローに近いかたち
  • PDMの人はアイデア、議論、起票、レビュー、要件定義
  • 開発の人は要件定義レビュー、開発設計、テスト設計、開発・テスト、リリース

以前の問題

  • 旧システムvs新システム
    • 開発スピードについていけない
    • ケースが漏れる
  • プロセスの改善を行った。

現在のフロー

  • 現在は、要件定義、開発設計、テスト設計(シナリオの概要を書かせる)、ケース設計、手動テスト、本番確認

今後の展望

  • 今後は開発と同じ速度でテスト設計を始められるようにする。
  • 要件定義の段階からQAが入るようにする。テスタビリティの観点からレビューに参加する。
  • 開発の設計が始まった段階でテスト設計も行うようにする。

    • 開発の設計では漏れている観点をデベロッパーにフィードバックできるようになった。
    • 開発とQAの意思疎通がうまくいくようになった。
  • 今後は、テストケースをもっとプラグラマチックなケースで書かせて、すぐに自動化できるように行う。

    • 設計にはコストがかかるが、実施コストは下がるので、トータルコストも下がる。
    • 次回以降はデベロッパーに配ることで、デグレードを抑えることができる
  • QAの責任範囲は広がっていった。

まとめ

  • QAはリリース後の全てのバグに権限を持っている
  • QAの実施可否
    • 作ったツールのパス率、ITの結果、UTの結果から判断する。
  • 本番リリース可否

    • 全ての案件において、リリースできるかどうかの決定ができる。
      • 営業がリリースの要望を持っていても、拒否することが出来る。
      • バグが残っている状態で出荷することもある
  • PDM、開発、QAの三権分立を行っており、パワーバランスを保っている。