いもろぐ

思い立ったら書いていくスタイルで

テスト関連イベントの雰囲気と、TestingCasualTalks#2の感想

5/14に第6回Ques、5/25にTestingCasualTalks#2 と、近い日程でテストイベントがありました。

Quesでは一般参加者として、TestingCasualTalksではスピーカーとして参加したのですが、これらのテスト関連イベントについて思ったこと、感じたことを書いてみます。

前提として、私自身がソフトウェアのQAなのですが、今のところ非開発者なのでお仕事ではコードは書かないです。(書けないんじゃないよ!ちょっとだけ書けるよ!) そんな私が参加するイベントはJaSSTとかWACATEとかです。過去に自分で「Webなテストの勉強会」(タイトルはうろ覚えw)と題して20~30人くらいの勉強会+懇親会を企画したことがあります。第5回Quesではスピーカーとして参加させてもらいました。(その時の資料はこちら) これらの会の空気感はとてもよく似ていて、テストの勉強会ってこんな感じなのねー、って思ってました。(よく考えたら関わってる人たちに共通の知人が多いのであたり前か)

で、今回のTestingCasualTalks#2ですが。 120人(?)くらいの参加者の100人くらいが開発者というね。私の気持ちとしては完全なアウェー感でしたねw 第5回Quesの時はQA、開発者、その他、が1/3でして、そんな体で資料とかトーク内容考えてたので「あれ、これわ...」って思いました。 話をしている最中の会場の暖かい笑い(?)はとてもありがたく、懇親会の雰囲気とかでうまいこと馴染めたかな?って思いました。

今回は3人のスピーカーが登壇したのですが、私以外の人の話は「コードでのテスト」の話がメインで、会場の食いつきもそちらのほうが強かったような気がしました。さすが開発の皆さん、自然言語よりも形式言語で語ってくれってことですよね!<違うと思う



@hsbtさんのmrubyの話は、次が私の発表だったのでドキドキしててちゃんと聞けませんでしたごめんなさいw

www.slideshare.net



2番手として私の発表。ポイントは手書きプレゼンに挑戦 <そこ?

www.slideshare.net



@deme0607さんのブラウザテスト自動化・並列化の話

speakerdeck.com

これは自分の発表が終わって気持ちが解放されていたのと、ちょうどSeleniumWebDriverでのブラウザテストはやったことがある(これからまたやる)のでとても興味深く聞けました。とはいえ、私の場合はまだ「大規模化」とまではいけてないので、技術的な解決方法よりも「ブラウザテスト自動化のメリット(の説明の仕方)」とか参考になりました。

その後のLTではWebサービスに使えそうなテストツールを教えてもらいました。

  • 負荷テストツール
    • Gatling:名前からしてこれでもかと負荷を与えてくれそうな。
  • セキュリティテストツール

ちょっと調べてみよう。

発表スライドにも書いたのですが、ガイアックスでは「技術を使ったQA」というテーマで新たな活動を開始しようとしています。そもそも私が技術わかってんの?て感じなので頑張ります。そして一緒にやってくれる人募集してます。いやほんとに。



最後に、QuesとTestingCasualTalksの大きな違いを書いておこうと思います。これはとても大事なことです。

Quesの方がTestingCasualTalksに比べて女性参加者が多い

@ikasam_aさん!TestingCasualTalksも盛り上げていきましょう!私にできることがあれば是非お手伝いさせてください!(女性集客のどこに貢献できるかわかりませんがw)




Ques#6 感想とメモ

2015/5/14 に行われたQues#6のメモ。

永田さんの話に勇気づけられた会でした。

あと、懇親会で知ってる人がだんだん増えてきてそこで近況報告とかするのが楽しくなってきたのでこの輪を大事にしたい。だけど懇親会の時間だけじゃ話足りないのよね。懇親会だけを目的としたイベントとかあればいいのに。(やればいいのか。ただの飲み会だけど)

