システムテスト自動化カンファレンス2015に参加してきました #stac2015

STAC 勉強会 技術

  • ということで、1週間も経ってしまいましたが、感想などを書き残したいと思います。
  • ちなみにカリフラワーも美味しいと思います。

告知ページ

4deb81d081862e256eb240be7c.doorkeeper.jp

まとめページ

togetter.com

パネルディスカッションの部分の書き起こし

nihonbuson.hatenadiary.jp

システムテスト自動化カンファレンス2015の感想記事一覧

  • 私の記事なんかよりも参考になりますよ！

tak-kohei.hatenablog.com

tak-kohei.hatenablog.com

d.hatena.ne.jp

suzaku-tec.hatenadiary.jp

  • 今回登壇していた松尾さんの記事

システム自動化カンファレンス2015で登壇してきましたkazucocoa.wordpress.com

  • 参加レポート＠gihyoの記事

gihyo.jp

  • それにしても、他の（テスト系の）勉強会に比べて参加者数も感想記事も多くて良いイベントだなぁと思いました。

本イベントの内容

  • それぞれのセッションごとに発表スライドの紹介と感想を書いていきます。

開会の挨拶（＆アンケート結果発表）

自動化が上手くいっていない要因は？→「スキル不足」との回答が多数だったことに対し

  • 「案外、やってみたらできるじゃん」と思ってもらえるのではと感じています。
  • やらずに「難しそうだから…」ではなく、やってみた結果、やっぱりスキル不足だと感じた人はどれくらいいるんだろう…？

テスト自動化研究会のスコープについて

  • もちろんテストタイプのスコープが機能テストであるとは思うけど、スライドでも書いてあったように、セキュリティテストとかにも範囲を広げられそうな気がする。
    • 以前、その分野も自動テストでできるという発表があったりしましたしね。

nihonbuson.hatenadiary.jp

テスト自動化のスキルを考えよう！～テスト自動化エンジニアに求められるスキル、期待される役割～

発表スライド

www.slideshare.net

www.slideshare.net

感想

  • 自動テストのスキルって、プログラミング部分よりもステークホルダーとの関係の構築だと思っているんです。
  • 例えば、環境って手動テストよりもシビアな部分なので、インフラ分野の人ともコミュニケーションを取る必要があるはずです。

自動家は見た～自動化の現場の真実～

発表スライド

www.slideshare.net

www.slideshare.net

感想

  • 受託開発の場合は、限られた期間内に納品することを求められるわけで、そうすると自動テストは一番切られやすい分野だからなぁ…

広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと

発表スライド

www.slideshare.net

感想

楽天の品質改善を加速する継続的システムテストパターン

発表スライド

www.slideshare.net

感想

  • メトリクスってすごい大事！
  • メトリクスに限らず、如何に結果を視覚的に訴えられるかというのは非常に大事だと思う
    • 特に、自動テストというのは意識しないと（意識させないと）「何をやってるかよくわからないけど、なんか動いてる」とか思われてしまうからね

キーワード駆動によるシステムテストの自動化について

発表スライド

www.slideshare.net

感想

  • 何でもできるように→カオスなソースコードの始まりですからねぇ…
  • キーワード駆動は特にそうなりがちなのだと思います。

Testing Tools for Mobile App

発表スライド

www.slideshare.net

感想

  • ただただモバイルは大変そうだなぁという印象を受けた発表でした。
  • あと、以前の #cooketn で「何かを変えることはストレス」「年を重ねるほど現状に保守しがち」と言っていた松尾さんが、「デファクトを変える」という方向に向かうためにとった行動が気になりました。（聞けばよかった…）

nihonbuson.hatenadiary.jp

パネルディスカッションLIVE！テスト自動化”エンジニア” の今とこれから

ディスカッションの内容の書き起こし

nihonbuson.hatenadiary.jp

感想

  • 登壇者から「とりあえずやってみろ」という言葉があったように、まだまだ確立した分野ではないからこそ、とりあえずやってみることが大事なのかなと
    • ただし、その後に全体を見たり、一度立ち止まったりしないと、いわゆる「自動化ハイ」状態になってしまうと思いますけどね…

全体の感想

  • 主催して下さったテスト自動化研究会の皆さん、また会場を貸して下さったYahooの皆さん、本当にありがとうございました！
  • 今回の内容はテスト自動化を行っていくうえでのスキルなど、一歩先の段階への部分が多かったと思います。
    • これから自動化を始めようと思っている人にはきちんと伝わっているのか少し不安ではありました。（何か、先行ってる別世界の人扱いされてないか心配…）
  • 自動化することよりも、それに至る経緯とか、継続させるためにはとか、そのような部分も大切なんだよと伝わっていたら良いなと思いました。

