いもろぐ

思い立ったら書いていくスタイルで

最近の社外発表のまとめ

8月に社外で話をする機会が2回あったので、その報告(?)と感想を。

5minQues

Quesのスピンアウト企画として実施されたLT大会。とにかく登壇者が豪華。よくもこんなメンバー集められたなと思いました。そして私はここにいていいのかと不安になりましたw

登壇者

私の発表の概要は

  • QEっていう、技術を使ってテストするチーム(2人)を立ちあげて勉強中です。
  • テストのノウハウを持った状態で開発もできるようになったらステキじゃないかなと思ってます
  • 開発スキルを身につけるために、開発チームに「留学」してます

...という内容。5分LTなので話しきれてないところもありますが雰囲気は伝わったかなと。

印象的だったのは「開発者とテスト担当者の視点?考え方?の違いは何なのか?」という質問。社内留学を始めて1ヶ月くらい開発者として(ド初心者ですが)コードを書いている中で、テストをする時の自分と何かが違うなと感じてはいるのですが、言語化できていない状況です。その後、人と話す中でもらったヒントとして「ゼロから動くものを作るのと、動くことが前提のところからテストするのとでは役割(何をしたら褒められるのか)が違うのでは」という話は、なるほどな、と思いました。

ココらへん、同じものに対して「テストするときはこういうことを気にするけど、開発するときはこういうところに注目する」みたいな実例が言葉にできるといいなと思ってます。

あと、留学自体についてもどこかで報告せねば。

九州ソフトウェアテスト勉強会

私の相方の実家が福岡で、そこに帰省するのに合わせて(?)九州でも発表してきました。参加者は12-13人くらいでしたかね。テストの勉強会に始めて参加する人が半分くらい。また、割合として開発者のほうが多かったです。

ここでは弊社で行っている新人研修の話をしました。弊社では新卒エンジニアに向けて独自に研修プログラムを組んでいて、例えばHTML/CSS、GIT、デザイン、ペアプロ、Webアプリ作成課題、、、のようなことをやっています。その中に「QA」という枠があって、そこについてレクチャーをしています。

おそらく新卒(というか学生)は、QAという存在すら知らないと思います。プログラムを作ることは学校でやってると思いますが、それをテストする専門の人がいるんだ、へぇー、ってところがスタート。

...詳しくはスライドを見てください!

この話の本筋ではないのですが大事なところとして、スライドおよび話の中で「Webと組込みの違い」という話をしたのですが、「WebのQA」という表現について質問が出ました。

例えば「Webシステムだけど金融とか、大きな業務システムとかを扱うところもあるわけで、Webとしてひとくくりにするとそこらへんがごっちゃになってしまうのでは」という質問。

確かにその通りです。私がイメージしているものは(金融とか医療とかと比べて)「軽い」ものを想定しています。誤解を恐れずに言えば「リリース時に品質が(相対的に)低くても大丈夫なもの」とか「品質よりもスピードを重視するようなもの」になります。またはBtoCサービス、という切り方も近い気がします。(ここらへん、うまい表現が思いつかない...)

私自身が「重い」Webシステムに関わったことがないのと、Webの特性として「軽い」ものが多いしそれがウリなんじゃないかなーって感じているので、私の中では「Web=軽い」というイメージがあって、「WebのQA」って一括りにしてしまっています。

@snsk さんのいうところの軽量品質保証がマッチするような業界、、、みたいなのかな。

ということで、発表の機会があったのでまとめてみました。


プロジェクトマネジメントのもう一つの世界観 に思ったこと

弊部部長のブログが素晴らしいとネット上で話題に!

hidehigo.hateblo.jp

これを読んだ感想を書いてみました。(ですので先に上記の記事を読んで欲しいです)

私は前職で「クリティカルチェーン」とか「学生症候群」の話を知った時に、あぁ、自分もそうだよなーと思いました。その時は業界的に「予測型」があたり前の世界だったので、いかに未来を予測するか(そして記述にあるようにバッファを盛り込むか)みたいなことをやってたなーと。

