ドメイン分析勉強会で学んだこと #NaITE

naite 勉強会 技術

前回に引き続き、ブラックボックステストの話です。

2月20日の土曜日にドメイン分析勉強会がありました。

nagasaki-it-engineers.connpass.com

発表スライド

www.slideshare.net

1問目

f:id:nihonbuson:20160222093047p:plain

http://www.slideshare.net/mhlyc/ss-58471801/37

問題に対する意見

  • 「Lv.20に到達したとき進化する」というのは、Lv21以降は進化しないのか？
    • 「Lv.21以降も進化する」とのこと
    • つまり、「Lv.20以上は進化する」と訂正されました
  • 「Lv.100に到達した後、なつき度が200を超えた時、進化できるのか？
    • 進化しません。あくまでもLv.100に到達した瞬間になつき度が200を超えていたら進化します
      • すると、テスト対象は「Lv.Xの時に進化するかどうか」ではなく「Lv.X-1からLvXに変化した時に進化するかどうか」がテスト内容ではないか。
        • それならば、「X=1」は有効同値クラスではないのではないか。(Lv0からLv1に変化した時はエラーになるはず)
    • 登場する条件に主従関係があるので、デシジョンテーブルでやった方が良いのでは？

自分が解いた図

f:id:nihonbuson:20160222093145j:plain

f:id:nihonbuson:20160222093200j:plain

  • 赤い部分が進化する場所、青い部分がエラーの場所

解いた結果後の疑問

  • X≧1やY≧0の条件は必要ないのでは？
    • 「進化する」というドメインをテストしたい場合には必要が無さそう
      • 「進化しない」というドメインもテストする場合には、図のL字部分（赤でも青でも無い場所）のテストを行う必要がある
  • Lv.101以上やなつき度256以上をテストする必要が無いのでは？
    • 「進化するかどうか」をテストするという目的ならばテストする必要はなく、別の「範囲外はエラーになるかどうか」という目的のテストで行うべきでは。
    • ポケモンを想像するとエラー前提でテストする必要があるように思えるが、最近のスマホゲームとかは最大Lvの引き上げとかがあるので必ずしもエラーではない
  • XとYの両方がONポイント（カド部分）のテストをなぜ行わないのか？
    • そのテストをして期待値通りの結果にならなかった場合、どちらが原因で期待通りにならなかったか分からないため
      • ドメイン分析は、あくまでも対象の直線（もしくは曲線）の式が正しいかどうかを見るために行っている。
      • なので、傾きなどが正しいか他のテストケースで示すことができれば、XとYの両方がONポイントのテストを行う必要がないはず。
    • 理科の実験と同じで、テストしたい部分以外はできるだけ影響を与えない場所(INポイント)を取った方が良い
      • すると、「傾きが正しいことも同時に確かめられるため、INポイントを固定しないほうが良い」という考え方は、失敗の原因を隠すのではないか？
        • あるテストケースが失敗した場合、それがONポイントが原因なのか、INポイントが原因なのか判断つかなくなるのではないか？

2問目

f:id:nihonbuson:20160222093235p:plain

http://www.slideshare.net/mhlyc/ss-58471801/39

自分が解いた図

f:id:nihonbuson:20160222093300j:plain

f:id:nihonbuson:20160222093310j:plain

  • 赤い部分が対象

解いた結果後の疑問

  • X<30はX≦29と書き換えた方が良いのでは？
    • OFFポイントが有効で、ONポイントが無効になってしまうので分かりづらそう
    • ちょうど、 @akiyama924 さんがドメイン分析で似たような話をしていたので聞いてみました

  • どちらが良いのではなく、統一することが大切なのは、まさしくそうだと感じました。

  • 3次元の図を描く必要は無いのでは？

    • 描くことが必須ではない
    • ONポイントやOFFポイントがどこか分かるために描いたりする

演習問題を解き終えた後の意見

  • 今回の例題2つはそもそもドメイン分析で解かないのでは？
    • 1問目はデシジョンテーブル、2問目は境界値分析で十分
    • ドメイン分析を行うのは、4次元以上だったり、2変数以上を組み合わせた条件があった場合
  • テスト設計技法を考える前に、そのテストの目的は何なのか考えることが大切
  • テストケースを具体的に考えることで、そもそもの仕様の不透明部分が分かったりするので、今回のように考えることは実装前のレビューとして有用

終わりに

  • 内容はドメイン分析の勉強会ながら、テスト目的やレビューなどにも話が及んで大変参考になる勉強会でした！