パネルディスカッションLIVE！ テスト自動化”エンジニア” の今とこれから （システムテスト自動化カンファレンス2015） #stac2015

勉強会 技術 STAC

モデレータ：

  • 浅黄 友隆（ヒューマンクレスト）
  • 松木 晋祐（ベリサーブ）

登壇者

  • 松尾 和昭（クックパッド）
  • 三浦 一仁（AAAメンバ）
  • 荻野 恒太朗（楽天）
  • 森下 大介（ヤフー株式会社）
  • 小井土 亨（SQiP 運営委員会メンバー,株式会社OSK）

はじめに（浅黄）

  • このパネルディスカッションでは「これから」に焦点を当てる
  • 後半はツイートを拾います
  • 今まで色々なことをやってきたと思います。
  • その上で、今後、挑戦的にやってみたいことを聞いてみたいです。

今後、テスト自動化で、広げたいこと、挑戦したいこと

松尾

  • 挑戦したいことは1つある
  • サーバー込みのサービスが分割されている
  • 大きなサービスが個々のサービスに分割され始めている
  • それに対して、サーバー間での連携が壊れていないか確認するところが見えていない
  • サーバー間やクライアントサーバー間のAPIを変えてもテストの中で気付くようにして、最終的なサービスとしてはAPIが妥当であると確認した上でリリースできるようにしていきたい
  • その先はまだ見えていないです。

三浦

  • みうみうと紹介されるぐらいにみうみうです
  • 今までは量との戦いだった
    • 3000ぐらいのJavaプロジェクトをどうするか
  • Jobをコピー？テンプレ？
  • 今、インフラチームにいます
  • インフラも量との戦い
  • 世の中と比べると2〜4年ぐらい遅れていると思う

荻野

  • 5年ぐらいでやってみたいのはテスト実行以外の自動化
  • 私は元々データ屋さん
  • メトリクス含めて分析することで、テスト設計の一部まで自動化していきたい

森下

  • Unitテストレベルは各人進めていると思う
  • システム間の結合部分
  • 環境の構築部分
  • データセットの投入部分
  • テスト観点
  • 結合ポイントの多さ・少なさに対してどうやって効果的に仕掛けられるのか

小井土

  • 職種的に私はプログラマ
  • 自動化をもっと広めていきたい

松木

  • お互いのを聞いていて「それできるよ？」という人はいますか？

小井土

  • クラスの生成の自動化をしたりはしている
  • やってみないと分からない
  • まずはやってみるのが大事

松尾

  • 自動化とか海外を参考にしても、データの持ち方とかはサービスによって異なっている
  • サービスに依存しているので、ベストプラクティスが一致するわけではない

小井土

  • JRの踏切システムがハードからソフトになった
  • 実際に運用環境でやってみて、うまく行ったら切り替えてみるのも良いかも

松尾

  • 動かしながらというのは正にそうだと思う
  • ソフトウェアも機械仕掛けも腐敗するのはなどの計算式が出せるが、ソフトウェアは計算出来ない
    • まだ人類には早いのかもしれない
  • 元に戻せるというところには力を入れるべき

森下

  • やりにくいテストは本番に近いところでやってみる
  • jjug_cccでも本番のところの方でテストする事例があった
  • まだリリースしてないならば本番環境でやってみる
  • すぐに戻せる状況にする
  • そういうのがあるよねと把握はしている
    • けど手が回っていない
  • データに依存する部分は難しい
  • テスト環境が複数インスタンスあれば、データを入れる場所をどうするかなどを考える必要があり大変
  • またあとテストし終えた後のデータは消すのかどうか？なども考える必要がある

三浦

  • 如何に環境を引っ張り出せるのか
    • コンテナが良いと思うが、まだ安定していない？
      • 信頼性と一般化と事例が増えてきたら…

IoTのことは無視できないと思うが、その方面への工夫は？(会場からの質問)

松尾

  • ソフトウェアなのかハードウェアなのかサービスなのかによって変わってくる
  • Apple Watchなどの自動化は今までとあまり大差が無いと思っている
  • 何かIoT対応でやることは増えるのか？