見積もりを依頼されてまず思うのは「これくらいでできそうです」と言ったらその中で終わらせないと約束破ったな的な非難をされるんじゃないかという恐れ。それでも当時は「見積もってその通りに終わらせるのが仕事。それが無かったら仕事できないじゃん」が常識でした。

私はアジャイルとかスクラムをここ2年くらいで知りました。弊部には2人「認定スクラムマスター」がいますが、その人がスクラムマスターを務めたプロジェクトを見てて感じたことがあります。(残念ながらプロジェクトメンバーとして参画したことがまだ無い)

  • メリット

    • 目の前の、作業完了が予測できる範囲を見てるので安心できる(このスプリントとその次くらいにが終わった時に何ができるのかわかる)
    • バックログにやるべきことが優先度の高い順に並べて上から順にやっていく(非常にシンプル。割り込みがあってもそれがバックログに追加される)
    • 予定も仕様も変更されるものである、が前提なので、変化を許容できる(プロセス的にもそうですが、特に精神的にも変わってあたり前が受け入れられる)
    • 変更(特に追加)がある場合、それに応じてスケジュールかスコープが変わるので、「今のスケジュールのままだし、スコープも同じだけど、コレを加えてね、よろしく」ってことにはならない
    • これらから、関わるメンバーの気持ち的なゆとりが生まれる
  • デメリット

    • 自分たちが1スプリントで実行可能な作業量をウォッチしていくので、過度な残業や休日出勤がされないかわりに、プロジェクト終盤の「追い込み感」が無い (コレに関しては私自身がメンバーになって体験していないので、外からはそう見えた、ってことで)
    • 例えば来週火曜にリリースだからこの土日出勤してでもブラッシュアップしていきたい!という気持ちに歯止めがかかってしまう(←ココらへんは臨機応変にやればいいとは思いますが)
    • 従来の(納期とスコープが動かせないタイプの)開発の仕方のほうが、短期間プロジェクトであればいいモノができるのではないか(ここは比較してはいないので完全に私の主観なのと、いいモノの定義もいろいろ)

また、スクラム自体に勘違いされそうだなと思う点として

  • 発注する側からみると、何でもかんでも好きなときに、お気軽に変えていいんだな、って思われちゃうのは違う
  • 開発チーム側からみると、「できるところまでしかやらない」が「ラクしていい」に受け取られるのは違う

特に後者で、日々ものすごい業務量をこなしている開発者にとって「できるところまでしかやらなくていい」という言葉を聞くと、なんかすげー助けられた感があるじゃないですか。ホっとするというか、肩の荷が下りるというか。一方で、「じゃあえて低く設定しとけばラクし放題じゃね」みたく受け取られちゃうんじゃないかというのが心配なところ。そうじゃないですよねw

スクラムが上手くいく条件として私が思うのは「発注する人も作る人も、本気でそのプロジェクトの成功を願ってるし、そこに向けて惜しみなく自分のできることを出していけるし、メンバー間の信頼度も高い状態。結局のところ人が成功のカギ」

「労働者は可能な限り少ない労力で可能な限り高い賃金を得たいし、使用者はその逆」という世界には絶対に合わない仕組み。

(私自身はスクラム開発について本読んだくらいしか知識がないので、この記事の中で勘違いや知識不足などあったら申し訳ありません、、、)


SeleniumWebDriverでテストする練習

前任者が残してくれたコードを元にして自分で勉強してみました。 コードとかはこちら↓

qiita.com

タイミングよく、ちょうど実戦で使える場面が出てきたので早速これを使ってやってみます。

課題としては、いろんなブラウザで実行するには? とか RSpec的にもっとうまい書き方あるんじゃないの? みたいなのを考えています。

selenium界隈ではこんなのがあったみたいです。次は参加してみようかな。

qiita.com

新人研修用にQAレクチャーした話

表題の件はコチラのブログに載ってますw

gaiax.hatenablog.com

このブログに書かれていない話を。

このレクチャー、実は3回目なんですよね。