感想、思ったことを先に

  • スクラム開発について

    • もともと開発チームのベロシティ(スプリント内にいくつのストーリーポイントを消化できるか)は一定(実際は慣れていくと上がるけど)として進めるはずなので、スクラム開発していながら「終わらないから残業とか土日でやるわ」っていうのは違う気がする。
    • その場合は納期を遅らせるか、スコープを減らすか、の対応がスクラム的には正解なんじゃないかな。
    • できるところまでしかできません、が基本。
    • 大前提として「自分のプロジェクトであり、成功させることが自分のミッションである」と感じているメンバーが集まっていること。
    • そうじゃないと「できるところまでしかやりたくありません」っていう「逃げ」になって不毛。
  • スプリント内に終わらない話

    • スプリント内にテストが終わらない、あるいはテストは終わってもそこで見つかったバグ修正が終わらない、とか。
    • 本来は「○○のバグを修正する」という作業もストーリーとしてチケット化され、ストーリーポイント(作業にかかる工数というか相対的な値)を割り振るのがセオリー。
    • だけどスプリントでのベロシティは変わらないはずなので、ここでもスコープ(か納期)の調整が発生する。
    • これを吸収するには「バグ修正」のタスクを予め想定しておくこと、かな。
  • そもそもスクラムのチームって一つのチームなのでは?

    • 役割が違うだけで、チームとしてやるべき作業は洗い出されているはず。
    • 企画・設計・開発が作ったものをQAがテストする、という仕組みじゃない。
    • 企画・設計・開発・QA(必要ならその他の役割も)で一つのチーム、という思想。
    • だけどこれまでの経緯から「作ったものをテストする」タイプの関わり方をしていた組織にとって、開発チームの中に入っていって何ができるのか、は課題。うちの会社でも課題。
    • でもそこで確立できたら楽しそう。
  • スクラムに必要なドキュメント

    • 何でもドキュメント化するんじゃなくて、チームの暗黙知が高まると、そのチーム内のコミュニケーションは高速になるよ、というのはわかる。
    • そうしそうしたいけど、そこに後から入ってくる人とか、引き継ぐ人がいる。
    • あるいは将来の自分が見た時に「これなんだっけ?」になりそうなジレンマはある。
    • 「必要最低限のドキュメント」として何がアレばいいのか、はその時々だけど、その時々で定義できるのかな自分は。

セッションのメモ

ソニーの永田さんの話を聞いたメモ。(最初のKDDI鈴木さんのセッションには到着が間に合いませんでした)

品質をよくできなければアジャイル開発は成功しない

テストベースどうするのか?

  • ドキュメントが書かれない。
    • それがないとテスト出来ない・・・うまく関係が持てない
    • まずここが障壁になりそう
  • なぜドキュメント化しないか?(QAから見て欲しい情報)
    • 企画、開発は暗黙知を持っていて、それで意思疎通している。
  • 設計をするためにアーキテクチャプロトコルはドキュメント化している
    • そのドキュメントと暗黙知をミックスして開発している。
  • その中にQAが入って欲しい情報をとってくる。
    • ユーザーストーリーで要求と仕様を表現できるか?
    • 彼らの暗黙知の中に入っていく
    • ドメイン知識は知らなければダメだし、(そのチームの)ポリシーみたいのを感じる?のが大事

設計開発へのフィードバック

  • (テストをして)何をフィードバックするのか、を説明する
    • そのためにどんな情報、成果物が必要か
    • その中で信頼関係が生まれる
  • 設計者にテストケースをレビューしてもらう
    • 設計にテストを組み込んじゃう
    • 設計しているときにシステムテストをやるイメージ
  • ツールから取れる情報を見える化する
    • メトリクスとかKPIに対する現状とか
    • バーンダウンじゃなくてバーンアップチャート
    • ストーリーポイントが増えていることがわかる
  • ベロシティは経験値。改善していくことで上がっていく。
    • 劇的には変わらない
    • 手戻り(バグ)を減らす
    • コミュニケーションロスを減らす
    • 待ち時間を減らす
  • 現状の把握(メトリクスとか、事実を見て)
    • それに対してどうするかを計画する、何をするのかを都度決める
    • (今起こってる、すぐ改善すべきところはどこなのか)

3分悩んだら聞け

  • 困ったら聞けばいい→ドキュメント減らせる→暗黙知高まる

