JaSST'20 Kansaiに参加してきました!

9/12(土)にオンラインで行われたJaSSTソフトウェアテストシンポジウム-JaSST'20 Kansaiに参加したので、気になったセッションをレポートします! 関西は初参加!
今回のテーマは「テストについての分解・再構築」です。
本文中にリンク貼った書籍や資料は、当日のTwitterで教えていただきました。
当日のまとめはこちら
JaSST'20 Kansaiまとめ(オンライン) - Togetter


「テストの視点でシステムを分析する」

見えないものと取っ組み合う

望月 信昭(ウェブレッジ)さん
<概要>
テストベース分析で困りがちなこと

  • ソフトウェアは目に見えない → 何となく理解した感じで作業を進めてしまう

対象をテスト視点で理解する

  • モデル化してみる(図を描く)
  • 記法とかがハードル高いと感じる人は「テスト技法を使って問題を解いてみる」と考えてみるのも手(対象を理解するためのツール)
  • ただし対象に対してどの技法を使うのが適切かを選ぶのもハードル高い
  • →ちょっと使ってみて考える。失敗してもこの対象にはこの技法は会わないという学びをゲット

対象の振る舞いを理解して、見えないものを見えるようにすることができる

テストの視点でシステムを分析する

堀川 透陽(ベリサーブ)さん
<概要>
テストのシフトレフト
前提

  • ビジネスモデルキャンバス(ビジネスゴールを導くためのツール)

顧客・tesuto 対象をビジネス視点で書き出していく

  • PEST分析 仮想課題から気付きを得る

外部環境の変化から生まれる要求、見直される要求があるのではないか

USDM(要求仕様記述手法)による要求と仕様の再構築
言葉にする→言葉にかけないものを作ってはいけない
メリット

  • 要求と背景が明確になることで、テストのゴールも明確化される
  • 合意形成しながら進めることで、仕様の妥当性があがる

デメリット

  • 作成に熟練を要する(作り直し)
  • 合意形成のための工夫が必要

USDM作成→テスト設計HYST法のFV表、FL表へ接続できる


<講演中で触れられてたことの参考文献など>
USDM参考書籍

テキストマイニングによるテスト分析、リスクベースドテストへの応用の詳しい事例
https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol19.pdf

テストの視点でシステムを分析する ~アジャイル開発を例に

江添 智之(バルテス)さん

  • 仕様化以前の状態で品質を考える
  • 何ができればOKか を上流工程から考える
  • エピック→スプリントに入りきらないユーザーストーリー → 受け入れ条件を考えるとユーザーストーリ―に分割できる
  • 要求の「完成」の定義と受け入れ条件で整理する

「スペックアウト」でソースコードを理解しよう

池田 祐一(AFFORDD関西部会)さん

スペックアウトとは

設計書の不足を補うために、ソースコードから必要な設計書を起こす行為
知りたい機能、知りたいこと、必要な調査資料、投入できる時間etcを目的を明確にして取り掛かる
 

スペックアウトの手順例

1. 資料やソースファイルの一覧を用意する
資料、内容、用途などを表にする
2. 関数の一覧を用意する ファイル名、関数名、説明(目的語と動詞を各)を表にする
3. 変数の一覧を容易 ファイル名、変数名、説明(名詞を書く)

4. データ参照関係を調査する 関数と変数のマトリクスにCRUDのどれを行っているのかをつけていく
5. 知りたい機能の処理構造を調査する 変数名表からあたりを付けて構造図に落とす
6. 必要に応じて処理手順を調査する(複雑なパターンなど) 処理パターンを抽出してPADフローに表現
7. 要求仕様を復元する コードや構造図を参照しながら、イベントから始まる一連の動作を表現する
8. テスト仕様を作成する
9. テスト結果を記入する

<講演中で触れられてたことの参考文献など>

テクノロジーセッション

「試験に役立つモデリングのススメ」

渡邉 豊幹(サイボウズ)さん
サイボウズさんの米国市場向けの販売管理システム開発チームの話

問題点

  • 影響範囲が把握しにくい
  • 新規メンバー/他チームへの教育コストが高い

対策

  • モデルを作成してみる。文書より図の方が人間には分かりやすい

モデルとして残すもの

  • Keeps

- システム全体の構造shisutemuzentainokouzou
- 業務で扱う対象とそれらのつながり
- システムの(ユースケース図、コミュニケーション図)渡されるデータや実行APIを記載

それ以外はTempsとして一時的な資料、メンテナンス等はあまり考えない