テストエンジニアが普段考えていることと、テストをするということ

技術

先日、面白い話題がtwitter上で繰り広げられていたので載せます。

普段のこんなところから、テストエンジニアは考えを巡らせていると知ってもらえればと。

テストエンジニアの日常

  • こういうドキュメントにも思考を巡らせてしまいます。*1
    • 動くものだけがテストの対象ではありません。

テストをすることへの誤解

「テストをする＝開発物が出来てから初めてテストのことへ頭を巡らせる」と思われていないでしょうか。

少なくとも、周りの開発者は（社内、社外関係なく）そういう思いを持っている人が多かったです。

しかし、JSTQBのシラバスによると、テストの目的として以下の4つが書かれています。

  • 欠陥を摘出する。
  • 対象ソフトウェアの品質レベルが十分であることを確認する。
  • 意志決定のための情報を示す。
  • 欠陥の作りこみを防ぐ。

http://jstqb.jp/dl/JSTQB-SyllabusFoundation_Version2011.J02.pdf#page=14

この記事の最初に書いた内容は、欠陥の作りこみを防ぐことにも繋がると思っています。

「この場合はどういう挙動になるんだろう？(101辛以上はどうなるんだろう？)」という、仕様書には書かれていないことを開発者に伝えることができます。

こんな工数を減らしたい！（無くしたい！）

  • 実装したけど、リリース日前日に大幅な修正が入った
  • 実装したけど、出来たものは利用者のやりたいことと違っていた
  • 実装前に想定できたことを考慮せずに実装してしまった

こんな工数はもったいないです。

これらを実装前に指摘するためにも、テストエンジニアがいると思ってます。

最後にちょっと宣伝

今回の話題として使った同値分割・境界値分析と同じブラックボックステストの設計技法である、ドメイン分析の勉強会が今週土曜日にあります！

興味を持った方は是非参加してみてください！*2

nagasaki-it-engineers.connpass.com

*1:ちなみに自分も、106辛は調べなくて良いのか気になりました。1辛～5辛と6辛～10辛を別クラスとして考えるならば、繰り返しのルールとして捉えると106辛は気になってしまうので。（多分1巡目で1辛～10辛を同値クラスとして再編成するのだとは思いますが）

*2:ちなみに私は運営側に関わっていない、ただの勉強会参加者

組織にテストを書く文化を根付かせる戦略と戦術 #jopf

jopf 勉強会 技術

勉強会告知ページ

connpass.com

発表スライド

www.slideshare.net

発表のねらい

  • 戦略の話と戦術の話

自己紹介

  • 昼はコンサルの仕事をしている
    • いろんな組織にテストの書き方を根付かせるための活動とか

銀の弾丸はない

  • レガシーコード改善に正解はない
  • テスト自動化は銀の弾丸ではない
  • 導入方法にも銀の弾丸はない
  • 導入を目的にしてはならない
  • 状況は現場によって全く異なる
    • 勝ちパターンはだいたいある
  • 「t_wadaが来たから大丈夫だ」ではない

ジェラルド・ワインバーグの影響図

f:id:nihonbuson:20160217215450p:plain

  • ストレスが増えるとテストの回数が減る
  • テストの頻度が減るとストレスが減る
  • どうやってこの無限ループを抜け出すか
    • ノードを増やす？
    • テストではなく自動テストにする＆テストが先に来るようにする

f:id:nihonbuson:20160217215505p:plain

  • テストを書く時間がないのではなく、テストを書かないから時間が無くなるのです by James Grenning

文化を変える

  • 文化はすぐに変わらない
    • 大体2年ぐらいはかかる
  • ソフトウェアプロジェクトの掟「動くコードに触れるな！」に戦う
    • コードは緩やかに死んでいく
    • どうやって動くコードに触れるような仕組みにするのか

イマココから始める

  • ToBeではなくAsIsとNotToBeから始める
    • 「自動化すれば、ChatOpsにできて…」とかではなくもっと現実的なところを考える
  • 現状がどうなっていて、どうなりたいか
    • ヒアリングする
    • 「勘弁して欲しい」ということを裏返すことから始める
  • 期待値のマネージメントをする
  • 人やプロジェクトの速度はそこまで変わらない
  • 日本人を行動させる言葉「まわりはもうみんなやってますよ」は劇薬なので、用法用量を守ること

夢を語りがちになるよねぇ…

それよりもロードマップをきちんと引く方が良いと思ってます

