2016/6/18(土),19(日) 「WACATE2016夏　～走りきるテスト設計～」に参加しました。

「Workshop for Accelerating CApable Testing Engineers」、通称WACATEに参加してきました。神奈川県・三浦海岸にテストバカが集まって夜通しテストの話をする勉強会です。
WACATE2016 夏 ～走りきるテスト設計～ 開催概要 - WACATE （ソフトウェアテストワークショップ）

以下、前回の参加レポートです。
toshimana.hatenablog.com
…2015夏も参加しているはずなのですが、レポート書いていなかったですね。

概要

タイトルに"走りきる"と書いてある通り、「テスト分析」から「テスト設計」、「テストケース実装」までの一連を行うことが今回のメインテーマとなっています。

「テスト分析」「テスト設計」「テストケース実装」を全て行うワークショップは、JaSST'16東北の企画当初に想定し、最終的に断念したテーマでもあります。
ワークそのものにも興味がありますが、どんな運営、ワークをするのかに凄く興味を持って参加しました。

BPPセッション 近美さん

ASTER-テスト設計コンテスト'14の優勝チームの一員である近美さんの発表は、まさに今回のテーマにうってつけだと言えます。「テストエンジニアはどうあるべきか」の話だったり「テスト技術があると何が嬉しい」といった話があり、上流から下流までの様々な話題の詰まった満足度の高い発表でした。特に印象に残ったものを書き出します。

「始めるのは危機感、続けるのは楽しさ」

普段は意識しないけど、言われると納得する一言。「炎上駆動改善」のように、普段動かない人を動かすには危機感を煽るのが有効。だけど、それではどこかでガス欠になってしまう。なので、楽しさを体感できる仕組みも必要。ゲーミフィケーションがフィットする？この一言は自分の成長サイクルを見直す一環にもなる。

テスト活動も「段階的」戦略で構造設計が必要

良い(と自分が信じている)ものでも、周りは正しく(=自分が期待する通りに)理解してくれない。他人に伝えるためにはどう伝えるかを考える必要があるし、伝える言葉によって、伝わり方が変わることもある。他人を変えることはできなくて、自分が変わる事しかできない。なので、他人を最適化するためには、自分がどう振る舞えば良いかは良く考える必要がある。

ゲストセッション 秋山さん

www.slideshare.net

テスト分析手法「HAYST法」考案者である秋山さんの講義。テスト要求分析で基本となる「分解」について、どのように考えればよいかを説明いただいた。十分に洗い出せているかを確認するための分解フレームワークの紹介や、どのように分解できていると良いのかの例示など。60分という時間ながら、濃厚かつ分かりやすい内容。テスト分析のチートシートとしてスライドを持ち歩きたい内容でした。

ワーク「走りきるテスト設計」

1チーム6人で、二日間を使ってテスト分析ーテスト設計ーテストケース実装を体験する大ボリュームのメインワーク。WACATE実行委員から「WACATEへの参加登録システムのテストケースを用意してほしい」という依頼に応える体のお題でした。お題の説明資料が来た時は、「こんな大ボリュームが二日間で終わるのか！(いや、無理だろう)」と思ったのですが、チームメンバーが上手く協力できてなんとか走りきることができました。

テスト分析

顧客要求や対象のシステムから何をテストしなければならないかを分析する。

  • テスト要求分析：システムの目的の洗い出し
    • 誰が何の目的でこのシステムを使うのか
  • テスト対象分析：画面項目や入力項目の洗い出し
    • 画面A、画面Bなどの画面の種類の洗い出し
    • 氏名、メールアドレスなど入力項目の洗い出し

雑な言い方をすると、テスト要求分析はトップダウン、テスト対象分析はボトムアップな洗い出しになりやすい。理想としては、ボトムアップとトップダウンが繋がるのだけれど、時間の都合で今回はそこまではいかなかった。

感想

仕様書に引っ張られた印象がある。テストエンジニアは仕様書に書かれていない所を含めて不具合を見つけることが求められるが、仕様書以外のテストすべきことについては十分な議論ができなかったことが反省点として挙げられる。

テスト設計