三浦

  • 3年前ぐらいがIoT元年だと思うが、もっと昔からこの分野の自動化はあった
  • ビジネスアプリは弱くて、それを超えられると思うが
  • 機械をいじれるかどうか
  • 廉価な機械が手に入るようになった
  • 簡易に使えるAPIが増えてきた
  • 1コマンドでJenkinsとも連携ができる
  • これをクラウドでIoTでできるようになるかも(jjug_cccでも発表されている)
  • コンピュータ上で物理演算までできるかも
  • ハードとソフトの垣根がなくなっていくのでは

荻野

  • IoTのことについては何も考えていない
  • Googleのカンファレンスに行った時に、6,7割がIoTの話だった
  • IoTの世界になるとクライアントがいっぱい出てくる
  • 全てのクライアントに対してのクラスを作るべきかというようなディスカッションがあって興味深かった

森下

  • IoTの知見は無いが、自動化の仕事が増えることに対して
    • 仕事が増えることはネガティブなことではない
    • やっていくエンジニアの価値は重要だと思う
  • DevOpsという言葉はあるが、テストはその狭間にあると思っていて、その認知度が低いと思う
    • ここに価値が認められれば新しいことができるかも

小井土

  • 分散型のシステムになると思うので、切り分けの自動化をする必要がある
  • ある程度までの判断を絞るところまで自動化するようにすべき
    • 人では判断に時間がかかる
    • そういった部分の技術が必要になってくるかも

A/Bテストに自分自身で責任をもっているか？(会場からの質問)

森下

  • 業務系システムなので、A/Bテストはあまりやっていない
    • むしろ広告の配信をやっているチームの方がやっている
      • オーディエンスがどう反応するのか
  • ロジックが複雑すぎて予想できない
  • 人の反応まで含めると、自動化ってなんだろう？となる

価値があるのか自体をテストしたいみたいなことはあるか(松木)

荻野

  • Data Driven Testingで発表したが、開発者がぐるぐるテストできる環境を用意したりしている

三浦

  • 世代別プロダクト環境を作っている（過去3世代、1週間ごと）
    • どこまで追ったら壊れるかを調べたりしている
    • 変化を見るためのもの
  • お客さんが、とは違うかも

手動テスト用のテスト設計と自動テスト用のテスト設計の違い。自動テスト側の追加の負担はあるか？

  • システムテストレベル
  • 複数のプロダクトに渡っている
  • 自動化するチームがある
  • 自動化チームとしては自動化できるように書いて欲しい
  • 自分達で頑張ってくださいと言われた
  • 設計チーム側とうまく行っていない
  • 自動テストと垣根が無いと思っていたが、テストデータの前提が暗黙で書かれていたので…
  • 自動テストにする際のいざこざとかはあったのか？

松尾

  • 機械によって再現可能かどうか
  • 人の感じ方とかは手動テスト
  • 自動テスト用のテスト設計は無いと思う
  • 人が触っていたものを自動テストにする場合は、0/1とかでジャッジできるところがあるかどうか
  • モバイルアプリだったら画面遷移はやるが、アニメーションがちらついているかなどのところ
  • OK/NGが判断できるかどうか
  • 何か良いのを出してください

三浦

  • 詳しく聞いてみたけど、応えが…
  • 人が多く絡むものならば、人間たちがわかりやすく引けるかどうかが大事
  • 統治のために
  • 事前条件が置けるかどうか
  • 人間が絡まない場合は、長いシナリオの途中でファジーなアンニュイな判断がある場合は手動に落としている
  • 大人数だとややこしいかも

荻野

  • Opsの人とインフラと話すと感覚的な話が多い
  • 0.2sで違うぞ、バグだ、正常に動いているの判断が難しい
  • 明文化していないところを如何に明文化するか
  • 手動テストと自動テストの得手不得手がある
  • ピンポイントで探すところは手動テストでやるべき

森下

  • システムテスト系はまだまだな分野ですが…
  • 人間系の問題なのか仕組みの問題なのか
  • 別々で考えるべき
  • 自動が得意とするところはどこか

小井土

  • 自動化するかどうかはコストバランスが重要
  • どのくらい繰り返せるかが大事
  • 自動化前提で設計する部分はある
  • 市場に出た時に不具合がインパクトがあるとか
  • システムの大部分は自動化出来ない
  • Checkingの部分をやる
  • テストデータは手動でも自動でも関係なく難しい
  • カバー率とかテストデータに関係なく出ちゃうこともある
  • やれるところ、困っているところからやる

自動テストを行えば行うほど手動テストやレビューの重みが強くなっていくと思うが、役割分担をしたりしているのか