結果

  • 概要が把握しやすい、俯瞰しやすい
  • モニタリング対象の洗い出しやE2Eテスト

「Global QAチームを目指して ~日本とシンガポールの2拠点QAチームを築く上での気づきと大切にしたこと~」

角 尚美(チームスピリット)さん

シンガポールで採用

QAエンジニアの役割定義をアップデート

  • コアスキル(ISTQBのFLレベル)
  • スペシャリスト(ISTQBのFLレベル+α)

の2軸で定義

リモートでも2か月で立ち上げ
 開発チーム全体でSG-QAのオンボーディングのサポート

招待講演

「ゆもつよメソッドによるテスト分析の成り立ちと狙い」

湯本 剛(freee / ytte Lab)さん

例:西暦和暦変換アプリのテスト

テスト分析

テスト対象フィーチャ:和暦西暦変換
テスト条件(仕様と期待結果):西暦の年月日から和暦へ変換した日付を出力する

テスト設計方針
テストケース:この辺で一般的なテスト設計技法を活用

分析と設計について

分析:対象を把握する→分析結果は客観的、誰が見ても分かる
設計:枠組みを考える、アイディアを決定する→設計結果は主観的。人によって答えが異なる

要求分析:システム要求を分析して仕様を作成する

あー、テスト分析だと確かにインプットするものの名前じゃないので分かりにくいのかも。文脈にもよるだろうけど、より正確にはテスト要求分析というと誤解がないのかな

テスト分析では理解したことを以下のように整理する
  • 仕様項目の特定と列挙
  • 期待結果の特定と列挙
  • テストパラメータ列挙(テスト設計時により明確に定義していけばよい)

テストカテゴリー
 テスト条件を見つける際に一貫性のある解釈をするために論理的昨日構造の各要素にテスト対象から見てふさわしい名前付けをしたもの
テストカテゴリと意味づけ

テスト設計
テスト設計方針を決める→テストパラメータ導出方法、同値のサイズ、組み合わせ方法

テスト条件を網羅するためのテストケース設計モデルの選択をする 技法の選択とか

モデル化する:必要なものを取り出し、不要なものを削る

テスト設計の変遷
テストカテゴリーをベースにしたテスト分析の方法

テスト分析手法の概要
  • ドキュメントフォーマットと実施順序のルール化/テスト分析マトリクス
  • 論理的機能構造→テストカテゴリー
  • 仕様項目特定パターン(研究中)

メリット
大きくとらえてテスト対象を網羅しているかが分かりやすい
テストしなければならないことを先に洗いだすことができる
→テスト条件(仕様項目)の段階でテストが十分か、漏れがないか、といった確認が可能になる

ドキュメントフォーマットと実施順序のルール化

複数人でテスト設計するときの記述内容を合わせる
テストカテゴリーは確認箇所を汎用化させたもの

論理的機能構造

テストカテゴリーになるべきものを決めるためのモデル

  • メンバ全員が参照モデルを深く理解する必要はない、テストカテゴリに対する認識合わせが最も重要
仕様項目特定パターン

テスト実行時のデータ入出力パターンですべて特定
テスト実行によって呼び出される小機能の結果確認

感想

「自分たちが扱っているシステムやプロダクトで何がしたいか」をどう整理すればよいかを改めて考える機会になりました。
色々な手法があるけど、どうとらえてチームでどう納得するか、というところがミソなんだろうなと思います。
ゆもつよメソッドの話をちゃんと聞いたのは今回が初めてだったんですが、論理的機能構造をどう作っていくかが私の中で落とし込めてないので、そこをもうちょっと深めたいです。

関西は今回が初でしたが、オンラインで開催していただけて自宅から参加でき、移動ゼロで素敵なお話が聞けてありがたかったです!
登壇者、運営の方々、参加者の皆様ありがとうございました!

JSTQBシラバスに出てくる「ヒューリスティック」とは何ぞや

JSTQBのテストアナリストやアジャイルテスターのシラバスで、「ヒューリスティック」という言葉を見かけて意味が分かりにくかったので、自分なりにまとめてみます。しっくりくる日本語がないので、英語のままにした方がよさそうな単語ですが、いきなり出てくると意味がとらえがたい単語ですね。

ヒューリスティック(heuristic)の辞書的な意味

Google先生に聞いてみたところ、以下の意味になります。

enabling a person to discover or learn something for themselves.
(人が自分で何かを発見または学習できるようにします。)

()内は私の訳なので、間違っていたらすみません。
語源は何だろうと調べてみたところ、ギリシャ語由来らしいです。これまたGoogle先生情報です。

