テスコン(テスト設計コンテスト)2018 決勝戦いってきた3(完)

過去記事の再投稿です。


2018-03-06

みなさまこんにちは!!テストチームとのの(@tonono2587)です。
前回前々回 に引き続き、完結編としてOPENクラスの振り返りをしていきます!!

tonono.hatenablog.com tonono.hatenablog.com

OPENクラス 参加チーム

OPENクラスも5チームでの闘いでした。(発表順)

  1. タニタガワー6
  2. 紙印テスト倶楽部
  3. イイてすと
  4. ふわパン
  5. てすにゃんV3

個人的にはタニタガワー6のプレゼンききやすくて好きでした。
ふわパンさんのチーム名の由来聞きました?(チームメンバーの体型が)ふわふわ+パンダ って言ってましたよ?!めちゃくちゃかわいい!!!!!(好き!!)

結果

内容が入ってこなくてすみません。結果は以下です。

【優勝】てすにゃんV3 【準優勝】ふわパン

おめでとうございます!

ASTER-テスト設計コンテスト'19-OPENクラス 決勝戦

講評/総評でどんな感じだったのか振り返ります。

講評

タニタガワー6】

  • USAを提唱
  • 「かっこいい」と自分たちで言っていた
  • シンプルでわかりやすいと思います。
  • なぜ4つでいいのか、なぜそれがでてきたのか、を詰めていくとよいのでは

【紙印テスト倶楽部】

  • テストの取り組みは受け身になりがちだが、今回の発表は能動的にテストから仕掛けていく取り組みが内包されていてよかった
  • いままでの経験を積み重ねている
  • 最多出場で必ず*1決勝に残っている(すごい)

  • 継続する力がすごいし、しかも毎年新しいことを仕掛けている

  • アウトプットするし、たくさんの人に知らせている姿勢◯
  • そのフィードバックを次につなげる循環がよい◯

【イイてすと】

  • 特別枠だった、予選からレベルアップしていた
  • 業務フロー業務分析*2につかったりするものをテストにつかう
  • 見える化する」ことが大事
  • あれ自体が業務フローをあらわすものなので、それをテストに適応させていきたい
  • 質疑応答タイムで言っていた「テストに適用できると証明したい!」という熱い思いをはじめからだしたほうがよかった

【ふわパン】

  • 他チームが新しい技を出してきた中で、普通のテスト設計をしてきた
  • それがちゃんとできていた
  • こういうテストありだよな~と思った
  • オーソドックスにテストしていて、メンバーにこういう人がいたら安心できる内容だった
  • この基本は守って向上していってほしい
  • ただ、「言葉」(用語)が方言っぽくなっている (テスト技法→テストタイプ、テストポイント→テスト条件、など)
  • 非機能テストからやる→やっていることは王道だが表現が違った
  • 可視化して説明してほしい

【てすにゃんV3】
(すみません、てすにゃんの講評ありました?聴き逃してしまいました 汗) どんな内容だったかだけメモ載せときます

  • 製品のリリースを止めるバグを許容範囲までなくす
  • bugspots(よみ:バグスポッツ)を利用
  • 製品のリリースを止める事象およびバグをどう特定するか
  • フォルトツリーズを用いた事象の分解
  • テストで対処する/しない事象はどのように決めるか →被害金額とリスク値から決める
  • 対処するためにどんなテストをどのくらいやるか? →テストタイプのリスク低減表による許容範囲の調節

f:id:glpgsinc:20180227204505p:plain:w300 にゃ~

総評

  • テスコンがはじまってから2、3年はテスコンの次の活動がなかった。 いまは審査員になったり、次の活動に繋がったりしている
  • 卒業して、より広い活動、レベルの高い活動へ>次の世代が同じように追いかけていく→全体が右肩上がりしている

  • 審査員はフェアにみている →だれがつくったかは全く気にしないで成果物をみて、審査している

  • ひろくみて、いろんな関係をフラットにみて、だんだん落とし込む王道をいったのがふわパン

  • それは関係をモデリングして、落とし込んでいって…→これは難しいこと
  • 他4チームは何かほかの考え方に寄せている→こうすれば考えるのが楽になるのでは?
  • 考え方の違いなのでどっちがいいとかはない
  • (例えば円柱があったとして、)円をモデリング>長方形をモデリング>… 全部捉えようとしてしまったら扱いきれなくなってしまう
  • トレードオフですね
  • ほとんどのチームが何かに寄せて安心してしまったので点数が拮抗していた
  • 全部捉えようとしてしまったらほうは、扱いきれなくなってしまっていた感じ

  • 表せるものはなにで表せないものは何で、を理解した上でケースに落とし込む →その理解をどっち側からやるかが問題

  • 模範解答はない

  • 正解はない。100点の成果物はつくりようがない

  • 業務だと納期があり、深く深く考えるには限界がある

  • 一方テスコンは仕事の納期に比べれば考え抜く余裕がある
  • 考え抜いたものを見せてください!
  • テストとは何か考えたり

  • プレゼンがみんな似ているのでおもしろくない〜

  • 独自のプレゼンテーション がみたい!
  • 型ができて「型通りやると決勝いける」みたいになってきたらつまらないよね。

