こんな感じで描けます。かわいい♡
テキストエリアに
Title:login user -> login : try login login -> user info : exist User? user info --> login : user info -> roll info : exist Roll? roll info --> login : login --> user :
で書けばできあがり💛 すてき、かわいい💛
※お題は↓を参考にしました。
ここにあるような実行仕様や複雑な分岐とかは作れなさそうですが、 シンプルなシーケンス図をささっと描きたいときは、テンション高めにかけそうです：）
タイトルをキャッチーにしたくてこんなタイトルになっちゃったけど、リスペクトは必要だし、お互いの信頼関係があってこそだと思っています。
わたしたちの会社ではSlackを導入しています。
その中でも、エンジニア中心のchannnelでは技術情報の共有のほかに
普段の開発で困っていることを気軽にきけるchannnelになっています。
手動テスターの私も、このchannnelで何度も助けてもらっています。
以前、迷えるエンジニアが質問をしていました。（私のIssueの修正で詰まったようです）
結果として、ちょっとしたミスが原因だったようですが、その間にも先輩エンジニア（おっさん）が
的なアドバイスをしていました（このプロジェクトチームではないメンバーです）
おっさん（といっても同世代のおっさんたち）が数人集まれば、色んな情報が入ってきます。
おっさん集まれば文殊の知恵です。
経験によるアドバイスも（今回あったかはわかんないけど）あるだろうし、引き出しの数と出す速さも全然違うなぁと
見ていて感心してしまいました。
もちろん、何にも考えずになんでもかんでも質問するのは
もうちょっと思考や工夫しなさい
って思うけど
（わたしたちの会社では「N分考えてわからなかったら聞きなさい」ということを先輩たちがよく言っています。定量的でよいと思っています）
気楽にきける環境があるし（ここでダメ出しみたいなことはしない・・・と思ってる）
先輩たちも寄り集まれる環境があるのって
いいなぁと思いました。
横で見ているテスターもすっごく勉強になっていて超おすすめですよ！
私のテストはバグを出すことが中心ではなくて
— リナ？ (@____rina____) 2017年8月9日
エンジニアが作るプロダクトの細部まで意図があるかどうか、お客さまに提供できるかを確認するための時間
て感じなんだと思う（その中にバグも探すけどそこに重きを置いてないかも）
ふんわりと書いてしまったので、(・∀・)ｲｲﾈ!!してくれた方それぞれの想いがあるんだろうなと思っています。
私自身が思っていることを今回エントリしてみようかな。と思います。
色んな意図があるかなーと思います。たとえば、
意図って、「これって何でこんな作りにしてるんだっけ？」て質問にエンジニアが答えられるかどうか
「何となくつくりました」ではない答えがあるかどうか かなー
そのためには「なんで」と思う力が私には必要かもしれないし
なんでの答えが明らかなものは聞かないとか
ある程度予測できる疑問まで落とし込めるか（issueになんでなんでじゃエンジニアも困っちゃう）とか
この例の場合、「上のメニューはXXの視点で見ると、この名前がいいと思ってつけた」とか「つい左メニューは上メニューのことを考えずにつけちゃった」とかあると思うので
テストするときに、そのどちらかなんだろうなーと思えるようになることが大事だと思っています。
（もちろん外すときもあるけど）
数値目標やメトリクスで一目瞭然なのかもしれませんが
まずは、私が最初の利用者として提供してもいいレベルかどうかを体感しています。
（といっても、私は出荷判断をしていません）
例えば、なんか動き（UIかな）が変って思ったときに、
お客さまが使うなら、どういう動きだったり、配置だったり、色だったり、言葉だと
やりたいことができるかな？と考えます。
考えながら動かすときと、変だなと思ったときに「どうあるべきか」を考えてIssueに書きます。
そこまで最初から設計書にあると悩む時間がもったいないかもしれません（なので、最近は画面レビューもするようにしています）
私は自社が提供するプロダクトの8割前後をテストしています。
分母が難しいけど、新規プロダクトで機能テストが必要なものの場合は
ほぼ私は一度は触っているはず・・・です。
上に書いたように、私が満足するためのことを可能な限り詰め込んだプロダクトができあがっているはずなので
リリースや納品するときに、私はそのプロダクトのファン第一号であることが大半であると思っています。
とはいえ、リリースする頃には他のプロダクトのテストをしているので
エンジニアに私のプロダクト愛があんまり届いてないなぁと前前から思っていました。
私自身も、プロダクト愛あるんだけどなーなんでだっけー？と思っていたので
今回気持ちの整理ができました。
うーん、わからない
きっと一部ではそうかもしれないし、そうでないかもしれない。
2年ほど前から、この時期にソフトウェアテストの初心者セミナーという
ワークと座学をおこなっています。
www.slideshare.net
2017年 29名
2016年 39名
2015年 27名
とこれまで95名に参加いただいています。
また、このセミナーは、わたしたちの会社の新卒全員（技術部もマーケも全員）と
中途社員にも受けてもらっているので、のべ100名以上に参加いただいています。
社内の新人教育をしてほしいとマネージャーから依頼がきたことがきっかけでした。
その時に、わたしがやっているFBグループに相談したところ、色々なアイディアをいただきました。
そこで社内資料を作ったのですが、わたしたちの会社に特化したものではないものが作成できたことと
FBグループで社外のかたから色々知見を得たフィードバックという意味もあって
社外でもセミナーをするようになりました。
（社内は業務時間内にやっていますが、内容は一緒です）
このセミナーでは、一番最後にYWTを使ったふりかえりとセミナーアンケートを実施しています。
社外向けセミナーは、YWT（今回はTだけ）を全員に発表してもらうようにしていますが
とってもいいなーって思っています。
YWTとは、ふりかえりをするためのフレームワークです。
Y（やったこと） W（わかったこと） T（次にやること）
を書く、今回のようなセミナーでとても有効なのではないかなーと思って取り入れています。
YWTのTは「次にやること」なんですが、私はTRYしたいこと として書いてもらいました。間違って覚えていたというのもある・・・ごめんなさい
私は、WACATEというテストのワークショップで初めて教えていただきました。
5段階評価で今回
満足度 4.6
理解度 4.7
をいただきました！やったね！わーいわーい：）
最後15分くらいで、参加者全員のTRYを発表していただきました。
これだけであと2時間くらい話せる気がしました。
興味深いものをいくつかご紹介します。
以下のブログが参考になるかなと思います。
私が最初に買ったのが
この辺なのですが、293とかは、読んでもなんか当たり前のことが書いてある気がして
よくわかりませんでした。
「今しているテストがうまくなる魔法の本」を欲しがったのだろうなと思っています。
「これさえすればバグが出せるテスト実施の本」を欲しがったのかもしれません。
これらのどれも未だに必要な本で、特に293は、今色々言語化したいなーと思っていることが
まさに書いてあってびっくりするので、
テストの勉強をして数年だったり、テストマネージャーなどテストを他の人とやっている、教えている人には
そうそうそう という内容が書いてあるのでお勧めです。
ちょっとゴリ推ししたところもありますが＾＾；
やっぱり日本で売っている「テスト技法」だけが凝縮された本なのでおススメしています。
ただ、きっと技法だけが理解できても、業務にうまく適応できなくて挫折するかもしれません。
とお伝えしています。
そうじゃない優秀な方も多いと思いますが、
私は結構使いどころがわからず戸惑いました。
そのときに「使えない」と思うか「使い方を工夫する」「つかいどころが分かった時にさくっと使いだす」ために必要なので 諦めないでください。
あと、使い続けないと忘れるし、下手なままです・・・
JSTQBシラバスのPDFは無料ダウンロードできるので、是非おすすめします。
今回シラバスの中から紹介したものも多くありますが、
他社や社外で話をする場合、相手が何の話をしているか、JSTQBを知っていると言葉のずれが減って、会話が楽になります。
「テスト」といっても、さまざまな「テスト」があって、
そのせいで会話がかみ合わないことをできるだけ減らせるといいなー
みたいな話をしました。 また、試験もあるけど、まずはシラバスを読んでみるといいよ！無料だし！ とお伝えしています。
みんなも読んでみるといいよ！
さっそく共有してくれるのって嬉しいです！
また、私の場合は”めんどくさい”とか”別に外でも中でもよくない？”て思ったものは
どちらにも共有するようにしています。
このブログもそうですし、わかんないのは社内や社外（Twitterが多い）で聴いてしまいます。
自分が楽でプレッシャーにならない方法を模索して欲しいと思います。
もちろん、社外秘じゃないことであれば。
個人の好みもあるんだろうけど、「闘う」ってあんまりよくないような気がしています。
私にはあわないかなぁと。
わたしたちの仕事は、エンジニアのやったものに対して、ダメだったところや、カイゼンした方がいいところ
エンジニアにとって、つらいところを指摘することが多いお仕事です。
そのときに、戦うモード（上司はエンジニア側ではないだろうから、この例は変かもしれないけど）なのは、お互いが消耗するんじゃないかなと思います。
できれば、テストする人もエンジニアも、使うお客さま全員が
しあわせになれる方法を考えたほうがいいなーと思いました。
今回「テストケースってこんなに考えないといけないのね」のワークをしたので、「減らす」TRYが出てきたのはびっくりしたしとても嬉しかったです。
テストはどうしても増える傾向にあると思うので、
減らすためには工夫しないといけないと気付いてもらえたのは本当にうれしいです。
すでにテストケースが用意されているところだそうで、
「今の自分たちがやっていることが何なのかふりかえる」って気づくの本当にすごいと思いました。
テストの意図がわかるようになると、もっと工夫するところがでるし
意味のないテストにイライラするかもしれないし
ここから、今回キーワードに出していない「テスト設計」に目覚めるかもしれません。すごいなぁ。
とってもﾜｸﾜｸしました。
数年ぶりに私のテスト勉強会にきてくださった方です。（他にも某研究室の元学生さんが5年ぶりに後輩つれてやってきてくれました）
それぞれ諸事情もあるし、疲れることもあるので、自分のペースで社外にでるといいよ。とお伝えしました。
疲れたら外にでない日があってもいいと思う。
でも社外はやっぱり刺激的だし、できるだけ楽しい気持ちで帰ってもらえるとうれしいので、
私もがんばろうと思いました：）
社内でずーっとプレゼン最下位グループにいた私なので、とってもうれしいです！
やればできるようになるし、
今までみてきた諸先輩方のセッションで、ぐっときたところをどんどん取り入れたり意識して
たくさん伝えられたらいいなぁ。
SNSに慣れていないとかもあるのかもしれませんが、このセミナーの資料は毎年公開しています。
また、申込み画面にアジェンダを記載しているのですが、
「マイヤーズの三角形問題」を予習している人がいませんでした。このセミナーと関係なく知ってる方はもちろんいらっしゃるんですが
マイヤーズの三角形問題
と記載しているけど、事前に中々調べないもんだなーと思っています。もちろん調べてくる必要はないようにワークをしています。
調べてくるときっと面白くないかも
毎年「もっと深く教えて欲しかった」や「最後が駆け足だった」というような声をいただきます。
今回の目標は「さまざまなキーワードや用語がある、テストの存在を知ってもらいたい」ということがあって
さらっとお伝えするようにしています。
１つ１つ本当に勉強しようとすると、それだけで１テーマになると思うので難しいのですが
来年またちょっと工夫できたらいいかもしれないなぁと思います。
自分がテストの勉強している内容を、少しだけ体系的に、
自分が外に出るようになって「テスト楽しい」をセミナーで体験して欲しい
自分が色々シンポジウムとかに参加して得た「楽しさ」「発表スタイル」を感じて欲しい
せっかくなので社内だけじゃなくて、社外にも伝えたい
色々想いはあるんですが（書いてて気づいた）
うまく伝えられるようになってきたみたいです。
（それでも初年度の「感動しました」は、いただけてないので、エモさが減ってきたのかもしれない。
でも、誤解のないような説明はずいぶんうまくなってきたんじゃないかなぁ）
このセミナーではいきなり武器を渡すことはできなくて（カタログを見せてるのに近いのかな）
テストって楽しいのかもしれない
自分たちも何かできるようになるかもしれない
テストも勉強することがあるのか
とかをちょっとだけ、本当にはじめの一歩を踏み出せてもらえるといいなーと思っています。
また、悩みを聞いて「これはこう」「これはそうじゃない？」とか
本を読んでつまづく気持ちとか
この数年で色んな人と色んな話や経験をしたことが活かせていると思いました。
わたしは今のところ「ソルジャー」「エキスパート」みたいなところにはいなくて
多くの人にテストの子とを知ってもらったり
そこから活躍する人たちを発掘したりするのが楽しいみたいなのと
凡人だからこそ、伝えられることとか、わかりあえることがあると思うので
これからも続けたいなぁと思います。
3年前に現在の所属企業でも同じワークショップをしたときに. 英語版のスライドを作成してもらいました。
Speaker Deckの方が使いやすいと思うので、日本語版もあげなおします。
Speaker Deck日本語版はこちら
Speker Deck English version here.
昨年に引き続き、今年もPHPカンファレンス福岡2017でお話してきました。
昨年の↓ underscore42rina.hatenablog.com
さて、私は非エンジニアなので、2年も連続して採択してもらって本当にありがたいと思いました。
ありがとうございます！
昨年は「日本で一番PHPのテストしている」と豪語したわけですが
「（開発部署で一人でテスト専門にやっている手動のテスターの中で）日本一PHPのシステムのテストをしている人」だと思っていたのですが、
昨年部署構成が変わって、開発部門じゃなくなったので、全然日本一じゃなくなりました。たぶん。
去年話せてよかった。
今年はさらにテストの話もせずに、日本語の話（バリデーションメッセージの話）をしました。
エンジニアさんがささっと設定しちゃうのかなーって 思う背景とか
そういうメッセージ だと、ユーザーはどう思うのかなとか
なぜだめなの？とか
じゃー、どうすればいいのかなとか。
今回のセッションは、本当に当たり前の人は当たり前すぎる話だったので
こんな当たり前なことを15分も使ってメインホールで話して大丈夫なのか
超不安でしたが
ちょっとだけ「そうなんだよね」とか「明日からちょっと気にしてみよう」
って気になってもらえたら大成功だと思います。
そんなこんなで、今年のスライドがこちらです↓
www.slideshare.net
※今年はYoutubeの動画配信もOKにしちゃったので、あとで追加します：）
※追記しました↓（2017/07/24）
登壇後にAsk the Speakerや懇親会で
「発表を聴きました」
って何人かの方に言っていただけました。
「おすすめされて、メインに聴きにきました！」って方もいてくださって嬉しかったです。
ありがとうございます！
「日本語大事ですよね」
って言っていただけて、うれしいです。
機会を作ってくださった、実行委員のみなさま、聴講していただいた参加者のみなさま
応援してくださったいつものみなさま
どうもありがとうございました。
今年も参加できてよかった：D
2年ほど前に社内用に書いたエントリーだけど、いいこと書いてたので一部修正して公開します。
もともと私自身の頭の整理をするためにこのエントリーを書きました。
初めて私とテストされる方や新人のエンジニアは特に読んでいただけると嬉しいです。
私と仕事をしたことがあるエンジニアのみなさま、バグ票（チケットやIssue)のやりとりをしていて「何かやたらこのチケットにリナさん食い下がってくるなー、こだわってるなー」と思うことがあるはずです。
普段、チケットを起票するときには原因が何となく予想できていることが多いです。
例 表記ゆれ データベース登録時のエラー JavaScriptのエラー 変数の型間違い などなど
ある程度のパターンがわかっている場合は、「なおしました」と書いてもらうか、あるいは書かなくても修正していただいてチケットを確認します。
時々、全く予想つかないバグが出ることがあります。
その場合はある程度腑に落ちる説明をお願いしています。 理由は、
例：
■バグの現象： 登録画面で誤った入力をした場合にバリデーションメッセージが表示されず、404エラーの画面が表示された。 ■バグの原因： ・バリデーションは入っていたが、バリデーションに引っかかっていたときの画面遷移先が間違っていた。 ・バリデーションメッセージが表示されなかった。
このように、1つの現象に２つバグが含まれる場合、2つとも修正されずに手前の修正（この場合、バリデーションメッセージを表示する）だけされることがあります。
わたしの場合、
の両方が納得できたときにはじめてチケットをCloseするようにしています。
バグの原因が報告時点で二つとも指摘できればよいですが、現象だけで判明（または予測）できないことも多いです。
ですので、「気持ち悪い」「変な動き」と思った部分が説明を受けて納得できると、Closeすることができます。
バグって１個出てきたらそれを修正して終わりではなくて、必ず同じようなバグがないかを確認する必要があります。これはエンジニア側も常に意識しておいてほしい。
で、「こういう原因でバグでした」という情報があると、同じような箇所を確認できたり、「こういう修正をしました」という情報があれば、その修正ならばこのケースは考慮できてるかな？とか確認できるので、どう修正したかを伝えるのは大事です。
つらつらと書いていますが、単に私のこだわりだったり我儘だったりわかってないだけ、ということも多々あると思います。
バグ票は私（テスター）とエンジニアの活動を幸せにするためのコミュニケーションツールだと思っております。
思い込みの部分もあると思いますので、優しいツッコミお待ちしております。
underscore42rina.hatenablog.com
から数週間経過。
見事にアクセスが減ってしまった。
Excelってやっぱり人気なんですね。
テストでもアクセス伸びるようにがんばろー（あんまりテストの技みたいなの書かないので、それはそれで微妙だけど）
