WACATE2019冬「あなたの番です」参加レポート1日目!

ソフトウェアテスト業界にはお馴染みのWACATEにやってまいりました!
f:id:yuki_shiro:20191214231734j:plain
若手(若手じゃなくても)が手を動かして学ぶ2日間合宿形式のワークショップです!さあ、加速できるかな?

BPPセッション

(はるにゃんさん)
何も言わない。これを見てくれ。
f:id:yuki_shiro:20191214231620j:plain
石油王に敬意を表して、私にしてはグラフィックなグラレコになりました。
BPPをとるために戦略的に考えて、インパクトに残るポジションペーパーにしているのかの過程を説明してくれて、すごく分かりやすかったです。人生初の登壇だったそうですが、間の取り方もうまくて何度も爆笑が巻き起こったセッションでしたw
テストラジオでもBPPセッションの裏話が紹介されているので、ぜひこちらも聞いてください!
testradio.fm

業務でも活用できるソフトウェアテストの7原則

(ブロッコリーさん)
資料やセッションの経緯は、ブロッコリーさんがブログで公開してますので、ぜひこちらでどうぞ。
nihonbuson.hatenadiary.jp

感想

ワークは、実際にテストの現場でありそうな会話から、テストの7原則に反してそうなものを見つけるという内容でした。ワークのまとめで言及されていたのですが、テストの7原則を理解した上で、「7原則があるからと言って、正義を振りかざすべきタイミングを見極める。原則に沿えない場合もあるので話を聞いて障壁を取り除く」ことができるのが重要だと感じました。次のワークでも感じましたが、相手を詰めても前に進めないので、7原則は、背景などを話した上で「じゃあどうするか」を考えるための材料にするべきものですね。

物語を想像して問いを立ててみよう

(かおりっとさん)
資料はこちら!
speakerdeck.com
「問い」をうまく活用して、相手の考えていることを紐解いていくセッションでした。
ワークで実施した内容は次の通りです。

  • 相手に何かを思い浮かべてもらう
  • 相手が思い浮かべたものを当てるために、「問い」をしていく。ただし「問い」で使えるのは、Yes/Noでこたえられる質問のみ。
  • ワークでは時間が限られるため、実行委員が用意してくれたテストに関するキーワードの中から「答え」になるものを選ぶ
  • 質問は5個まで

実際にやってみると、色々な想定外が発生し、思った以上に難しかったです。

  • 「問い」を立てるって難しい
  • 自分が「問い」で使った言葉で相手が同じものをイメージしているとは限らない
    • 「イベント」という言葉でWACATEやJaSSTを想定していたけど、相手は「レビュー」などの粒度で想定していた、という例があった
  • キーワードの中から答えを選ぶ形式で、選んだものが同じ事態が発生。同じものを選ばないだろうというバイアスが働き、答えを当てられなかった
感想

問いって本当に難しいなーと感じました。問いはうまく使わないと、相手を詰めてしまう凶器になりかねないとは思ってます。ワークの短い間でも、背景のずれやバイアスがかかったりとかを、ちゃんと意識できる状態で体感して、「ここまでずれるものなのか!」という実感が持てたのは大きいな、と思います。
「自分たちのシステムを使う人はどういう人だろう?」と考えるときとか、何かの認識ずれでバグが発生してしまった時のふりかえりとかで「問い」が使えそうな気がしています。

形式手法ってなんだろう?

(べにさん)
speakerdeck.com
形式手法は数論理学に基づいた手法。

  • 仕様を厳密に書ける、明確に意味を一つに絞れる
  • プログラミング言語そのまま? いいえ、実装ではなく仕様を記述することが可能です

形式手法のいいところ

  • 仕様を厳密に書ける
  • 実装ではなく仕様を記述できる
  • 実装前に検証が可能
  • 何が複雑なのかを把握できる
感想

形式手法は、基礎知識がないと難しいと感じました。例を真似すれば書けはするのだけど、自分が何を書いてるのかわからなくて同じチームの方に解説してもらいました。チームメンバに助けてもらえるの良かったです。ただ、すみません、形式手法は私には早かった。。。あまり理解できてないので要復習です。。

ディナーセッション、夜の分科会

