(ソフトウェアテストワークショップ)に参加してきました。1日めのワークショップの各セッションでとったメモと、内容・感想をお伝えします。BPPセッション:心が叫びたがってるんだ。前回のwacate2017夏でBPP賞を取った阿部さんによるセッション。ライフハックのお話ということで、何かの事象にたいしてすぐ反応していたり、日々の仕事がつまらなく感じられてしまう場合のお話からスタート。人間は9つのタイプに分けることができる、今回のワークでは大きな区分3つにわけて、自分がどんなタイプかを確認。して自分のタイプを知ることで、自分がどういった反応を示しやすいのかを把握し、それをもとに自己理解を深めたり、日々つまらないと思っている仕事の捉え方を変えて楽しめるようにしたり、できたら良いよね!という流れでした。ここで紹介されていた内容とは別ですが、私もストレングス・ファインダーで自分の強みを把握することで、仕事に対してどう捉えたら自分に向いている切り口から取り組めるのか、といったことを考えられるようになってきました。(少しずつ)直感を役立てつつも、直感に従ったらうまくいったからといって勘違いをしてしまうと、結果的にストレスを爆発させてしまったりします。2017気をつけます。阿部さんは今後こっち方面の資格をとろうとされているそうなので、資格取得後にまたつっこんだお話を聴けるのが今から楽しみです。一つ目の手がかりピンときた!ってどういうこと?大切なこと自分の直感を素直に受け入れる。自分を受け入れて、自分のやり方を見つける。自己受容できるようになる。朱峰さんにより、論文に関するセッション。暗黙知が共有されている社内でなく、社外向けに整理することによって自分の知識・経験の棚卸しになる査読者からのフィードバックがもらえるなどのメリットがあること。パーフェクトな論文を書かなくとも、会議によっては事例発表から受けつけてくれるものもあるので、まずはそういったところから投稿してみるのも良いそう。日々仮説と検証繰り返して過ごすのが大事だ。2017↑「よし、論文書こう」から入ってもたぶん大変だな、というのが正直な感想。すればいいかというと、おそらく普段から課題意識を持って過ごしていて「こうすればいいんじゃないか」をとにかくトライし続ける。すると成功と失敗が溜まってきて、そこからの「論文にまとめてみるか」の流れになるのかなーと。論文を書きたいというモチベーションから始まって課題意識を持ち始めるのはアリだとおもいます。メモ本日のゴール論文、会議(学会)の基本をしる自分の仕事上の取組みや工夫が、イケてるのかどうか評価してみよう論文ワンチャンある気になる論文書いて、良い事あるんかい?→ある自分がやっていることを体系立てて整理・評価できる。常盤さんによる、違いを捉えるセッション。話し合いをしているときに、一方は答えを欲していて、もう一方は意見を出しあって一緒に考えたい場合など、思いが違うことによって分かり合えないシチュエーションがあります。いったときに、「なんでわかってくれないんだ」と怒ったり悲しんだりするのではなくて、その背景にある「違い」をまず捉えてみよう。すると、いろんなところに活かせるよ、というおはなしでした。ワークではあるシチュエーションに対して、個々人がどういった結論を出すのかを表明して、そこでの考え方の違いなどを話し合いました。前提事項の違いや、抽象的なことばに対する認識の違いなどがあると、話が平行線になりがちだよなーと再認識。2017↑ただし、全部が全部チャンスチャンス!と前のめりになりすぎると燃え尽きてしまうことも・・・。いう常盤さんらしいアドバイスもあって、ためになりました。メモ今日のワークはふたつ苦手な場面を分析してみると・・・いろいろ違う背景には<違い>があるのでは目的は一緒だけど、手段が違う背景・考え方が違う目的が違う全部違う違いを捉えたら、次のステップ。違いを捉えすぎることにのめり込みすぎると・・・あれもこれもチャンスと捉えて、最終的に疲れてしまう。時には休んだり、逃げたりしよう。Tsunoda内容・感想テストをやっている人の中には、普段プログラミングしたり、ソースコードを読んだりしない方もいます。いえ、普段テストを考える上で「ソフトウェアの知識」というのも有用。今回はソースコードを読んでみよう!というお話でした。ワークでは実際にバグの仕込まれているソースコードを読んで、どこがおかしいか指摘するということをやりました。角田さんの想定したいた以外の問題も見つかったりした一方、やはり普段読むことがない人は苦戦している様子でした。「かつ/または」の違いや、型の違いなどが問題だ、という雰囲気のところに触れていたのはよかったかなーと思います。個人的には「システムテストの自動化で学ぶ、テストエンジニアのためのプログラミング入門」とかやってみたい。scarletplover内容・感想よく聞くけど実際にちゃんとしたのをやったことがないユーザビリティテスト。そもそもユーザビリティとはというところから始めて、ユーザビリティテストのフローの一部をワークで体験しました。ワークがわからなかった!というのも、タスクとかシナリオとか、単純に経験なくて聞き慣れないワードで考えないといけなくて、ワークの意図を理解しきれなかったのが一番の原因ぽいです。プログラミング経験ゼロの方が「ソースコードを読んでみよう」をやったときはこんな感覚だったのかもなぁ・・・と勝手に想像。自分はワークには歯が立たなかったものの、機能テストとは全く違う考え方で進むというのが実体験できたのがかなりの収穫でした。イメージとしては、マーケティングリサーチとかに近いかたちで進めているのかな?どうなのかな?続きとして改めて聞きたい・本とかで読んで理解したい内容ですね。記憶しやすさなどなど→実際にはそううまくいかん。ここがふつうの機能テストと違う場所を確保したりふつうのテストと比べても色々シビアテスト設計タスク設計ユーザにやってもらうタスクや課題を決めるまず、主要なタスクに落とし込む。細かいバリエーションをやろうとしない。事実を書く何を、どうすると、どうなったこの段階では分析しない介入はしない。データ分析その他!ディナーセッションの抽選でソフトウェアテストPRESSが当たったものの、すでに持っていたのでジャンケンしたのが私です分科会では「テストの妥当性」の話をしました。この辺ブログにまとめてみたい。分科会後の自由時間では、B氏の発表の再演をしていただきました。Ito都内でテストエンジニア&ブロガーをやっているyoshikiitoです。ソフトウェアエンジニアの学習方法や成長するための考え方、会社に依存せず自分の力で生きていけるエンジニアになる方法などについて興味があります。仕事は主にソフトウェアテストやテスト自動化。趣味は浦和レッズと読書と技術書を買って積むこと。