テスト分析で出てきた項目に対して、テスト設計技法を用いてテストケースを作る準備をする。何をテストするかをモデルを書いて整理することで、テストケースが十分であることを担保する。今回はテスト設計技法として、以下のモノを利用しました。

感想

技法ありきのモデリングとなった印象がある。テスト設計技法を使うことが網羅を担保することにはならないはず。何を保証したいのかを整理した上で、それぞれの保証したい内容をテスト設計技法で整理する方が望ましい。技法を使えることに満足してはいけない。

テストケース実装

テスト設計で作成したモデルに基づき、テストケースを生成する。テスト分析のワークショップではテストケース導出までやることはほとんどないので、テスト分析、テスト設計したものでテストケースを出してみるのは楽しかった。最後の報告で、モデルとテストケースを照らし合わせて「我々はこれでテストの網羅性を担保しています」とドヤ顔でいうのも楽しかった。

感想

チームではユースケーステストを担当した。ユースケーステストはまともに作成したことがなかったが、シナリオテストとして作成してみた。シナリオテストでは、シナリオを実行することで「シナリオ通りにシステムが動作するか」を確認するテストだと思っていた。しかし、シナリオを作成する過程で「このシナリオは現実に即しているか」をレビューして、実利用時の挙動から新しいテストすべきことを見つける役割もあるかと感じた。

まとめ

運営側の目線でワークショップの内容についても考えていました。本ワークショップオリジナルのテスト対象なのに、仕様書が良く作り込まれており、運営側の力の入り具合が感じられました。ワークショップとしてとても楽しい二日間でした。欲を言えばJaSST東北実行委員として、WACATE実行委員と運営やワークの内容について色々意見交換したいと感じました。*1

*1:だから、WACATE実行委員は7/2(土)のJaSST'16東北おかわり会に来ればいいと思う。 tohoku-dev.jp

2016/4/23(土) 「とちぎテストの会議04」に参加してきました。

那須野が原ハーモニーホールで行われた「とちぎテストの会議04」に参加してきました。
d.hatena.ne.jp

今回で2回目の参加になります。
前回参加した時の記事はこちら。
toshimana.hatenablog.com

今回の昼食はご当地大盛中華料理店「阿Q」で揚げ焼きそば、肉丼、餃子をいただきました。仙台テストクラスタのマスコット様と一緒に食べたんですが完食ならず…
余りは持ち帰りパック(お店で販売してる)に詰めて持ち帰りました。
f:id:toshimana:20160424093431j:plain


「つくるいとなむ」をテーマにしており、
テストの話だけではなく、教育、成長に関する話が多かったです。
とても刺激的な話を沢山聞くことができました。那須、楽しい。

招待講演

『会社をHackするために未来会議をやったら出版流通をHackすることなったでござるの巻』岩切さん

speakerdeck.com

凄まじかった。

『失敗ばかりの開発チームをいとなむ』椎葉さん(@bufferings)

b.hatena.ne.jp

良いものを作れたら嬉しい、と大体のメンバーが思っている。開発チームで良いものを作る方向に動いていない(と自分が思う)ことが多い。悪いのでは人ではなく「場」。人の動きを阻害する「場」を何とかする。何度も繰り返し伝えたり、自然と気づける仕組みを導入したりした。

感想

環境を変えると人も変わる。椎葉さんは恐らく「文化」を作ったんだと思う。
あと、自分の愛娘を預けたい、と思えるチームを作るというゴールがあることが素晴らしいと思った。自分のためにチームと一緒に成長したいという、理想的なモチベーションが保たれていると感じた。また、自分事だからこそ、現実から目を背けずにいられるのだと感じた。

一般講演

[経験と、ルールと、知識と] 松尾さん(@Kazu_cocoa)

www.slideshare.net

障害の再発防止として、「今は経験ベースだから、ルール(自動化、チェックリスト化)ベースを増やしていこう」というのを実践し、さらに踏み込んだ内容。ルール／知識ベースの障害対策を覚えた人より、経験ベースの人の方が障害が発生した時の事後対応を適切に行える。しかし、失敗への予防は経験だけよりも知識／ルールがある方が役に立つ。重要なのは学ぶこと(対象を理解しようとすること)。知識／ルールも深掘りすることにより「経験」を覗くことができる。それを自身に転化できたら面白い。