美味しいごはんを食べたり、飲む人はお酒をいただきながら夜23時までテストについて語り合う変わり者たちの宴です! 夜の分科会では、よしたけさんのテスト観点共有会のセッションに参加しました。電話番号に関する観点を出し合ったのですが、みんなで観点を出し合うと、自分にはない観点をもらえたり、相手の出した案に乗ってそれをより深められたりというのが面白かったです。
成果物はこちら。
f:id:yuki_shiro:20191217204142j:plain
テスト観点共有会の詳しいやり方は、よしたけさんのブログをどうぞ!
yoshitake-1201.hatenablog.com

おまけ

WACATEはご飯も美味しいですよ!
f:id:yuki_shiro:20191217204108j:plain
f:id:yuki_shiro:20191217204122j:plain
三浦半島の海の幸を堪能する意味でもぜひWACATEへ!

テストマネジメントツールを適用する前に考えること

この記事は、ソフトウェアテスト Advent Calendar 2019の10日目の記事です。
qiita.com
前の記事はこちら。
halspring.hatenablog.com
9月にいくつかテストマネジメントツールについての勉強会に参加して、考える機会が多かったので、ちょっとアウトプットしてみました。参加したイベントはこちら。
connpass.com

テストマネジメントツールとは

テスト管理ツールは、主にテストケース、テスト実施結果(OK/NG/再実施など)、進捗、実施履歴などをWebで管理するツールです。要件管理はあるものとないものがあります。呼び方は「テストマネジメントツール」だったり「テスト管理ツール」と呼ばれていたりします。

導入時に考えること

テストマネジメントツールに限らず、ツール導入の際にはいくつか事前に考えておくべきことがあります。

  • ツールで解決したい問題は何か?
  • ツール導入でメリットは得られるのか?(デメリットの方が大きくなることはないか?)
  • ツールが課す制約がこれまでのテストのフローを妨げる場合、それを許容できるか?
    • 導入時には「ツールで解決したい問題」に目が行きがちですが、「ツールが課す制約」についても考える必要があります。これについては後で述べます。
  • コストはどのくらいか?
    • 初期費用や月額費用
    • 導入にかかる教育コスト
    • 運用コスト(手順を整えたり、オンプレやOSSの場合は自前でメンテナンスするコスト)

導入してメリットがある条件

ツールのメリットを享受するための前提はあまり触れられてないなと思ったので、自分なりに整理してみました。なお、テストマネジメントツールを使わない場合、テストケースの管理はExcelスプレッドシートで行われることが多いので、比較対象はスプレッドシートとします。

複数人で使用すること

利用者が一人であるなら、次の理由からスプレッドシートでよいと思います。

  • 管理対象とするテストケースや結果が、自分で把握、説明できる分量に留まると予想される
  • すでにスプレッドシートで運用しているなら、学習コストや利用フローの整備、ツールの利用料などのコストを払うのに見合わない
  • 古のExcelの場合、複数人で操作してファイルが壊れることを想定しなくてよい(それでも「予期せぬエラー」で壊れる場合は想定しておいた方が良い)
テストケースの再利用を前提としていること

テストマネジメントツールは、テストケースの「普遍的な部分(実施手順、確認内容など)」と「テスト毎に毎回変わる部分(実施予定日、実施予定担当者など)」を分けて管理できます。普遍的な部分を資産として持っていて、そこからテスト実行ごとに「テスト毎に毎回変わる部分」を付加して、「テストインスタンス」を生成するイメージです。湯本剛(@yumotsuyo)さんの資料の説明が分かりやすいので、引用させてもらいました。

資産化しておくことでテストケースの複数回の利用を容易にしているのが、テストマネジメントツールの利点であるため、単発でしかテストケースを使わないのであれば恩恵は大きくはないと思います。
テストケースを再利用することを前提とすると、テストマネジメントツールの恩恵を受けやすいのは継続して開発、リリースする案件で使うことだと思います。条件に合う案件は、自分の観測範囲では自社サービス、ツールの開発案件が多い印象です。
単発の案件であっても、同じような案件が複数あるのであれば、観点とか項目といったナレッジの蓄積を目的として使うのは意味がある気はします。

ツールが課す制約を許容できるか