小井土

  • 自動テストをやって今までできていなかったことが見えていくことがある
  • 自動化することで人がもっとやれることが見えてきた

森下

  • 自動テストはSTestレベルだが、寿命が長く繰り返しテストするときに、予期しないテスト失敗で検知できるのは良かった
  • デグレしてないかというテストを手動でやるのは不毛な部分では？
  • レビューに関して言えば、作りが妥当か、仕様を満たしているかなどを見るべきで、住み分け出来ているのでは

荻野

  • バグには3種類ある
    • 仕様にバグがないか
    • ソースコードにバグがないか
    • 設計が妥当かどうか
  • それぞれのタイミングでレビューすれば良いのでは

三浦

  • SIerチックであれば、人格が違うことが多かった（手動と自動で）
    • V治モデルで的な
  • アジャイルの時もフェーズが違かったかも
    • 手動テストはリリースに近かったと思う
    • 時期がずれていた

松尾

  • 開発と同じ実装レベルでレビューが必要なのかと言われれば、必要になると思う
  • 開発の対象が違うだけ
  • 開発者における仕様とかレビューとかはやっていっているので、テストに対しても同じぐらい
  • 最後は…やっぱり言いにくいですね

今やってみる、動かしながらとか出ていますが、一言で一番必要な要素はなんだろうか？

  • エンジニアとしてのアドバイス的なものがあれば
  • 三浦さんは最後で

小井土

  • 「面倒くさいな」自分のやっていることに疑問を持つということが大事

森下

  • 取り組む側は「とりあえずやってみろ」
  • 手を動かしてなんぼ
  • エンジニアはものを動かすのが楽しいよね
  • 楽しみというところに戻る
  • 推進側はテストできないところを潰していく

荻野

  • パッション、スキル、スモールチーム

松尾

  • 「問題を楽しむ」

三浦

  • 「幸せになる」ということです
  • 色々な幸せがあると思うが、関係者が幸せになるように自動化を進めていく

パネルディスカッション全体を通じて

浅黃

  • IoTに知見がありませんと言いつつも、自分の得意な分野に持ってきて解決できる手法を探しているのが印象的だった
  • 自動化は簡単ではないが、パッションや問題を解く、幸せになるということを元に実施していく
  • これから社内に広げていく糧になったと思う

本イベント全体の紹介とか感想とか

nihonbuson.hatenadiary.jp

『クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜』懇親会部分 #cooketn

技術 勉強会 cooketn

はじめに

  • 懇親会中は様々な所で特に決まりもなく話しています。
  • その中で会話に参加した部分のみ載せています。
  • あと、会の終了後に思い出しながら書いているので、自分が参加した中でも結構漏れがあります。
    • 指摘、補足がある方は教えて下さい！

深谷さんとの会話

  • Q．testingをした部分をどのように残していくのか？
  • A．一緒に「この観点があるよね」と言いながら残していく。

感想

  • テストの分析と設計が一緒になっているのかもしれない
    • どうやって後世に残していくのかを考えることが必要かも
      • 文章上だけだとどうしても把握しにくいことがある

松尾さんとの会話

  • 何かを変えることはストレス
    • 発表スライド内にもありましたね
  • 開発とテストエンジニアが完全に分かれている組織が一緒になろうとするのは無理が生じる
    • そうならないためには、最初から完全に分かれないような文化が必要
      • 開発者がある程度のcheckingまで責任を持って行う仕組みとか

感想

  • よく社風とか文化が大事という話がありますが、こういうところに響いてくるのかもしれませんね。
    • 少なくとも大学生の就活していた頃は、その理解をできていなかったと今さらながら反省…。

関さんとの会話（あまりメモ取れてない＆書けない…）

  • テストの自動化に対してはある程度割りきった方が良いのかも
  • 組織的なことはあまり考えずに、責任がどうとか関係なく、自分でやっちゃえば良い

感想

  • コンシューマや自社サービスが技術の先を行って、エンタープライズ系が後を追う形になっているのは、こういった面があるのかもしれないです。

和田さんとの会話

レガシーなコードをテスト可能な状態にするには

  • 個々で事情が違う
    • もしもコードが機能分割できている状態ならば、小さいところから始めても良いかもしれない
    • もしも密結合な状態になっているならば、Request,Responseのレベルでテストを書いた方が良いと思う。
      • まずは状態の再現性から保障する
      • その後、リファクタリングしよう
      • 逆に小さいところから始めてしまうと、簡単にテスト結果が変わってしまうため、再利用しにくいものになってしまう可能性がある