感想

ルール／知識を中心に理解した場合、そのルール／知識にしか焦点が向かなくなる「思考が縛られる」状態に陥ることがある。ルール／知識はとても有用だが、思考が狭まるものにならないよう、学び続けることが必要だと感じた。

[チームメンバーを"テスト"する] やっとむさん(@yattom)

www.slideshare.net
新しいチームメンバーには定期的に(毎週)試験を実施する。試験は点数を判断するものではなく、チームが何を大切に感じているかを伝えることに利用する。

[剪定テスト] よねざわさん(@vestige)

www.slideshare.net
剪定（せんてい）とは樹木の枝を切り、形を整えたり、風通しを良くする事。 見た目を美しくするのみでなく、養分を効率よく利用させて生長を促進したり、病害虫の繁殖を予防する効果がある。*1

[0からはじめたUIテスト・ABテスト～スマホアプリ開発の経験をもとに～] @ki_macho

大学生が作ったアプリでUIの改良にABテストをやってみた。大学生のアプリ作成はウェーイになりがちだから、しっかりした方法でやりたかった。

[テスターのドロア（わたしのあたまのなかのひきだし）～プログレスダイアログの巻～]みわさん(@miwa719)

speakerdeck.com

みわさんがプログレスダイアログをテストするときのテスト項目の紹介。「何を考え、何を心配しているのか」を伝える目的。
プログレスダイアログの「しばらくお待ちください」のメッセージがあるとき、時間が長すぎないか、短すぎないかがテスト項目にあるなど、仕様書には出てこないような内容もテストするところは流石だと感じた。

[割とみなさん挫折しているかと思いますが、実践アジャイルテストの第５部は意外とよく出来てると思います。正誤表もででます。] 川口さん(@kawaguti)

speakerdeck.com
タイトルの通り。途中で出てくる第5部の全体像の図は世界一わかりやすい(らしい。川口さん談)

[テストと情報エントロピー] 松山さん(@Dai_HungryWater)

www.slideshare.net
テストの良し悪しを情報エントロピーで表現できるのではないか、という話。情報エントロピーが大きいテストほど良いテストなのではないか。

[かえりみち] (@track8)

speakerdeck.com
雪月花に合わせて季節に沿ったバグを紹介。ログ出力の年月日が日本表記か英国表記かの違いと最新ファイルの指定方法が名前ソート(年月日が日本表記でしか機能しない)が組み合わさったバグ、熱によるクロックダウンによるシステムの速度低下、サマータイム問題など。だいたい、エンジニアは何もしていない。

「チョットデキル人に訊け！」

秋山さん(@akiyama924)、和田さん(@t_wada)、関さん(@m_seki)によるパネルディスカッション。和田さんだけお題を事前に聞いていないというサプライズがありました。秋山さん、関さんが事前に準備した回答であることを強調し続けるおまけ付き。


凄い人の話を聞いたときどうするか

秋：凄い話は理想に近い。理想と現実のギャップを理解すること。
和：成功した人がする成功した話は一番きれいな話。そこから成功のパターンを掴むことが大事。あと、前に出てきていない話(苦労話など)を聞く。

ちゃんとテストしているか

秋：リスクの高い項目(健康・財産・環境)は特にテストが必要
和：開発と品質保証のテストが異なる。開発は自身が近くした範囲でしかテストできない。開発者が自信を持てるテストと製品として十分な品質を担保するテストは異なる。品質保証のテストを行うには、自分が見ている枠の外に視野を広げる必要がある。他人の考えをテストに取り入れられているかが重要。

テスト上手くなりたいか？

関：テスト上手くなりたい、とは思わない。興味のあることをやっているだけ。

感想

「興味があることだけをやっている」という関さんにとって、テストを含む多くのモノはその興味を満たすために必要だからやっている、という感覚なのかと思った。ぶれないビジョンがあるからこそ、良いものを作るために淡々と前に進めるのだと感じた。

その他

フリートーク