制約というちょっと強い表現を使いましたが、ツールを導入することによって今までと作業フローが変わったり、不便なことが出てきたりするが、それを許容できるか、という観点です。これ以下の内容は、私の主観が強いので当てはまらない場合もあると思います。

前提

私が触れたことのあるテストマネジメントツールは、Squash TM、TestRailの2つ、あとはKazu Suzuki(@kz_suzuki)さんのブログでPracti Testを少し眺めたくらいです。
www.kzsuzuki.com
そのため、それら2つ(+1つ)をベースにして、スプレッドシートでの運用と比較しています。
スプレッドシートでのテストケースの運用時には、「ID、テストケース名、手順、期待結果結果、実施予定日、実施予定担当、実施結果」を1行で管理しているものと仮定します。

テストケースの一覧に見るテストマネジメントツールスプレッドシートの比較

テストマネジメントツールスプレッドシートでは、設計の思想が違います。テストマネジメントツールは、もちろんテストに関するあれこれ(要件、テストケース、実行結果など)の管理を目的として作られたツールですし、スプレッドシート表計算を主眼として作られたツールです。
テストマネジメントツールスプレッドシートでテストケースを作成する場合、テストケース一覧の表示内容、運用に差が顕著に出ていると思ったため、次の項目について比較してみました。比較したのは、「前提」でスプレッドシートでの運用時に管理対象として仮定した「ID、テストケース名、手順、期待結果結果」とプラスアルファです。「実施予定日、実施予定担当、実施結果」については、テストマネジメントツールの場合、テストケース作成の段階で管理しないため省略しました。

比較対象 テストマネジメントツール スプレッドシート
ID
テストケース名
優先度
手順 ×
期待結果 ×
表示項目のカスタマイズ ツールで表示対象に設定できる項目のみ 追加が可能(組織でテンプレートとして定められている部分を除く)
一覧に表示できる行数 制限あり(TestRailでは2000行だった) スプレッドシートの限界までは理論上可能

凡例:
〇:デフォルトで表示対象、記載対象とされている
△:デフォルトではないが、多くの場合表示/記載あり
×:なし(表示できる対象として設定されていない)
  補足:テストケース名から参照的に手順、期待結果を表示することは可能。ただし選択した1ケースのみ。

テストマネジメントツールの導入で変わる部分

スプレッドシートでの運用している時と比べると、変わる点は次のようなものがあると考えています。

  • 手順、期待結果をレビューする場合、テストマネジメントツールではテストケースの一覧上でできない
    • 手順、期待結果を含めたCSVなどでのエクスポートは可能
    • ただし、ツールによってはテストケース名の一覧と手順・期待結果の一覧は別のシートで出てきて多少見づらい
  • テストケース名で、テスト内容の分かりやすいサマリを表現することが求められる
    • 期待結果が一覧上でも見えていれば、テストケース名を多少適当につけていても、テストの意図を補完できたが、それができなくなる
    • スプレッドシートでもテストケース名を分かりやすくつけていた場合は従来と変わらない
  • 一覧に表示する項目をカスタマイズできない
    • スプレッドシートだと、運用上の良し悪しは置いておいて、欄外にメモ欄など追加できたが、ツールではできない

上にあげた例では、スプレッドシートでの運用に問題があるものもありそうですが、ツールの導入によって、今まではできていたことができなくなることは考慮する必要があります。

まとめ

テストマネジメントツールは、ツールのメリットを出せる状況下で使えば、効率化を素晴らしくサポートしてくれるものだと思っています。ただ、ツールの導入には利点だけでなく、従来はできていたことに制約がかかるパターンがあるので、制約を考慮した上でもなおツール導入のメリットがあるのかは考える必要があります。

福岡で小早川隆景、乃美宗勝の足跡巡り+柳川で立花氏巡り

JaSST Kyushuに行くついでに前日ちょっと早く福岡入りして、私の好きな戦国武将である小早川隆景乃美宗勝ゆかりの地を巡ってきました。

宗勝寺

乃美宗勝のお墓のあるお寺です。
f:id:yuki_shiro:20191128132838j:image

福岡の交通網が集まる天神からバスで20分程度で到着します。近所には毛利氏の勢力と大友氏の勢力が攻防を繰り広げた立花山城があります。宗勝公は朝鮮出兵時に病を得て、九州に戻ってきてこのあたりで亡くなったと伝わっています。ごく普通のお寺なので、本堂に軽く参拝してから宗勝公のお墓へ。