感想

  • 「USA」について、ユーザーストーリーマッピングがベースのテストということで、どんなテストをするのかわかりやすかった気がします。
  • 一方で、それで足りているかとか、安心かどうかを考えるにはプレゼン時間はあっという間すぎてついていけませんでした(´・_・`)話がわかるようになってきたらそこまで考えられるのかな。。
  • 紙印テスト倶楽部の、テストを考える前に仕様(テストベース)に対してフィードバックをする方法はすごくしっくりきました。
  • 「テストベースをテスト設計成果物へ変換する」ところで、いま知識が足りなかったりもやったりしているような気がする
  • bugspots、知らなかったのでぐぐりました

SHANON Engineer's Blog: Google のバグ予測アルゴリズムと bugspots の導入

  • コードに手を加えられているところほどあやしい、からそこを狙え、ということでしょうか?
  • ぐーぐる先生が言うなら信用できる!みたいなイメージをもちました
  • 正解がないぶん考えたなりに自信をもって「こうやって正解出しました!」と言えないと大人はうんと言わないですよね。がんばりどころのヒントになりそうです。

もやもや晴れた?

前々回で整理した、わたしのもやもやは。。

  • 考えた内容(設計)がうまく表現できない
  • 伝わるもっといい書き表し方があるはずだ
  • テスト分析してるけどなんか足りてないかもという不安感
  • テスト分析にはもっといい方法があるのでは?!

→聴講を通してヒントはあったように思います!

  • 全体を捉えるような視点で振り返るとよさそう
  • 何かに寄せて考えてみたり、全体から落とし込んでいったり、やり方がいろいろある
  • レベリング

昨年決勝戦にきたときは、正直ほとんど話についていけず、成果物の展示をみても 「字がいっぱい〜。。。」くらいにしか思えませんでした。

tonono.hatenablog.com

※ただモチベーションはものすごくあがった

今回も「字がいっぱい〜。。。」とは思いましたが(おいー)、
なんの話をしているかはわかるようになったなと思いました。

とくにU-30での発表内容やフィードバックは、自分に置き換えてみていくと実務に適用できそうなところがありました。 来年はもっと話のスピード感についていけるようになりたいです。

さいごに

参加者のみなさんお疲れさまでした!
このレポートをとおして観戦してくれたみなさまも、おつきあいありがとうございました。
テスト界ではテスコンのようないろんなイベントがありますので、どこかでまたお会いできたらうれしいです!とののでした。(^_^)/~

*1:必ずではなかったとご指摘いただいたので確認し訂正しました。2018/03/06

*2:教えていただいて修正しました。2018/03/06

テスコン(テスト設計コンテスト)2018 決勝戦いってきた2

過去記事を再投稿しています。


2018-03-05
みなさまこんにちは!!テストチームとのの(@tonono2587)です。
先日テスコン決勝戦にいってきました!
テスコンとは?を整理した 前回に引き続き今回はU-30クラスの模様をお伝えできればと思います。

tonono.hatenablog.com

U-30クラス 参加チーム

参加チームは5チームでした。(発表順)

  1. あんだーズ
  2. チームT研
  3. 新米
  4. T.B.D
  5. いんプレオ

審査後、結果発表より前の休憩時間に審査員から各チームへフィードバックの時間があったのですが、
これがめちゃくちゃおもしろかったです。
うっかりしていたらはじまっていたので途中からしか聞けませんでした。。(とても残念)
わたしが聞いたなかでは、以下のようなフィードバックがありました。

あんだーず

  • どういう情報がほしくて、このインプットを選んでいるのかが足りない
  • そのためコンセプトを実現しようとしている感がなくてモヤる
  • おそらくあたまの中で変換があった。そこが成果物にでていない
  • 意図が表現できてないかも?
  • ISO25010出してるけど、コンセプトで触れていた「品質」を定義しているわけではない。。
  • 「なぜこれが必要なのか」の説明は一生懸命やってたからとてもよかった

T研

  • 「一意に定まる」というのはどう評価すればよかったのでしょう?? →そもそも一意に定まらない、難しい。。
  • 曖昧なもの(ここでは要求定義書?)をボールペン入れたからって一意に定めるのは難しい
  • 状態遷移図に力を入れていたのがよくわかったけど、質があんまりよくなかった
  • 例えばUMLドメインモデルを書くと状態がわかると思う。そうすると状態遷移図が書きやすくなる
  • 次は状態遷移「表」もかけるようになるのかな
  • 状態遷移ではカバーしきれないので、状態遷移図で網羅できないところを考えたら、テストの全体像がみえたのでは?

いんプレオ

  • 「やったことリスト」ではいけない(足りない)
  • 書いてないことをどうがんばってテストするか
  • ティラミスはエンプラむけ?なので組み込みでつかうの難しいのでは?
  • ラルフチャートのほうがつかいやすいかも
  • 成果物が読み解きづらかった

よかったところは?悪かったところは?ここが難しかった、どうすればよかったか、などなど、成果物を囲みながら発表者からの質問に審査員が口頭で答える、という形式でした。
審査員の方々はだめなところをきっぱりはっきり隠さず指摘してくれるのですが、 発表者側もまわりで聞いている参加者もとても前向きな空気でした。 もちろん、よかったところもはっきり言ってくれていました。(^^)
めちゃくちゃ真剣にフィードバックをくれるので横で聞いていてすごい羨ましかったです。
わたしは普段の業務でちゃんとフィードバックをもらえていると思っていましたが、こんなにいろんな人に見てもらえる機会はあんまりないのではないでしょうか!いいな!!

結果

U-30の結果はこうなりました〜

【優勝】T.B.D 【準優勝】新米

おめでとうございます!

ASTER-テスト設計コンテスト'19-U-30クラス 決勝戦

講評

  • 「どうつくったか」などいろいろ考えている様子がある
  • ただ、「Why」の部分が薄い
  • いいこと考えてるのに伝わらない
  • 技術要素を扱い切れていない、理解していないように思える →腹落ちさせてからつかいましょう
  • コンセプトとやろうとしていることがちぐはぐになっています。 (風呂敷を広げすぎてたためてないとか)
  • 全体の一貫性をもったドキュメントとプロセスがほしい
  • いいテストケースをつくりたいから設計するのに、その最終的なアウトプット(テストケース)がちょっと残念になってしまっている
  • 経験が少ないぶん、poorなテスト観点になってしまうかもしれない。それでもきちんと考慮された結果として成果物を出さなけれればならない
  • そこをがんばる!

総評

  • 前回と比べて格段にレベルアップしている!!

【一貫性、全体をみる姿勢】

  • 成果物全体をみる妥当性の視点が必要
  • (温泉旅館みたいな)継ぎ足しで拡張したようなものが多い
  • ちぐはぐしていて全体がひとつにまとまっていない
  • 市場調査や要求分析はしている
  • アーキテクチャはしっかりしているがテストケースが不足している
  • 上流と下流で矛盾がある
  • 最後に全体をみて、違和感があればなおすことが必要
  • 確認の時間を最後にレビューの工程をもつとよいと思います

【習慣的に技術を高めてほしい】

  • 技術の基礎不足
  • 使っているアピールはあるが使えてない
  • ファッション的に技法の名前を上げてもバレます!笑(HAYST法難しいですよね)
  • 日頃からつかえば使えるようになる
  • テスト技法は、日頃から実践して身につけるものだと思います(例えばドラクエのように、鍛えたらレベルアップできる!)
  • テスト技術をガンガンつかっていきましょう!!
  • OPENでもいける!頑張っていきましょう!

f:id:glpgsinc:20180227181625p:plain:w300

感想

テスト分析のところでは「三色ボールペン法」がかなり使われていました。
それほど難しくないし、効果的な手なのかなと思いました。
仕様に対して、「気になる」といえるように、ここでいうとペンを入れられるように、いま社内で少しずつトレーニングしてみているので、
やっていることは間違いじゃなさそうだと安心しました(^^)

講評、総評であったように、テスト設計全体をとおして「一貫性をもたせる」ことがわたしの実務においてもヒントになりそうです。
「伝わること」は、論理的であるとそれに近くなるのでは、と思いました。
プレゼンをきいていて、「ちぐはぐな感じ」が理解できたことは、昨年の聴講から成長できたところではないかなと自分で思います!!(^o^)/

話がわかってきたところで、レベリングはまだまだです。。
身近な技から身につけるのが早そうということもわかりましたが、スマホアプリのテストにおける身近な技ってどのへんからだろう…??
テスト界の技マップみたいのあるんですかね?ひとつ技を身につけたところで(ククク…奴はテスト技法四天王の中でも最弱…) みたいのやりたくありません?(え?)

次回予告

ここまでU-30クラスを振り返りました。
フィードバックはほんとに他のチームのもききたかった。。
OPENクラスでも、おもしろいお話ありましたよ〜!
次回へつづきます(^o^)/

テスコン(テスト設計コンテスト)2018 決勝戦いってきた1

過去記事の移行です。


2018-03-01

みなさまこんにちは!!テストチームとのの(@tonono2587)です。
タイトルのとおり、2/24(土)にテスコン決勝戦聴講してきました!! レポートしつつ振り返りたいと思いますので、おつきあいください。

そもそも「テスコン」って?

テスト大好きなみなさんには説明不要かもしれませんね。
テストがまだ好きではないそこのあなた、テスコンとは簡単にいうとソフトウェアテスト界のオリンピックです。(あえてそういっておきます!)
(4年ではなく)1年に1回、日頃磨き上げられたテスト設計の技を競い合うものです。
プロテスト現役の方はもちろん、普段テストに興味がなくても、中継生放送なんかされてしまったあかつきにはみんなテレビの前に大集合のイベントなんですよ!(あえていう)
……残念ながら生放送はされておりませんので、僭越ながらわたくしが現地で観戦してきた模様をお伝えできればと思います。

テスコン概要

テスト設計コンテスト (略称:テスコン)には、U-30、OPEN の2クラスあります。
30歳までの選手のみエントリーできるU-30クラスは今年で2回目の開催となります。
コンテストの流れは以下です。

  • 共通のテストベースをもとに、テスト設計をする
  • 定められた成果物を提出
  • 予選:各地域にて成果物による書類審査およびプレゼン審査
  • 決勝:地域を勝ち抜いたチームで書類審査およびプレゼン審査 ←こんかいココ

詳しくは公式サイトをご覧ください
ASTER-テスト設計コンテスト

予選で選ばれたチームの、さらに洗練された技をプレゼンを通して観られるわけですね!!

勝戦概要

日時:2018年2月24日(土)10:30〜
場所:日本大学理工学部 駿河台校舎1号館 144教室

御茶ノ水デアツイ闘いが繰り広げラレル〜

スケジュール:
プレゼンまでに、書類審査までが終わっています

  • 開会式
  • U-30クラス 5チームのプレゼン(各チームテスト設計についてのプレゼンと、質疑応答)
  • 休憩(審査)
  • OPENクラス 5チームのプレゼン
  • 休憩(審査)
  • 結果発表/閉会式

聴講の目的

先ほど申し上げましたように、オリンピック級のイベントですから、
いまこのとき開催しているからという理由でなんとなく観たっていいと思うんですけれども、
わたしが決勝戦を聴講しようと思ったのは、ずばりテスト設計でモヤっているところがあったからです!

  • 考えた内容(設計)がうまく表現できない
  • 伝わるもっといい書き表し方があるはずだ
  • テスト分析してるけどなんか足りてないかもという不安感
  • テスト分析にはもっといい方法があるのでは?!

そんなもやもやがあって、テスコンはそれを競うんだからなにかしら解決のヒントがあるに違いない!! と思い、各チームの表現方法やテスト分析、設計のやり方を知りたくて聴講しにいきました。

ここまででテスコンがどんなものか、そのわたしにとっての見どころを整理してみました!

次回は、U-30クラスの様子を振り返ろうと思います。
果たしてわたしのもやもやは晴れるのか!?
お楽しみに!

はじめてのAppleWatch

過去記事の再投稿です。


2017/06/09
はじめてのAppleWatchメモ
検証のためAppleWatchを初めてさわったとののの記録です。

今回のテーマ「はじめてのAppleWatch」

検証(項目書作成)のため、この度初めてAppleWatchにさわりました!
AppleWatchサポート(公式ページ)を行ったり来たりするのがちょっと面倒だったので、操作に慣れてきたところで基本操作をまとめておくことにしました。
検証するとき要りそうなことメモです。

AppleWatchのきほん

  • ペアリングする
  • 操作する
  • アプリを入れる
  • 通知を受け取る
  • その他

ペアリングする

何をするにもまず「ペアリング」しなければならないことを知りました。
iPhoneの「Watch」アプリに沿ってやれば流れに身をまかせるだけで簡単にできます!

☆ポイント

  • しっかりと充電してある/しながらでないとペアリングさせてくれません。
  • BluetoothWifiがONになっているか確認しましょう
  • 簡単だけど地味に時間がかかるのでペアリング/ペアリング解除は前もってやっておきましょう

やり方 https://support.apple.com/ja-jp/ht204505

※以下、時計端末のことを「Watch」、ペアリングしているiPhoneのことを「本体」と呼んでいます。

操作する

ペアリングできたら操作してみましょう!
まずボタンや各部の名称を整理します。

f:id:tonono:20181013231047p:plain
※AppleWatchユーザーガイドより

つぎに基本的な画面の名称を整理します。

◇文字盤(いろんな種類がありカスタム可能)
f:id:tonono:20181013231346p:plain


◇ホーム画面(長押し→ドラッグでアイコンの配置変更ができる)
f:id:tonono:20181013231459p:plain


◇Dock(アプリへのショートカットみたいな)
f:id:tonono:20181013231524p:plain


◇通知センター(文字盤のとき上から下へスクロール)
f:id:tonono:20181013231614p:plain


◇コントロールセンター(文字盤のとき下から上へスクロール)
f:id:tonono:20181013231639p:plain


iPhoneでおなじみの画面+時計の画面、という印象です。あとはアプリの画面ですね!

◇指での操作は本体と同じです。
→タップ/スクロール(スワイプ)/ドラッグ…など
スクリーンショットもとれます!
 デジタルクラウン+サイドボタンの同時押し(サクッと押すと撮れる)

アプリを入れる

プリインストールアプリも結構ありますが、どうやってWatchにアプリを追加するのでしょうか?

その1:App Storeから入れる

本体の「Watch」アプリに「App Store」タブがあります。
そこにWatch対応したアプリが並んでいるのでインストールするとWatchに表示されます。
(同時に本体にもインストールされます。)

その2:本体でインストールしてからONにする

  1. いつものApp Storeで「Apple Watch Appも提供」と表示があるアプリをインストールします。
  2. 本体「Watch」アプリの「マイウォッチ」タブ下の方にある対応アプリのリストをタップ
  3. 詳細画面の「AppをApple Watchで表示」をONにする
  4. Watchに表示される

Watchだけにアプリをインストールするというより、本体のアプリをWatchでも使えるという感じがします!

通知を受け取る

Watchで通知を受け取るときは条件があります。

  • 本体、Watchともに通知の許可がONになっていること
    →本体の通知をWatchに反映しているので、本体がOFFだと届きません。
  • 本体とWatchが接続されていること
    →接続が切れているときは本体に届きます。
  • 本体がロック画面またはスリープ状態になっていること
  • Watchを装着していること(肌に触れていること)
  • Watchにパスコードロックがかかっていないこと

こないときは上記をチェックしてみましょう!
公式の案内 https://support.apple.com/ja-jp/HT204791

その他

そのほかとののが仕入れた情報やメモ

  • 機内モードにすると本体との接続はOFFになる(「ペアリング」と「接続」は別)
  • 「計測」のセッションは1アプリのみ可能
    →ワークアウトで計測しながら他アプリでも同時に計測することはできない

Apple Watchサポートページ https://support.apple.com/ja-jp/watch
Apple Watchユーザーガイド http://help.apple.com/watch/#/apda40d70599

以上!お役立ち情報あればください
Watchの検証はこれからだ〜

Cookpad Tech Kitchen #7 参加レポート〜ごちそうさまでした〜

過去記事の再投稿です。


2017/04/25

こんにちは!テストチームとのの(@tono2587)です。
今回はクックパッドでおいしいごはんをごちそうになった話を書きます!!!

嘘ですごちそうになりながらテスト現場のお話聞いた参加レポートです(おいしかったのは本当です)(めっちゃおいしかったです)

Cookpad Tech Kitchen #7 〜 理想の開発現場の「ふつう」のお話 〜

日時:2017/04/21 Fri. 19:30〜
場所:クックパッド株式会社 東京都渋谷区恵比寿4-20-3 恵比寿ガーデンプレイスタワー12F 登壇者:秋山 浩一さん、関 将俊さん、深谷 美和さん、松尾 和昭さん

cookpad.connpass.com

公開された資料

どんなお話が聞けたか

  • 「理想の開発現場」について
  • 理想の開発現場の「ふつう」について
      「うまくいったらどうなるの?」
      「なんでやるんだっけ?」
      「やりたくないの?」
      「えー」
  • そのチームで喜ばれるふるまいについて
  • 明日からできそう??

「理想の開発現場」について

タイトルの「理想の開発現場」とはどういうこと? という説明を秋山さんより

  • いままでは、テストと開発それぞれが独立しているほうが理想の形だと思っていた。
     ・技術、お金、管理それぞれが独立(IV&V)
  • しかし、2015年のみわさんの発表を聞いてもう一つの理想の形に気がついた
     ・「人はミスをする」ことが受け入れられていて、テストエンジニアと開発者が一緒に品質をよくしている形
     ・ダイバーシティインクルージョン…多様に集まって、お互いに認め合うこと
  • ソフトウェアの世界では、このようにひとつの世界で情報交換したほうがよいのではないか
     ◯よいところ
     ・何を言っても大丈夫なこと…認めあっている
     ・「人」ではなく「こと」に焦点が当たっていること…品質をよくするために人が動く
     ・見方が違うことが大事
     ・共同作業と当事者意識…一緒にひとつになってやっている

解説にはカンペがあったそうです笑

今回はそんな理想の形=みわさんのチームについてのお話でした。

これから話す内容について関さんより

  • これまでは、できあがったチームの事例を報告していた
     →それを聞いたからといってできるとは限らない!
  • 今回は、チームになっていく過程を報告します
     →問題解決の最中に起こる話からよいチームができていっているのではないか?
     フレーズ→ふるまい→価値観 のようにチームの価値観ができていくのでは。
  • こんな名言があります
    『生きている花をつくろうとすれば、ピンセットで細胞を一つ一つ物理的に組み立てるのではなく、種から育てるであろう。』
         ーーークリストファー・アレクサンダー『時を越えた建設の道』

(種の撒きかたを教えてくれるんですね?!)

理想の開発現場の「ふつう」について

よくつかわれているフレーズがあります。

「うまくいったらどうなるの?」

  • このフレーズのよいところ
     ゴールがわかる、確かめる方法がわかる、ゴールまでのステップがわかる、うまく迷える
    →これをきっかけにしてぼんやりしていることをはっきりさせられる

  • 例:◯◯の調査をします と言われたとき
    ほんとうにやりたいことのための調査なので、そのやることがみんなにわかるようになったらやめようか、とか決めることができる
    Q:調査の区切りは先行投資だと難しいのでは?
    →時間で切る ことが多い

「なんでやるんだっけ?」

  • このフレーズのよいところ
     ・ゴールの意味がわかる、やりすぎを抑えられる
    →その作業自体の意味を考えたり、その作業でつくろうとしてるものがわかってくる。「不足」は不具合とかで見つけやすいが、やりすぎはわかりづらいのでこのフレーズが役に立つ
    →不安に思っていることはバラすほうがよい。
    →1人よりn人で考えたほうがみつけやすい

  • 例:だれかが迷っているとき、話し合いが急に静かになったとき、結論が出ないとき、困っているように見えるとき、熱中し(すぎ)ているとき

Q:Cookpadではどうですか?
人に干渉するのはけっこうやります。進捗の確認とか
Slackとか直接でちょくちょくコミュニケーションとる
できるならやったほうがいい

「やりたくないの?」

  • このフレーズのよいところ
     ・1人だけがやりたくない、状態にならなくできる(ヤダ共有)
     ・やる気がないからやらない、とはならなくできる
     ・上手い人がかわりにやってくれたりする
    →「嫌なこと」をなくしていくことができる。モチベートするのではなく、嫌なことを認めてなくしたり、みんなのものにすることができる

  • 例:問題を前に言葉が出ないとき、言い訳をする人が出てきたとき

Q:微妙なところに気づいてあげる工夫は?その人が「やりたくなさそう」という判断基準は?
→顔をみるから気づく。その人の話を聞いていてゴールが明確じゃないときや、明らかに目をそらすとかのとき

「えー」

  • このフレーズのよいところ
     ・瞬時に違和感を伝えることができる
    →「えー」って言うと課題かも、って気付ける
     ・それが何かをみんなが一斉に考えて話し始める
    →たいていの場合課題(問題)がみつかる

  • 例:「あれ?」とかも同じ使い方。ちょっと待って、というかわりだったりする
    →理不尽なこと言われたときには有効

◆スビードを大切にしているチームだからつかいます
 ・「早く」みんなに伝えたい
 ・自分で納得できるまで確かめてから伝えたい

Q:途中から入ったひとにも「えー」が悪く伝わらないコツは?(「えー」って普通否定的なイメージ)
→次の言葉までセットにしてる 「えー◯◯?」
Q:新しい人が「えー」の意味をわかるきっかけは?
→みんなのいる場で言われる/使われることが多いから慣れていく
→自分のことと同じようにその場にいる人が考え始める

そのチームで喜ばれるふるまいについて

  • 変だな?と思ったときにすぐ誰かにいう
  • バグかな?と思ったときにすぐ誰かに言う
     →スピード重視だから。バグじゃなくても怒られたりしない(いままではバグかな?くらいでは報告しなかったし、違うかもしれないことに開発者の工数をとることはよくないことだと思っていたけどいまはそうではない)
  • 仕様がわからないときだれかにきく
     →誰かが知ってるのに、わからない人が調べている時間のほうがもったいない
  • テストのやり方がわからないときだれかにきく
  • テストを思いついたとき、やる前にだれかにいう
     →ここバグ出そうだな〜って思ったときにすぐ言っちゃう
     →実装する前でも言う。考慮できてなかったところに気づいたりする
     →知っているなら先に言いなさいよ、というスタンス。いいものをつくりたいはずなのに、自分のやりたいことが優先されるべきではない。バグでそう→実装で確認は自分がやりたいことじゃないだろうか。
     「わざわざできあがってから言うのは、きみは意地悪だ」
  • こうしたフレーズを繰り返し言っていき、だんだんチームの価値観をつくっていく

明日からできそう?

15年も一緒にやっている長いチームだから、チームとしてできあがっているからこそ成り立つものなのでは?
と思われるかもしれないが、このチームに限った例ではないよ
→ラムダノートという会社と1ヶ月くらい一緒に仕事したらそっくりなチームができたから

まとめ

・テストエンジニアと開発者が一緒につくっていくのもチームの理想の形
・理想の開発現場ではなにが普通なのか
 ・よくつかわれているフレーズがあり、価値観をつくっていってると思う
 ・みんなが当事者
 ・新しく入ったメンバーにも繰り返し言っていき、慣れてもらう

Twitter公式タグも盛り上がってました!

感想

話を聞いて、わたしがすぐできそうなことについて考えました。

  • モヤモヤはすぐに伝える
     なんでも全部すぐ言うのがよいとはまだ思いませんが、悩みすぎたり、考えすぎて止まらないようにしようと思いました。まずは時間で区切ってみます。
  • 朝会をちょっと変えてみる
     いままで:進捗をざっくり確認→今日はAさんここ、Bさんこっちからお願いします。→他は何か(共有事項)ありますか?(終)
     これから:最後の(共有事項)の聞き方を具体的にしてみる。不具合でたかとか、仕様不明点ないかとか…
     →心当たりを見つけやすいし、細かいことも共有しやすくなりそう。
     →逆に無駄話みたいになっちゃうこともあるので、ほどほどでよいとアドバイスもらいました。
  • 「よいものをつくるため」を忘れない
     喜ぶのが自分ひとりだけ、にならないこと。
     →ちょっと面倒だな…ということも、「これを使う何万もの人がこっちのほうがうれしい」と言われたらがんばれる

ほか
ごはん全部おいしかったです。豚肉の角煮みたいなやつとか、生姜焼きとか、炊き込みご飯とか…でも食べながら聞くのは上手くできなかったです…もっと食べたかった…笑
ごちそうさまでした…
…というわけで、おいしいごはんとおいしいお話をいただいた1日でした。今よりもっとよくなるためにすぐできそうなことも見つかったので、早速やってみようと思います。

テスト設計コンテスト'17 決勝戦聴講レポート

過去記事の再投稿です。


2017/04/19
こんにちは!テストチームとのの(TW:@tono2587)です。
今回は2/23に参加した「テスト設計コンテスト」のことを書きます。

時間は経ってしまいましたが、初めてのテスコンだったので張り切ってレポートします!

・テスト設計コンテストとは?
・決勝戦概要
・U-30クラス
・OPENクラス
・全体講評メモ
・感想など

テスト設計コンテストとは?

名前だけは聞いたことがあったのですが、いったいどんなコンテストなのかは知りませんでした。一緒におさらいしましょう!
簡単に言うと、「テスト設計のスキルを競い合うことで、さらに高めていきましょう!という会」な認識です。
公式サイト:http://aster.or.jp/business/contest.html
「OPENクラス(だれでも)」と「U-30クラス(30歳以下のみ)」の2つのクラスにわかれており、それぞれで予選がおこなわれた上での決勝戦となります。
わたしはチュートリアルは参加せず(知らなかった…)、この決勝戦のみ聴講で参加しました。

今回のテストベース

U-30クラス:「話題沸騰ポット」
OPENクラス:カラオケシステム

テストベース仕様、採点基準についてはコチラから↓
http://aster.or.jp/business/contest/rulebooku30.html http://aster.or.jp/business/contest/rulebook.html

勝戦概要

◇日時
2017年2月23日(木)
10:00 U-30クラス決勝戦開始
12:30~13:30 昼休み
14:40 OPENクラス決勝戦開始
18:10 終了

◇場所:日本大学理工学部 駿河台校舎 7号館

◇参加チーム(発表順)

U-30クラス OPENクラス
OPTiM てすにゃんRev2
いんプレオ 紙印テスト倶楽部
ヤングレッジ STUDIO IBURI
でこパン462 モモテツ
チームT研 わんだーズ
SHINNOSUKE
TBD

☆持ち時間は発表15分→質疑応答5分の計20分

U-30クラス

優勝 でこパン462 準優勝 SHINNOSUKE

総評メモ
井芹洋輝さん(審査委員長)より

入賞チームについて

  • でこぱん462
     テスト要求分析の発散と収束が上手だった(まとめが上手かった)
     3つの目的でビューを分けてやっていたところがよかった
     テストの手法を理解してつかっていた

  • SHINNOSUKE
     わかりやすかった
     よく内容をみるとあれ?ってところがある
     アーキテクチャを2つつくって片方を採用したところがおもしろいが、根拠が少ない

  • TBD(準優勝惜しかった)
     テスト要求分析でいろんな分析をやっている
     新しい技術にチャレンジしているのがよいが、なぜその手法なのか、どうつながっているのか、それがみえず説得力に欠ける
     技法、手法をつかうなら理解していることも証明できるとよい

U-30クラス全体について

  • テスト開発プロセスの基礎ができていない

  • 技術力不足
    チュートリアルで設計について説明があったけど、それを満たしていない
    手法の使い所がおかしい、正しくない

  • 竜頭蛇尾
    分析がテストケースにまで落ちていない
    テスト設計は、「テスト」が成果物であり、本質。
    「テスト」をよくすることが一番で、そのためにやっている。

  • テストの厚みの分析が足りない
    根拠の分析が弱い。
    「なにを」テストするかはできているが「どこまで」テストするかが足りない

上記の改善について

  • 品質 についてよく考えて下さい。理解してください。
    ポットに対してテストが仕様書どおりではそもそもテストが足りない。
    (倒れる危険があったり、子どもがつかう、という前提がある。)

  • 「よいテスト」について考えてください
    保守性の高いテスト、マネジメントが高いテスト、等
    テストの内部品質を工夫しましょう

  • 各「技」はしっかり身につけてください
    技ばかりにこだわってはいけない。それをつかってこそ

OPENクラス

優勝 STUDIO IBURI 準優勝 わんだーズ

総評メモ
鈴木三紀夫さん、湯本剛さんより

  • 成果物をみて
    とんでもない成果物の量で圧倒しているチームもあったが、それは本当によいかどうか
  • アーキテクチャはいろんなビューでみなければいけない。
    どう組み合わせたら品質がよくなるのか
    いくつかのアーキテクチャのビューのなかで、順番のやつが簡単です 
    アーキテクチャ設計」とは…をよく考える
  • アジャイル開発にチャレンジするなら中途半端ではなく、それについてもしっかり勉強しておかないといけない
  • 「用語」をしっかりつかうこと。
    一般的な使い方をしたほうがよい。発表にそれぞれ違う定義でつかわれている。この発表ではこうです、という定義がされていてもいつもと違う使い方だと誤解しそうになる

全体講評メモ

西康晴さん(審査委員長)より

  • テスコンはじめの4年は主に「テスト観点」で勝負がついていた。
    そこからテスト要求分析の技術がついてきて、2年くらい前からテストアーキテクチャ設計の質で勝負が決まるようになってきた。
  • 設計方針とはなんなのか をしっかり考える
    ものの設計とは何か?
    車輪で走るような自転車の設計、とかはわかりやすいが、じゃあ「テスト」の設計は???
    テストの設計は何が動くのかよくわからないからソフトウェア設計よりも難しい。  
    参加者みんなで技術力をアップさせていっている。

  • テストレベル、テストタイプ などの定義は世界にもある。
    それをどういう順番で並べるかを検討する方法はまだ世界にはない。
    UMLテスト 2.0とかに入ってくるかもしれない
    世界最先端です!

  • 今回はテストベースが「派生製品」だった
    じゃあ次回は?自動化を考えたら設計の中身も変わってきたりするでしょう

  • 要求分析→アーキテクチャ設計
    この流れが、過程が踏まれてない

  • 成果物がただの日記で、「理由」「意図」がない
    やることが決まっていて、何も考えずにやったことを出せばOKがもらえる仕事になっている

  • つかう用語、技術は理解してつかわなければならない
    自分たちの技術にする、アイデアにする、現場の工夫をコンテストの機会で整理してください
    それをフィードバックにして、自分たちの強みにする

感想など

  • 同じテストベースを与えられているのに、成果物も発表も同じものはひとつもない
    逆に、自分たちの立ち位置の説明→設計の流れ説明→要求分析→テスト設計の流れはだいたい共通していたので、基本的なテスト設計の流れを知ることができました。
  • プレゼン(発表)も得点に入っている
    設計した成果物だけではなくて、プレゼン内容が得点に影響するところがおもしろかったです。自分たちの設計したことを相手にわかるように説明することも、ときには必要なスキルなのだ思いました。
  • すぐできそうなこと
    「用語」や「手法」を正しく理解すること。スキルアップには基本知識を増やすことが一番はやそう
  • 「世界の最先端です」
    総評のこの話が一番わくわくしました!最先端技術のすぐそばにいる!

学んだこと

  • テスト設計の基本の流れを理解しました
  • テストの成果物も設計により様々なのだと知りました
  • 十分な設計をするためにテスト設計の基本知識を身につけることが近道だと教えてもらいました
  • 技術を高める機会が社外にもあることを知りました

さいごに

参加者には発表者や関係者が多い印象でしたが、聴講のみでも参加できてよかったです。
参加前にもう少しテストベースについて読んでいったり、予習していけばよかったなと思いました。(そのほうがもっと話が入りやすかったかも)
総評で「世界の最先端にいるから、本とかに自分の名前のついた手法が載ったりするかもよ(意訳)」と言われたときはすごくテンションがあがりました!
勉強のし甲斐がありますよね。これからもがんばりましょうー!!!

「テスト分析とテスト設計勉強会」に参加してきました(後編)

過去記事の再投稿です。


2017/03/22
こんにちは!テストチームとのの(TW:@tono2587)です。
先日2017/02/03、「テスト分析とテスト設計勉強会」に参加してきました!
内容もりだくさんに思えたので、前編と後編で参加レポートをまとめました。
(前編のシェアありがとうございます!)

こちらは後編として、もう少しお付き合いください。

…。。。(テスト設計)

■勉強会の内容(後編)

□湯本さん:ゆもつよメソッドにおけるテスト分析とテスト設計
□河野さん:テスコン優勝事例におけるテスト分析・設計の解説
□まりまりさん:大学祭の模擬店でデザインの力を感じた話

□湯本さん:ゆもつよメソッドにおけるテスト分析とテスト設計

分析とは?
対象をよく理解すること。
知りたいことに沿って対象をわけて、再整理する

設計とは?
・仕様をもとにして対象物の骨組みを決めること
・構築するにあたっての課題を解決すること
・発明(創意工夫)すること

例:家の設計
①家の仕様:予算、2階にトイレ、など。
②家の設計:①を元にして設計図ができる。→家の骨組みができる。
*ここにトイレを配置する場合、どんな配線(水道の)にするか?予算内でおさまるか?(課題解決)
③家の実装:大工さんが建てる

分析と設計を分けるのはなぜか?

◇全体像の理解が容易になるから。
「これをテストしてください」と言われたとする。
→なにをテストすればよいのか???となる。*ここで分析が必要になってくる
→分析をすることで、必要なことがわかる(要件を理解する)
→それをどうすれば実現できるか考える…つまり、設計

◇分析と設計は求められるスキルがちがうから。
分析スキル:ドメイン知識が必要。
設計スキル:その問題についてはこういうカバーのしかたがあります、などの「引き出し」
バー方法をいろいろ知ってる必要がある。

◇分析と設計の成果物も分けたほうがよい
仕様変更による修正から、テストのやり直しとかがやりやすいため。

「分析しなくていいならやらなくていい。それは難しいからやる。やったほうが効率がよい。」

□河野さん:テスコン優勝事例におけるテスト分析・設計の解説

◇このプレゼン自体も分析/設計をしました。それの例も出しながら解説
流れ:分析→設計→実装
何の集まりなのか、聴講者の人数は、会場の大きさは?→それに対する答え(分析)
分析結果をもとに、話の内容、その順番を決める(設計)

◇分析と設計とは?
・考えて、何かしらの成果物を出す行為
・知的変換の大きさが分析と設計では違う(分析は材料あつめ、設計は料理くらい違う)
・分析は世界の整理、設計は課題解決

◇わかりやすい例とわかりにくい例で、分析と設計を考える
・わかりやすい例:家を建てるとき
・わかりにくい例:テスコン事例

お家を建てるとき
分析:住む人の周りの世界を整理する(営業の仕事)
・両親と同居するか?自宅で仕事をするか?休日は何をするか?生活の導線は?和風/洋風?
・制約(土地の場所、予算、建築基準法
聞き出して整理する

設計:お家の図面を書く(設計士の仕事)
・分析結果を満たすようなお家の構造を設計する

テスコンの場合
・テスト要求分析
・テストアーキテクチャ設計
・テスト詳細設計

まとめ
分析するために材料を用意する。その集めた材料で設計していく!

□まりまりさん:大学祭の模擬店でデザインの力を感じた話

模擬店でりんごあめと芋タルトを売りました
1日目:りんごあめ→2本で120円、芋タルト→大きいお皿に小さい芋タルトが1個で120円…
お客さんの声(え、りんごあめ2個なの?!い、芋タルトちっさい…)
*売れない…

対策(このあたりが「分析」だったのでは?)
☆金額を下げる
☆りんごあめ2個問題
→「2個」だとちゃんと言おう!
☆芋タルト(ぼったくり)問題
・この大きなお皿に何個なら満足するのか??
→在庫も捌けたいので、まとめ買いしてもらおう!

ーー看板のテーマを担当者に伝え、看板を描いてもらったーー

結果

大学祭の模擬店でデザインの力を感じた話 - Speaker Deck

資料の25〜
すごくわかりやすい看板になった!
→売上がのびた!!!!!

■参加後の気持ち

◇テスト分析、テスト設計ってなんだろう
 分析は、テスト設計するための材料あつめ。これからテストする対象について知る、整理すること
 設計は、それを実現するための方法を考えて形にすること
◇今まで項目書作成に時間がかかっていたのはなぜか?
 材料が十分に集まっていなかった。何をテストするかなど、整理できていなかった。
 なので抜け漏れが出て、その修正にまた時間がかかっていた。
 設計のスキルがそもそも足りない。…引き出しがまだ少ない。
◇わたしは何をすればいいのか
 やり方を変える:まず分析をする。
 知識を増やす:引き出しが必要なことがわかったので、仕様に対するカバー方法を知っていこう。

■感想/前後編のまとめ

 前編でもやもやしていた「分析」と「設計」がわかってきました。お家の例はすごくわかりやすかったです。
わたしは最近設計士の仕事が増えてきていたが、やっていることはいろいろすっ飛ばして大工に近かった、ということがわかりました。
現状が理解できてきたので、何をすればいいかもだんだんわかってきました。(上記)
まりまりさんがデザインの力で問題解決したように、この分析→設計の流れをおさえておけばテストという形でなくても使えそうな考え方だと思いました。
いろんな学びがあったので、仕事がよくできそうです!!!
よいアプリへの力になれますように!応援よろしくお願いします〜〜!
やる気のアップしたとののでした。ではまた