人を知る

  • チームメンバーはストロングポイントが違う
    • 楽しいから頑張る
    • 定時で帰れるから頑張る
    • 自分のコードが綺麗になっていくから頑張る
    • 回帰テストを機械がやってくれるようになるから頑張る
    • コードカバレッジなどのメトリクスの達成感があるから頑張る
    • ビジネス価値が増えるから頑張る
      • 不具合修正ではなく、新しい価値を提供する

変えることの難しさ

  • 人は誰しも変化に対して身構える
  • リファクタリング（振る舞いを変えないままで中身を変えていく）をやろうというとやる気になるが、「今やりましょう」というとなかなかやってくれない（リファクタリングのジレンマ）
    • 「後でやるよ」と言ったりする(TODOタスクになりがち)
      • そしてやらない
    • 部屋の掃除と同じ
    • リファクタリングはお客様に価値を与えないように見えてしまう
      • 実際には中長期的には価値を与えるのだが…
        • ソフトウェアの成長速度が下がっていく
      • ボディブローになる
    • リリース後は、別機能の着手に追いやられる
  • プログラミングの中に混ぜ込まなければならない

変えることの難しさは以前に #cooketn でも松尾さんが伝えてましたね

nihonbuson.hatenadiary.jp

Grace Hopper（COBOLの作成者）の言葉

  • 事前に許可を得るより、後で許してもらう方が楽

すべては変化する。これを受け入れざるをえない

  • 仕様が固まることはない
  • 開発が終わることはない
  • 理解は常に深化する
    • 1年前のコードより今書いたコードの方が技術的にも業務理解的には深いはず

技術的負債の四象限（マーティン・ファウラー）

f:id:nihonbuson:20160217215545p:plain

  • 第四象限に対して、どのようにアプローチしていくか
    • 気付くチャンスを増やす
    • 気付いた時に改善できるようにする

テストは品質を上げない

  • 品質が「わかる」ようになる
  • テストは体重計のようなものである
    • 体重計を買ったって痩せない
    • 体重計に乗っても痩せない
    • 体重計があることで現状が分かる
  • テストを書くだけでは良くはならない
    • 情報が増えても、悪いことが分かるだけ
  • 設計とプログラミングを見直すことで品質を上げる
  • 再設計とリファクタリングをテストで支える

戦術編

  • 全部書こう！→破綻する
  • 改革は小さくかつ最も効果のあるところから
  • 最も困っているところから
    • ECサイトなら決済などのお金＆個人情報
    • お客さんによっては、新機能のところから
    • バグを修正をするところから
      • 欠陥は偏在する
    • 静的解析でピンポイントに
      • 複雑度が高いところから

完全にテスト分析・テスト計画の話ですね

テスト戦術

  • 『リーン開発の現場』に、どこから始めるべきか書いてある

リーン開発の現場 カンバンによる大規模プロジェクトの運営

リーン開発の現場 カンバンによる大規模プロジェクトの運営

  • リスクが高い
    • 例えば管理画面の履歴とかはリスクが低い
  • 手動テストのコストが高い
  • 自動化コストが低い
  • リスクが高くて自動化コストが低いならやってみるべき

誰とやるか

  • 少しずつ広げていく
    • 改善の芽が育つように
    • 親離れできるようにするのがコンサルのゴール
  • 最初はペアプロからやってみる
    • 1人が2人、2人が4人に
  • 最初の1人は若手のエースかベテランから
    • 戦略編の「人と知る」にも繋がる
    • 依頼をくださった人と相談することが多い

こだわるな

  • 最初から全部やろうとしない
    • 何はやって、何をやらない
    • テストを書きながらコード書いて、リファクタリングをやって…とかもこだわらない
      • 慣れが必要だし
      • 「テスト駆動までできてないんですよー」という発言はどうでもよい
  • テスト駆動にこだわるな
  • テストファーストにこだわるな
    • テストの書く順番は最初はこだわらない
    • 慣れてきたらテストの書く時間とコードを書く時間を同じぐらいにしていく
  • ユニットテストにこだわるな
    • ネットワークやデータベースを偽物に置き換えて…とかに拘る必要がない
    • t_wadaさん自身もこだわっていない
  • テストの速さにこだわらない
  • テストの網羅性にこだわらない
    • 最初から「例外系を網羅する」とか考える必要はない

こだわろう

  • 良いユニットテストの指標にも優先度がある
    1. 再現可能であること(Repeatable)
      • Aさんは動くけどBさんのところでは動かない
      • もう一回動かすためにはこのファイルを消して
    2. テストは互いに独立していること(Independent)
      • A→B→Cの順番なら通るが、C→B→Aの順番だと通らないとか
      • 並列で走らせる時にエラーにならないようになっていること