QAが(開発プロセスも含めて)改善する

  • おしまいのフェーズに入ってくるのではなく
  • 朝会も振りかえりもQAが入っていて改善していく
  • 施策の効果がメトリクスに現れる
  • 例えばバグ傾向のフィードバックとか

ウォーターフローでは情報を待ってた

  • アジャイルイテレーションごとにメトリクスがわかる
  • それを改善するところに入っていく、むしろ仕切る
  • アジャイル開発を正しく理解することが必要だけど。
  • やってることはシステムテストレベル。マニュアルテスト。
  • それをやるためのテストベースを「取りに行く」

トークライブ

鈴木さんと永田さんのトークライブ。MCは@snskさんでした。

アジャイルチームに歓迎されるテスターのスキル・人物像

  • 鈴木さん
    • コミュニケーションに苦痛を感じないこと
    • 暗黙知やフィジカルなコミュニケーションがMUST
  • 永田さん

    • 年齢とか関係ない。
    • 得意なところ、何を提供できるかを「表現できる」と信頼される
  • 永田さん

    • アジャイルは設計も開発もシロウトじゃできない
    • リアルタイムで改善していきながら、設計も実装もする。CMMIではレベル5
    • やる気。面白いなこれ、やってやろうって思える人。
  • 鈴木
    • スーパーヒーローはいらない
    • どこにでもいる人でやっていける
    • マインドセットが大事。

最低限必要なアジャイルチームのドキュメンテーション

ユーザーストーリーのテンプレはある。ただHOWが書かれていないのでテスト設計ができない。どんなドキュメントが必要になるのか。

  • 永田さん
    • エラー処理を全ては(ドキュメントに)書くわけじゃない
    • が、だいたいパターンが決まってる。(ウィンドウのどこにエラーがでる、的な)
    • そこは書こうよ、という決めにした。
  • 鈴木さん
    • 製品によって違うけど、うちの場合は画面設計書は必須。
    • ユースケースマップを作っている
    • 誰が目的で使うか、かな。
    • (そのドキュメントは)主に設計開発の人がつかう。QAの人もみる。
  • 永田さん
    • 結局はチームで決めること。
    • 今までQAが入っていないなら、これから入っていって「何がアレば自分たちは何ができるのか」を言っていく(成果を出す)ことでチームに信頼してもらう

...以上です。 今回も楽しい会でした。 運営の方、ありがとうございました。


ansibleやってるよ、ほんとに。

ansibleでサーバ環境の構築を自動化しているのですが、なんというか、今さらですが人がやることを自動化していくっていかにも技術ー!って感じでステキ。

ただ、いかんせん私の理解が遅いのと、技術情報の調べ方に慣れていないのでなかなか進まないこと。(でも楽しい)

調べたことがあったのでQiitaに書いてみました。

qiita.com

ansibleやってみてる

久々の更新。そして久々の技術の話。(他の人には役に立たないただの日記)

新人研修として、実際にテストを体験してもらうというアクティビティをやる予定です。 テスト対象は私が作った全然いけていないイベント掲示板アプリ。 自分の勉強も兼ねてRailsで書いてみました。

じつは去年も同じことをやったので、その時のソースコード持ってきて環境だけ作る、みたいなことなのですが、去年は環境構築の部分をまるっと他の人にお願いしちゃいました。

今年はせっかく(?)なので自分でやってみようと。

新人3人分の環境を、Dockerのコンテナ(これは自動で作ってくれる社内サービスを利用)にansibleで構築し、ServerSpecで確認する、みたいなの。

今はansibleで格闘しているのですが、ansibleの書き方以前にわかってないことが多すぎ。 Linuxのこととか、ssh接続とか鍵認証とか、bitbucketからcloneするとか、、、

もちょっと理解のスピードを上げていかないとならない、と焦るものの、焦ってもすぐに理解できる頭ではないので、まぁ少しずつでも前に進もうと思いましたとさ。

JaSST'15 Tokyo クロージングパネル「テストエンジニアとデベロッパーとの幸せな関係」

JaSST'15 Tokyo のクロージングパネルを聞いていた時のメモが出てきたので記しておきます。テーマは「テストエンジニアとデベロッパーとの幸せな関係」でした。