カバレッジなどのメトリクスの話

  • カバレッジなどの数値は見える化するためのものであり、高みを目指すものではない。
  • 仮に90%であっても、70%から増えていって90%になった場合と、100%から90%に減っていく場合で意味合いは大きく異なる。
  • 体重計は今の体重を知るためにある訳で、体重計に乗ったから体重が軽くなる訳ではないのと一緒。
  • 現状を知るのが大事
    • 詳しくはJasst北海道の資料参照(p42あたり)

JaSSTソフトウェアテストシンポジウム-JaSST'14 Hokkaido レポート

直リンク→ http://jasst.jp/symposium/jasst14hokkaido/pdf/S1.pdf

感想

  • レガシーコードの改善案はとても参考になりました！
  • メトリクスやtestingの部分などは、開発者視点だとあまり捉えないことが多いですが、これからの開発にとって重要な部分だと思います。
  • 開発も参加しつつ、テストのことを学べる場としては、JaSSTがちょうど良いと、改めて感じました。

JaSSTソフトウェアテストシンポジウム

『クックパッドエンジニアのトークナイト〜テストエンジニアvol.2 Testing編〜』発表部分 #cooketn

勉強会 技術 cooketn

前回に引き続き抽選に当たったので、参加してきました。

connpass.com

前回の勉強会の記事についてはコチラ

nihonbuson.hatenadiary.jp

今回はメモを手書きで取ったため、抜けが多いです。

口頭の説明を中心にとったので、公開されたスライドの補足的に使ってもらえればと思います。

はじめに（松尾さん）

スライド

www.slideshare.net

※p6まで

前回と今回のテーマについて

  • 前回はcheckingをテーマにした。

  • 今回はtestingをテーマにすることに。

「今回は面白いと思うので」という言葉を残しつつ、関さんにバトンタッチ

前振り（関さん）

スライド

speakerdeck.com

※p24まで

設計とテスト

  • ソフトウェアの開発とは2種類の作業を含んでいる。設計とテストである。
    • 計画を立てることも設計の1つ
  • 良いテスト=エラーを発見できるテスト
    • testingの方が近い

checking vs testing

  • checkingは待ち伏せ
  • testingは探しに行くこと

私達のtesting

  • 感じる＆壊す
  • いつ感じるのか？
    • 製品を目の前にして
      • 使いにくさ（「仕様書に書いていない」も含む）
    • 朝会
      • 「仕様です」「合意しました」はおそらく失敗している（なので禁句にしている）
    • 対象
      • 製品はもちろん対象
      • チームも対象
  • 感じた後どうするか？
    • 理解する
    • 考えながら触ってみる

クックパッドでのtesting（松尾さん）

スライド

「はじめに」と同じスライドのp7～p21

普段の観察

  • 朝会（いろいろな部署からの共有）
    • いつもと違う？→バグへと繋がる
      • 寝不足
      • メンタルは大事
  • issue
    • やり取りの多さ
    • 関係者の多さ
    • 話の複雑さ
  • チャット
    • 雑談、話題
      • ガヤガヤしてる→集中できていないかも？
  • 席周辺
    • 人の往来、相談回数
      • 松尾さんの席の近くは技術基盤チームなので、そこと相談しているものは気になる
  • 製品を触る
    • アプリを触る時
      • 感情の変化
      • 違和感という直感

感じ方、知り方を拡張する

  • 多彩な経験、考え、歴史
  • 話す、見る、聞く…

視点を動かして拡張する

  • 大局⇔局所
    • 組織⇔事業
    • 全体の振る舞い⇔部分的な振る舞い
  • 役割の切り替え、つなぎ目に注目する

感性/考え方

  • 変わらない/変わりにくい
    • 脳の成長は25歳ぐらいまで
    • 変わるにはストレスがかかる
  • 変化することを知る
    • 動機、環境、組み合わせ
      • 振り返りからの改善とか

miwa style（深谷さん）

「前振り」と同じスライドのp25～p60