f:id:yuki_shiro:20191128133834j:image

本堂左手の細い山道を通って向かいます。地蔵堂らしきところの裏手を通ってさらに山の中へ。

f:id:yuki_shiro:20191128133934j:image

落ち葉がこんもり積もり、ところどころで倒れた竹が邪魔をしてきます。案内板が順路はこちらと示しているし、道はこれ以外にないので乗り越えて進みます。ちょっと愛を試されてる気分のする道でした。雨が降ってたら引き返してたかもしれませんw曇りぐらいで本当によかった。あと夏だと虫が多そうなので、冬でよかったです。

ほどなく重臣のお墓へたどり着きます。
f:id:yuki_shiro:20191128141046j:image

この奥に宗勝公と奥様のお墓がありました。f:id:yuki_shiro:20191129015053j:image

向かって左のお墓に「宗勝寺殿」「勝運」の文字がありますので、こちらが宗勝公ですね。f:id:yuki_shiro:20191129015117j:image

なかなか福岡までくる機会がないので、今回お参りできてよかったです。基本的に曇ってたのですが、宗勝公のお墓の前に来た時にちょうど晴れ間が来たのも嬉しかったです。偶然晴れただけとは思いますが、なんか「よく来たな!」って歓迎された気分になれました。

筥崎宮

日本三大八幡といわれる筥崎宮にお参りしてきました。こちらは小早川隆景によって楼門が造営されています。

f:id:yuki_shiro:20191129015149j:image

元寇の際に敵国の調伏を祈ったことから「敵国降伏」の額が掲げられています。筑前は豊臣政権期に小早川が領有していたので、こちらの筥崎宮太宰府天満宮に隆景公の足跡がちょこちょこ見られます。今回は太宰府まで足を延ばせませんでしたが、また太宰府にも訪れたいと思います。

柳川藩主立花邸御花

筥崎から足を延ばして柳川まで行ってきました。

f:id:yuki_shiro:20191129015216j:image

ほぼ佐賀の隣なので、筥崎から移動すると1時間強かかります。正直1日に詰め込みすぎな気はしましたが、目的は好きな戦国武将である立花宗茂ゆかりの資料館を見たり、ウナギのせいろ蒸しを食べたりすることでした。

柳川藩主立花邸御花は、明治維新以降に華族となった立花家の邸宅が公開されており、同じ敷地内にレストランやホテルも建っています。現在も立花家が経営されています。旧大名家、華族の多くが、明治維新や戦後に資産を手放されたことを考えると、現在も経営されているのはすごいことなのでは、と思います。

さて正面から入ると、瀟洒な洋館が迎えてくれます。

f:id:yuki_shiro:20191129015235j:image

敷地内のレストランでウナギのせいろ蒸しをいただきました。レストランのナプキンに立花家の家紋が入っていて、この時点でテンションがあがります。


f:id:yuki_shiro:20191129015253j:image

せいろ蒸しは蒸し上がるのにちょっと時間がかかるので、その間に洋館内部を見学しました。伯爵家にふさわしい格式のために、意匠に凝っているところや、家族だけが使うためシンプルに作られているところなど丁寧に解説されていて、興味深く見学できました。柳川名物のさげもんが飾ってあって、写真を撮れるスポットなんかも準備されてました!

f:id:yuki_shiro:20191129015318j:image

さげもんの拡大したものがこちら。色とりどりでとてもきれい。

f:id:yuki_shiro:20191129015330j:image

洋館部分と接続して和風建築も建てられており、そこからはお庭が眺められます。縁側、とよぶにはちょっと規模が大きい気もしますが、縁側もあるのでのんびり庭を眺めながら一息付けます。

f:id:yuki_shiro:20191129015410j:image

別の建物からお庭全体と和風建築部分を眺めてみました。

f:id:yuki_shiro:20191201235211j:image

見学を終えて戻ると、ちょうど蒸したてのせいろ蒸しがやってきました。せっかくなので奮発して、う巻きとうざくのついたおすすめセットにしてみました。


f:id:yuki_shiro:20191129015436j:image