early 19th century: formed irregularly from Greek heuriskein ‘find’.
(19世紀初頭:ギリシャで「見つける」を意味するheuriskeinから不規則活用された)

ちなみにアルキメデスの「エウレカ!」と同じ語源のようです。
f:id:yuki_shiro:20200301175842p:plain
こういう豆知識が好きなので個人的にテンションがあがりますw
雰囲気としては、経験などから発見して学習する、みたいな意味合いになるでしょうか。

ヒューリスティックという言葉が出てくる分野

ざっとググってみた感じ、心理学、教育分野、IT、証券などで出てくるようです。人の心の動きに関わるものなので、人間のかかわる活動全般に出てくるということかと思います。「経験から学ぶ」といういい意味でも使われるし、「経験に縛られる」という悪い意味でも使われるようです。

JSTQBテストアナリストで出てくるヒューリスティック評価法とは何か

テストアナリストのシラバスでは、使用性テストの文脈で出てきます。該当箇所はこちら。

ヒューリスティック評価(使用性に関するユーザインターフェース設計の体系的なインスペクション)は、設計における使用性の問題を発見するのに使用できるので、イテレーティブな設計プロセスの一部として使用できる。
(4.2.4.2 使用性テストの詳細 p44)

ユーザビリティの専門家が対象となるシステムを見て、経験則に基づいてUI上の問題点を発見する手法だそうです。専門家ではなくても、あらかじめ用意されている観点があるので、それに沿って評価できます。あらかじめ用意されている観点としては、ヤコブ・ニールセンのユーザビリティ10原則が有名です。原題は「10 Usability Heuristics for User Interface Design」です。ヒューリスティックという言葉が出てきてますね。
詳しい内容はこちらのサイトで確認できます。
www.nngroup.com

JSTQBアジャイルテスターで出てくるヒューリスティックとは何か

アジャイルテスターのシラバスでは、探索的テストの文脈で出てきます。該当箇所はこちら。

テスト時には、一連のヒューリスティックを適用できる。ヒューリスティックは、テストの実行方法と結果の評価方法についてテスト担当者をガイドする [Hendrickson]。たとえば、次のようなものがある。
A set of heuristics can be applied when testing. A heuristic can guide the tester in how to perform the testing and to evaluate the results [Hendrickson]. Examples include

  • 境界
  • CRUD(作成(Create)、読み取り(Read)、更新(Update)、削除(Delete))
  • 構成のバリエーション
  • 中断(ログオフ、シャットダウン、再起動など)

(3.3.4 探索的テストとアジャイルテスト p44)

最初の説明部分の文章は、分かりやすくするために英語版を併記しました。「A set of heuristics」と書かれているので、ここでは「経験則一式」くらいの意味で書かれているのだと思います。

以上、JSTQBの文脈で出てくる「ヒューリスティック」についてまとめてみました。何かの参考になれば幸いです。

参考

こちらのサイトや書籍を参考にいたしました。
ヒューリスティック評価
https://u-site.jp/usability/evaluation/heuristic-evaluation/
・ユーザーエクスペリエンスの測定

テスト手順、詳しく書くかざっくり書くか

こんなことをつぶやいたら、色々ご意見をいただいたので自分なりにまとめてみます。


具体的テストケースと論理的テストケース

JSTQBのテストアナリストのシラバスには、具体的テストケースと論理的テストケースについて言及があり、ざっとまとめてみると次の通りになります。

具体的テストケース 論理的テストケース
概要 テスト担当者がテストケース(すべてのデータ要件を含む)を実行し結果を検証するために必要な特定の情報と手順のすべてを提供する テスト対象とすべきものに関するガイドラインを提供し、テストアナリストが、テスト実行時に実データや手続きさえも変更することを可能にする
メリット テスト担当者の経験が少なくてもテストケースを見れば、テスト実行可能。再現性が高い。監査にも使用可能。 テスト実行時の変更を許容するため、具体的テストケースよりカバレッジが高い場合がある。
デメリット メンテナンスに労力がかかる。テスト実行者の想像力を阻害する場合がある 再現性が低い場合がある。

(Advanced Level シラバス日本語版 テストアナリスト 「1.5.1 具体的テストケースと論理的テストケース」 p13)
上記の概要は、シラバスからの引用ですが、具体的テストケースの方は、テスト実行の主語が「テスト担当者」となっているのに対し、論理的テストケースの方は、主語が「テストアナリスト」となっています。テスト実行するのが誰かによって、テスト手順や期待結果の粒度をどの程度書くかが意識されてるように思います。