朝会から何を知るのか（機能的なことは前提として）

  • 担当者を知る
    • 最良のアクセス先を知る
    • どんな人なのかを知る
      • 人に合わせてテスト内容をトッピングする
  • 揉めていることを知る
    • ある部分で盛り上がったチケット
      • その裏で盛り上がっていない内容には要注意
  • プログラマが混乱していることを知る
    • プログラマは分かっていないことを気づいていないかもしれない
  • プログラマが心配していることを知る
    • 作れると思って作っている人？…そう思っている人に「なめんな」と言いたい(by関さん)
    • 周りが「ヤバイんじゃないか」と言っていることに気付くようにする
    • 声の調子
      • 不安そうな時は不安そうにしていてほしい
      • 自信満々にしていると関さんにやられる
    • 心配事をこちらから話す→実装することを気にしてもらえる
    • 朝会中もエアテスティングしている
  • 報告されたバグから多くのことを知る
  • 知らなかった過去を知る
    • 昔のチケット
  • 誤解した仕様を知る
  • ここまでの内容は以下の記事に書いてあります。

miwa719.hatenablog.com

あるチケットのTesting

  • チケットを読む
    • 何が出来るようになったの？
    • 出来たことはどうやったら分かるの？
    • 実装中に起きていたこと
      • 朝会で聞いてはいるが、新たな気持ちで
      • 気になったメモを読み返す
    • 怪しい匂い
      • 沢山書いてる
      • あっさりしている
      • 説明がコードっぽい
      • 「苦戦中です」と書かれている
      • 簡単に書いてる
      • 結局どう書いていても匂う
  • 動かしてみる
    • チケットに書いてあるテストケースを忠実に行う
      • checkingの気持ち
    • ファーストインプレッション
      • 初見に感じる「何か」を大切にする
  • Testing
    • テストケースを変形する
      • 表には出てこない処理を思い浮かべながら
      • 複雑なものほど丁寧に
      • 面倒なもの（複雑なプログラムなど）ほどじっくりと
      • 匂いの種類や強さによってバリエーションを変える
        • 「テスターによって壊し方が異なる」(by関さん)
    • 関連するかもしれない機能との相性
      • 話題になっていないものこそ注目する
      • 入力はどこから来るのか
      • それを使う機能を試す
      • 別機能と一緒に使ってみたらどうなるのか試す
      • チケットのキーワード検索から関連のものを探す
    • テスターモードからユーザーモードへ
      • ユーザはどんな気持ちで触れるのか
      • ユーザは次に何を操作するのか
      • ユーザのユーザのユーザを考える
        • 例1）クックパッドを見て料理したお母さんの料理を食べる人（ユーザのユーザ）
        • 例2）クックパッドを見て指導した家庭科の先生の元で調理実習した生徒が、その料理を披露してお母さんに報告する（ユーザのユーザのユーザ）
      • 機能寄りではなく、やりたいことをやれているのか調べる
        • 「やり過ぎ」にも気付くことができる
    • 過去に起きた嫌なこと
    • これから起こるかもしれない嫌なこと
      • 不安なことをいろいろな人に話してみる
    • 昨日との違い
    • プログラマとの会話
      • 「こういう所が不安」「実は…」みたいな話が聞ける
      • プログラマと一緒にテストしてみる
    • プロ無職（関さん）との会話
      • 直球で「ここにバグがあると思うから」と言われる
      • 「休んだら？」とテストを止めに来る係りでもある
        • 「集中しすぎるのは良くない」(by関さん)
    • テスターとの会話
      • おかしいと思うことを他のテスターはどう感じるのか
      • テスターが作ったテストもどう感じるのかは重要
      • ペアテスティングをやってみる
    • おかしさを見つけたら開発者の元へ
      • 鮮度が良いうちに現象を見てもらう
      • ログを取る
        • 再現しなくてもログから分かることもある

まとめと所感（関さん）

スライド

所感

  • テスターは「テストを書く」とは言わない。「テストする」とは言う。
  • Feelingを育む土壌が重要
  • 人がミスするのは当たり前ということを受け入れる空気も大事

さいごに（松尾さん）

  • testingは人によるものが多いが、勉強会では話されないことが多いので、こういうことも共有していきたい

質問

心配事を話す時に設計上の情報を共有してもらっているか？それとも漠然とした捉え方か？

  • 他の人との会話を聞いた上で、大きなレベルで捉えている。

心配事を話すタイミングは？

  • 9:15～9:45が朝会。その後に、朝会の2次会が10分ほどある
    • 新人を育てるには、2次会で育てれば良い(by関さん)
  • また、テスト環境はすぐに用意できる状態にある

チケットの粒度や期間は？

  • チケットには機能単位
  • 半日～2日程度
  • 追記はあり
  • テスト技法に従ってテストケースを書いてもらっていたりもする