蒸してあるのでウナギがふわふわ、たれのしみ込んだご飯も美味しくてペロっと食べてしまいました。せいろの下部分は全部ご飯なのでかなり量はあるんですけどねwしっかり蒸しあげてあるためか、ごはんも最後まで温かい状態で楽しめました。

敷地内にある立花資料館にも行ってきました。立花宗茂所蔵の鎧や江戸期の大名としての立花家に伝わる華やかな大名道具が見ごたえありました。

特に宗茂所蔵の鎧は、一度見てみたかったので良かったです。腕の部分は全部鎖帷子風になっていて、シンプルで動きやすそうな印象を受けました。色々な逸話から、いざとなれば自分も前線に出て戦うタイプの方という印象があるので、何となく納得感のある鎧でした。宗茂公は70代で島原の乱に出陣して、有馬城の一番乗りをされた方ですからね。

個人的に小早川隆景立花宗茂は、大河ドラマの主人公になってほしい歴史人物のNo.1、2なので、弾丸旅行でもこの二人にゆかりのある地を巡れてすごくよかったです!

JaSST '19 Kyushuに参加してきました!

JaSST Kyushu初参加!今回はテーマなし、とのことですが、緩やかに関係性とチーム、開発とテストのお話です。
f:id:yuki_shiro:20191129231408j:plain

「チケットシステムで理解するあのチーム」

(関さん、miwaさん)
あのチームの紹介

  • テストを中心とした反復開発のチーム、20年近く続いている
  • セーフティクリティカルのシステムを開発している

反復開発

  • V字モデルを何度も何度も繰り返すやつ

すべての活動をテストする

  • 実装、仕様、要求、作り方
  • テストは終端ではなく発端
  • すべての活動を「くり返し」できるように

あのチームの特徴

  • 非常に大きい
  • 組織変更と関係なく長生き
  • Wikiの規模は約9万ページ、毎日1000ページが編集
  • チケットシステムは非常に長生きしている(結果として長生きになっただけ)

1. チケット編:チケットは仕事の一つの単位
2. インデックス編:大量にあるチケットをどう扱うか
3. 朝会編:どう観察しているか

1. チケット編
  • 前提:ワークフローが変わるもの(変化を促す、邪魔しない)
  • サマリ:一行で表す「できること」、自分たちが分かれば十分、分からなかったら誰か突っ込むからいいかな
  • チケットの種類
    • story、bug:触って確かめるテストを書く
    • task:システムの変化がないもの
  • 状態
    • openとcloseだけ
  • 見積もり
    • あと何日かかりそうか、何日かかったか
    • 順調なのか、困っているのか、いつ試せるのかにフォーカス
    • あのチームでは、納期を約束させたり速度を競ったりはしない
  • 忍者式テスト
    • すべてのチケットにそれを確認するテストを書く
    • 毎日テストする、テストが増える
    • 試した人結果を記録
    • 履歴のすごいものは2003年のチケットが見直されたりする
    • テストスイートを日単位で全部網羅するのは不可能
    • →、1ヶ月とかで見たら網羅できるように今日のテストスイートを出せるアルゴリズムをシステムに組み込んだ
2. インデックス編

チームがどの製品、バージョンに集中してるかわかる

3. 朝会編

朝会で考えること

  • 「この製品を変更するべき」かの表明、どう変更しようと思っているかが問われる
  • 朝会は45分、延長なし
  • 朝会で使われるインデックスページは壁と付箋に似ている
    • 物理ではできない、過去のチケットの更新とか過去のチケットを見る習慣ができる
感想

チケットシステムを通して、あのチームのやり方やどうしてそうなっているのかがわかる紹介でした。チームが必要としている状態にフォーカスしていく様子が分かって、結果として長生きしていることが納得できました。チケットシステムの機能を、あえてチームに必要なことに絞って、他への報告に必要な機能を削いでいるのがすごいなと思います。「他への報告が求められないのは、チームがしくじってないから」というあのチームがカッコよすぎる。

「フレーズで体験するあのチーム」

問題を解決していく最中に起こる「小さな会話」が「良いチーム」を作るのではないか
フレーズ

  • 「うまくいったらどうなるの?」
  • 「見せて」
  • 「ワザと?」
  • 「わかんない」