ガチなスライドを用意して、2分発表しました。

www.slideshare.net

テストの地図

みわさんから「テストの地図」についてお話しいただきました。良い価値を届けるための開発に使えるテスト技法としては「テストの地図」はこれまで触れた中では最も理想に近いと感じた。
miwa719.hatenablog.com


感想

感想をまとめるの大変なくらい盛り沢山の内容でした。また来たいです。

*1:引用：wikipedia https://ja.wikipedia.org/wiki/%E5%89%AA%E5%AE%9A

2016/4/9(土)「JaSST東北2016準備会(仮)」：VSTePのやり方を変えてみたら失敗した話

仙台は今、VSTePが一番熱い街らしいです。

JaSST東北実行委員が集まって、一日かけてVSTeP勉強会を開催しました。仙台在住組は何度か集まってやっていましたが、今回は福島組や北海道からも人が集まって「かんばんりすと」を対象にしてVSTeP演習を実施しました。慣れていないメンバーがいたり、本会はテスト分析に慣れていない人がたくさん来ることもあって、より効率的にVSTePでテスト観点図作成ができないかの試みをしてみました。以下のようなことをやって大失敗したので、それらの話をまとめてみました。

  • テスト観点図作成時にあらかじめ大枠を用意してみた
  • テスト観点図作成時に因子水準表を作ってみた

今回のVSTePでのテスト分析手順は以下のように実施しています。

  1. 仕様書確認
  2. 仕様についての認識合わせ(フリートーク)
  3. テスト観点洗い出し
  4. テスト観点グルーピング
  5. テスト観点図作成
  6. テストコンテナ作成
  7. テストコンテナ依存関係整理

テスト観点図作成時にあらかじめ大枠を用意してみた

やろうと思った理由

テスト分析に慣れていない人がVSTePをやると、恐らくテスト観点洗い出しまでは何とかなるが、テスト観点図作成はとても苦労すると予想した。そのため、あらかじめ最終形が見える大枠を用意することで、慣れていない人でも大きな失敗なくテスト観点図が作成できるのではないか、と考えた。

やったこと

テスト観点グルーピングをしたあとに、テスト観点図のトップレベルにあらかじめ、「入力」「テスト対象」「出力」の大枠を置いてみた。大枠に基づいてテスト観点のグループごとにテスト観点図を作成してみた。

やってみた結果

大失敗した。全く納得のいく形にならなかった。
始めは上手くいく予想があったし、分かりやすいテスト観点は大枠の下にぶら下がる形になった。しかし、分類が難しいテスト観点が出てきたとたんに手が止まってしまった。さらに、しばらく考えてもどのように整理すればよいかのアイディアが出てこなかった。

面白かった事

「入力」「テスト対象」「出力」の大枠を外して、通常のVSTePの手順でやってみた。メンバーが慣れていることもあって、テスト観点図はスラスラと組み上がっていったのだけど、最終的に「入力」「テスト対象」「出力」の形になっていた。

分析

共通認識がない状態で、枠に当てはめようとすると、周りと意見が合わない、納得のいくモデルにならない。
決められた枠を用意すると、思考が「枠の中にどうすれば収まるか」に変わってしまう。

感想

テスト観点図作成フェーズで作るべきは、洗い出したテスト観点の「納得のいく構造関係」。フェーズ始めはチーム内の納得感がズレているので、それを合わせていくことが重要である。チーム内の納得感がずれている状態で枠を与えてしまうと、チーム内に取り戻しのつかないギャップが発生してしまうように感じた。チームの納得感に合わせて進めていくことが大事であり、大枠を用意してもチーム内の納得感を生み出す働きは起こらない。

テスト観点図作成時に因子水準表を作ってみた

やろうと思った理由

VSTePに慣れていない場合、テスト観点図のイメージが湧きにくい。テスト観点をMECEに洗い出したものが欲しいのであれば、別の手法で洗い出してテスト観点図のツリー構造に落とし込めば上手くいくのではないか。

やったこと

今回は因子水準表を作ってMECEのようにテスト観点を洗い出した。
f:id:toshimana:20160411081212j:plain