具体的テストケースと論理的テストケースをどう使い分けるか

自分の使い分けについて考えると、テスト実行するメンバとの物理的距離と熟練度が大きく影響しています。

テスト実行するメンバが同じ場所にいる場合

使用するテストケース

論理的テストケースです。「××欄に任意の値を入れる」などの表現をよく使っています。

前提

テスト実行に入る前に、テスト実行してもらうメンバに、テスト対象の目的の説明やテスト対象を一緒に動かしてみるなどを行います。物理的距離が近いと、実行メンバの理解度の確認やなにかあったときのフォローが容易にできます。
ある程度複雑な手順が必要だったり、使用するコマンドなどを具体的に指定した方が良い場合は、テストケースとは別途、確認手順書を書いて具体的な内容はそこに寄せるようにしています。メンテナンスは必要ですが、テストケース一つ一つに手順を書くことに比べると、共通化できている分楽です。

良い点

テスト対象の目的、それで実現したいことを共有しておくと、こちらが想定していなかった問題を見つけてもらえることもあります。(逆に、うまく共有できていない時には、細かすぎるバグを大量に報告してしまったこともありました)
テストケースを書く量が少なくて済むので、メンテナンスが楽です。詳細にテストケースを記載する時間が浮くので、教育とかバグを見つけるための活動に時間を使うことができます。Twitterでもこのようにアドバイスをいただきました。

テスト実行するメンバが離れた場所にいる場合

使用するテストケース

具体的テストケースの方が多いです。特にあまりフォローができない場合は、テスト実行に迷わないように具体的に書きます。

良い点

テストケースの記載通りに進められる場合は、経験の少ないメンバでもスムーズに進められます。

悪い点

ちょっとしたUI変更で、テストケース通りに進められない場合は質問の嵐になることがあります。テストケースを修正するにも時間がかかります。物理的距離が離れていたり、さらに時差がある場合はフォローがしにくいので、自分の中には、この問題への対処策はこれといったものがありません。ある程度実行メンバを教育して、修正案を出してもらい、自分はそれを判断するだけにする、とかでしょうか。。

まとめ

テスト実行メンバが同じ場所にいる場合は、論理的テストケースを作成して、メンバへの教育を手厚くするのが良いと思います。離れた場所にいる場合は、よい対応策を募集中です。
最後に、ふとしたつぶやきにアドバイスをくださった皆様、ありがとうございました!

JaSST'20 RejectConに行ってきた

ピースオブケイクさんで、JaSST Tokyoに残念ながら落ちてしまったプロポーザルを供養するイベントがあったので、供養に参加してきました。イベント概要はこちら。
connpass.com

noteでのテスト自動化に関する取り組み(ピースオブケイク・増原さん)

※ちょっと遅れて到着したので、講演途中からのメモです。

  • MagicPod使ってる
    • クラウドシミュレータでシナリオが作れる
    • サポートが速い

 

  • 分かったこと
    • エンジニアを巻き込むの大事→はまりどころに二人で立ち向かえる
    • PR単位のFBになると実行時間長め
    • リリース前のテストで変更箇所に集中できる

Flow理論に学ぶレベルアップの鍵(Mark Wardさん)

リベラル・アーツの世界

リベラル・アーツはRIPPAなものを作るのに必要
フローはレベルアップの鍵。
強い状態(フロー)

  • 楽しさ、幸福感
  • 集中
  • 複雑さ:込み入った問題を解くこと

→フロー状態は能力と挑戦が釣り合っている状態。釣り合ってないと不安だったり退屈だったりする。

  • メンタルステート図
    • 挑戦と能力の度合いによって、心理状態にどう変化があるか
    • 挑戦ルート:不安→覚醒→フロー。フローに至るまでの速さは、理解の速さやスタート地点の差による
    • 能力ルート:くつろぎ→幸福→フロー。コントール感があるが、時間がかかる

→頑張れないなら、頑張り方を変える必要がある。それには組織の理解と協力が必要

WebアプリケーションE2Eテスト自動化の3つの壁(末村さん)

自動化の現実

自動化は進んだものの

  • バグを検知できない
  • 思ったより高頻度で実行できない
  • どうでもいいところでコケまくる

バグ検出できないことへのアプローチ

  • 網羅性が低い
    • スナップショットテスト:HTMLの差分を比較(Jestとか)
    • ビジュアルリグレッションテスト:スクショを比較(CodeceptJSとか)
    • 実行時エラーを検知