レガシーコード改善ガイドは必ず読むべし

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

  • テストが書かれてないコードはテストが書きにくい
    • テストが書けない構造を変えていく
      • 組み込みソフトウェアの場合は、テストが書けるようになるまで外科手術を行う
    • 外から無理やりテストを書くようにする
      • WEBアプリケーションならば、HTTPのrequest/responseとDBの事前状態と事後状態で抑える
  • 絞込点を探す
  • 仕様化テストを行う
    • 仕様との乖離が起きる
    • 何が正しいか分からない
    • とにかく現状で動いていることを正の状態にする
      • 動きが変わったかどうかだけは分かるはず
    • 十分綺麗になったら、何が正しいか考える

見える化

  • 割れ窓理論
    • NYは治安を上げていくために、割れている窓を綺麗にしていく
    • 汚いものがあると罪悪感がなくなっていく
    • 気付いたところから綺麗にしていく
  • メトリクスを取る
    • カバレッジが低いうちは効果大
    • 変化がすごいあると人間のモチベーションが上がる
  • 小うるさいツールを乗りこなす
    • 大量の出力を出したりする
  • 分母分子を見ないで傾きを見る。

静的解析を使いこなす

  • 動的テストと静的テスト
    • 対象を動かすことによって調べる
    • 対象を動かさずに調べる
      • コード行
      • メソッドごとの行
      • テストは書くだけではない
  • 全体のメトリクスを計測して俯瞰の視点を得る
    • ヒートマップ的な
  • 部分的なメトリクスを計測し続けて傾向を見る
    • リスクインパクトのある決済部分は改善しているなど

コードレビュー

  • コードレビューのインフラに投資する
  • WIP pull request
    • 完成する前から共有する
  • コードを見る文化、見られる文化を育てる

設計の可動域を確保する

  • テストがないのは設計が悪い兆候
    • 今の状態のものにテストを書くと、改善時にテストを書き直すはめになる
  • テストと実装の間に遊びを持たせる
    • 大外からテストの手をのばすとか
      • その代わり、動作は遅いし、データの準備が必要だったりする

背中を見せる

  • サンプルとデモが大事
  • 真似してもらう土台を作る
    • 最初はサンプルのコピペでもOK
    • 架空のプロジェクトでもOK
  • テストのある生活を体験してもらうことが大事
    • その生活を体験するとそこから辞める人はほとんどいない
  • その後にテストのメンテナンスを学ぶ

改革について

  • 自分達から始めてみる
  • できるからやるのではなく、やるからできるようになる

OSS活動の活発さと評価の関係について #jopf

技術 勉強会 jopf

勉強会告知ページ

connpass.com

発表スライド

www.slideshare.net

発表のねらい

  • 個人開発者が現在のOSSの現場でどんなことを考えて、どんな問題が起きているか共有する
  • 社会学っぽい話

OSSと私の関わり

  • power-assert
  • いつものAA
  • ちなみに今日の会場でこのAAは生まれた

2016初頭のOSS風景

  • Social Coding革命
    • GitHub
    • 身分制度の変革
    • GitHub以前は組織が階層構造になっていた
      • メインコミッター
      • コアコミッター
      • コミット権の与えるものと与えられるもの
    • GitHubによって起こったもの
    • プロダクトではなく、コミュニティ

tagomorisさんのお話

tagomoris.hatenablog.com

OSS プロダクトに必要なもの

  • 公開だけでなく、努力とか取り組みとか必要
  • 継続的な開発とメンテナンスが必要

OSSコミュニティを作るために

  • 開発チームがオープンであること
    • 何か問題やエラーレポートをどうするかなどをオフラインで決めているような印象を与えないもの
      • 実際にはやっていなくても、その印象を与えてしまってはいけない
    • コントリビューション手順を示すこと
      • ますはissueに
      • まずはチャットに
  • 企業のサポート
    • メジャーになってきたOSSの場合
    • 業務時間外にやっているイメージがあると思う
      • OSSのプロジェクトが大きくなってきた時に馬力が出なくなる
  • 常に英語を使う
    • 例えばロシア語で書かれていたら引き返すでしょ？
    • OSSの界隈は英語が標準
    • たとえチームが日本人しかいなくても
      • 後々、世界中からのコントリビューションを受け入れるため
    • 日本語で来たissueは即閉じるぐらい
    • 日本語で書かれていると、敷居が高くなる
    • せめてタイトルだけは英語にするとか

