技術的な話を抜きにソフトウェアテストの分析と設計について語ってみるよ

location_city Osaka schedule Jun 18th 03:00 - 03:45 PM JST place 新潟 people 5 Interested

こんにちは、世界。
新潟で、テストの街「葛飾」と仲間たちがソフトウェアテストの分析と設計について語ります。

みなさん、ソフトウェアテストはどうしていますか。

まさか、いきなり、猿みたいにテスト実施から始めていないですよね。

テストには、以下の主な活動からなるテストプロセスがあります。

  • テスト計画
  • テストのモニタリングとコントロール
  • テスト分析
  • テスト設計
  • テスト実装
  • テスト実行
  • テスト完了

今回は、オンライン区長とテスターおおひらが、テストプロセスで特に好きなテスト分析とテスト設計について、実際にどうやっているかを話します。

ちなみに、
オンライン区長はオンプレパッケージ製品、テスターおおひらは業務系SaaSのテストを普段しています。

二人とも独学で始めて、10年経ちました。

テスト分析・テスト設計は業務に密接に関わるので、外で話すことはありませんでした。

そのため、かなり独自になっているかもしれませんので、あしからず。

もちろん、批評、反論なんでもござれ。

10年ぐらい考えた続けたテスト設計について、
みんなでワイワイディスカッション形式で語りますので、
よろしくお願いします。

 
 

Outline/Structure of the Talk

  • メンバー自己紹介
  • オンライン区長が実戦時してるテスト分析、設計について語るよ
    • どんな開発プロセスなの?
    • どんなテスト分析・設計している?
  • ディスカッション(オーディエンスからもテーマを募集)
    • テスト分析・設計で大切にしていること
    • テストオラクルについて思うこと
    • アジャイル的な開発で、システム全体的なテスト分析ってどうやってんの? 
  • おわりに

Learning Outcome

オンライン区長のテスト分析・設計が知れます。

Target Audience

業務アプリケーションのテスター

Prerequisites for Attendees

テストに興味がある人