実行速度問題へのアプローチ

  • テストデータをAPIやコマンドで作る
  • 通信部分だけ実行する
  • 状態をキャッシュする:ログインを毎回やるのはつらい
  • 並列実行(Zalenium、Selenoidなど)
    • 注意点:何度実行しても同じ結果になるようシナリオを作っておく必要あり

安定性へのアプローチ

  • 失敗したステップをリトライする
  • シナリオをリトライする
  • 不安定性を可視化する(Allure Reporterがいい)

まずはE2Eは難しいことを理解する

  • E2Eでしかできないことに注力しよう

おまけ

プロダクト開発におけるアジャイルQA活動(生井さん)

不採択の理由を踏まえる

  • 品質は健康診断*アジャイル開発→最近QAとお医者さんの話題も上がってるし着眼点は悪くなかった
  • 査読コメント
    • チームに展開した結果はどうだったかの事例がききたい(説得力)

伝えたかった事

  • 開発に終わりはない:プロダクトは成長・複雑化していくが、テストリソースは同じ勢いでは増加しない
  • 広さ*深さに加えて時間
    • 広さ:品質特性を軸にどこを見るか
    • 深さ:どこまで見るか
    • 時間:適切に発見できるか
    • 時間*深さ 素早く検査できるか、頻度を意識する必要がある
  • ソフトウェアテストの海はとても広い
    • 物量が膨大になった中でどう理想に近づくかが腕の見せ所

当たり前のことを当たり前にやる

テスト?自動化?それよりもQA/QCの業務とは(仮)(gremitoさん)

プロダクトに最もあう品質チェック作業を模索または最適化

QA/QCのリーダーシップ
QA:品質保証
QC:品質管理

終盤にいくら頑張ってもバグをつぶせない

  • 開発メンバとのコミュニケーションはとっていたか
  • テスト計画は開発の序盤あたりから始められていたか
  • 開発のMTGに参加して状況を把握しているか

開発チームの中にQAメンバがいる
QAは初めの方から参画する
品質チェックに入る前にテスト計画とテストケース作りを終わらせる
→開発チームの一員

ウォーターフォール(V字)開発でモブ設計してみた(t_isekiさん)

問題点

  • 開発者が特定のモジュールを設計、開発する
  • システムテストフェースで後戻りが大きすぎる

実現したかった事

  • やり直しを減らしたい

なぜモブか?

  • ファシリテーションが難しい(めくら承認、設計した人が悪者に)
  • 作業管理が面倒
  • 問題 vs 私たちの構図にしたい

モブ設計

  • 準備
    • 主担当が章立てを容易
    • 章立てに対して気になることや注意点などを参加者がメモ
  • 実施結果

<Good>

  • 要件や設計思想の統一認識
  • ドキュメント整備
  • テスト設計のシフトレフト
  • 当事者意識が芽生えた

Improve

  • 長時間やるとだれる

感想

テストに対して、リベラルアーツや自動化やチームのお話など、色々な切り口からの発表があって、どの発表も楽しめました! 本当にこれRejectなのかと思うほど、素敵な内容でした。企画、登壇者、スタッフの皆様ありがとうございますー!

「テストの宿泊型ワークショップWACATE2019冬参加報告」で参加報告してきました

先日WACATEの参加報告会が、ビズリーチさんのD3で行われ、私もそこでLTをさせていただきました!
イベントの詳細はこちらからどうぞ。
d-cube.connpass.com
当日の様子はTogetterにまとめられてるので、雰囲気を知りたい方はこちらもどうぞ!
togetter.com
WACATEのテーマの一つに「加速」があるのですが、どの方のプレゼンも加速感あふれてて素敵でした。

K氏「開発者からQAになった話 とWACATEに行ってきた」

概要
  • 知識量は土台、思考力がより良い結果を導ける
  • テスト技法とかの土台があって、思考力によってより良い結果を導く。知識と思考のバランスが大事。
  • プロセス改善もQAの業務。リリース後の問い合わせのパンクを防げたりした。
  • 業務フローを把握していればシナリオテストに流用できる
感想

開発、QA、PM的な立場を経験されている方なので、それぞれで得た見方を、役割を変えても生かしてるところが素敵です。QAから改善のボールを開発に渡して、開発者が続けてくれてるのがすごいなと思います。

たおかさん「WACATEにより爆発的に加速したQA歴3か月の新卒の話」

なんと初LTとのこと!