どこを見るか

  • OSSは結構見られている
GitHubの画面
  • ライブラリを選ぶ時の基準
  • GitHubをよく見ているのは会場の4割ぐらい
  • Starの数
  • 最終更新日
  • issueがどれぐらい溜まっているか
  • 何回リリースしているか
  • 何人が開発に関わっているか
npmのサイト
  • ダウンロード数
  • 少ないのならば、真面目に品質管理をしてないならば危ないかもしれない
  • 最後のリリース日

バージョン番号の付け方

  • セマンティックバージョニングによる

セマンティック バージョニング 2.0.0

  • major, minor, patch
  • 下位互換性のあるバグ修正はpatchを上げる
  • 下位互換性のある機能追加はminorを上げる
  • 下位互換性のないものはmajorを上げる(バグ修正、機能追加関係なく)
    • 利用者側のコードの修正が必要
    • デフォルトの値の変更
    • コードの廃止
  • 詳しくはcodelunchfmで喋っている

The power-assert Leaves From Moratorium | CodeLunch.fm

  • 作者がルールを守ることで、利用者側の負荷が下がる
  • Version1未満は何をやっても良い状態なので使いづらいと判断する

疑念

t-wada.hatenablog.jp

  • コードを書く人が増えれば増えるほど、ブレるのでは？
  • 機能を落とすとVersionを上げる事になるので、なかなか機能を落とせない
  • ソフトウェアとしてエントロピーが増えて、自重で潰れてしまうのではないか
  • うまく出来たソフトウェアとは
    • 足し算ではなく引き算
    • 単機能である
  • 完成する→rejectしまくる=Noする→活発でないように見えてしまう
    • メンテナンスしてないからではなく、完成しているから
    • しかしサイトを見るとその見分けがつかない
  • 賑やか感を出すとソフトウェアが壊れてしまう

戦略1

  • 動作検証も更新に入るべき
  • 最終更新日も更新される
  • 元旦に年を更新するとか

戦略2最終更新日以外にも診てもらう

  • ダウンロード数が上がっていくとか、それを使うプロジェクト数が増えていくとか

戦略3プラグイン機構

  • バランスを取るために、プラグイン機構を作る
  • コアの設計を守る
  • 貢献している感が増える
  • 自分達の設計が完全に破綻するのを防ぐ
  • 特定のOSだけでしか使わない機能はコアではなくプラグインで
    • メンテするときに実際のOSが無くて困ったり

戦略4適者生存の法則

  • 似たようなソフトウェアが食い荒らす状況になっている
  • 極端に流動性が高い状態になってしまう
  • ロードマップ志向とエコシステム志向
    • 一つ一つのエコシステムが矛盾だらけ
    • ロードマップの場合はど真ん中にいれば良い
    • エコシステムの場合は真ん中から距離を取ってみるべき

「社会問題」たち

  • 伽藍とバザールになった…？
  • 一つ一つの発言が強くなっていることによって問題が発生した

社会問題1. 燃え尽き

  • 一時期から燃え尽きてしまう人が増えていた
  • 作者が提供したくない要望に対してサムズアップ(+1)が膨大に発生し、作者が燃え尽きる
  • GitHubは群衆をマネージメント出来ていない
  • GitHubを止めようとか、issueはRedmineに立てようと考えるプロジェクトが多くなった
  • 公開質問状をGitHubに送った
    • 既存のissueの検索の仕組みがない
    • 毎回Close対応をしなければならない

github.com

  • →「+1が連続して出てこないようにします」という返答が来た
    • それのコメント欄が+1ばかり

github.com

社会問題2. Code of Conduct

  • 行動規範
    • 人種差別、宗教批判をしないなどの当たり前のことを明記しよう
      • 「違反したらこういうルートから報告する」というような細かい取り決めまで。
      • メインコミッターなどでも社会的違反をしたら追放する
  • より多くの人に、未来の人に良くなるように
  • 同意したり同意しなかったりするプロジェクトが現れた
  • 僕らはうまく行っているから書く気は無いよ→「お前らのプロジェクトは反社会的だ」と言われる
    • twitterとかの炎上に似ている
  • 行動規範の議論が一番殺伐している
  • The CoC is not about Social Justice.という条項を入れるまでになっている
  • 今までは「当然人種差別しない」と暗黙的に思っていた