「うまくいったらどうなるの?」

どこまでうまくいってて、どこから分からないかが明確になる。ゴールが明確になる。ゴールが明確になってない場合は、ゴールが明確になってない状況が分かってみんなで解決できる。どこまでも間違ったまま行くことがなくなる。
「うまくいったらどうなるの?」ポジティブな問いかけの言葉。またテスト可能。「なんでこれやるの?」だと上からになりがちだし、答えづらい。

「見せてー」

製品でもコードでも現物を見ることを大事にしている。見ると放っておけなくなる。みんなの自分事になる。
途中のものを見せるのがストレスになる人もいる。ただ、印象としては見せた方が楽になる人の方が多そうに見えるらしい。
※JaSST Kyushu実行委員ははZoomの画面共有で「見せてー」をやっているそうです。

「ワザと?」

制約や思い込みを取り外して考え始める。本来あるべき姿や理想。
おかしいと思っているけど、おかしいと言いづらいときや、混乱しているように見えるときに使える。
理想的な対策ではないけど、時間内では許容範囲な対策などを行い、その後「時間内では許容範囲な対策」だったことが忘れ去られた場合とかに使える。
「ワザと?」はチームに対する問いかけ。自分自身への問いかけにも使える。本当は自分は気に入らないけど、他からの強い要望があった場合とかに本音を言いやすくなる。

「ワザと?」はちょっとキツく感じる言い方なので、ニュアンス同じでもっと柔らかい言い方ないかなー、とつぶやいたところ2案いただきました。

  • @shimashima35さんから「それは意図通り?」
  • @YasuharuNishiさんから「なにか思うところがあったりしたんじゃない?」
「わかんない」

瞬時に自分の違和感を伝えられる。なぜわからないかをみんなが一斉に考え始められる。たいていの場合、課題(問題)が見つかる。
みんなわかってるけど、わからないときなどに使える。
このフレーズを使えるまでには時間がかかるので、新人が入った場合は、3か月くらい一人にさせないとか、「自分がわからなくて自分の時間を無駄にすると、チームの時間を無駄にする」意識の浸透などの前提が必要そうな印象を受けた。

感想

最後の「明日からできそう?」という問いかけには、「見せてー」とか逆に「これ見てー」あたりはできそう、「ワザと?」はニュアンスは分かったけど自分やチームになじむフレーズにするにはちょっと時間が必要そうかな、というのが今のところの自分の答えです。チームで成果を出すということに、チームがフォーカスする文化と一体のフレーズな気がするので、自分のところの文化になじませるには、自分の言葉や言い方をできるよう調整が必要な気がしてます。案をいただいた2つも、誘導尋問にならないようには注意して使おうと思ってます。

「オンラインコミュニケーション時代における日本語文章の書き方 ~チーム内とチーム外のコミュニケーションで気をつけること~」

町田さん
日本語の書き方に取り組むようになったのは、仕事でのレビューがきっかけ。日本語が好きなので、間違いが気になってしまう、自分が気になることを共有することでレビューの負担を減らしたい、もきっかけ。
文書は残せる点がメリットだが、間違うと間違えたまま残るのでディスコミュニケーションの元になる。
少人数チームによる開発では不完全な文章でも伝わるなどで、文章を書く機会は減る。ただ、付箋やホワイトボードを含め、正しく書くことの重要性は高い。

町田さんの3つのポリシー

1.読み手の立場に立つ
2.一字一句に魂を込める
3.できるだけ書かない
 →コードを書かなければバグは生まれない
 

心がけていること7点
  • 読み手によって求めることが違う
  • 読み手によって好む文章が違う
  • 背景を伝える
  • 簡単な言葉を使う
  • ごちゃごちゃした文章(文書)は読む気がなくなる
  • 文章は読まれない
  • 簡潔に書く
実践している7つ+1つ
  • 何度も読み返す
  • 真似をする
  • 意味を調べる
  • 類義語を調べる
  • 校正ツールを使う
  • 頭を冷やす
  • 俯瞰する
  • 英語に翻訳する
    • 翻訳して意味が通じなければ、ややこしい日本語
こだわっている7つのこと
  • 係り受け
  • 主語
  • 長文
  • 指示代名詞
  • 否定文
  • 専門用語
  • 助詞