概要
  • 新卒3か月目「QAだったらどうする?」開発者の質問に答えられず。→自分に自信がない。QAとして情けない。
  • そんなとき、上司から「WACATEってイベントがあるよ!」
  • お気に入りのセッションソフトウェアテストの7原則
  • 参加後、自分で考えて動けること
    • 目の前のことではなく、その背景や理由を念頭に対応する
    • 言語化して誰かに表現することにより、真に自分の理解が深まる
感想

新人でWACATEに参加して、さらにLTまで立候補する加速感が素晴らしすぎる! (自分が新人のころをふりかえると、日々の業務でアップアップでそこまでのチャレンジ精神はなかったと思います)
素敵なのは、自分で「テスト完了することがゴールになっていた」と気づいたことだと思います。内容も素敵だったし、初LTとは思えないくらいに堂々と発表されてました!

かなさん「WACATEに参加すると・・・?」

概要
  • WACATE参加前「なんとなくテストケースを書いて、なんとなく実施する人」
  • 参加した後
    • 言語化大事と気づいた!
    • なぜを常に考えるようになった
    • 社外に相談できる人ができた!
  • WACATEではワークはうまくいかなかった。プロダクトの特性を考えずにテストしようとしてた。
    • しかしWACATEは業務でないので失敗できる。失敗をもとに加速できる!
  • 自分のプロダクトで大事なものはなんだ?を考えて社内の同じチームの人に話せるようになった
感想

スライドをご覧になっていない方は、ぜひスライド見てください! かなさんのイラストや図がとてもかわいいくて引き込まれます! 
WACATEの説明や、雰囲気などが伝わってきて、とても素敵なプレゼンでした! WACATEについてやセッションの説明もとても丁寧で、WACATE未経験者にはすごく伝わりやすいプレゼンだったのではないかと思います。

02さん「WACATEとテストと開発エンジニア」

概要
  • 参加の動機:品質悪いと上司に言われて夜泣いた→自分で品質を良くするために勉強したい
  • 品質やテストについて一緒に勉強する仲間が欲しかった
    • とにかく手を動かして勉強したい
  • セッション中の学び:ただ覚えるだけでは得られない経験・知識を得た
  • 自分一人では理解できなかった分野を理解できた
  • WACATEは一つのコミュニティ
  • WACATE後
    • テストやテストコードをテーマに登壇するようになった!
    • 知識:ある程度実践した見たものばかりに!
    • アウトプット:たまにテストのテーマで登壇するように
    • テスト仲間:Twitterフォロワーの1/3!
感想

WACATEで得た仲間のことを「社外の同期」や「WACATEは一つのコミュニティ」と言っていたのがとても印象に残りました! 私の感覚としても、すごく実態に合ってる素敵なワードチョイス。「同期」という言葉が、気軽に相談できて、一緒に切磋琢磨できる感じを表してて本当に素敵です。
プレゼンの進め方も、ゴールの提示がはっきりしていてわかりやすかったです。

信頼貯金さん「WACATE参加報告 ~WACATEに参加した前後で何が変わるのか~」

概要
  • WACATEとは
    • テスト活動の基礎からアドバンスドまで扱う
    • 分野の知見を豊富に持つ人から話を聞ける
  • ワークや分科会で一気通貫で理解が深まる
  • WACATE 2019夏
  • テスト計画の誤った理解をアンラーニング
    • 「計画は守るために作るものだ」から、計画は手段、プロジェクトの狙いを反映していい、に変わった
  • テスト計画を守れないとき、できないときはできないと言っていい。それはチームで解決すべき問題
  • WACATE冬、テーマが多い。すごいポテンシャル
  • 自分一人では到達できないできないところに到達できる!
感想

テスト計画に触れたところで「テスト計画を守れないとき、できないときはできないと言っていい。それはチームで解決すべき問題」と話されてたのが印象に残りました。「アンラーニング」がキーワードなのかなと思いますが、こう思えるようになった学びが素敵です。

shiromoto「WACATEで得たものとその活かし方」

発表の感想

WACATEの参加動機、駆動方法は色々ありますが、その一つに「カープ優勝駆動」というものがございますw 勢いでも何でもいいので、飛び込んでみると世界が開けるよ、という話だったのですが、もし誰かの背中を押せてたら嬉しいな、と思います。WACATE参加で仲間が増えるのは、本当に参加のメリットなので、迷ってる人がいたらぜひ一度参加をお勧めします。

きんぢさん

概要

WACATE実行委員の宣伝のセッションでした。
WACATE実行委員をやると、次の力が身に付くそうです。

  • アウトプット
  • プレゼン構成力(少しずつ解像度を上げていく)
  • 合宿の企画力
  • 仕組化・自己組織化
  • 実行委員はいいぞ!
