テストもぐもぐ会 2018秋の陣 開催

どうも、子守と運営両方やるもんじゃないなと思ったオムそばです。
当日なにもできなかった。。。

さて、本日は、先日開催された"テストもぐもぐ会 2018秋の陣"について書きたいと思います。

■テストもぐもぐ会って？

@____rina____さんの、「オムそばさんに会うと、オムそばを作ってくれるの？」という何気ない一言から生まれた会。
内容は、QAに関わる人達が、QAに関わる人達のために料理を振る舞いながら、皆でQAに関する談笑をするという、ゆる～い内容。

■話題

今回出た話題はこちら。

• 明日から未経験領域のドメインを担当してと言われたらどう動く？
• テストデータの管理、ベストプラクティスは？
• QAのキャリアについて
• QAエンジニアの教育ってどうしてますか？
• エンジニアじゃない人に 品質/テスト を説明するには？
• 性能テストやセキュリティテストどうしてます？
• 料理のQAやってみる。

全体的に、自分たちの現場では普段得ることが難しいであろう話題が多い印象でした。
外に出ることによって得られるメリットの一つですね。
※それぞれでどんな話が繰り広げられたのかは、子守と料理に専念していた関係で、聞けませんでした。求む、感想ブログ。

今回のベストもぐもニスト賞は、csasakiさんの、「QAエンジニアの教育って、どうしてますか？」(12人中6票)でした！おめでとうございます！
今回から、ベストもぐもニスト賞、ベストフード賞を受賞した方は、次回の参加費を無料とします。

■料理 

今日の献立は、以下の通りでした。

• ラーメンサラダ
• エビチリ
• 餃子
• チキンのトマト煮
• ご飯
• 味噌汁
• オムそば

今回のベストフード賞は、NAKAKEROさんの「チキンのトマト煮」(12人中4票)でした！おめでとうございます！

■次回に向けて

今回は、裏テーマとして、"何度も使える開催場所候補を見つける"のと、"スタッフを付けて運営してみる"を設けて実施しました。

一つ目は、今回の落合第一地域センターを発見することができました。設備が整っており、また、利用料金が5,000円と比較的安いことから、しばらくここで開催を続けようと考えています。