このパネルを聞いて「開発とQAは対立するものじゃなく、一緒になっていいものを世の中に出そうぜ」っていうチームなんだよね、って改めて考えました。そのための共通言語としてコードで話ができたらカッコイイよね。

...もっとちゃんとしたまとめがこちらに公開されてたのを今気づいたデス。

※(さ)は私の感想です。★は私がいいなーと思ったところです。

チェンジビジョン 平鍋さん

  • アジャイルのワークショップをテスターがやっていた。@アメリカ
  • キャンディの話
    • 開発者がテスターに聞きに来た時にキャンディをあげる
    • 距離を近くする
    • 人と人の距離を近くすることがアジャイルの本質
  • 上着のジッパーの話。開発とQAを理解の食い違いを早い段階でなくしていく
  • テスト側、開発側、と別れない方がいい
  • (さ)アジャイルとテスト、が近づいている?

ACCESS 松木さん

  • これまで
    • スティングは品質保証の主要な一部
    • バグレポート中心の(devとの)コミュニケーション
  • これから
    • 開発チームの生産性を向上させる役割
    • これまでのQAはなくならない、広がるイメージ
    • 効果的なテスト自動化
    • (さ)自動化じゃなくてもいいから「技術でテストできる」といいのでは?テストコードだけじゃなく。
    • テスト実行環境を簡単に増やせる技術
    • 非機能要件には高いスキルが必要
    • コードが書かれてからお客さんに届くまでを早くすることにテストエンジニアがかかわる★
    • (さ)具体的には?DevQUTのこと?
  • DevQUT
    • Communicatization(造語)
    • 仲良くする、コストが下がる
    • 開発と普段から話をする → 自信があるところないところとか優先度
    • ユーザーと近くなる→ユーザーコミュニティとか製品についているフィードバックシステムをツールとして使って、開発に届ける
    • (さ)ユーザーヒアリングとかにQAが関わるとかかな?