感想

WACATEで参加者が解散した後、片付けや次の予約、次の次の仮予約まで済ませてくださってるという実行委員の方々には、感謝しかないです。毎回ありがとうございます!
WACATEで得たものを日々の業務で活かしたり、悩んでるテストエンジニアにWACATEを進めたりで、恩返しや業界への貢献をしていきます。

「数学ガールの秘密ノート/学ぶための対話」は、学生時代に数学をパターン暗記で乗り切ってしまった人にお勧め

昨年参加したソフトウェアテストの合宿形式の勉強会・WACATEのお楽しみ抽選的なイベントで『数学ガールの秘密ノート/学ぶための対話』をいただきました。

色々とぐさりと来るところがあったので、ちょっと感想などを書いてみます。なお、数学ガールはシリーズものですが、私はこれ一冊しかまだ読んだことがありません。

この本をお勧めしたい人

数学が苦手で、パターン暗記で乗り切った人にお勧めします。私はほぼパターン暗記で学校の数学を乗り切ったタイプです。

なぜお勧めできるか

私は数学が苦手です。苦手な理由は、恐らくですが中学・高校時代に数学を理解せずにパターン暗記で対処していたからではないか、とこの本を読んで思いました。

本の中で何度か主人公で数学の得意な「僕」は、数学を教わりに来てる「ノナちゃん」から「暗記しますか?」と聞かれます。暗記ではなく理解するよう主人公は諭すのですが、まさに暗記してたのが昔の私です。たぶん今もその傾向は続いていると思います。

パターン暗記の問題点

自分の場合ですが、パターン暗記のやっかいなところは、パターン暗記で教科書の理解確認問題や中間テストは対処できるので、理解できてないことに気づきにくい点でした。そして、単に覚えているだけなので、当然忘れていきます。

範囲の広い実力テストなどになると、中間テストに比べると正答率が劣るので、うっすら「実は分かってないかも?」と疑います。その時に理解するよう動けばよかったんだと思いますが、今思うと、自分の対処は「暗記するパターンを増やす」と「反復練習して記憶から抜ける量を減らす」でした。受験対策としては間違ってないんですが、理解が進んだかといえば、ちょっと怪しいです。

この本のお勧めなところ

この本では、言及されている数学の範囲は、一次関数とグラフのみです。それだけなので、パターン暗記で覚えてしまおうとするとすぐ済む内容なんですが、暗記ではなく理解を促すように話が進みます。ちょうどパターン暗記してしまいそうになるあたりで、ノナちゃんが「暗記しますか?」と聞いてくれます。自分も暗記に走りそうになっていたことに気付けるので、ノナちゃんと一緒に意味を考えながら読めるようになっています。

数学をパターン暗記で乗り切った人が、意味を理解するってなんだろうと思いながら読むと、ちょうど良い本だと思います。

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

2日目レポートも行ってみまーす。

f:id:yuki_shiro:20191215130639j:plain
三浦海岸の朝焼け

モーニングセッション:Agile Testing Days 2019 参加レポート

ブロッコリーさん)
資料はこちら!
speakerdeck.com
Agile Testing Days:ドイツのポツダムで11月に毎年開催、全日程6日間、参加費は約30万円。
800人くらいが参加する。キーノートだけで14個!本会議のセッションは9レーン。
セッションには認知科学や健康がテーマのものもある。
「人間てのは壊れた櫛だよ。人それぞれ得意不得意がある。だからチームとして動くといいよねー」みたいなこと主張してるセッションがあったり、ホームズとワトソンになりきってるセッションがあったり、着ぐるみで発表しようとしたけど暑くて開始3分で脱いだり、とか多様すぎる。ドイツと南アフリカにすむ二人が学習パートナーシップを組んだ結果、毎日カンファレンスに参加している気分になった!→距離について言い訳するのはやめようぜ!

感想

国際カンファレンス楽しそう!特にAgile Testig Daysはフリーダム度が高くて面白そうなのが伝わってきました。資金面は何とかするにしても一度行ってみたいですね。なお、手軽に国際カンファレンスを楽しむ手立てとしては、OnlineTestConf Japanもございますので、よろしくお願いします(宣伝)!

アジャイルとテスト

(つのださん)
資料はこちら!
speakerdeck.com

アジャイルについて