やってみた結果

因子を根、水準を葉としたツリーができた。しかし、次のテストコンテナ作成フェーズでは、テストコンテナを適切なまとまりで抽出することが難しかった。因子間の関係性についてチーム内の認識が合わせられていないため、テスト可能なまとまりの抽出に苦労した。

分析

「何をテストしたいのか」が見えないテスト観点図になっていた。因子水準表でまとめたが、MECEに洗い出した感覚はチームで共有できた。しかし、具体的なテストケースが出てこなかっため、テスト観点図が現実と乖離してしまったように感じた。

感想

VSTePを行う上で、現実との乖離が起きていないかはよく確認する必要がある。作ったモデルから、現実がイメージできないのであれば、モデルを見直すことを考える必要がある。

総括

VSTePに限った話ではないのだけれど、モデリングの肝は「納得できること」と「現実に即していること」だと感じた。2つを満たせていれば、例え実際に抜けがあったとしても、自信を持てると思う。自信を持てるからこそ、抜けがあったら真摯に捉えられる。技術は実力を効率良く表現するものであって、実力以上を出すものではない、と感じた。

反省点

「JaSST東北の本会も近いから、モデレータ育成をメインにやろう」という趣旨で始めたはずだけど、ガン無視でVSTePによるテスト分析に夢中になってしまった。

2016/2/21(日)「JaSST東北2016準備会(仮)」：テスト上流設計の嬉しいところ

テスト上流設計を体験したのだけど、人に教えるときには「テスト上流設計はイマドキ皆ヤッテマスヨ」では心には響きません。嬉しいことがあるからテスト上流設計をするのです。そのテスト上流設計の嬉しいところをまとめます。

テスト実行の戦略を立てられ、出戻りの発生を減らせる

テスト上流設計を行うことで、出てきたテストコンテナは不具合が起きた修正コストの見通しが立ちやすい。例えば、パフォーマンステストで失敗した場合、大規模な修正が必要になる場合がある。テストコンテナ間の依存関係を整理した上で、修正コストの大きいパフォーマンステストをできるだけ早く実行するテスト実行計画を立てることで、開発・テストの総工数を小さくすることができる。また、テスト計画が明確になれば、それに合わせて開発計画を最適化できる場合がある。テスト実施タイミングの設計はテストコンテナクラスのような抽象かされた項目が検討しやすい。

仕様変更時のテスト修正コストが低くなる

派生開発による機能追加が起こった場合、すべてのテストケースを洗い出すのにはとても多くの時間がかかる。しかし、テストコンテナのように抽象化されているモデルが存在すれば、テストケースの洗い出しを変更が必要なテストコンテナに限定できる。修正を毎回総当たりで行う必要がなくなり、テストケースの修正が容易になる。

ノウハウが溜まりやすい

テスト観点やテストコンテナでテストは抽象的なため、別案件へ応用しやすい。その別案件の検討で新しい観点が見つかれば、さらに別案件を成長させることに繋がる。例えば、未知のバグが出てきた場合に、そのバグから新しいテスト観点が生まれるかもしれない。それらのテスト観点はそのままテスト設計者のノウハウになる、と考えている。

感想

適切なテスト上流設計は製品の品質向上の道しるべとなる。テスト上流設計を学ぶと、テストと開発は自転車の両輪のような関係であると感じる。良いテスト設計は開発設計と繋がり、品質管理と品質開発が良い循環をすることで素晴らしい製品をつくることに繋がると感じた。

2016/2/21(日)「JaSST東北2016準備会(仮)」：Jasst東北メンバーのモデリングハマりどころ

「テストに興味がある」という点から、JaSST東北メンバーは一般的な開発者よりはテストに詳しい(ことが期待される)のですが、今回の準備会ではいろんなところでハマりました。今回は私たちがハマったポイントをピックアップしてみます。

ツリー構造の整理方法

状況

今回の勉強会に先立ち、事前にJaSST東北メンバーでツリー構造を用いたテスト観点整理演習を行っていた。できたツリーは機能の下が操作やデータになっており、統一感がないツリーになっていた。思いつくものは出したつもりだったが、見返しても十分洗い出せたか分からず、もやもやが残ってしまった。