OSSプロジェクトの三要素

  • popular
    • 多くの人に使われる
  • healthy
    • メンテナーがアクティブ
    • コミュニティも活発
  • supported
    • 持続性を満たすために企業などから何らかの支援がある
    • 仕事の一部もしくは全部を開発に回さない限り難しい
    • 企業がhiringする形でサポートしている
      • GoogleやMicrosoftもGitHubに移行してきた
      • メインコミッターの殆どは昼に給料を貰って開発している

まとめ

  • Social Codingは本当に「社会」になりつつある
  • コードを通じて社会に関わりましょう

質問

  • Q.power-assertで求める姿は？
  • A.拡大路線か良識的でありたいと考えるならば、プラグイン構造で考えたい
    • もう完成している
    • どんどん狭めて、関数を1つにしようとしている
    • jsは周りが賑やかなので、それに対応しようとして賑やかになる
    • ただしコアは変わらない
    • 同格のメンテナーにした
      • コアチームが出来たから同格になるわけでなく、結局創設者がリーダーになる
        • 死んだら壊れそう
    • 海外の方が貢献している人が多い

JJUGナイトセミナー『Git入門』に行ってみた＆解決策考えた #JJUG

勉強会 技術

JJUGナイトセミナー『Git入門』に行ってみました。

jjug.doorkeeper.jp

Gitはじめの一歩

スライド

www.slideshare.net

感想

  • イラストが可愛くてすごい分かりやすかったです！
    • このスライドを見るだけで、色々とGitのコマンドがイメージで理解できます

  • 困ったときのコマンドを沢山伝えてくださったので、色んな場面でこのスライドを見直す機会ができると思います

  • 「Gitは歴史」という言葉が印象的でした。

    • ちなみに発表を聞いた直後の自分

  • めっちゃ「Git=歴史」が刷り込まれましたとさ

Git実践入門

スライド

www.slideshare.net

参考記事

syobochim.hatenablog.com

感想

  • 大規模なプロジェクトのGit運営の発表を聞いたことが無かったので、大変参考になりました！

  • 特に業務フローをきちんとしていないと大変なんだなと感じました

懇親会で質問したこと

  • Q 小規模、中規模、大規模ってどのくらいの人数を指していますか？

    • A 小規模は自分が見渡せる程度、中規模は2,3人の信頼できる人に任せてその人達と見渡せる程度、大規模はそれ以上

  • Q どれが一般用語で、どれが業界用語で、どれが独自の用語ですか？

    • A 特に意識はしていなかった。
    • （周りの人と話してて）とりあえず「ライブラリアン」とか「UT」とかは業界用語らしい。

発表中の発言の解決策

「名前のbranchにしちゃう人を止めたい（細かい単位でbranchを作ってほしい）」という悩みに対して（下の画像の赤囲み部分について）

f:id:nihonbuson:20160126004616p:plain http://www.slideshare.net/syobochim/20160128-jjug-nightgit/60 より

  • Gitのフックを使えば良いのでは？

  • 例えば、branch名にチケット番号が入ってないと、pushを自動で拒否することかできると思います！

「ケース2では権限の設定が出来ないから、ケース1のようにメインリポジトリとサイトリポジトリで分けて管理してるので重厚になってしまう」というような発言に対して（下の画像の赤囲み部分について）

f:id:nihonbuson:20160126003056p:plain http://www.slideshare.net/syobochim/20160128-jjug-nightgit/53 より

イベントを参加した全体の感想

  • とっても楽しめた！
  • Gitについてまだまだ知らないやり方がいっぱいありそう！
  • 何がGitとしての言葉なのか、後でちゃんと調べたいと思った

WACATE2015冬に参加してきました！ #wacate

勉強会 技術 wacate

半年ぶり2度目のWACATEに参加してきました。

WACATEとは、1泊2日で行われる若手テストエンジニアのためのワークショップです。

wacate.jp

今回は冬ということで、多くの内容を浅く広く行いました。（夏は一つの分野を深掘りします）

内容を紹介しながら振り返っていきます。

ポジションペーパーセッション

感想

この一言に尽きます。

そんな変人の集まりがWACATEです。（失礼）

BPPセッション

感想

スライドはまだ公開されてないので中身は伝えにくいですが、とりあえず私はおでんにならなかったです！

突撃となりのテスト計画 〜こんなときお隣さんはどうしてる？〜

スライド

www.slideshare.net

感想

  • テストに関して多くの悩みが共有された
  • 私のいた班では、「テストの完了基準がわからない」という悩みの解決策を考えた
  • 私なりの考えとしては、一旦区切りをつけることが大切かなと。
    • そのためには、以下のようなことが必要かなと感じた
      • テスト内容に優先度を付ける
      • かけられる工数との兼ね合いを考える