チケットに書いてあるテストケースというのは開発者が考えたテストケースか？

  • そうです。
  • バグを出したい気持ちで書いていると思うが、基本的なテストケースである。

探求の終着点はどこか？

  • 基本的には時間で区切る。
  • チケットによってその時間もまちまち
    • 通常、約3個/日のチケットをクローズしているが、日をまたぐこともあり

時間で区切るのは経験から？

  • 感覚で。
  • 「もういいよ」という雰囲気になったら
  • リリースまでに全てのチケットを見えるようにするのが大事
  • 残業すると周りのプログラマがざわざわする

ペアテスティングを行うと、「ここは他の人がやってくれるから」みたいな仕切りを作ったりしないか？

  • 私の方から壁を作ることは少ない

感想

  • 人の往来の多さを気にするという感覚はすごい分かる。
    • 私個人としては、コミットの多さとかも気になることがあるぐらい。
  • 朝会の二次会っていいな。
    • ちゃんとその時間の枠を確保しているのも素晴らしいです
  • 担当者を知って、その人と適切に話すと言ったことは、TPI NEXTのコミュニケーションのエリアが効率化レベルまで行っているように感じました。
  • checking→testingと話してきていたけど、ユーザーモードの話とかはUXの分野にまで踏み込んでいると感じました。
    • 明確な区分をする必要も無いと思うけど

発表後の懇親会の内容

  • 別記事にしてます。

nihonbuson.hatenadiary.jp

第7回Quesに参加してきました。 #Ques7

技術 勉強会 ques

先日、第7回Quesに参加してきました。

atnd.org

参加メモ

今回は事情によりノートPC画面が見れなかったので内容が飛び飛びですが、スライドに載っていないこと（発表者が直接発言していたこと）と質問内容を中心にメモを取っていました。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

発表内容について

全体的な内容については、それぞれの発表スライドとsakaimoさんのブログ内容が参考になるかと思います。

sakaimo.hatenablog.com

勉強会全体の感想

  • 「アジャイル＆テスト自動化」「テスト分析」という、一見関係ないような2つを題材にすることで、普段知らないことを学ぶことが出来て良かったのだと思う。
    • テスト設計を考える人にとっては、アジャイルやスクラムなどサイクルが短いものに対して考える機会が少ない…かも
    • テスト自動化を行う開発者は、あまりテスト分析やテスト設計を考えないことが多い…かも

第7回Ques「テスト分析の概要」参加レポート #Ques7

ques 勉強会 技術

スライド

www.slideshare.net

アンケート

JSTQB FL取得者

  • 半分ぐらい

    テスト分析をズバリ説明できる人

  • 2人ぐらい

    テスト条件をズバリ説明できる人

  • 2人ぐらい

このセッションの目的

曖昧模糊なテスト分析が実際に何であるか改めて理解し、他人に説明できるようになろう！

例題

  • 次の仕様に対してテスト条件を考える

    • パスワードは４文字以上１２文字以下の 英数字のみを許容する。
    • パスワードを３分以内に連続して４回以上間違って入力すると、アカウントを５分間ロックする。

  • ここで導き出すのは「パスワードを3文字にする」といったようなテストケースではなく、あくまでもテスト条件。

  • 解答例はスライド参照

演習問題

  • 次の仕様に対してテスト条件を考える
    • 「ユーザデータ登録」画面の「インポート」ボタンを押下することで、「ユーザデータの一括登録」画面に遷移する。
    • 「ファイル選択」ボタンを押下すると「ファイル選択」画面が表示され、ツリー構造のビューからインポート対象のファイルを選択することができる。
    • 「登録」ボタンを押下するとファイル内のデータを読み込み、「ユーザデータの一括登録」画面を閉じ、「ユーザデータ」画面を表示する。

テスト分析・テスト条件について

  • テスト条件は粒度が様々。
  • テスト条件は考える人によってアウトプットが様々。
  • だからこそテスト条件に対してレビューすることが大事。
  • テスト分析を方法論化することで、出力形式を統一することができる。

質問

テスト条件のレビューの参加者は？

  • 関係者全員

レビューの参加者に開発者も入ると、内部的なことについての意見が出てしまうのでは？

  • 新しい観点になるので良い

あいまいな要件とコードしか無い場合のテストベースはどうするのか？

  • 要件レベルとコードレベルは異なるものだと思う。
  • 困っていることは何か考え、それを解決する手法を考える。

テスト分析の範囲は？（システム全体か、対象部分のみか）

  • 条件依存による。