症状

ツリー構造で整理しているのに対して、適切な上下関係になっていなかったり、同階層の要素が揃っていなかった。そのため、MECEになっているかが設計者が自信を持てていなかった。

解決

ツリー構造で整理する場合、上下関係や粒度が妥当かを意識すると良い。

  • 上下関係であれば、inheritance*1かcomposition*2で整理すると良い。一般的にはcompositionの方が網羅しやすい。
  • 同じ階層に並ぶ要素の言葉は合わせると良い。例えば、「設定反映」と並ぶ言葉は「設定画面」より「設定表示」の方がしっくりくる。

技術者は細かいところを気にするのは得意なので、気になったところを納得がいくように変えていくと良い。良い構造になっていると、抜け漏れに気づきやすくなる。

感想

ツリー構造による整理はテストに限らず良く使っている。しかし、事前の演習では上手く整理することができなかった。上手く整理できないときは、完成形のイメージを持たないことによる不安が根本にあると感じた。今回、納得できる整理の仕方を学んだことで、完成形のイメージを持たない「未知の対象」に対しても自信を持って整理できるのではないか、と期待している。

何をテストしたいのか

状況

テスト観点の洗い出しを行った後、テスト観点を整理していた。例えば、解凍機能を持ったアプリケーションのテスト観点で「操作」が上位階層に出てきて、その下に「ダブルクリック」や「ドラッグ＆ドロップ」が連なっていた。テストで確認したいものは「ダブルクリック」や「ドラッグ＆ドロップ」なのか？

症状

テスト観点で洗い出したものをグルーピングはしていたが、何のためにグルーピングをしていたのかが抜け落ちていた。

解決

テスト観点を整理するときは何をテストしたいのかを常に確認すること。例えば、「操作」そのものを確認したいのではなく、その「操作」を通じて別のモノを確認したいはず。

感想

観点の洗い出しさえ済んでしまえば、グルーピングはほぼ考えずにできると思っていたのが甘かった。「今自分は何のために作業しているか」は意識しておく必要がある。各作業の意味や前後の工程とのつながりを作業前にメンバー間で確認しておくと良いかもしれない。

モデリングと現実

状況

テスト観点を整理した後に、テストコンテナ設計を実施した。テストコンテナをテストを実施する時系列順に並べて、メンバー全員でできたモデルに納得していた。にしさんに確認してもらったところ、「実務でホントにこの順番でテストするの？」との指摘を頂いた。

症状

技術的な観点では作成したモデルに全員が納得していた。しかし、経験的、実務的な観点では作成したモデルは納得できないものだった。

解決

モデリングの演習などをしていると、直観からは離れたモデルになる場合がある。モデリングに慣れていない場合は、自分達の直観に合っているかをよく検討する必要がある。逆に慣習のような利点のないデザインパターンによるモデルが構築される場合がある。良いモデリングを追及すると利点のないデザインパターンを改善できる場合がある。

感想

「練習のための練習」は本番に役に立たないことが多い。新しい技術を学ぶ場合、その技術を理解することに注力するあまり、「実務に沿っているか」から意識がずれやすい。今回、現実に沿わないモデルを作ってしまい「ﾔｯﾁﾏｯﾀ」って思った。

*1:継承。ex. 人間-学生-大学生

*2:構成。ex. 人間-(頭、体、腕、足)

2016/2/21(日)「JaSST東北2016準備会(仮)」：VSTePの特徴

仙台ににしさんをおよびして、JaSST東北メンバーに対して、テスト設計を叩き込んでいただきました。
一日中テスト漬けでとても疲れましたが、とても力になる一日でした。
ありがとうございます、にしさん！

学んだ内容をブログにしようと思っているのですが、学んだことがとにかく多くて一度に出そうとすると膨大な量になります。
なので、いくつか分割してブログにしてみます。
今回は「VSTeP*1の特徴」で、にしさんが挙げた以下の2つをピックアップします。

  • VSTePは機能・データの列挙ではない
  • VSTePは設計者の満足度を高めるためモデル(図)を用いる