感想

オンラインだろうと文章を書くことは必要なので、分かりやすい文章を見直すきっかけになりました。実践している7つのところで、プラスとして言われた英語に翻訳する、は確かにそうだなと感じました。翻訳しにくい日本語は、その時点で長文すぎたり、主語が抜けてたりして、実際読みにくいです。場面に応じて、町田さんが気を付けてることや実践していることを真似させてもらいます!

ふりかえりタイム

ふりかえりタイムをとってもらえるのが理解の促進になって、ありがたかったです。フレーズのところの質問で「NGワード」についての質問が出たのがすごくよい質問で、自分には思いつけなかったし、あのチームがフォーカスしてることをより深く知れるきっかけになりました。「生産性」とかはあいまいなんですよね。

おまけ

実行委員の方が周辺のランチマップを公開してくれたり、テスト酒場の方が前夜祭と懇親会を企画してくださったりと至れり尽くせりでした。どれも美味しかったです!
前夜祭の二次会で食べた「土竜が俺を呼んでいる」の梅塩とんこつラーメン。
f:id:yuki_shiro:20191201232123j:plain
ランチの「とんかつ若葉」さんの低温でじっくり上げたとんかつ。
f:id:yuki_shiro:20191129231446j:plain
懇親会の「だるま屋」さんのごまサバ。刺身もほかの料理もすごくおいしかった!
f:id:yuki_shiro:20191129231454j:plain

登壇者、実行委員、参加者の方々ありがとうございました!関係性とチームについて改めて考える機会をいただきました!

第14回Ques「Agile Testの今」に参加してきました

11/15(金)に行われた第14回Quesに行ってきました!いつもいけてる話題ですが、今回もいけてる話でした!
ques.connpass.com

ソフトウェアエンジニアと共にテストを作るチームでの、テストエンジニアの関わり方(越中谷さん)

資料はこちら。
speakerdeck.com
ちょっと遅刻してあまり聞けてないのですが、ベースとなっている部分は、別の日に行われた「SPEEDA Testing Day」と同じなのでそちらのメモを貼ります。
f:id:yuki_shiro:20191117222619j:plain

感想

自動テストが仕様になっているのいいなーと思いつつ、それをキープするのはきっと地道な作業なので、きちんと定着してるのがすごいと思いました。仕様のやりとりや最新をどうキープするかは目下の悩みどころなので、テストできっちり押さえてるのすごく素敵です。ハッピーパスはきっちりテスト項目が押さえてます、くらいからなら取り入れやすいかな。

顧客価値を安定的に届けるために―Rettyにおけるアジャイル開発とQA改善の取り組み(常松さん)

資料はこちら。
speakerdeck.com
メモは二枚になってしまいましたが貼っておきます。
f:id:yuki_shiro:20191117222640j:plain
f:id:yuki_shiro:20191117222646j:plain

感想

課題の見つけ方とそれぞれの対処方法がすっきりまとめられていて、とても聞きやすかったです。「ツールがあるとツールの使いこなしに目が行く」とおっしゃってたのが印象的でした。確かにツールがあるとツールで管理できない部分は意識に上がってこないのですよね。自分のチームでも部分的に物理カンバンちっくな内容を取り入れてみてるので、すごく共感して聞けました。いい文化は残しつつ、地道に文化を作っていくは、自分のチームでもぜひ取り組みたいです!

今回も参考にしたいお話が色々聞けて、本会から懇親会まで楽しめました!登壇者、運営の皆様ありがとうございました!

JSTQB Advanced LevelのTM/TA/TTAの違いについての理解

2019/11/04にNaITE(長崎IT技術者会)さん主催の勉強会でLTしてきました。
nagasaki-it-engineers.connpass.com
JSTQB Advanced Levelの受験をする中で、TM(テストマネージャ)、TA(テストアナリスト)、TTAテクニカルテストアナリスト)って、それぞれどんな役割を求められてるのか、という点は何となくはわかるものの、何となくしかわかってなかったので言語化してみたものです。

発表資料

資料にもシラバスの目次を掲載しましたが、章の学習目安時間が長いところ(=ページ数の多いところ)が各ロールがメインで注力する分野になると思います。自分が経験のある分野が多い方が取り組みやすいかな、というのが受けてみた感想です。