サイバーコネクトツー 八田さん

  • ゲーム業界から見ると難しい話
  • 品質保証の違う点は「バグがないこと」と「面白いこと」を求められる
  • ゲームの仕様を決めるmtgに積極参加
    • 仕様を早く把握することをチェック内容を予測できる
  • 過去のバグ経験を元にして、実装チェックリストを開発者と共有

    • 開発者に依存することなく過去バグを未然に防げる
  • Q:テスト技術の進化によってDevとQAの関係が変わってきてるのでは?と思っていたが、技術よりも距離を近くする、ということ?

  • A:ゲーム業界も新たなハードが出たりして大きな変化はある。その中で求められるのはいかにDevとコミュニケーションとるか。不具合を出さないようにするか。がメイン。
    • 新しい技術を完璧にデバッグするのは難しい
    • Devが持っている情報をもらう
  • 平鍋さん
    • QAが仕様に入って一緒に決める、というのはゲームのほうが進んでる
    • ビジネスの構造が違うのかもしれない
    • QAの発注の仕方とかどう?
  • 八田さん
    • 人月で頼む。デバッグ会社に開発後期に頼む
    • 社内にQAを置くことで早くから関わる。その後に外注と提携
    • プロジェクタにデバッガをアルバイトで雇って、終わったら解散、が最初
    • その後に社内にQAを作ろう
    • ノウハウをためて開発者から頼られるようになった
  • 野中さん
    • 技術面でこうやったらもっと距離が縮まるよ、とか
  • 松木さん
    • 上流におけるQAの取り組みとしては、開発者とコミュニケーション取りながら、はそれがいい
    • 下流では、ターンアラウンドタイム(バグが埋め込まれてから、発見されて、報告されるまでの時間)をどれだけ短くできるか。
    • (さ)この考えを広めて社内でも具体化したい。実装直後にテストが書かれてるとか
    • コード書いてその場のレビューで言われたらすぐ直せる
    • 実装後3週間立って言われても遅い
    • そのためには
      • 機能テストを自動化すると大変。メンテが。
      • ユースケーステスト、シナリオテストのような、「ユーザーはこうするよね」だけで自動テスト書く+CI
    • QAと開発者が距離を置いちゃうは品質を神格化しているから
      • 品質はよくわからないので怖がる。尊敬してる
      • それをわかったようなQAを司祭として扱う
      • もっと近いものにする
      • 品質特性の中から何が大事かを、定量化に早く返せるようなツールを仕組みを作ってる★
      • (さ)なにそれ?
  • 平鍋さん
    • 出荷判定会議が怖かった
    • 有無をいわさず最高品質を届ける、という宿命
  • Boltonさん
    • 開発とQAの距離を縮める、について
      • お互いの尊敬はキャンディではなく、お礼の気持で成り立っている★
      • 大事なことがあって、技能を持って正確に伝えることができれば、devから聞きに来てくれる
    • 品質を定量的に表現することに抵抗がある
      • 何故かと言うと、数字を体現するものであって、数字そのものが何かを意味するものではない
      • 厳しい会話を回避するための方法では?
    • 難しい話し合いでもうまく対応する方法がある
    • 自分自身のことを表現することは勇気がいる、勇気があると前に進める
    • ターンアラウンドタイムを短くすることに関しては誰もが質問する
      • PGをコードを生成することに責任を持つ?それともうまく動くコードをに責任を持つ?
      • PGが機能するコードを書くことを責務とするならTRTIMEは長くなる
    • フレデリックいわく2006@インド
      • 完璧なコードをPGが生成することを期待はされていない
      • こういう動きを確認しました、を言えることを期待されている
    • テストとチェックの違いを分けて考える
      • PGは書いたらすぐにチェックをする。
      • PGに対してこうしろあぁしろというのは違う
    • 言葉としてQAを使うのは嫌い
      • 製品の質を高くすることは、プロジェクト全員の役割だから
      • testerとしてはコードもスケジュールも予算もスコープも出荷日も出荷判定もコントロールできない
      • このなかで、品質を確約することはできるのか?
    • これらの権限をもっているのはデベロッパーやマネージャ
      • 本当はこれらが「QA」
      • testerとしては彼らに今の状態がどうなのかをわかるようにする★
    • そのためには
      • ソフトウェアは人々のrelationshipsでできている
        • PGとQAを物理的にも近くする
        • フロアレイアウトを変えてでもそうする
        • コミュニケーションの一部がコード
      • プロジェクトは常に時間との開発
        • これまでに作ったことのないものにチャレンジしている→不確定
        • 時間との戦い、ミスも起こる。自然なこと
        • 短い時間で何かを学ぶ必要がある
        • だれも実現してないことをやろうとする
  • 八田さん
    • ゲームを早くリリースする
    • ...早くはならない。発売日が決まっているからそこに向けて面白い要素を詰め込むか
    • 課題は「いかに短期間でデバッグするか」
    • プランナーは12月発売だけど11月ではもっと詰め込もうとする
    • 完全にできたときにモニタリングしても間に合わない
    • 出来る限り早期からモニタを行っている
      • 細かいところまで気にしている
      • 開発に関わっている人以外にプレイしてもらう。感想(アンケート)を書いてもらう
      • QAだとすでに触っているので、それ以外の人にやってもらう
  • 平鍋さん
    • QAがどのユーザーを巻き込むか、をアジャイルに取り込んでいるのは聞いたことがない
    • 伝統的なQAは欠陥がないかをみる。
    • ゲームが「面白いか」をQAが見るのは品質の定義が広がっている感じ。(すごい、という意味で)
  • Boltonさん
    • 使うことが「楽しいかどうか」を質問するのはいいこと
    • ユーザーに「感情面」を聞くのは重要★
    • 使いやすいかとかだけじゃなく
    • 目的を達成できているか、とか
    • (さ)そうなるとフロントエンドの動きとか、表現が大事って気がする。「体験」をどこから感じるか。。。
    • 実装する人とテストする人はマインドセットが違う
    • 作った人とは別の人が外の視点からみること
  • 八田さん
    • (QAをおいてうまくいった話だが、QAチームがなかったらどうなったか)
    • その分PGを増やすことになったと思うが、テストをすることに手は回らないと思う
  • 平鍋さん
    • (DevとQAを分けるかどうか)
    • プロジェクトの内容、規模によってウォーターフローもagileもやっている
    • アジャイルでやってるチームにはQAはいない
    • ユーザーサポートは2人いる
    • そこから顧客から見える製品のあり方を話している
  • Boltonさん
  • 松木さん
    • (テストを別組織にするべきかどうか、その場合何をするか)
    • テストをする人は開発者の中
    • テストのマインドをもった開発者
    • チームが目指したい形と、そのチームを包含する組織(会社)の目指したい形が違うことがある
    • 会社が目指す形にあっているかどうかを確認したい場合は開発からQAを別にしたほうがいい
    • QAとマネジメントの違いはなにか?
      • 組織として表現したいビジョン→マネジメントがもつ
      • QAはそれがそうなっているかをチェックする部隊

