WACATE2018 冬に行って来ました②
WACATE2018 冬に行って来た感想2回目です
感想1回目:WACATE2018 冬に行って来ました① - シブヤの日記
※WACATEというのはソフトウェアテストの若手向け合宿です。
開催内容等は以下を参照してね
WACATE2018 冬 プログラム内容
https://wacate.jp/workshops/2018winter/program/
Toggatter ♯WACATE
https://togetter.com/li/1298468
<2日目 (12月16日)>
○モーニングセッション:(主に)Agile Testing Days 2018 参加レポート
・海外の学会・カンファレンス・シンポジウム、最先端のものに触れられ、感動が得られたり、モチベーション上がる。
・自分が発表しなくても参加者同士の会話を通じてフィードバックを得られる。
むしろ、会話がなければ得られるものは少ない。
ただ行って聞いてくるだけなら論文読めばいいだけ。
→これは、国内のシンポジウムとかでも一緒かもと思った。
でも、知識や思考が追い付いてないと、その場での会話はすぐにはできない。
文字よりプレゼンの方が身につきやすい人がいるし、その人にあった参加目的があっていいとも思った
○本当に初心者の方に送る「そもそも自動化とは何か。自動化するために必要なスキルとは」について話すセッション
・自動化したらコストが減るって思う人がいるらしい。
導入にお金かかるのは何でもいっしょじゃないのか?と思って、不思議だった。
でも、実際のコストはやってみないと想像つかないなと思った。
・自動化できるもの、しないものがある
・自動化は現場によって変わるものが沢山あるけど、変わらないものもある
「AutomationTest.SSF」自動化スキル標準
・これから始める場合
まず、自分のタスクで自動化、スモールスタート、動かして成功体験を得ることが大事とのこと
なにごともそうだなぁと思いました。
・実現可能かどうかより、「自動化したいかどうか」って話があって、
これは、仕様決めたり課題の対策考える時と一緒だなって思いました。
できるかどうかで考えちゃ、あんまいいものができない。
○コードカバレッジを知ろう!
・今の業務で関りがないので、こうゆうの出てくると嬉しい
コードカバレッジの種類
・ステートメントカバレッジ:C0、命令網羅
-命令文(図形)を1回通っていればOK.分岐先は通らなくてもOK
・コンディションカバレッジ:C2、条件網羅
-入力にTrueとFalseを入れたもの
-ルートの網羅は考えなくてOK
-言語の特性によって、&条件の場合に左辺が評価されない場合があるので、その場合は、適切にケースを増やす
・ブランチカバレッジ:C1?、分岐網羅
-判定の真偽を網羅
・デシジョンカバレッジ:C1?、 判定条件網羅?
-制御フロー図を描いた時のブランチ(枝)を網羅
※ブランチカバレッジとデシジョンカバレッジは
どちらも100%網羅の時には同じ結果になる
※ブランチカバレッジとデシジョンカバレッジについては、
あきやまさんのツイートからまとめています。
・試験にでるとごっちゃになるやつ。
○自分のためのチェックリストを作れるようになろう
・チェックリストを使うという概念があんまりなかった
・テストケース(テスト手順?)とチェックリストって似てるかも
・悪いチェックリスト:書いてある内容が不明瞭。
・よいチェックリスト:重要なものしか書かない。手順はチェックリストに含めない
○50分で講師になれそうな気になるASTERセミナーテキスト
・「ASTERセミナーテキスト」
FLシラバスと、目次が同じ。でも、図解があってみやすい
図解があるゆえ、シラバスよりも詳細説明がすくない
・FLシラバス読むとき、一緒に読むとよさげ・・・?
・研修を行う場合、目的、対象を明確にするといい
また、対象の人たちの分かる言葉に、用語をマッピングするとわかりやすい
(ただし、用語の置き換えはNG。公式の用語を知っていることに意味がある)
○ライブコーディングでわかるテスト駆動開発
・テストコードを書いて、失敗させてから、失敗しないように製品コードを実装する
・テストの観点に、テストエンジニアの視点があるといいかもと言っていた
・情報量が過ごすぎて、脳内の処理を追い付かせるのが大変でしたが、とても面白かったです。
・夜の分科会の体験も楽しかったし、TDDの環境作りたい。
○翌日の話
・体力持たなくて、とても仕事なんか行けなかった。
10時間眠った。
次から有休申請をあらかじめ出すようにしようと思いました。
以上です。
WACATE2018 冬に行って来ました①
WACATE2018 冬に行って来ました
今回の冬、とっても行ってよかったです。
※WACATEというのはソフトウェアテストの若手向け合宿です。
開催内容等は以下を参照してね
WACATE2018 冬 〜C’mon baby ジドウカ〜 開催概要
https://wacate.jp/workshops/2018winter/
WACATE2018 冬 プログラム内容
https://wacate.jp/workshops/2018winter/program/
Toggatter
https://togetter.com/li/1298468
■自分のために、内容を振り返ってみる
セッションごとに、感想を書きます。
※ダラダラと長いです※
※長いので、2回に分けます※
2回目:WACATE2018 冬に行って来ました② - シブヤの日記
<1日目 (12月15日)>
○オープニング
・WACATEってなんなの?
みんなこの二日間どんな気持ちでいたらいいの?
ってことを中村さんが、優しくお話してくれます。
・緊張している空気が若干和らぐ。
○ポジションペーパーセッション
・自己紹介して、班の人と「よろしくー」ってします。
プレゼンや話を聞く練習にもなります。
・終わった時に、司会の並木さんが
「みんなできててましたねー」って褒めてくれてやさしい
・全体的に砕け過ぎず、程よい緊張感
○BPPセッション
・ブロッコリーさんがいろんな人の名言を伝えてくれた
・私が気になった言葉
-『テスト設計』って名前にすると、設計を省略しろとは言いにくい
→名前って大事だなって思った。
-品質保証とはアクティビティ(活動)である、作業ではない
→テストだけじゃない、自分が気を付けないと、いつでも作業になってしまうから、肝に銘じとこって思った。
-手で実行したテストは費用 自動化されたテストは資産
-ゴミなテストを自動化してもゴミが作られるだけ
→資産を作るようにいつも考えておかないと、テストだけでなくいろんなことがゴミになると思った
○コマンド&コントロールから抜け出そう!?
・コマンド&コントロールド:言われたことやるやつ。受動的
セルフオーガナイズド:自分で理由に納得してやるやつ。自律的
セルフオーガナイズドの方が、みんなハッピーになれそうな感じ
・「嫌です!」って言っちゃうのは、受動的なのかどうか?は、その時によって変わる。
なんでもかんでも「やります!」は、考えないでやっているのなら「コマンド&コントロールド」
・テストを作業でなく活動にするためにはセルフオーガナイズドにしていくのだな~
○JSTQB TA テスト技法の紹介
・ワークでクラフィシケーションツリーで組み合わせを考えてみた
大きい2因子間の組み合わせを作ってから、
次の因子がうまく組み合わせるように考えながら組み合わせる方法が、個人的に好き。
仕事で普段やっているのと似てた。
・ドメイン分析は秋山さんの「ソフトウェアテスト技法ドリル」に書いてあった。
「全然知らない!」と思ってしまったので、もっと練習したい。
○プロセスを図にしてみよう!!「その仕事の地図を書くのは君だ!!」
・PFD大好き。
・自分が普段やる作業や、これからやろうとする作業をPFDにすると
途中でやることぶれないし、ほかの人に説明しやすい。
次やるときにもどうしたらいいかわかっていい。
・業務と異なるシステムのお題が出ると、すごく難しいんだけど、勉強になっていい
○組み込みマニュアルテスターだった私が、Web系自動テストエンジニアに!?💦テストエンジニアに求められるスキルと今後のキャリア💪🏻
・環境が変わると今までの「あたりまえ」が通用しなくなるけど
基礎知識は変わらない。
JSTQB FLレベルの内容を、現場に合わせて適応できる現場が変わってもなんとかなる。
・変わったことを自覚、基礎知識があって、知識をか環境に合わせて適用できる能力、全部別の能力だ。
FL取得、もっかい頑張ろうと思った。
○ディナーセッション
・生魚が苦手な人たちが、肉を焼いているプレートに刺身を乗せて焼いていた。
真似してみたら、すげーうまかった。(もちろん刺身の状態でもおいしくいただいている)
新しいことを受け入れてチャレンジすると、得られる喜びがある。
○分科会
・ブロッコリーさんのTDDモブプロ体験に参加してみた。
・めっちゃ楽しかった。
自分の意見が受け入れられたり、質問を答えてくれる人がいたり、
試行錯誤して動いて「やったー」てなると、
「あの人がすごい」とか「俺がすごい」じゃなくて、「みんなすごい!」になって
とてもうれしく思えた。
・改めて考えてみると、私の業務の後輩たちは、わからないことあるとその場でみなで相談が急に始まって、
あーでもないこーでもない試行錯誤始める。
あまり長引くと、私が意見を言ってしまうのだけど、
これはモブプロみたいなものだったのかも。若い人たちは、皆でいろんな情報を共有していて、いろいろ早い。
取り敢えず、ここまで。
▼残り
<2日目 (12月16日)>
○モーニングセッション:(主に)Agile Testing Days 2018 参加レポート
○本当に初心者の方に送る「そもそも自動化とは何か。自動化するために必要なスキルとは」について話すセッション
○コードカバレッジを知ろう!
○自分のためのチェックリストを作れるようになろう
○50分で講師になれそうな気になるASTERセミナーテキスト
○ライブコーディングでわかるテスト駆動開発
○翌日の話
後輩に、テスト準備でやることを伝えたい
後輩にお伝えしたい内容です。
お仕事した結果、お金が発生するので、
いつまでに何をするのかをお客様と合意取ったうえで作業をする必
大きなまとまりの仕事をする場合は、
何をするかの方針が決まったら、スケジュールを立てないといけま
・ちゃんとできるよ
・この順番でやるよ
を、明確にして、合意をとります。
計画時に出てきた大きな作業たちが、どんなことをすれば完了にな
を考えてスケジュール立てますが
作業たちの単位が大きすぎてわからない時は、分割して考えます。
どれくらいでかかるかな?先にやるべきことは?を考えて、順番を
そして、実際に作業に取り掛かったら、進捗がわかるようにします
問題がある場合、早めに分かった方が、時間的余裕により解決策が
できないこと、わからないこと、まずいこと、今はまだ問題になっ
この先ちょっとヤバいかも・・・?って場合は、あらかじめほかの
ます。
ほかの人に相談すると、自分にない知見が得られることがあります
「他にどうすることもできない」と思っていても、
他人から見たら「やらなくていいじゃん」とか「このやり方にすれ
とか。
人員投入が必要な場合も、急な話だと追加が難しいことがあります
スケジュールはあくまで予定なので、見直しして変更することがよ
------------------------------
なので、テスト準備する時は、以下の作業が必要です。
①テスト計画の作成
※現在のプロジェクトでは、テスト計画はほとんど見積もりしか
書いてないですが、本来はテスト実施スケジュールや環境の記載も
見積もりを出すためには以下が必要です。
・どんなテストをするのか
・テストケース数
・実施にかかる工数
・予想される不具合数
※新規テストケース作成の場合、
上3つは、見積もり段階ではふんわりした値です。
準備を進めながら、精度を上げてゆきます。
②テスト準備のスケジュールの作成
③テスト準備の進捗ファイルの作成
※スケジュールと進捗ファイルが一緒になっている場合もあります
私はガントチャートを使ってます
④スケジュール通りに準備を進める
※問題がある場合、早めに察知が必要なので、進捗は毎日わかるよ
------------------------------
▼後輩イメージ
絵描いた。楽しかった。
JaSST'18 Tohoku感想
JaSST'18 Tohokuに行ってきました。
職場の勉強会で話す内容の下書きとして、ブログに感想を書こうと思います。
▼資料やレポートはこちら
http://www.jasst.jp/symposium/jasst18tohoku/report.html
▼感想
HAYST法はテスト開発技法です。
今まで、仕様書あることを前提にした方法だと思っていたのですが
仕様書に書いてないこともテストできる方法でした。
プロセスを見ると 要求分析・テスト設計・テスト実装 とあって、
VStepもゆもつよメソッドも基本的には同じ。
どうやってかんがようか?ってところがみんな違くて
それぞれの作った人の関心や困りごとの解決に特化した形になっているんだと思う。
だから、こうゆうものを学んで、自分たちの仕事に活かせるように取り込めるといいなと思っています。
私が4月のイベントで「世界平和のためにテスト活動している」という話をしたのですが
秋山さんが、世界平和を実現するための方法がHAYST法って言っていて、
私の中では、ただのマインドでしかない感じだったのに、急に世界平和が具体的になって、周りの人がついてきてくれそうな印象を受けました。
(※4月のイベントは私は資料上げてない。 https://connpass.com/event/83134/ )
今回、ユーザーストーリーというのを使って、機能の分析をしていた。本には書いてなかったやつ。
よくある正常パターンと、あんまりなさそうなパターンでの使い方を考えることで、市場にあるだろう範囲をカバーできるとのことで
開発者の想定を超えて考えることができる方法ってのは、凄いなと思った。
あと、ユーザーストーリでユーザーのやりたいことで機能を分けて、
それでも大きすぎれば目的機能を小さくして考えるというのがよかった。
○ワークでやったこと
・テスト要求分析
①6W2H:3つの視座で考えることで要求を理解する
②ユーザーストーリー:ユーザー視座{When(いつ), Where(どこで), Who(だれが)}から、どんな機能があるか考える
③FV表:ユーザーストーリーから機能にして、どんなテストしたいか考える
※大きいままだと考えられないから、小さくして考えることがFV表のミソ。
機能についてどんなこと確認したいのか(観点?気になるところ?因子?)、
どんなテスト(シナリオ?パフォーマンス?組み合わせ?)が必要かをかんがえます
・テスト設計
③ラルフチャート:FV表の機能一つに対して、情報の整理と因子の 洗い出し。
入力・出力・ノイズ・状況変数(読み込み/書き込み)を考える
④FL表:因子と水準、意図を整理するための表。一行が1テストケースになる。
※ワークでやってない
FL表はワークでやっていない。説明だけ聞いた。
その水準を選んだ理由を書くことができて、いいなと思った。業務の改善につなげる。
ーーーーーーーーーーーーーーーーーーーーーーーー
○まとめ
・わからないことは、大きすぎて複雑に見えているだけ。
私には、できない理由がありすぎる
いきなりですが、私には野望がある。
ラインスタンプを作ってみたいのだ。
ラインスタンプでお金を稼いでみたい。
スタンプを作ろう!と周りに宣言したものの、何もしないまま4年ほど経過している。
やりたいけど、なんだかできない。自分の好きなスタンプ作れるし、たぶん作るの面白いし、うまくいけばお金も入る。
ラインスタンプ作ってみたい!
ラインスタンプでお金稼ぎたい!
でもめんどくさい!!
なんでか。
40枚も絵をかかないといけないからだ。
正確には42枚。
・メイン画像 1個
・スタンプ画像 40個
・トークルームタブ画像 1個
面倒くさい!
面倒くさいよ!
ほかにも、いろいろできない理由がある。
▼とにかくできない理由
--------------------------------------------
・沢山絵をかくのが面倒くさい
・色を塗るのが面倒
・テーマが決まらない
・ひとつひとつ、何を書くか悩む
・作業する時間がない
・締め切りがないから着手があとまわし
--------------------------------------------
あーもう、面倒くさい。
こいつらが、いなくなればいいのに。
▼こいつらが消えたらどうなる??
--------------------------------------------
・沢山絵をかくのが面倒くさい →簡単に必要な絵がそろう
・色を塗るのが面倒 →色塗りが楽
・テーマが決まらない →周りの人、自分がよく使う表現がテーマになる
・ひとつひとつ、何を書くか悩む →何を書くか決まっている
・作業する時間がない →スケジュールたててある
・締め切りがないから着手があとまわし →締め切りがある
--------------------------------------------
▼できない理由がない状態だけまとめてみた
--------------------------------------------
・簡単に必要な絵がそろう
・色塗りが楽
・周りの人、自分がよく使う表現がテーマになる
・何を書くか決まっている
・スケジュールたててある
・締め切りがある
--------------------------------------------
いっこいっこ、この状態にしていけばいいってことだよね。
「ラインスタンプでお金稼ぎたい」って野望のための小さな目標って感じ。
じゃぁ、どうゆう順番でやれば叶えられるかな・・・?
▼並べかえてみた。下から順にやるよ。
--------------------------------------------
・簡単に必要な絵がそろう(・色塗りが楽 も含む)
↑
・何を書くか決まっている
↑
・周りの人、自分がよく使う表現がテーマになる
↑
・スケジュールたててある
↑
・締め切りがある
--------------------------------------------
なんかもう、これだけでできる気がしてきた。やったね!
で、ここまで考えて、ほかの人に相談してみたら、
今はラインスタンプ、40個も作らなくていいらしい!知らなかった!!なんだよ!ばか!
ガイドライン: https://creator.line.me/ja/guideline/sticker/
それも踏まえて、どんなことすればいいのか考えてみた。
▼やること考えた
--------------------------------------------
・簡単に必要な絵がそろう(・色塗りが楽 も含む)
├─・過去に書いた絵を使う
└─・少ない個数で申請する
↑
・何を書くか決まっている
└─・もうすでに決まっている。なにもすることない!!
↑
・周りの人、自分がよく使う表現がテーマになる
├─1、周りの人、自分がよく使う表現・フレーズを集める
└─2、集めたフレーズにテーマを付ける
↑
・スケジュールたててある
└─・締め切りに向けてスケジュールを立てる
↑
・締め切りがある
└─・勝手に締め切りを立てる!!
--------------------------------------------
これを下からやってけばいいの!できそう!!
実際には、付箋を使って考えていたの。
手を動かしながらやった方が頭が回転する気がするし、貼り替えて並び替えできて便利!
とにかく、やることはわかった。実際にやってみよう!!
****
今回私が行った手法は、TOCfEのATTと呼ばれる思考ツールを利用したものです。
ATTとは、アンビシャス ターゲット ツリー の略。
到底無理と思える野望を実現させるための筋道を立てることができる思考ツールです。
そんなATTが明日から使えるようになるワークショップが
5/27(土)、西新宿であります!!!
↓↓↓
https://tocfebc.doorkeeper.jp/events/59320
よろしければ、お気軽にお申込みください。ませ。
****
さて。
なぜ、わざわざブログにしたのかというと、
私が、TOCfEBootCampというワークショップでATTの講師をやるからだ。
つまり、やりたいけどできないことを叶える計画たてる方法を、教えようというのだ。
そんな講師の癖に、やりたいこと、めんどくさがって、やれないまま。
そんな状態で、講師なんて何の説得力もないだろ!!と、
実際にATTを作ってみたのでした。
いままで、野望もないし、ATT苦手だし、私ダメダメだわーって思っていたけど、
改めて、自分の事で書いてみたら、案外すっきりできてしまった。不思議。
シブヤだよ
シブヤがブログ始めました。
今はまだ書くことがない。。。