世の中の流れが速い、ニーズをそもそも完璧に確定するのが難しい

  • アジャイル向きなシステム:外部要因に大きく影響を受ける
  • アジャイル向きでないシステム:不確実性があまりないシステム。ミッションクリティカルとか
  • アジャイルソフトウェア宣言→ソフトウェアをよりよく作るための考え方

アジャイルのテストについて

アジャイルのテスト→フィードバックを得るため

  • 頻繁なコミュニケーション
  • 手戻りを減らすための複数人同時作業
感想

アジャイルに向くもの、向かないものの説明も含めて、短いけど丁寧にアジャイルとテストをまとめてもらえたセッションでした。アジャイルのテストは「フィードバックを得るため」は、確かにそうだなーと思います。自分の現場でも、フィードバックを早めるための施策は試行錯誤してるので、レビューでのフィードバックなど地道にやっていきます。

ソフトウェアテスト業界でのステップアップを考えよう

(きんぢさん)
資料はこちら。

www.slideshare.net
メモも貼っておきます。
f:id:yuki_shiro:20191215130719j:plain

感想

「品質 is 何」や「3年後どうなっていたいか」のような問いかけで、班のメンバーから本当に現場に応じたいろいろな意見が出てきて面白かったです。自分にとっての品質は、「ユーザがシステムで解決したいことを解決できている」とか「やりたいことをより簡単に、楽にできるようになっている」とかだと考えています。これが医療機器とか自動車とかに携わる方になると、「人が死なないこと」とかが出てくるのだなーと自分にない視点が出てきて面白かったです。
テストの分け方はテストレベルやテストタイプ、自動化などいくつか種類があるので、この後のキャリアのために自分がどの位置で仕事しているのかを把握するのは重要だと思いました。キャリアマップを作りたいなーと思っているので、このセッションからヒントをいくつかもらえた気がします!

WACATE流勉強会の作り方

(えっちゅーさん)

  • 勉強会をやるとよいところ
    • プロジェクト運営の疑似体験ができる
    • アウトプットすることで思考の整理、分かるところ分からないところの明確化ができる
  • 勉強会をやるのに考えること

時間

  • 必要な時間は?
  • 会場、準備にかかる工数

会場

  • 人数と会場の広さ
  • 必要な設備が整っているか
  • 開催希望日に利用ができるか

事前準備

  • 参加者に事前にやってきてもらうと嬉しいことは?
  • 持ってきてもらいたいものはある?

開催回数

  • 今回限り? 何度も開催する? 定期/不定期?

対象者

  • どういった人に参加してもらいたい?

運営にかかるお金

  • お金をかけずに開催できる? かかる場合、何にどれくらいおかねがかかる?
  • 必要な金額はどうやって集めるか?

登壇者

  • 自分たちが話すか、講演者を呼んで話してもらうのか?
感想

WACATEに限らず応用できる話ですが、WACATEの実行委員の方々がすごくこだわって勉強会を作られてるのが伝わってきました。ここまで考えてくださってるの、本当にありがたいです。
自分が主催した勉強会で、テーマ設定と参加者のレベル感を上手く合わせられず、ちゃんと勉強会の設計しておけば良かったと後悔したことがあるので、次に活かします。

招待講演:テスト設計をより良くするモデリングと観点分析

資料はこちら!
speakerdeck.com

感想

講義のために簡略化されたとはいえ複雑なテスト対象をモデリングして、リスクまでクリアに見えてく様子がすごく綺麗でした!あれを自分でできるようになりたい。
モデリングはわりと難しくとらえてたところがあるのですが、比較的簡単なものはテスト技法ですでに使ってるというところで、ちょっと勇気が出ましたw にしさんの「絵(図だったかも?)を描け」に通じるところがあって、本質はたぶん同じことを言ってるのではないかと思いました。
モデリングで知識の部分はごく一部で、目的に応じて使い分けるところが難しいと感じます。テスト技法自体は知っていても、現実のどの場合にどの技法を当てはめればいいのか、すぐには判断つくようになりませんでした。要件レベルになると経験があまりないので挑戦になりますが、ここができるようになるとビジネスに貢献できる幅が広がるので、自分としては今後の挑戦のしどころです!

2日間を通じての感想

テストに情熱を持つ方々とワークしたり、お話したりできて楽しかったです!場を作ってくださった実行委員の方々、話してくださった参加者の方々ありがとうございます!
今後やりたいことへのヒントがもらえました。息切れしないようにちょっとずつ加速しますw Twitterアイコンとご本人が一致した方が増えたのも嬉しかったです。またどこかの勉強会でお会いすると思うので、よろしくお願いします。