1回目は2013年に「ジョブウェブコラボレーションプロジェクト」として、エンジニアになりたい学生に向けたセミナーでした。

www.jobweb.jp

なにこれ、面白そうだよね!

そもそもエンジニアになりたい学生が品質とかテストに興味を持っていること自体が激レアなわけです。この会でもどこまで学生に刺さったのかなぁ。。。初めてだったし、不安だったなー。そういえば形から入ろうとしてスーツ着てで講義してたのを思い出しました。

2回目は2014年新卒研修。その会はエンジニア5人に向けて行いました。

そして今年の3回目。自信を持って言えるのは、今回が一番盛り上がったということ!今年の3人はいいやつだw



その都度少しずつ資料を更新しているのですが、自分でも改めて読みなおしてみると、 もっとちゃんと理解しなきゃなー、とか、もっと別なことも大事なんじゃないかなー、 とか思ってしまい、どんどんボリュームが増えるっていうね。(削除もしてます)

自分の勉強にもなってとてもいい機会でした。いやほんと。人に教えるっていう経験は大事ね。


テスト関連イベントの雰囲気と、TestingCasualTalks#2の感想

5/14に第6回Ques、5/25にTestingCasualTalks#2 と、近い日程でテストイベントがありました。

Quesでは一般参加者として、TestingCasualTalksではスピーカーとして参加したのですが、これらのテスト関連イベントについて思ったこと、感じたことを書いてみます。

前提として、私自身がソフトウェアのQAなのですが、今のところ非開発者なのでお仕事ではコードは書かないです。(書けないんじゃないよ!ちょっとだけ書けるよ!) そんな私が参加するイベントはJaSSTとかWACATEとかです。過去に自分で「Webなテストの勉強会」(タイトルはうろ覚えw)と題して20~30人くらいの勉強会+懇親会を企画したことがあります。第5回Quesではスピーカーとして参加させてもらいました。(その時の資料はこちら) これらの会の空気感はとてもよく似ていて、テストの勉強会ってこんな感じなのねー、って思ってました。(よく考えたら関わってる人たちに共通の知人が多いのであたり前か)

で、今回のTestingCasualTalks#2ですが。 120人(?)くらいの参加者の100人くらいが開発者というね。私の気持ちとしては完全なアウェー感でしたねw 第5回Quesの時はQA、開発者、その他、が1/3でして、そんな体で資料とかトーク内容考えてたので「あれ、これわ...」って思いました。 話をしている最中の会場の暖かい笑い(?)はとてもありがたく、懇親会の雰囲気とかでうまいこと馴染めたかな?って思いました。

今回は3人のスピーカーが登壇したのですが、私以外の人の話は「コードでのテスト」の話がメインで、会場の食いつきもそちらのほうが強かったような気がしました。さすが開発の皆さん、自然言語よりも形式言語で語ってくれってことですよね!<違うと思う



@hsbtさんのmrubyの話は、次が私の発表だったのでドキドキしててちゃんと聞けませんでしたごめんなさいw

www.slideshare.net



2番手として私の発表。ポイントは手書きプレゼンに挑戦 <そこ?

www.slideshare.net



@deme0607さんのブラウザテスト自動化・並列化の話

speakerdeck.com

これは自分の発表が終わって気持ちが解放されていたのと、ちょうどSeleniumWebDriverでのブラウザテストはやったことがある(これからまたやる)のでとても興味深く聞けました。とはいえ、私の場合はまだ「大規模化」とまではいけてないので、技術的な解決方法よりも「ブラウザテスト自動化のメリット(の説明の仕方)」とか参考になりました。

その後のLTではWebサービスに使えそうなテストツールを教えてもらいました。

  • 負荷テストツール
    • Gatling:名前からしてこれでもかと負荷を与えてくれそうな。
  • セキュリティテストツール

ちょっと調べてみよう。

発表スライドにも書いたのですが、ガイアックスでは「技術を使ったQA」というテーマで新たな活動を開始しようとしています。そもそも私が技術わかってんの?て感じなので頑張ります。そして一緒にやってくれる人募集してます。いやほんとに。