テスコン2015に参加したときの話

(また技術の話じゃない、、、最近プログラムできてない、、、ブログ名変えようかな)

テスト設計コンテスト2015に参加した時の話を社内に共有しました。 それを会社のブログに載せてもらいました。

「テスト設計コンテスト2015」 参加レポート

ご覧あれー。


Design Sprintに対する疑問点の解消

前回のエントリDesign Sprint Night! 参加してきた - 非開発者がプログラム技術を使ったQAを目指すブログ の中で「デザインスプリントに対する疑問点」を書いたのですが、なんと馬田さんに質問する機会があり、回答をいただけました!ありがとうございます!

以下、私はこう理解した、を書きます。(あくまで馬田さんとのやりとりの中で得た私の解釈です)

質問1

DSの効果としてBlueBottoleCaffeとかPocketで「こんな成果でました」という話があるが、これは最初からKPIとして設定していたのか、結果としてこうなったのか(なぜならデザインスプリント(以下DS)のプロセスの中で目標値の設定の話が出てこないから)

  • Blue Bottle CoffeeもPocketも「KPI的な(数値としての)目標設定をしたかどうかはわからない。
  • だけど結果の振り返りができる程度での目標設定はやっておくべき。
  • 効果があったのか、なかったのか、どの程度だったのか、はわからないと意味が無いですよねー。
  • ということはやはりDay1での課題設定の時に「何をどうすることがゴールなのか」をちゃんと決めよう、ということに繋がるんだなと思いました。

質問2

「ユーザーストーリー」というのがよく理解できていない。そのシステム、画面を使って、「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」かな?

  • 「ユーザーストーリー」というワードは明確に「これ!」という感じでは使われていないようです。
  • GoogleVenturesのサイトで参考になるURLを教えてもらいました。

  • ↑これを読んだ私の感想としては当初思っていた「ユーザーがある目的を達成するために、どういう手順で、何を操作するか」というよりも「ユーザーに、どういう行動をしてほしいか」のほうがしっくりくるなと思いました。

  • システムの画面遷移だけでなく、「Creating a new product concept」の時や「Improving conversion rate from a landing page」の時にもストーリーを書くようです。
  • つまりモニタの中の話だけじゃなく、こちらの理想とする「ユーザーの行動(電話をかける、とか、旅行に行く、とかも含む)」を絵(図)に書くことなんだと理解しました。

質問3

Day5でユーザーテストするときはプロトタイピングしたもの。それを本実装するのはいつ?Day5で出てきた課題を解決できたかどうかは再度ユーザーテストが必要になると思うのだけど、そこはまぁ自分たち判断でいいのかな。

  • 本実装への移行は自分たち判断になる。
  • そこに関しての正解があるわけではない。
  • ここでも「本番に反映したあとに測定」して効果を判断することが必要(例えばABテストしてみるとか、単純にBefore/Afterで比較するとか)
  • それにはやはり「ゴール」が必要

質問4

前進している感じがある」のと「やった結果が成果につながる」かは別だと思うのだが、成果になっているのかの確認もスプリント内にあるのかな?

  • ここは「成果」を何であると定義するか、による。
  • Day1 の課題設定に対して、Day4 のプロトタイプを用いて Day5 で仮説検証ができたのならそれは成果になる。
  • 一方で「本番実装した後にわかる定量的な改善結果」に関しては(本番実装自体がDS後のものなので)スコープ外と考える。
  • つまりDSの中では数字にとらわれるよりも、いいと思ったことをじゃんじゃんやってみようぜ、ってことかなと思った。

…というのが私の理解です。この辺りを踏まえた上で来週から社内で1スプリントチャレンジしてみます。