VSTePは機能・データの列挙ではない

テスト観点を洗い出す際、仕様書からキーワードなどを抽出することが多い。しかし、それは仕様書で表現したい機能やデータに関するテスト観点ばかりが出てくる。そのため、出来上がったモデルはは仕様書を構造化したものになる。大体にしてそのシステムの関心事がすべて仕様書に記載されていることはない。そのため、仕様書からテスト観点を抽出しても、そのシステムの関心事を抽出することができない。
テスト観点を洗い出すときは、一度仕様書から離れて、対象となるシステムがどういうものかを考える必要がある。特にシステムの関心事は開発者視点よりも利用者視点に立って、使う人たちはそのシステムにどのような関心を持つのかを可能な限り考えつくす必要がある。

感想

ある対象を理解するためには、その対象だけを見ているだけでは不十分であり、その対象の周りに何があるかを考える必要がある。仕様書を見ていると、仕様書が表現したい物を理解することはできる。しかし、その仕様書を元に作りたいシステムについては、仕様書からの理解では不十分ということだと感じた。仮に仕様書だけ渡された場合でも、その仕様書の上に作りたいシステムがあって、そのシステムを使いたい人がいることを考慮して、使いたい人に価値があるような設計をする必要があるんだと感じた。

VSTePは設計者の満足度を高めるためモデル(図)を用いる

テスト設計で重要なのは、テスト設計がその設計に満足すること。よくExcelにテスト観点をまとめたりするが、全体像が把握しにくい。VSTePはマインドマップなどのモデルを多用するが、それは設計者がテストの全体像を俯瞰しやすく、テスト設計の満足度が高くなりやすいから。モデル化して感じたもやもやを解消しながら満足度の高い設計を行うことが良いテスト設計に繋がる。

感想

分析や設計には「満足度」のような感情が入らない、というイメージがあった。しかし、人が作るものである以上、完璧な分析や設計は存在しない。そのため、「どこまでやるか」を人の満足で表現しているのはとてもしっくりきた。分析や設計を行うのは人間であり、「人間が行う」という現実から目を反らしていないからこその「満足度」重視なのだと思った。

*1:Viewpoint-based Software Test Engineering Process

自分棚卸

20代最後の年で自分を見つめなおす必要を感じたので、
ブログに纏めておきます。


先日、中学校の同窓会があって、懐かしい仲間と楽しい時間を過ごしたんですが、そんな中で「自分のことを相手に全然伝えられていない」と感じました。

自分を理解してもらえるような話*1が全くできていませんでした。
厄介なのは、「自分の能力には自信があること」。
大学の4年を注いだ奇術部でのエンターテインメントに対する考えや価値を出すことに力を注いだビジネスに対する考えはそれぞれ十分に自信を持っている*2し、両方持っていることは自分の強みだと胸を張って言えるんですよ。


ただ、大体の人にはそれらは価値がない。
だれもが面白い舞台を作る方法が語り合いたいわけではないし、だれもがより良い価値を生み出す仕事の仕方を語り合いたいわけではない。
なので自分のことは、分かる人にしか分からない。
エンターテインメントでもビジネスでも、できるだけ多くの人が価値を理解できる方が良いと思っている身としては、自分の残念ぶりにとてもショックを受けました。


ということで、これからは【相手に自分を伝えること】を心掛けようと思います。
これまでそれをやってこなかったのは「自分の弱みを出したくない」というところから始まり、加えて「自分を晒さなくても、良いものを作ればよい」という考えがありました。
伝わらないことに価値なんてないし、自分を晒しても良いものは作れるけど、そこから目を反らしてたら【相手に自分を伝えること】ができなくなってました。


なので、【自分再構築】のための【自分棚卸】中です。
ただ、ゼロから再構築じゃないです。
自分が自信のある分野は確かにあるので、その知見を活かして、再構築してきます。
しばらくは自分の強みを棚卸していきます。



後で見返すと絶対恥ずかしくなるタイプの文章だけど、
勢いに任せることも重要だよね。

*1:相手を理解することも重要ですが、今回はよりクリティカルな方を挙げています

*2:まだまだ精進は必要ですが…