最後に、QuesとTestingCasualTalksの大きな違いを書いておこうと思います。これはとても大事なことです。

Quesの方がTestingCasualTalksに比べて女性参加者が多い

@ikasam_aさん!TestingCasualTalksも盛り上げていきましょう!私にできることがあれば是非お手伝いさせてください!(女性集客のどこに貢献できるかわかりませんがw)




Ques#6 感想とメモ

2015/5/14 に行われたQues#6のメモ。

永田さんの話に勇気づけられた会でした。

あと、懇親会で知ってる人がだんだん増えてきてそこで近況報告とかするのが楽しくなってきたのでこの輪を大事にしたい。だけど懇親会の時間だけじゃ話足りないのよね。懇親会だけを目的としたイベントとかあればいいのに。(やればいいのか。ただの飲み会だけど)

感想、思ったことを先に

  • スクラム開発について

    • もともと開発チームのベロシティ(スプリント内にいくつのストーリーポイントを消化できるか)は一定(実際は慣れていくと上がるけど)として進めるはずなので、スクラム開発していながら「終わらないから残業とか土日でやるわ」っていうのは違う気がする。
    • その場合は納期を遅らせるか、スコープを減らすか、の対応がスクラム的には正解なんじゃないかな。
    • できるところまでしかできません、が基本。
    • 大前提として「自分のプロジェクトであり、成功させることが自分のミッションである」と感じているメンバーが集まっていること。
    • そうじゃないと「できるところまでしかやりたくありません」っていう「逃げ」になって不毛。
  • スプリント内に終わらない話

    • スプリント内にテストが終わらない、あるいはテストは終わってもそこで見つかったバグ修正が終わらない、とか。
    • 本来は「○○のバグを修正する」という作業もストーリーとしてチケット化され、ストーリーポイント(作業にかかる工数というか相対的な値)を割り振るのがセオリー。
    • だけどスプリントでのベロシティは変わらないはずなので、ここでもスコープ(か納期)の調整が発生する。
    • これを吸収するには「バグ修正」のタスクを予め想定しておくこと、かな。
  • そもそもスクラムのチームって一つのチームなのでは?

    • 役割が違うだけで、チームとしてやるべき作業は洗い出されているはず。
    • 企画・設計・開発が作ったものをQAがテストする、という仕組みじゃない。
    • 企画・設計・開発・QA(必要ならその他の役割も)で一つのチーム、という思想。
    • だけどこれまでの経緯から「作ったものをテストする」タイプの関わり方をしていた組織にとって、開発チームの中に入っていって何ができるのか、は課題。うちの会社でも課題。
    • でもそこで確立できたら楽しそう。
  • スクラムに必要なドキュメント

    • 何でもドキュメント化するんじゃなくて、チームの暗黙知が高まると、そのチーム内のコミュニケーションは高速になるよ、というのはわかる。
    • そうしそうしたいけど、そこに後から入ってくる人とか、引き継ぐ人がいる。
    • あるいは将来の自分が見た時に「これなんだっけ?」になりそうなジレンマはある。
    • 「必要最低限のドキュメント」として何がアレばいいのか、はその時々だけど、その時々で定義できるのかな自分は。

セッションのメモ

ソニーの永田さんの話を聞いたメモ。(最初のKDDI鈴木さんのセッションには到着が間に合いませんでした)

品質をよくできなければアジャイル開発は成功しない

テストベースどうするのか?

  • ドキュメントが書かれない。
    • それがないとテスト出来ない・・・うまく関係が持てない
    • まずここが障壁になりそう
  • なぜドキュメント化しないか?(QAから見て欲しい情報)
    • 企画、開発は暗黙知を持っていて、それで意思疎通している。
  • 設計をするためにアーキテクチャプロトコルはドキュメント化している
    • そのドキュメントと暗黙知をミックスして開発している。
  • その中にQAが入って欲しい情報をとってくる。
    • ユーザーストーリーで要求と仕様を表現できるか?
    • 彼らの暗黙知の中に入っていく
    • ドメイン知識は知らなければダメだし、(そのチームの)ポリシーみたいのを感じる?のが大事