なぜTM/TA/TTAが分かれているのか

懇親会で話に出たのが、この疑問です。推測ですが、JSTQBの翻訳元であるISTQBがヨーロッパで設立されたからではないかと思います。
契約時にJob Descriptionで何を行うのか細かく定めるので、TM/TA/TTAがそれぞれ何を行うのかきっちり定義されています。求人時もTM/TAでまったく別の求人票となっています。日本の場合はQAとしての求人で、役割はきっちりとは定義されてないように感じます。
そのため、日本でQAをやっていると普通に一連のものとして行う業務が、JSTQBの定義としてはTMとTAという別職種のタスクを同時に行っているという状態になったりもします。JSTQBの試験問題にも、TAの試験の選択肢の中にTMのタスクとして定義されてるものが紛れていて「普通に業務でやっているので、これは正しい内容だ」と思ったら、シラバスの定義的にはTAのタスクではないので不正解、というものがありました。

JSTQB Advanced Levelを受けてみたいけど、どこから挑戦したらよいかわからない方に参考になれば幸いです。

ButterflyEffect#2に行ってきました

「すごい人が話を聞きたいと思う人の話はすごいはず」をテーマに開催されてるイベントです。
butterfly-effect.connpass.com
当日のまとめはこちら。
togetter.com

「そーですねー!」のコール&レスポンスなど「いいとも」的な小ネタが満載でおもしろいw
今回のゲストはきょん(@kyon_mm)さん

きょんさんが最近取り組んでること

まずは、きょんさんが最近取り組んでること、界隈で話題になってることをざっくり紹介してくださいました。

  • ランダムロール
    • POやSMといった固定ロールをランダムに。PO、SMをくじびきで。
    • 相手の仕事はやってみないと分からない、という発想から
  • 15minスプリント
  • KPT
    • KPTにかぎらず書き出す
    • もやもやがProblemに言語化できる段階では遅い
    • なんでも書いていい
  • フラクタルスプリント
    • エンジニアリング、デザイン、アート、サイエンス
    • スプリントの最後の時間はアートやサイエンスに使う
  • 受動的な時間管理
    • スプリント開始、終了直前、終了をチャイムで管理
    • 時間は教えてもらうくらいでちょうどいい
何がどうしてこうなったか

15minスプリントが生まれた思考の源流を探るべく、幼少期からのきょんさんの生い立ちが紹介されました。

  • スプリント時間を短くする。アイディアを簡単にする
    • Googleをヒントに桁を変えるとアイディアが出やすくなる
    • 一番単位を変えやすいのスプリントじゃない? という発想らしい
  • 15minでできること
    • 1つ目 実現可能かググってみる
    • 2つ目 試して動かしてみる
    • 3つ目 要件に合うか試してみる
  • 3スプリントでこれだけ
  • 4つ目のスプリントは「スタバ行ってきます」というのもアリ
  • ずっとゴールに集中しているのはおかしくないか?
    • 目的のない行動も取り入れなければならない
    • 1つの目的にだけ従属すると生き生きできない
  • スプリントの最後の一コマはアートとサイエンスの時間
  • 考えることを減らす、知らないことを想像するのを減らす
    • ランダムロールなどは本当は人にやさしい。
  • すごい人を見ると同じ土俵で勝負できない
    • その結果人間をやめる
  • 個々の個体の生命があるのに、全体として一つの自我としてふるまえる
    • 軍隊アリとか
    • ある種のアリは、境界が接すると一方の女王アリが自殺する、種としてはその方が良いため
  • コーチングの際に大事にすること
    • ポジショントークをする。この立場から見るとこう見える、を貫き通すと多様性が生まれる

次回はすえなみ(@a_suenami)さんだそうです。

感想

小ネタあり、きょんさんがどうしてそういう思考になっていたかの掘り下げありで面白かったです。桁を変える話はなるほどなーと思ったし、人間をやめようとして人間に近づいたり人に優しくなるのが興味深いですね。普段のプレゼン形式よりパネルディスカッション形式だと、人柄が出やすいのかなとちょっと思いました。パネルディスカッションというよりトークショーっぽい感じもして楽しかったです。
登壇者、運営の皆様、ありがとうございました!