わりとディープ？同値分割↔境界値分析

スライド

www.slideshare.net

感想

  • ただただ楽しかった。

  • セッション後や後夜祭の時に発表者に色々聞いて分かってなかった部分は自分なりに納得できた。
  • ただ、表を見て間違えやすいと感じたのも事実。
    • そこらへん、後日、別記事で示したいな

TPI NEXTで自分たちのテストを評価しよう

スライド

www.slideshare.net

感想

  • 実際にその場で判断することが出来て、TPI NEXTの一部を体験出来たのは良かったと思う。
    • ちなみに人外判定とは、コントロールクラスすらできていないことを表す

f:id:nihonbuson:20160114001916p:plain

http://www.slideshare.net/goyoki/tpi-next-56869662/34より。

  • 本当は基本クラスタの説明をして、「テストツールより先に他の部分をやるべきだと示されている」と伝えられると良かったんだろうけど、30分じゃ難しいですよね
    • テストツールのコントロールレベルは「E」と書かれているので、それよりも「A」「B」「C」「D」の部分を先に行うべきということが示されています。

夜の分科会

内容

  • 勉強会初心者の集まりに参加しました
    • ブログを見ると分かる通り、沢山の勉強会に参加している立場で話しました。
  • 伝えた内容は以下の通り
    • Twitterでテスト関係者をいっぱいフォローして、CONNPASSにログインすると、自分の興味があるような勉強会に出会える connpass.com
    • 勉強会で知り合った人を元に、別の勉強会で別の知り合いが出来てくる
    • 懇親会も積極的に出た方が色々な情報を得られる
    • 勉強会の内容が業務に直結することは殆ど無い。ただ、その中から部分的にでも業務に活かせないか考えてみる
      • 業務に直結するようなことを得たいなら勉強会の主催・発表者になった方が良い
      • 今は業務に直結しなくても、近い将来使いそうだなと思う勉強会にも行ってみると良い
    • 勉強会の内容、懇親会の内容は（書いても良い範囲で）ブログとかに書き残してみると良いかも
      • 「勉強会で聞いたことあるなー」と思った時に検索すると、自分の記事にヒットするので思い出しやすい

感想

  • ちょっと自分が喋りすぎた感が…。次からは自重します。

深夜の分科会

  • こんな感じで、深夜2時ぐらいまでテストについて語り合いました。
    • 眠い人は別部屋できちんと寝ています。

内容

  • テスト分析とかCheckingとTestingの話とかしました。

英語なんてこわくない～英語ドキュメントを読んでみよう

スライド

www.slideshare.net

感想

  • 文型って大事なんだなと
    • 言われてみれば、確かにSV部分だけで何となく内容が分かる

60分でわかった気になるISO29119

スライド

www.slideshare.net

感想

  • 新卒1年目の人とか特に組織論のイメージが湧きづらかったかもしれません…
  • ただ、この話ってすごい大事だと思っていて、このことを理解しておかないと、ただ単に与えられたことをこなすだけのつまらない仕事の仕方をすることになっちゃう可能性があると思ってます

探索的テストはじめの一歩

スライド

www.slideshare.net

感想

  • 演習も一緒にやってみて探索的テストのイメージができました
    • 今までアドホックとの違いをイマイチ理解できていなかったので…

質問されない資料にするための4ステップ

スライド

www.slideshare.net

感想

  • エモいプレゼンではなく、きちんとロジカルに伝えられると良いなと感じた
  • また質問する立場としては、もう少し質問者に考えさせる内容を投げかけられると良いという事が分かった
    • ちなみに、このことはWACATEの懇親会で発表者と話していてわかったことです

ソフトウェアテストの最新動向の学び方

感想

  • 夜の分科会のところでも書いたけど、こういう最新動向を知ることで近い将来の自分の立ち位置を何となく想像でき、その結果、次の勉強すべき内容の選択がしやすくなったりすると思ってます。

全体的な感想とか

  • 前回に比べてベテラン組が少なかったということもあり、色々と悩みながら行っていた印象がありました。

  • みんなソフトウェアテスト大好き！

  • 詳しい内容とかは、それぞれのスライドを見るか、にしわきはるなさんの記事が大変参考になります！

haruna.hatenablog.jp

記念すべき #bpstudy の100回目で発表してきました！

野球 勉強会 発表

はじめに

  • タイトルの通り、bpstudyの100回目で発表してきました！