二つ目は、y-wakisakaさんをスタッフ登用できました。y-wakisakaさんが会場予約、開場準備、片付け指示等、よく働いてくれたおかげで、私が子守に専念することができました(ぉぃ

改善点としては以下の通り。

• 序盤のアイスブレイクが弱いため、参加者が雰囲気に慣れるまでに時間がかかる
• 料理する場所と話す場所の距離が近く、話が聞き取りづらい(次回から配置検討)
• 換気扇の音がうるさい(これは料理している間は我慢するしかないかも...)
• 必要な調味料が不足していた(次回から事前調査する)
• 調理器具が散乱してしまい、片付けに時間がかかった
• 布巾の不足(自分たちで持ってこなきゃいけなかったらしい)
• 主催が子守で機能不全を起こしていた(おもちゃ持参します)

 会を重ねるごとに良い会となるよう、着実に改善していきます。

■最後に

ご参加いただいた方々へ、拙い運用ではございましたが、皆さまが何か一つでも自分の仕事に活かせる何かを持ち帰ったり、負の感情の発散できたりしたのであれば、幸いです。

次回は春頃を予定しています。詳細が決まったらconnpassや、Twitter(@teamomusoba)で発信します！お楽しみに！

技術書典5 参加レポート

どうも、元埼玉県民のくせに初めて池袋サンシャインシティに入ったオムそばです。
いつも東急ハンズにしか行かないので...

 

さて、今回は、技術書典に初参加してきたので、それについて書きたいと思います。

■技術書典とは？

技術書典とは、2016年から半年に一度くらいのペースで(4月と10月)行われている、技術書の同人イベント。
公式サイトはこちら。

今回で6回目、という情報以外は特にチェックせず、「知り合いが本出すから買いに来た」と、ただそれだけの理由で挑んできました。

■予想の20倍の混雑度

はい、舐めてました。
会場には20分前に到着したのですが、その時点で長いながーーーい行列。
目算1,000人くらい並んでいました。
行列は文化会館を出て、サンシャインシティの外周へ...
しかも、後ろにどんどん人が並ぶ...

(最終的に入場できたのは、11:25頃でした)

どうしても欲しい本がある人は、最低でも開場1時間前に来た方がいいですね。
私が入場した時点で完売になっているものもありました。

▪︎ゲムマの経験がなければ死んでいた

さて、入場すると、こういった同人イベント独特の、狭い通路を流れに乗りながらタイトルとどんな本かを見ていく作業に。
人の肩越しに見ないといけないので、パッと見なんの本かわからないと、スルーすることに。
出展する方は、見やすい看板や、一言で売り物を表現するスキルが求められます。
この感覚…ゲームマーケットと全く一緒だ！！
ビックサイトの1ホール分と比べたら、文化会館なんて狭い狭い。
大体1時間くらいで全部見ることができました。

■戦利品

• 技術季報 vol.4
• 201 CREATED
• テスト開発者のための TDD して、 CI 回して、E2E のテスト自動実行して、なんやかんやする本
• エンジニアアンチパターン
• なそのテストラジオ

お目当てだった、サークル CRAB INK さんの"201 CREATED"を購入できて満足。
この内容、このクオリティで500円はバリお得。
すぐ横に 尊敬するなそさんの本も売ってたから中身確認せずに購入。
売り子さん(知り合い)に「え！？中身も見ずに！？」って言われましたが、基本、ジャケ買いする人なので…

またこのサークルが本を出すときは買いに行こう。

"負荷テスト"と"ストレステスト"の違い

どうも、テスコンのチュートリアルに参加して久々にテストのことを考えているオムそばです。
テストは崇高。

さて、今回は、チュートリアルにて、講演者である にしさん が、負荷テストとストレステストについて少し触れていたので、自分の理解を深めるために、自分の持っている書籍ではそれぞれがどう書かれているか見てみました。
(関係ないけど、テストに関する本、意外と持っていないんだなぁと実感させられた。。。) 

 ■ソフトウェアテスト教科書 JSTQB Foundation 《第3版》

ソフトウェアテスト教科書 JSTQB Foundation 第3版

• 負荷テスト：記述なし
• ストレステスト：予測または仕様化した負荷、もしくはメモリやサーバなどのリソースの可用性を低減したときの限界、または、それを超えた条件でシステムやコンポーネントを評価するテスト。

(このブログに似つかわしくない小難しい表現…)
JSTQBのFoundation では、負荷テストに関する記述はありませんでした。

■知識ゼロから学ぶ ソフトウェアテスト

知識ゼロから学ぶソフトウェアテスト 【改訂版】

•  負荷テスト：読んで字のごとく、プログラムのあらゆる部分に負荷をかけるテスト。短い時間に多量のデータを入力し、出力させ、それに伴う処理を実行させる。
• ストレステスト：負荷テストと同義

知識ゼロから学ぶソフトウェアテストでは、負荷テストとストレステストは同義として取り扱われておりました。
ただ、書いてある内容は、JSTQBと少し毛色が違いますね。

■ソフトウェアテスト 293の鉄則

ソフトウェアテスト293の鉄則

•  負荷テスト：プログラムに対して、トランザクションを大量に発生させたり、同じリソースの大量要求を発生させるなどにより、プログラムやシステムに対して高い負荷をかけるようなテスト
• ストレステスト：記述なし

ソフトウェアテスト293の鉄則では、ストレステストの記述がありませんでした。
この本では時間に関する記述はないんですね。

■ISTQB シラバス準拠 ソフトウェアテストの基礎 Foundation Level

ソフトウェアテストの基礎:ISTQBシラバス準拠

•  負荷テスト：コンポーネントやシステムの動作を測定するテストの一種。負荷(例えば、並列実行ユーザ数やトランザクションの数)を増加させ、コンポーネントやシステムがどの程度の負荷に耐えられるか判定する。
• ストレステスト：要件で定義した限界、または、それを超えた条件で、システムやコンポーネントを評価するテスト。

ちょっと待って、ISTQB準拠なのに、前述のJSTQBと違って、二つは別物として扱われているの！？
もうわけがわからないよ…。

■この1冊でよくわかる ソフトウェアテストの教科書

【この1冊でよくわかる】ソフトウェアテストの教科書―品質を決定づけるテスト工程の基本と実践

• 負荷テスト：動作しているソフトウェアシステムに負荷をかけて行うテスト。次のようにさらに細かく分けてテストする場合がある。「性能テスト」「ロングランテスト」「大容量テスト(ボリュームテスト)」「記憶域テスト(ストレージテスト)」「高頻度テスト」「負荷テスト(ストレステスト)」
• ストレステスト：極端に高い負荷をかけた状況下(短時間に、容量の大きいデータを処理させるなど)での動作を確認するテスト。

こ、今度は親子関係…。負荷テストは広義の負荷テストと狭義の負荷テストがあって、狭義の方はストレステストと同義である、と…。

■まとめ

結論、"負荷テスト"と"ストレステスト"は、違いがあるときもあるし、ないときもある。
重要なのは、5つ書籍があって、5通りの書き方があるんだから、この言葉がPRJの中で使われる際は、最大限注意が必要であるということ。
負荷テスト、あるいはストレステストという言葉を用いる際は、その言葉が何を表すのか、しっかりと定義し、チーム全体で共有するようにしましょう。

WACATE2018夏 参加レポート 2日目 ～チームとしてどう動くか？～

どうも、WACATE終わってから周りが加速しまくっているのを見て焦るオムそばです。

さて、ちょっと間が空きましたが、2日目のレポート、張り切って書いていきたいと思います。

■所感

• やはり自分はマネジメントの人間なんだな(仕切りたがり屋的な意味で)。
• たったA4一枚の仕様に対し、成果物は全チームバラバラだった。これがもし、一つのシステムに対し、7チームがそれぞれサブシステムを開発していたら、と考えると、横串で見る組織(PM的な存在、今回は実行委員)の発信する情報の重要性を感じる。
• 新卒、というよりも、2～5年目の社員に受けさせたいワークショップだった。

■セッションメモ

■受けてみようUMTP認定試験！

• UMTP認定試験について、知っている人は少な目
• すぐにUMLを使う機会がなくても、いつか役に立つ、そのためのInput&Outputが大事、ただ、WACATEハイからの落差に注意(現場に戻って必要以上に落胆しないように)
• 試験終了後に「やったー！」っていうときっとカンニングになるよ

受けてみよう。UMTP認定試験！ from yuki okauchi

www.slideshare.net

■総合演習

ワークでは、"簡易稟議システム"に対するテストケースの作成を行った。
詳細なアウトプットは以下5点。

• 仕様モデル一覧
• 各仕様モデルの詳細
• 各仕様モデルに対するモデルベースド基準
• 各仕様モデルからモデルベースドテストで抽出されたテストパターン一覧
• メモ(仕様の不明点と、その解(チームでどういう仕様として解釈したか))

私の所属するチームでは、以下のように仕様モデルを決めて進めた。

• ユースケース図&アクティビティ図
  これらの図は、全体像を掴むことが主な目的
• 状態遷移図(稟議)
  稟議の機能に対する詳細な状態遷移図
• 状態遷移図(画面)
  各画面が、稟議の状態によって変化するため、こちらも状態遷移図で表現

チームの中で共有した決め事は以下の通り。

• 役割分担：
  - 全体統括(WBS管理、レビュー)：1名
  - ユースケース図&アクティビティ図作成(モデル&テストケース作成)：1名
  - 状態遷移図(稟議)作成(モデル&テストケース作成)：2名
  - 状態遷移図(画面)作成(モデル&テストケース作成)：2名
• 全員が納得した上で作業を進める、ただし、タイムテーブルは厳守する
• 仕様が不明確な部分は、時短のためシンプル(簡単)な方に倒す

決め事がはっきりしていたことと、1日目で良い人間関係ができていたため、特に大きな混乱が起きることなく、成果物を作り上げることができた。

■昼食

カレー！マホロバカレーめっちゃうまっ！！

※画像はなそさんに許可いただき、転載させていただきました。ありがとうございます！

■本日の総合演習 完結編
2日間の総まとめ。発表3分、質疑2分で各チーム発表。(これはちょっと時間少なかったな…特に、質疑応答部分は増やした方が良いと感じた)
見ていると、各チームアプローチが違って非常に興味深かった。
たったA4一枚の仕様で、しかも同じことを学んでいたにも関わらず、チーム作りや、PRJの進め方が違うことによって、成果物が大きく異なっていた。

■2日間をふりかえろう
個人の振り返り、そしてそれをチーム内で共有。
Y(やったこと)、W(わかったこと)、T(つぎにやること)に整理して振り返りを実施。

■原因結果グラフとWACATEは僕に何を教えてくれたのか(クロージングセッション)

• CEG(原因結果グラフ)とは
  状態、イベントと出力の論理関係をグラフで表現して、デシジョンテーブルに変換する組み合わせテスト技法
• ポイント：短文で考える
• ポイント：キーワードを見つける(あるいは、～していれば、ただし)
• 原因結果グラフは、原因から考えると混乱する！
• YesかNoかでこたえられるか
• 「他にないか」と問いかけよう
• 「どういう時に？」と問いかけよう
• ノードの名前は肯定文がベター
• 制約の中で覚えるべきは、EXCL, ONE, INCL, あと二つはREQ, MASK(これらはまずは覚えなくていい)

WACATE2018 夏　原因結果グラフ解説 from Masaki Kase

www.slideshare.net

WACATE2018 夏　原因結果グラフ演習問題 from Masaki Kase

www.slideshare.net

WACATE2018 夏　原因結果グラフ演習問題　解答例 from Masaki Kase

www.slideshare.net

■WACATE2018夏 クロージング
・小さなことでもいいので、アウトプットしよう！！
・ポジションペーパー賞 授賞式。Biased Favorite Paper賞に、@yoshikiitoさんが選ばれました！！おめでとう！！

とんでもなく濃密で、楽しい2日間でした！！
ただ、楽し過ぎてtwitterで大騒ぎしていたら、妻から皮肉交じりに「楽しそうでいいですね(白目」と言われたので、家族としっかりと相談した上で参加しないと、痛い目を見るぞ！！

次回のWACATEは 12/15～12/16 です。次回も行けたらいいなぁ。

最後に、WACATEに参加された皆様、そして、こんな素敵な会をきっちり運営してくれた実行委員の皆様、ありがとうございました！本当にお疲れ様でした！！

ソフトウェアテストエンジニア教育用(?)ボードゲーム『その言葉、なんですか？』

どうも、引き続きWACATEハイなオムそばです。
いつまで続くかな？

今回は、先日ふと思いついて試作版まで作ったボードゲームのご紹介。

■『その言葉、なんですか？』ストーリー

 あなたは今、自分のプレゼンテーションが終わって、質疑応答中です。
とある質問者から、あなたのプレゼン資料に対して、こんな質問を受けました。
「その●●という言葉、なんですか？」
あなたは理路整然とこう答えました…

■『その言葉、なんですか？』概要

本ゲームは、「キャット&チョコレート」や「横暴編集長」をモデルとしたゲームで、場に出ている"言葉の片割れ"と、手札にある"言葉の片割れ"を繋げて言葉を作って説明し、"質問者"(他のプレイヤー)を納得させるゲームです。
作り出した言葉は造語でも、実際にある用語でも構いません。
充分な納得感(プレイヤー数の半分以上が納得)が得られれば1ポイントつき、全部で2ポイントついた人がそのゲームの勝者となります。

• プレイ人数：2～10人
• プレイ時間：10～30分(人数に応じて変化)
• 難易度：易(ボドゲ初心者でもできます)

■『その言葉、なんですか？』ゲームの流れ
1. プレイヤーは自分の手番になったら、場にあるいずれかのカードの前後に、手札のカードを1枚くっつけて言葉を作ります。
2. 他のプレイヤーはその言葉を見て手番プレイヤーに「その言葉、なんですか？」と質問します。
3. 手番プレイヤーは自分で作った言葉について、相手を納得させるように説明してください。
4. 説明が終わったら、他のプレイヤーは一斉に判定をします。手を前に出して、納得したらグーサイン、納得できなかったら手を引きます。納得が半分以上得られたら、手番プレイヤーに言葉カードを渡します。
5. 手番プレイヤーと場に山札からカードを1枚ずつ補充し、手番を時計回りに次のプレイヤーに回します。

■『その言葉、なんですか？』教育的効果

• 説明能力の向上
  本ゲームは、自分で作った言葉をもっともらしく(あるいは実際の言葉を正しく)説明しなければなりません。そのため、順序立ててわかりやすく説明する必要があります。反応が悪い場合はどこが悪かったのか、他のプレイヤーにヒアリングし、フィードバックを貰うことで、自分の説明能力の弱点が見えてくるでしょう。
  また、他の説明がうまいプレイヤーの話し方や、話しの構成などを聞いて、うまい説明の仕方を学ぶこともできます。
• 用語理解の促進
  本ゲームは、実際にある言葉を分割して作成しています。そのため、一見なんだこれ？って用語でも、実際にある言葉の一部に必ずなっています。
  何だろうその言葉、と思ったら、すかさず質問したり、自分で調べたりすることで、テストに関する用語に詳しくなれるでしょう。

試作品として作って、WACATEの参加者の皆様にプレイしてもらいましたが、概ね好評でしたので、ソフトウェアテストエンジニアの教育用ボードゲームとして、各イベントで配布する方向で舵をきってみようかなと思います。
(その前に色々と大人の手続きが必要になりそうですが…)

ではまた。

WACATE2018夏 参加レポート 1日目 ～テスト特盛～

どうも、WACATEハイに既に陥っているオムそばです。
来週月曜が怖い。

今回は、現在進行形で参加中のWACATE2018夏 の参加レポート(1日目)です。

■所感

皆良い人。冗談抜きで。
他人の悩みに対して真摯に向き合う姿勢や、自分から率先して取り組もうとする姿勢、実行委員が定めたルール通りにちゃんと動く秩序、そして何より皆楽しそう。

あと、今回即席で作ったボードゲーム『その言葉、なんですか？』がそれなりに好評だったので、諸々大人の対応が終わった後に、テスト界隈に広めていこうかなと思いました。
※ボードゲーム自体の紹介は別記事でやる予定です。

■セッションメモ

●オープニングセッション

• 参加者39名
• WACATEは"加速装置"(これをきっかけに飛躍するもの)

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

• 職種バラバラ、年齢バラバラ、でも皆意気込みすごいところは共通
• 班のガイドラインを作る取り組み、チームごとに特色が出て面白い

●2017年度のJaSSTを振り返ろう

• 全国のJaSSTを回った超人のお話。
• 大量のインプットを一遍に吐き出したかのような発表、怒涛の情報量
• 資料はこちら

scrapbox.io

●昼食

• オム…カツ丼ッ！！(皆は海鮮丼)
  

●テストの視点からのモデリング

• きんぢラーメン大賞とJaSST東京2018 は同じレベルの力を持っている
• UMLに関する様々な説明(詳細はスライド参照)
• UMLを書くときの注意点は、"細かい文法にとらわれ過ぎないこと"、多少カスタマイズしてもよい、ただし"チーム内で合意すること"

テストの視点からのモデリング（公開用） #wacate from Kinji Akemine

www.slideshare.net

●ユースケース図&アクティビティ図

• 非常に聞き取りやすく、わかりやすい説明
• 小演習(50分!?)
• 時間内にアウトプットする能力の無さに絶望。細かいところに捕らわれすぎる傾向あり

ユースケースとアクティビティとテスト from kauji0522

www.slideshare.net

●状態遷移図

• できるだけシンプルにまとめよう
• 状態遷移図と状態遷移表で抜け漏れチェック
• 演習、ここでも弱点を痛感。作業を始める前にゴールイメージをしっかり整えてから書き出す癖をつけよう。

speakerdeck.com

●夕食

• おいしい和食！！

●夜の分科会「おもしろいボードゲームの観点」

• なぜか私のためにあるようなセッションが。
• マインドマップでおもしろいボードゲームの要素を引き出した。最初が「おもしろいボードゲームを探す」がメインテーマだったため、ボードゲーム以外の要素に全員の目が行った印象。メインテーマ設定大事。
• なそさんの芸術的センスが素晴らしい、イラストかわいいし、字が見やすい。

ここにいる間、全員がテストについて考えて会話し続けるので、朝から晩まで、テスト特盛状態な一日でした。

明日(今日)は、今日よりもっと楽しむぞい。
ではまた。

【GBW】ちょっとした、されど重要なこと ～備考の書き方～

どうも、突然の暑さに夏バテ気味なオムそばです。

GBW六日目は、軽めのお話。
皆さん、"備考欄"について、どのような記述をしておりますでしょうか？
「そもそもなんの備考欄だよ」という疑問が浮かぶかもしれませんが、私が今回お話するのは、様々なドキュメントにある備考欄全般に対する話です。

■備考はあくまで備考。だけど書くならしっかりと

プロジェクトの中で作成されるドキュメントは、大抵の場合、不特定多数の人、スキルの異なる人、立場の異なる人が見ることが多いです。
ドキュメントの中に記載された備考欄も、例外ではありません。

一つ例を挙げます。とあるテストケースを見たときに、こんな記述がありました。

結果：OK　備考：要確認

このテストケースは、実行者と結果確認者が別々の人が担当しており、どちらが書いたか全くわかりませんでした。
また、日にちが過ぎた後にこれを発見したため、当事者達も、どちらが書いたのか、また、何を要確認なのか、それが済んだことなのか、本当にOKなのか、全くわからない状態に陥りました。

このように、例え備考欄であっても、メモ書きのように使うことは控えておいたほうがよいです。
ではどう書けばよいのか？以下にポイントをまとめてみました。私の主観も入っているため、ご参考まで。

• 記述の最初に[yyyy/mm/dd 名前]を書き、誰がいつ書いたか明確にする
  ※yyyyはプロジェクトの長さによっては書かなくてもよい
• 主観的な記述をしない。
• 誰に見られても理解してもらえるような記述にする。
• 「確認中」のような記述に対し、解を得られた場合、その記述は消さず、
  「確認中 ⇒ 確認済、××さんから○○という回答を得た」のように、⇒で記述する
• なるべく簡潔に書く(深く読み込まなければならない備考は書かない)。
• 備考に重要な情報を書きすぎない。あくまでも補足として扱う。
  ※記載内容の重要度は、本文 > 備考 になるように意識する

備考だからといって、油断して書いていると、後々見返したときに、わからなくなるので要注意です。ではでは。