設計開発へのフィードバック

  • (テストをして)何をフィードバックするのか、を説明する
    • そのためにどんな情報、成果物が必要か
    • その中で信頼関係が生まれる
  • 設計者にテストケースをレビューしてもらう
    • 設計にテストを組み込んじゃう
    • 設計しているときにシステムテストをやるイメージ
  • ツールから取れる情報を見える化する
    • メトリクスとかKPIに対する現状とか
    • バーンダウンじゃなくてバーンアップチャート
    • ストーリーポイントが増えていることがわかる
  • ベロシティは経験値。改善していくことで上がっていく。
    • 劇的には変わらない
    • 手戻り(バグ)を減らす
    • コミュニケーションロスを減らす
    • 待ち時間を減らす
  • 現状の把握(メトリクスとか、事実を見て)
    • それに対してどうするかを計画する、何をするのかを都度決める
    • (今起こってる、すぐ改善すべきところはどこなのか)

3分悩んだら聞け

  • 困ったら聞けばいい→ドキュメント減らせる→暗黙知高まる

QAが(開発プロセスも含めて)改善する

  • おしまいのフェーズに入ってくるのではなく
  • 朝会も振りかえりもQAが入っていて改善していく
  • 施策の効果がメトリクスに現れる
  • 例えばバグ傾向のフィードバックとか

ウォーターフローでは情報を待ってた

  • アジャイルイテレーションごとにメトリクスがわかる
  • それを改善するところに入っていく、むしろ仕切る
  • アジャイル開発を正しく理解することが必要だけど。
  • やってることはシステムテストレベル。マニュアルテスト。
  • それをやるためのテストベースを「取りに行く」

トークライブ

鈴木さんと永田さんのトークライブ。MCは@snskさんでした。

アジャイルチームに歓迎されるテスターのスキル・人物像

  • 鈴木さん
    • コミュニケーションに苦痛を感じないこと
    • 暗黙知やフィジカルなコミュニケーションがMUST
  • 永田さん

    • 年齢とか関係ない。
    • 得意なところ、何を提供できるかを「表現できる」と信頼される
  • 永田さん

    • アジャイルは設計も開発もシロウトじゃできない
    • リアルタイムで改善していきながら、設計も実装もする。CMMIではレベル5
    • やる気。面白いなこれ、やってやろうって思える人。
  • 鈴木
    • スーパーヒーローはいらない
    • どこにでもいる人でやっていける
    • マインドセットが大事。

最低限必要なアジャイルチームのドキュメンテーション

ユーザーストーリーのテンプレはある。ただHOWが書かれていないのでテスト設計ができない。どんなドキュメントが必要になるのか。

  • 永田さん
    • エラー処理を全ては(ドキュメントに)書くわけじゃない
    • が、だいたいパターンが決まってる。(ウィンドウのどこにエラーがでる、的な)
    • そこは書こうよ、という決めにした。
  • 鈴木さん
    • 製品によって違うけど、うちの場合は画面設計書は必須。
    • ユースケースマップを作っている
    • 誰が目的で使うか、かな。
    • (そのドキュメントは)主に設計開発の人がつかう。QAの人もみる。
  • 永田さん
    • 結局はチームで決めること。
    • 今までQAが入っていないなら、これから入っていって「何がアレば自分たちは何ができるのか」を言っていく(成果を出す)ことでチームに信頼してもらう

...以上です。 今回も楽しい会でした。 運営の方、ありがとうございました。


ansibleやってるよ、ほんとに。

ansibleでサーバ環境の構築を自動化しているのですが、なんというか、今さらですが人がやることを自動化していくっていかにも技術ー!って感じでステキ。

ただ、いかんせん私の理解が遅いのと、技術情報の調べ方に慣れていないのでなかなか進まないこと。(でも楽しい)

調べたことがあったのでQiitaに書いてみました。

qiita.com