schedule Submitted 1 year ago

  • Tomonori Fukuta
    keyboard_arrow_down

    Tomonori Fukuta - SI企業が「アジャイル推し」になったら幸せになれますか?

    20 Mins
    Talk
    Intermediate

    田舎でスクラムシリーズ16年目

    ちんもの勤める会社が突然のアジャイルフィーバーになって1年。

    経営陣と組織職が全員アジャイル研修を受け、全社方針にも組織戦略にもアジャイルの推進なるものが組み込まれ、顧客から多くのアジャイル案件がやってくるという状況になった。

    果たしてこれは、長らくちんもが夢に見てきた世界なのか、そして会社人生の多くをアジャイルの展開に投じてきたちんもには、いよいよお役御免の時が迫っているのだろうか...。

    アジャイル時代にSIerが抱える新しい課題に果敢に切り込むちんもの無謀な挑戦、聞いてやってください!

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - A Practical Guide to Testing in DevOps - Katrina Clokie(動画放映)

    Jumpei Ito
    Jumpei Ito
    QA Manager
    WingArc1st Inc.
    schedule 1 year ago
    Sold Out!
    90 Mins
    Talk
    Intermediate

    DevOpsの世界において、テストはどのような位置づけにあるのか?

    テスターはどのように適応すればよいか?

    DevOpsでは、開発チームと運用チームが一緒に仕事をすることが奨励されています。これにより、製品を提供するために協力する人々のネットワークが広がり、テストの境界が拡大し、テストの性質が進化する機会が生まれます。

    開発チームが運用で利用可能なスキル、プラクティス、ツールを理解すると、テストは生産に向けて右肩上がりになる。例えば、本番同様の環境でテストを行うことができるオンデマンドインフラ、顧客指標から得られるA/Bテスト実験からのフィードバック、顧客からのフィードバックを迅速に提供するベータテストグループなどがあります。

    DevOpsによって納品ペースが上がると、新機能のテスト戦略にも課題が生じます。開発チームは、リリースを過度に妨げることなく、どのように新機能を調査すればよいのでしょうか。テストの自動化、モニタリングとアラート、迅速な自動デプロイとロールバックなどのツールの賢い利用を含めて、テストアプローチを適応させることができます。

    このセッションでは、Katrinaが彼女の著書「A Practical Guide to Testing in DevOps」からいくつかの考えを紹介します。また、DevOpsを紹介し、開発中、本番稼働中、インフラに対するテストのための一般的なDevOpsプラクティスをいくつか紹介し、DevOpsがどのように、そしてなぜテスト戦略を変えるかも説明します。

  • Shusuke Fujii
    keyboard_arrow_down

    Shusuke Fujii / Ayaka Moribayashi - みんなが初心者だからいい。全員で動く、アジャイルチームの成長日誌

    45 Mins
    Talk
    Beginner

    長期間にわたり、保守・開発を続けていると、メンバーの間にいつの間にか上下関係ができてしまい、うまく行っていたスクラムチームがいまいちな状態になったことはないでしょうか?
    私たちにもそのような時期がありました。そのようなチームに突如訪れたメンバー交代、そして入ってきたのは、アジャイルをやったこともなければ、エンジニア経験も浅いメンバーたち。
    そのようなメンバーを中心として、チームを再構成する中で、アジャイル開発を体験したメンバーがどのように成長を遂げ、新しい形でチームを作り上げていったのかお話します。

    チームを作るのに、何かとらわれのようなものを持っていないでしょうか?
    チームとは何か、チームとして達成したいものは何か、私たちは何度も話し合い、自分たちにあった形で変えてきました。
    アジャイルどころか、システム開発自体も知らなかったメンバーもいるなかで、スクラムを中心に取り組むこと、諦めることを先入観なしに行うことで、チームの雰囲気も変わり、大きく成長をすることができました。

    チームビルディングに悩んでいる方のご参考になればと思います。

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - 読書に悩むあなたに贈る50の読書方法カタログ

    90 Mins
    Talk
    Beginner

    何かを学びたいと思った時の方法の一つとして、「読書」があると思います。
    集約された賢人の知恵をもらうことが数千円の投資でできる読書は、物事を学ぶのに非常に投資対効果の高い方法であるはずです。

    しかし、現実を見てみると、読書が思うようなペースで進められなかったり、読みたかったはずの本なのに読んでいる途中で苦しくなって挫折したり、読んだのに何も行動変容が起きなかったりと、読書を通して自分が思っているような姿になれず、悩まれている方も多くいらっしゃると思います。

    本プレゼンテーションでは、ここ1年半で316冊の本を読む過程で自分が行ってきた、試行錯誤の結果(153個の読書方法を実践)の中から50個をピックアップして紹介する(※)ことで、読書の仕方に悩まれている方の一助になることを目指していこうと思います。

     

    ※ハイピッチで50個の読書方法を紹介しきるか、参加者の皆さんが気になる読書方法を幾つかピックアップしてゆっくり紹介するかは、当日に参加者の皆さんにアンケートを取って決めたいと考えています。

  • Mori Yuya
    keyboard_arrow_down

    Mori Yuya - プロダクトってなに? マネジメントってなんなの? ゼロからプロダクトマネジメントを明らかにするぞ

    45 Mins
    Talk
    Beginner

    このセッションは、以前はそれほど気にしていなかったプロダクトそのものや、マネジメント、最近耳にするようになったプロダクトマネジメントについて、徐々に当事者になりつつある方に向けたセッションです。プロダクト作りに注力するチームや、プロダクトオーナーが知識の土台を揃えられ、異なる立場の人との効果的なコミュニケーションに役立ちます。

    一言で「あっ (プロダクト|マネジメント|プロダクトマネジメント)ってそういうことだったのかー!」が得られるセッションです。ビジネス側やマネジメント層と区別される人達とも、よりスムーズなコミュニケーションができるようになります。私自身がプロダクト開発にはじめて接するときにはじめに聞きたかったことをお伝えします。

    ----

    「プロダクトオーナーがボトルネックだ」という声をよく聞きます。ところが、私がスクラムを学び始めた10年前から続いています。問題があればみんなが喜んで解決してしまう開発者コミュニティでは、まるでアノマリーのようなテーマです。

    しかし、もはやプロダクトの責任はプロダクトオーナーだけのものではなくなりました。プロダクトを明確に意識しなくても仕事として成り立っていましたが、すこしずつプロダクトという言葉があふれつつあります。スクラムでもプロダクトオーナーに加えて、プロダクトバックログ、プロダクトヴィジョン、プロダクトゴールというようにです。

    同様にマネジメントという言葉もよく耳にするようになってきました。「マネジメントって何?」と聞くと、「何とかして達成すること」だったり「やりくりすること」という答えが返ってきます。しかし、明日からマネジメントをする人にとってみれば、それらの言葉では動きようがありません。仕事をしている過程で「マネジメントの仕事はしていないけど、やりくりは日常的にしている」という方も多いでしょう。

    プロダクトもマネジメントも、明日から「こうすればいいんだ」と思える明確な表現が必要です。

    また、近年はプロダクトマネジメントという言葉が良く耳にするようになりました。いろんな方がいろんな説明をされています。先ほどのプロダクトとマネジメントが組み合わさった言葉ですが、それがいったい何を指すのか、ハッキリと理解した感触は得られていないのではないでしょうか。

    「開発側」「ビジネス側」という言葉があります。「ここまでは私たちの仕事で、それ以外のことは他の人達の責任」といった境界がよく話題に上がります。こういった境界は、複雑で難しい開発という仕事の中では、一時の心の平穏として役立つこともありますが、障害になることもあります。同じような境界を生み出す言葉に「現場」と「マネジメント」があります。これらの境界は、単に知らなかったり、やったことがないだけだったり、きっかけがなく関心が薄かったりするだけなのかもしれません。

    このセッションでは、そもそもプロダクトとは何か、マネジメントとは何か、プロダクトマネジメントとは何かを明らかにすることを通して、これらの境界を溶かし、様々な専門家の力が結集する組織に向けて役立ててもらえたらと思います。

     

    ■参考文献
    ■■プロダクト
    『競争の戦略』マイケル・ポーター
    『企業戦略論』ジェイ・バーニー
    『マーケティング』井上淳子、石田大典
    『マーケティング戦略』和田充夫、恩藏直人
    『コトラー&ケラーのマーケティング・マネジメント』フィリップ・コトラー、ケビン・ケラー
    『コトラーのマーケティング入門』フィリップ・コトラー、ゲイリー・アームストロング、マーク・オプレニック

    ■■マネジメント
    『新訳 科学的管理法』フレデリック・テイラー
    『企業・市場・法』ロナルド・コース
    『経営行動』ハーバート・サイモン
    『オーガニゼーションズ』ハーバート・サイモン、ジェームズ・マーチ
    『現代の経営』ピーター・ドラッカー
    『マネジメント』ピーター・ドラッカー
    『組織の経済学』ポール・ミルグロム、ジョン・ロバーツ
    『キャプランとノートンの戦略バランスト・スコアカード』ロバート・キャプラン、デビッド・ノートン 
    『マネジメントの世紀』スチュアート・クレイナー
    『昇進者の心得』リンダ・ヒル
    『組織の罠』クリス・アージリス
    『マネジャーの実像』ヘンリー・ミンツバーグ
    『戦略サファリ』ヘンリー・ミンツバーグ、ブルース・アルストランド、ジョセフ・ランペル
    『世界標準の経営理論』入山章栄

    ■■プロダクトマネジメント
    『プロダクト・マネジャー―開発から販売までの新しい布陣』ゴードン・エバンス
    『プロダクトマネジメント―新製品開発のための戦略的マーケティング』グレン・アーバン、ニキルシュ・ドラキア、ジョン・ハウザー
    『トヨタ自動車開発主査制度』塩沢茂
    『スバル360開発物語』桂木洋二
    『クラウン開発物語』桂木洋二
    『主査 中村健也』和田明広
    『P&Gウェイ』デーヴィス・ダイアー、ロウェナ・オレガリオ、フレデリック・ダルゼル
    『製品開発力』藤本隆宏, キム・クラーク
    『凄い製品開発』ジム・モーガン、ジェフリー・ライカー
    『プロダクトマネジャーの教科書』リンダ・ゴーチェル
    『世界で闘うプロダクトマネジャーになるための本』Gayle Laakmann McDowell、Jackie Bavaro
    『プロダクトマネジメント』Melissa Perri
    『プロダクトマネジメントのすべて』及川卓也、曽根原春樹、小城久美子
    プロダクトマネジメントの歴史と進化 by Martin Eriksson 角正典
    https://medium.com/waicrew/%E3%83%97%E3%83%AD%E3%83%80%E3%82%AF%E3%83%88%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E6%AD%B4%E5%8F%B2%E3%81%A8%E9%80%B2%E5%8C%96-e0d444f89615

  • Takayuki FUJITA
    keyboard_arrow_down

    Takayuki FUJITA - Let’s go WILD! 世界の片隅でAgile!Agile!叫ぶ

    Takayuki FUJITA
    Takayuki FUJITA
    Engineer
    agile459
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    ここ数年オンラインイベントが当たり前になりましたね。

    おかげで香川の田舎からでも各地のイベントに参加できるようになりました。
    今まで参加してみたかったあのイベントに参加できるようになった、交通手段や宿泊のことを考えずに気軽に参加できるようになった、私と同じような人は多いのではないでしょうか?

    でもなんだか満たされない人はいませんか?
    イベントに現地参加していた頃のような、活気や熱気、情熱、ワクワクドキドキ。

    そして田舎だろうと、ネットワークさえあればオンラインイベントが開催しやすくなった反面、各地で開催される魅力的なイベントとの差別化、特色を考えることに悩むようになりました。

    オンラインが当たり前になった地方コミュニティ活動で、次にやろうとしてること聞いてください!

  • Takahiro Anamizu
    keyboard_arrow_down

    Takahiro Anamizu - 「当たり前」を言語化して見えてきたもの

    Takahiro Anamizu
    Takahiro Anamizu
    Engineer
    -
    schedule 1 year ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    「どうしてXXXやってるんですか?」
    「え?(これ当たり前じゃないの?)」

    新しいメンバーと一緒に仕事をする時や自分の取り組みををチーム外で話した時に、こんなやりとりが生まれることがあります。
    そして、いざ「当たり前」を説明しようとしても、意外と言語化できてないことに気づきます。

    とある仕事の中で無意識のうちにやっていた考え方・行動が、自分の想像以上に興味を引くものだとコメントを貰いました。
    それを受けて、自分の取り組みを社内で発表することになり、無意識にやっていた「当たり前」にどんないいことがあるのか・誰でも実践できるものなのかなど言語化を試みました。
    その「当たり前」を説明するための言語化に手ごたえを感じつつも、なぜか心のどこかで受け入れられない感覚がありました。

    「自分が実践し始めたのはそんな理由だったのか?もっと自分の感情から生まれたものだった気がする......」

    自分の中で「当たり前」になる前の何かに重要なヒントを感じつつ、答えが見えないまま時間が過ぎていき、時には自分の行動に自信を持てなくなりました。
    それでも諦めず、深掘りと揺さぶりの問いを駆使して「当たり前」と向き合い、試行錯誤する中で見えてきたものについてお話しします。

  • ゆうすけ おおひら
    keyboard_arrow_down

    ゆうすけ おおひら - テスターがチームに溶け込むためにした幾つかのこと

    20 Mins
    Talk
    Beginner

    こんにち、世界!
    どうも、ただのテスターです。

    みなさんは新しいチームに加入した時どんなことをしますか。

    オンボーディングを実施しただけでは、なかなかチームに溶け込むことは難しいですね。

    特にテスターは、チームのメンバーに情報共有してもらわないと仕事ができないので、チームメンバーに信頼してもらい、チームメンバーとして溶け込む必要があります。

    今回は、中途入社したテスターの私が、スクラムチームへ溶け込むためにした幾つかのことを紹介したいと思います。

    素朴理論なので他の人に参考になるかはわかりません。
    中年のテスターが新しい会社に転職してどのように振る舞い、溶け込むためにもがいたかの事例を雑に紹介します。

  • Takefumi Iseki
    keyboard_arrow_down

    Takefumi Iseki - 開発スピードと品質を向上させるための QA の関わり

    20 Mins
    Talk
    Beginner

    開発すればするほど製品やサービスは複雑で多くなり、依存関係があったり、制約があったり、負債が多く大きすぎたり、様々な対応を行わなければならず開発スピードは落ち、バグも増えていくことになります。

    そんな製品開発の組織での QA・テスト の関わりを紹介したいと思います。

     

help