分割可能かどうかもテスト分析か？

  • 粒度を細かくすると工数もかかるため、トレードオフの関係ではある。
  • ただ、これをどうするかも含めてテスト分析

粒度について調整する方法論はあるか？

  • 今のところないと思う。

テスト分析を行っていると、テスト設計をしている気分になるか？

  • なる

JSTQBの言葉をどうやって読み解いたか？

  • 社外活動で知見を得た。
  • 同じキーワードが書かれているドキュメントを色々とあたることで理解できることもある。

規模が大きくいい加減な仕様を元にすると、いっぱいテスト条件が出てくると思うが、深追いを止めるコツはあるか？

  • ステークホルダーに「細かすぎてよく分からない」と言われない程度までやる。
  • レビューして不安なところがあったら、その部分を深掘りする。

感想

  • 演習問題は周りの人と見せ合う機会があったのがすごい良かった。

    • ちなみに私は、「画面表示の方法（新しいウィンドウか同じウィンドウのままか）」「ファイル選択数」などが思い浮かびました。
    • 他の人は「ファイルサイズ」や「押下回数」などの負荷テスト部分について考えていたようでした。

  • 今回、テスト要求分析については無いように思えました。

第7回Ques「アジャイルとテスト自動化」参加レポート #Ques7

ques 技術 勉強会

アジャイルとテスト自動化

スライド

www.slideshare.net

スクラムを選んだ理由と現状

  • 社内の半数程度で採用
  • ある程度のフレームワークが存在しているためにスクラムを採用
  • また、1,2週間に1度のリリースという早いサイクルに対応できるのも理由

Yahooのチームの特徴

  • チーム自らテストを行っている
  • リリースの権限もチームが持っている

テストの種類

テストの重要性について

  • 大変…だけど端折るのは良くない
  • バックエンドに関しても頻繁にリリースしているので、テスト自動化をすべき
  • 「テストしなくても良い」と思うことは、どこをテストすれば良いのか分からない証拠

ヤフオクアプリの自動化事例

スライド

www.slideshare.net

テスト自動化の優先順位について

  • 必ず落ちては困る画面から実施

iOS9の対応

  • xpathが変更される事態になり、その対応に苦慮した

ここまでのセッションについての質問

自動化の観点はクラッシュするかどうかのみで、検索結果の正確性は対象外なのか？

  • シナリオの画面遷移を見ている
  • メンテナンスの工数は増えたと思うが、QAの工数は削減されたのか？
  • 現状はまだまだ。ただし、手動で確認すべき画面は絞り込めているのは自動テストを実施してよかったこと

開発チームは品質に対する意識が高かったのか？（質問者の会社はリリースが短いからテストをしないという考えの人が多かったそうです）

  • 意識は高い。積極的に導入してくれる。
  • 「ユーザへの迷惑を無くすために」から考えた結果

障害の調査は誰が拾うのか？

  • 最初は専任者を作り、その人が行っていた。
  • あとは気付いた人が行うようにしている。
  • すぐに直せなさそうな場合はバックログに送る。

バックログに入ったものはどのように割り振っているのか？

  • スクラムマスターとプロダクトオーナーで相談する。

スクラムマスターへの負担は増えたか？

  • もともと割り込みタスクが日常的だったので、そこまで負担が増えたようには感じない。

テスト自動化に対する人数は？

  • スクラムマスター＆専任者＆テスト支援チーム所属の計3人で週1日×半年間

テスト実行時間はどれくらいか？

バグじゃないのにテストが落ちることはあるか？

  • 日々存在している。

テスト支援チームの役割は？

  • 必要に応じて。
  • 特に明確には決めていない。
  • 極力、サービス開発チームにやってもらう。

支援チームの人数はどれくらいか？

  • 5,6名

バグを手動で見つける人はいるのか？

  • 全員でやっている。
  • リリース前は企画の人などにも一緒に触ってもらっている。

テスト設計やテストケースを作る時間はあるか？

  • 時間は取れていないが、ホワイトボードに新機能の一覧を書いたりする程度

感想

  • 以前にWeb Service QA Meeting Vol.1で株式会社ネクストの方がページ遷移のテストを行っていたと言っていたように、自動テストはページ遷移部分から導入していくと行いやすいのかなと思う。
  • テストの自動化は開発者が実施して、テスト設計などの部分でQAエンジニアが入ってきて協力することが良い方法かなと最近感じてきました。
    • 少なくとも、開発とテストで役割を完全に分業するのではなく、お互いで補完しあうことが大切なように思えます。