bpstudy.connpass.com

  • ということで、発表内容を紹介しつつ振り返ってみます。（ロッテ寄りの感想多め）

優勝記念！まるごと東京ヤクルトスワローズ

スライド

www.slideshare.net

内容と感想

  • つば九郎、応援スタイル、個性的な選手など、ヤクルト愛を大いに感じる発表でした。
  • 来年はバーネットがいなくなっちゃうけど、その分バレンティンが暴れてくれるやろ…多分
    • アカン、神宮花火大会の火薬が更に増してしまう…（攻守両方の意味で）
  • 館山の3回のTJ手術もすごいけど、ロッテも昨年まで５年連続８度の手術をした男がいるんだからな！

タイムラインでポジろう!!

スライド

www.slideshare.net

内容と感想

  • 試合結果と呟きのポジティブ度は相関するかどうかについての発表でした。
  • 「連敗に関して、古参ファンは慣れているが新規ファンの影響で…」というのはすごい分かる
    • あと、Twitterを利用している分、年齢層が若め→新規ファンの割合が実際のファンの割合より多いのかも
    • 9連敗とかでも「まだ折り返しか…」と思える古参のロッテファンは強いと思ってる
  • 貯金推移だけでなく、貯金増減について示して比べてみると更に何か分かりそう
    • Twitterのポジネガは変動する値なので、貯金推移ではなく、差分を取った貯金増減の方が相関がより出てきそう
  • ロッテファンは9月後半からのポジティブ度の上昇はすごい分かりやすいなと思った

児童書で再確認する野球の楽しさ

スライド

www.slideshare.net

内容と感想

  • まんが『野球のひみつ』の素晴らしさを紹介した発表でした。
  • ルールからではなく、野球の楽しさから伝えるという発想がすごい
    • けど、冒頭が10.19ってどうなんだろう…？
  • 懇親会で実際の本を見せてもらいましたが、表紙の裏に書かれているのが野球ルールではなくボールの構造だったのが面白かった

数字から読む信号機の傾向と精度

スライド

www.slideshare.net

内容と感想

  • 3塁コーチに注目し、指示が如何に正確だったのかを紹介した発表でした。
  • この日一番どよめきがあったであろうスライドがコレ（高代コーチすげえ！）

f:id:nihonbuson:20151225081157p:plain

( http://www.slideshare.net/junssk/ss-56291371/22 )

  • 仮説、検証、考察がきちんと論理だっていた素晴らしい内容でした！
    • 次回はこういう発表をしてみたい！

こんなゴールデン・グラブ賞は嫌だ〜2015

スライド

www.slideshare.net

内容と感想

  • データから判断を行って、本当のゴールデングラブ賞を選ぶという発表でした。
  • 広島#9の備考にアダム・ダン率が入ってて笑った
    • 守備関係ないやん！
  • ロッテの#1が「RFとして肩がヤバい」というのが意外
    • 元投手で強肩だったのがこの選手の印象だったので
    • もしかして弱肩ではなく、送球がブレるとか？
  • ロッテ#47は下のような動画を作っておいてなんだけど、ゴールデングラブ賞を受賞から外すべきという意見には納得してる

www.youtube.com

ファン上がりのフリーライター。そのこれまでのこれから

スライド

www.slideshare.net

内容と感想

  • 発表者がライターになるまでの半生を発表していました。
  • ライターとして中に入れるのはすごい羨ましかった…
  • 大谷翔平本の一部分を1日で書き上げるのも好きだからこそできるものだなと思った。

引き際の美学

スライド

www.slideshare.net

内容と感想

  • 今年引退した選手をタイプ別に分けて過去に引退した選手と照らしあわせて紹介するという発表でした。
  • 30本塁打も放っていて「王貞治のバッティングが出来ない」と言った王さんはすごいなと思った
    • ロッテはマリンに来てから30本放った日本人選手がいないんやで！
  • 金田正一の引退の事情は初めて知った。
    • てっきり、400勝で身を引くと決めていたものかと…

俺の心にぐっときた野球同人誌

スライド

www.slideshare.net

感想

  • 発表本番、不手際があってすいませんでした。
  • 少しでも同人誌についての印象が変わってくれれば良かったです。
  • こういう感想が発表者として一番嬉しい…

  • ちなみに技術系の同人誌もいっぱいありますよっと

nihonbuson.hatenadiary.jp

  • 次回のコミケは12月29日から31日にあるので、野球同人誌または技術系同人誌を是非探してみてください！
    • もちろんそのまま参戦せずに、カタログを買って注意事項は読みましょうね！