Agile Testingは新しい概念なのか?〜品質保証の歴史を踏まえて考える〜

location_city Niigata schedule May 20th 07:00 - 07:45 PM JST place Online C people 7 Interested

AgileおよびAgile Testingは21世紀に様々な考えが考案されました。

  • 2001年…アジャイルソフトウェア開発宣言
  • 2008年…書籍『Agile Testing(邦訳:実践アジャイルテスト)』刊行
  • 2015年…テストマニフェスト考案
  • 2016年…継続的テストモデル考案

上記の1つ、テストマニフェストでは下記のように書かれています。

20200418161646.png

私たちは下記を大切にします。

  • 最後にテストする よりも ずっとテストし続ける
  • バグの発見 よりも バグの防止
  • 機能性をチェックする よりも チームが理解している価値をテストする
  • システムを破壊する よりも 最高のシステムを構築する
  • テスターの責任 よりも 品質に対するチームの責任

 

他にも「今までのQA/テストではなく、Agileの時代で重要なのは◯◯だ」という主張をよく見かけます。

これらの考えは、Agile以前に存在しなかったのでしょうか?

実はAgile誕生よりもずっと昔から日本では存在していた考えです。

そこで本セッションでは、Agile Testingの考えに深く関わりのある、品質保証(QA)の歴史を遡ることで、先人がどのようにテストや品質保証に向き合っていたのか、先人の考えが現在でも通用するものなのか考察していきたいと思います。

 
 

Outline/Structure of the Talk

  • Agile Testingに関わる考えの紹介
  • Agile Testingとは特別な存在なのか
  • 品質保証(QA)・品質管理(QC)の歴史を振り返る
    • 品質管理の進歩の過程
    • 日本型全社的品質管理と欧米型全社的品質管理
    • 品質管理の時代変化
  • Agile Testingと品質管理・品質保証の関係性
  • まとめ

Learning Outcome

Agile Testingとは何者なのか知ることができる

品質保証(QA)とはなんなのか知ることができる

Target Audience

品質保証(QA)とテストの違いがよく分からない人、Agile Testingが新しい考え方だと感じている人

Prerequisites for Attendees

普段の業務で行っているテスト活動、品質保証活動にはどんなものがあるのか思い出しておいてください。

Slides


schedule Submitted 9 months ago

  • Daniel Maslyn
    Daniel Maslyn
    IT Consultant
    N/A
    schedule 9 months ago
    Sold Out!
    90 Mins
    Keynote
    Beginner

    What is G.O.O.D. Testing? And why is it Important for Everyone?

    G.O.O.D.テストとは何か?そして、なぜそれが誰にとっても大切なのか?

    Whether your testing involves automation or manual testing, agile or traditional methods, dev ops or waterfall or whatever the context, the importance of not only the craft of testing but also the impact of testing and its purpose is worth considering. For years, we have been looking to make testing more efficient and more automated which of course has its obvious advantages, but what aspects of testing have not yet been developed? What good is it to remove defects out of systems that are at their core designed poorly or designed for questionable purposes? Is testing helping or hindering humanity if it enables systems that are designed dangerously or have hidden elements that hinder basic rights of their end users or have impact on important issues such as privacy, security or confidentiality.

    テストが自動か手動か、アジャイルか伝統的な手法か、DevOpsかウォーターフォールか、どんな文脈であれテストの技術だけでなく、テストの影響とその目的の重要性は考える価値があります。何年もの間、私たちはテストをより効率的に、より自動化することに目を向けてきました。もちろん、明らかな利点はありますが、テストのどの側面がまだ開発されていないのでしょうか?コアの設計が貧弱だったり、疑わしい目的のために設計されたシステムから欠陥を取り除くことに、どんな意味があるのでしょうか?もし、危険な設計があったり、エンドユーザーの基本的な権利を妨げたる隠された要素を持っていたり、プライバシー、セキュリティ、機密保持などの重要な問題に影響を与えたりするようなシステムが有効になる場合、テストは人類の役に立つでしょうか、それとも妨げになるのでしょうか?

    If you are also a Tester who is comfortable in the technical and business aspects of your testing but still feels there is something more to consider when we speak of “Quality” of systems, perhaps a look at my proposed G.O.O.D. Testing points could help.

    もしあなたが、テスターとして技術面やビジネス面では満足しているが、システムの「品質」についてもっと考えるべきことがあると感じているなら、私が提案するG.O.O.D.テストのポイントをご覧になれば、きっとお役に立てるでしょう。

    G.O.O.D. Testing involves 4 basic principles, it: 

    G.O.O.D.テストには、4つの基本原則があります。

    • GGives transparent insights into the quality and risks of the system to ALL stakeholders
    • OObserves the quality of the system not only in terms of verification or validation and defects but also in terms of the impact of the system in society at large 
    • OOpens the doors to ask questions about the intended use of the system in relation to the broad set of end users
    • DDetermines testing scenarios which measure the Quality of systems in terms of ethical characteristics such as safety for the end users in terms of privacy, security and confidentiality among others. 

     

    • G: すべてのステークホルダーに対して、システムの品質とリスクに関する透明性のある洞察を提供する。(Give)
    • O: システムの品質を、検証や妥当性確認だけでなく、システムが社会全体に与える影響も含めて観察する 。(Observe)
    • O: 幅広いエンドユーザーに関連して、システムの使用目的について質問するための扉を開く(Open)
    • D:エンドユーザーに対する安全性(例えば、プライバシー、セキュリティ、機密性)など、倫理的特性の観点からシステムの品質を測定するテストシナリオを決定する。(Determine)

    Especially in these times, where a larger amount of the population is forced to use digital platforms, the responsibility of testers to test G.O.O.D. becomes more apparent. The standards for releasing other physical, mechanical or pharmaceutical systems requires consideration for the safety of end users. Should not some standards also be applied to software when the software is of a nature that impacts the well-being of the end users or society at large?

    特に、より多くの人がデジタルプラットフォームを使わざるを得ないこの時代、G.O.O.D.をテストするテスターの責任はより明白になっています。物理的または機械的なシステムや、製薬システムをリリースをするための基準では、エンドユーザーの安全性に配慮する必要があります。ソフトウェアがエンドユーザーや社会全体の幸福に影響を与える性質のものであるならば、ソフトウェアにも何らかの基準が適用されるべきではないでしょうか?

    Imagine a time when systems are tested G.O.O.D. and if they do not pass the test, perhaps they not released or used “at your own risk” because they don’t meet the criteria of not only Quality but also of what is “Good” for the end user.  

    Are you testing G.O.O.D.? Or are you just Testing?

    システムがG.O.O.D.でテストされていることを想像してください。 またテストに合格しなければ、おそらくリリースされないか、品質だけでなくエンドユーザーにとって「良い」という基準も満たしていないため「自己責任」で使われるでしょう。

    G.O.O.D.のテストをしていますか?それともただのテストですか?

  • KENTA MARUYAMA
    keyboard_arrow_down

    KENTA MARUYAMA - Possibility to be born from crazy!

    60 Mins
    Keynote
    Beginner
    株式会社ソルメディエージ 代表取締役
    一般財団法人プロジェクションマッピング協会 理事・プロデューサー

    丸山健太  -KENTA MARUYAMA-

    地方新潟で起業し20年。

    夢中に、好きなことを続けていたら会社になり、サービスと人が繋がって大きな動きとなった。

    地方の制作会社がなぜ、全国の様々な街の賑わいを生み出すまでになったのか?

    面白い、夢中になることは、世の中も、毎日も変えていく。

    夢中は不可能を可能にし、多くの人を巻き込み、笑顔にする。

    開発者であったり、クリエイターであったり、どんな職業でも自発的に楽しく、夢中になり周りを巻き込むことで未来が変わる。

    我々の技術やアイデアは世の中を大きく変える可能性がある。

    エンジニアの皆様、夢中になって表へ出て多くの人を巻き込もう!

    創造へのアクション。

    夢中に!楽しく!

    世の中を変えていこう!

    If I was absorbed in doing what I liked, I became a company, and my services and connections expanded. Interesting and engrossing will change the world and every day. Enthusiasm makes the impossible possible, involves many people, and makes them smile. Whether you're a developer or a creator, you'll have fun on your own initiative in any profession, and getting involved will change the future. Our technology and ideas have great potential in the world. Engineer! Let's go out and get involved! Crazy! Happily!
  • Aiz ack
    keyboard_arrow_down

    Aiz ack - メンタルヘルス当事者の経験・学習から学ぶメンタルの健康と回復について

    Aiz ack
    Aiz ack
    Support Engineer
    WingArc1st Inc.
    schedule 8 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    皆さんの身近には「メンタルヘルス当事者」の方はいらっしゃるでしょうか?

    私の場合は、1人開発者でプライベートの問題を抱えつつ仕事をしていたがために身動き取れなくなり、体調を崩し、病院に行ったら一発アウト(うつ病の判定)でした。

    2018年の厚生労働省「最近の精神保険福祉政策の動向について」という資料では、日本の精神病患者は約392万人、30人に1人という統計になっています。

    つまり1学年に1人は精神疾患にかかる方がいるということです。

    一方で、精神疾患についてはあまり良い情報が多くありません。

    過去の精神病院等の扱いやメディアで犯罪者が精神疾患だったという報道によるイメージが悪いこと、精神疾患にかかったことを公表するとデメリットがある(職につきにくい等)があるためです。

    しかし、このままでは精神疾患を抱える人にとって良くなる社会にはなりようがありません。

    そのため、私一個人のケースですが、どのように精神疾患に掛かったのか、そしてどのように回復しつつあるのか、社会復帰できるようになってきたのかについてお話したいと思います。

    一番大切だと思っていることは「一度メンタルヘルスを崩した(病気)になったことの評価をネガティブなままにしないのが重要だ」ということです。

  • Ikuo Odanaka
    keyboard_arrow_down

    Ikuo Odanaka - 「時間がない」症候群、その傾向と対策

    45 Mins
    Talk
    Intermediate

    「時間がない」というならば問おうではないか、「時間があればできるのか」とーー。

     

    [やること]

    本プロポーザルは、アジャイルやテストを取り入れていきたい、変化を起こしたい時に立ちはだかる「時間がない」問題と向き合い、いかに変化を起こしていくか、を主題に置いています。

    [やらないこと]

    アジャイル、テストのフレームワークや手法に関する解説や深堀り

    [本文]

    テストを書きませんか?アジャイルやってみませんか?そういった問いかけに対して、真っ向から「それはやりたくない」と切り返されることはあまりなくなりました。むしろ、「テストは大事だと思っている」「これからはアジャイルだよね」と肯定的に返されることが少なくありません。

    しかし、いざ変化を起こそうとするとこう言われるのです。
    「やってみたいんですけど、時間がないんですよね。」「どうにも今は忙しくて・・・」
    あれ、結局は変化したくないのかな?気を遣って興味のあるふりをしていただけなのかな?と、少しぐんにょりしてしまったりします。

    私がここ最近大切にしているのは「北風と太陽」の寓話。その人にとっての太陽、心を動かすものは何かをみつけ働きかけていくことです。
    「いやいや、時間ないっていってるけどあるでしょ。作りなさいよ」というような北風を吹かすようなアプローチでは、人は動かないと私は考えています。

    今回のプロポーザルではその「北風と太陽」アプローチの中でも、特に「時間がない」という発言が立ち現れる背景、
    そしてその場合に考えられる良いアプローチについてお話したいと考えています。

    では、変化を働きかけられた人が「時間がない」という言葉を吐き出すとき、背景にはどのような課題があるのでしょうか。
    大きく分けて、以下のようなケースが考えられます。

    1. 本当に時間がない
    2. 新しいことに時間をかけてよいかわからない
    3. その変化を起こす理由がわからない/納得していない

    本プロポーザルでは、これら3つの課題に対してどのように行動するかを提案していきます。

    本当に時間がないー。インシデント対応に追われている、残業が常態化している、そういった状況に身をおいているのであれば
    そこに「変化を起こす」というタスクを重ねることは難しいように思えます。このような現場に対しては、なんとかして余白を生み出していく支援をまず行い、その次のステップとして変化を起こしていくアプローチが考えられます。

    新しいことに時間をかけてよいかわからないー。作ろうと思えば時間を作れるのだけれど、そういう時間の使い方をしていいのか判断がつかない。
    トップダウンでの意思決定が根付いた環境では、こういった不安が「時間がない」という言葉につながっていきます。
    判断がつかなくて悩んでいる人が判断をあおぐ人に直接働きかけてみると、案外「あ、全然やっていいですよ」という答えが返ってきたりします。

    その変化を起こす理由がわからない/納得していないー。時間がいくらあっても、それをやりたいと思っていたり効果があると納得していたりしなければ
    そこに時間をかけたくないのは当然です。そこから出てきた「時間がない」という言葉に対しては、「じゃあ時間があったらできるのですか」と問うても
    色よい返事が返ってくることは期待できません。そもそも、なぜその変化が必要なのか。有用なのか。それを納得していない人の目線で伝えていくことが必要です。

    このように「時間がない」という言葉の背景には様々な課題が潜んでおり、それらの課題をどう発見するか、そしてどう向き合っていくかについて
    自身の経験を交えながら提案していきたいと思います。

     

    [参考]デブサミ2022でのセッション

     

     

  • Miho Nagase
    keyboard_arrow_down

    Miho Nagase / Kazunori Otani / Teppei YAMAGUCHI / Tsutomu Yasui / Yosuke Ota / Yudai Moriya - F1 新潟グランプリ'22

    45 Mins
    Talk
    Intermediate

    Regional Super GT 2022、もとい、Regional Scrum Gathering Tokyo 2022を皮切りにスタートしたフィードバック1グランプリ'22国内ツアー、好評につき第2弾をここ新潟で開催します!

    F1のFはFeedbackのFです。
    アジャイルに関わる皆さんならきっと大好きなフィードバック、これを上手にできる腕を競う選手権です。

    この45分間のパネルセッションは、大喜利形式で行われる楽しいセッションです。

    アジャイル開発で悩んだり困ったりしたシチュエーションをお題として募集します。お題に対して回答者はフィードバックコメントをし、もっともナイスフィードバックと思われる回答がポイントを獲得します。
    ポイントの投票は回答者自身と、聴講者によっておこなわれます。
    高評価の観点が参加者によって醸成されていく、ダイナミックでインタラクティブなセッションです。
    最多ポイントを獲得した人はF1新潟グランプリの勝者となり、1年間、その栄誉が讃えられます。

    お題と回答の例その1
    お題「僕はスクラムマスターです。上司がチームのパフォーマンスを気にしているので、ベロシティのグラフを見える化してみたんですが、どうでしょうか?」
    回答1「上司にベロシティについての理解を問うてみてはどうでしょうか?」
    回答2「ベロシティは顧客価値につながる指標なんでしょうか?」
    回答3「デプロイメント頻度は計測できていますか?」

    お題と回答の例その2
    お題「私はデベロッパーです。いつもテストをきちんとしようと思うのですが、プロダクトオーナーの期待するスピードで作ることができません。正直毎スプリントこんなにきっちりテストをするなんて足枷に感じてしまうのですが、どうしたらいいでしょうか」
    回答1「テストをサボるとその足枷がどんどん重くなるのでは?」
    回答2「一度テストをまったくしないで進めてみてはどうでしょうか?」
    回答3「プロダクトオーナーを説得する役割の人はいないのですか?」

    出演者の情報です。
    実況:ながせ(miholovesq
    解説:もりや(yudmo
    ドライバー(回答者):よた(yota)、てやまぐ(teyamagu)、やっとむ(yattom)、かっちゃん(katzchang
    その他のドライバーにはこれから声をかけます。
    出走希望のドライバーも募集しています。ローカルレーサーは特に歓迎します!

    お題は下記のフォームで募集し、当日はこの中から厳正なる抽選で採用されます。
    Google Form: F1新潟GP'22お題募集フォーム

  • Yuichi Tsunematsu
    keyboard_arrow_down

    Yuichi Tsunematsu - 3年がかりのQA組織立ち上げ

    Yuichi Tsunematsu
    Yuichi Tsunematsu
    Manager
    Retty Inc.
    schedule 9 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    2019年の夏、マネージャーを引き継いだRettyのtoC Webサービス開発は度々障害を出し、QAプロセスの早急な整備が必要に思われました。当初はQA組織の立ち上げを考えていましたが、アドバイザーとの壁打ちの結果「皆でQAが担保できるのであれば、門番的なQA組織はいらない」ことに気がつき、リリース前テストとは遠いところから整備を始めました。QA観点の整備、検証項目の早期準備と相互レビュー、不要な機能の削除、早い段階での結合とテストなど。それらが成果を結び、2021年夏には大きな障害が起きにくくなったと組織で実感できるぐらいに状態が改善されました。

    しかし事業の注力領域がtoCからtoBに移るにつれ、これまで発生率で気にしていたエラー・障害を「発生件数」で気にするようになり、あらためてQA体制のあり方を再考しています。

    当初目指していた「門番にならないQA組織」に結実できるよう、考えたこと・悩んでいること・実践していることを皆様に共有します。

  • kyon _mm
    keyboard_arrow_down

    kyon _mm - ソフトウェアテストで参考にしている67のモノ

    45 Mins
    Talk
    Beginner

    ソフトウェアテストの学び方に関して書籍やウェブサイト、そしてそこから伸びる某かについて自分なりにまとめ直してみるかーと。思いました。これを全部読めとかではなくて、まぁ自分が今まで読んできて役に立ったものリストくらいの感じです。

    67個のリストは次のnoteに記載があります。当日はこれらの読み方とか、特に良かったところをピックアップして紹介しようと思います。

    ソフトウェアテストで参考にしている67のモノ 2021 #scrumniigata

     

    photo-1588580000645-4562a6d2c839?ixlib=rb-1.2.1&ixid=MnwxMjA3fDB8MHxwaG90by1wYWdlfHx8fGVufDB8fHx8&auto=format&fit=crop&w=1740&q=80

     

    Photo by Trnava University on Unsplash 

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) / Yoya Kobayashi / ゆうすけ おおひら - かたって品質文化! 〜 Markin' Quality 第9回:懇親会ジャック・1 〜

    45 Mins
    Workshop
    Beginner

    スクフェスの魅力ってなんでしょう? それはたぶん、現地・オンラインに集まった人がとにかく楽しくワイワイできることではないでしょうか?

    そんなイベントを盛り上げるために、あえてDay 1で行いたいWorkshopとして提案します。しかも "Markin’ Quality 第9回" として。

    スクフェス新潟に集まる人は、きっと多種多様だろうと思います。職種こそエンジニアが多い気はしますが、業界も仕事のやり方も性格も千差万別でしょう。そこで相互理解を初日に深めるために、アジャイルテストをテーマに掲げるスクフェス新潟だからこそ「品質」をベースにした懇親会をやってみませんか?

    スクフェス新潟というイベントが 通常の3倍楽しく、和気藹々となる こと、まちがいなし!!

    分類はアジャイルリーダーシップです。懇親会をワークショップにするという無茶なリーダーシップ(Leader Ship)という、わたしたちにとっても実は初めてのチャレンジです。たぶん、いろいろな対話を通じて、参加者の「スクフェス新潟」に対する解像度がグッとあがると思います。

  • Kaori Tokiwa
    keyboard_arrow_down

    Kaori Tokiwa / Azuma Miwa / Yasuharu Nishi - CTOのためのQAのつくりかた

    45 Mins
    Talk
    Intermediate

    QA(品質保証)の組織や体制をつくろうと考えるCTOやVPoE、EMが増えてきました。とはいえ、QAの組織や体制のあり方はQAメンバのスキルや開発チームの状況、プロダクトの特性、ドメインに求められる規制、自社の文化などによって千差万別です。また、つくった後もどんどん変化していく必要があります。そこで私たちSIGSQA-jpでは、QAの組織や体制をつくる時に見通しよく捉えるために、QMファンネルとQAスタイルファインダーを使ってみてはいかがかな、と考えています。QAの組織や体制に悩むCTO・VPoE・EM、開発マネジャー、一人QA、経営者の皆さんの助けになれば幸いです。

  • Azusa Fukushima
    keyboard_arrow_down

    Azusa Fukushima / manami Ozawa - チームのメンタルヘルスにおいて本人がケアできること、周りの人ができること

    45 Mins
    Talk
    Beginner

    みなさん元気に働けていますか?
    チームのメンタルヘルスと聞いてみなさんはどんなイメージを描くでしょうか。

    日々の環境変化の激しい中、こんなことありませんか?

    • コロナ禍になってチームのメンバーの様子がわからなくなった
    • いつの間にかチームメンバーが不調で離脱することになってしまった
    • 違和感に気付いてもどう対応していいか周りとしてはわからない
    • 自分の今の状態がいいのかわからない

    私たちは個人の元気がチームのパフォーマンス向上につながり、チームの状態もまた個人に影響すると考えています。

    本セッションはメンタルヘルスの専門的な知識がなくても、チームのメンバー同士でできることを一緒に考えていきたいと思います。

    SEから保健師になった福島と外部のメンターとして1on1を行う尾澤が、
    チームでのメンタルヘルスに関する事例や明日からどんな風にメンタルヘルスの向き合ったらいいかについてお話します。

    皆さんが笑顔で元気に働けますように。

  • Atsushi Nagata
    Atsushi Nagata
    Agile Coach
    Cybozu
    schedule 10 months ago
    Sold Out!
    20 Mins
    Talk
    Intermediate

    QA2AQ(品質保証からアジャイル品質への移行に関するパターン)は、アジャイルの品質保証を学ぶための有用な情報を与えてくれます。現在23あるパターンのうち、2020年8月から、21年10月までに12のパターンを社内で勉強会、ワークショップを開いてきました。もう使っているパターンもあれば、やられていないものもありました。その一部を、2020年8月に、スマートエスイー主催のセミナーで発表したこともありました。(Linksを参照)。

    今回の発表は、その中の一つを事例として発表します。

    パターン名は ”システム品質:ラジエータ: System Quality Radiator”です。

    メトリクスは、CFD(Cumulative Flow Diagram)を用いました。フローの質を測り、それをラジエターで毎日見せることで、チームがどのような行動変容したかというお話になります。

    "メトリクスは、メッセージを持つべき"、つまり"Talking Metrics"というのが戦略です。チームをオブザーブし、その兆候から予想されるリスクを、メトリクスを使っていかにチームに気づかせるかがカギになります。なので、メトリクスの形をアダプティブに変化させていきます。

    名付けて ”アジャイル・トーキング・メトリクス:Agile Talking Metrics

    メトリクスにはメッセージを込めます。つまりメトリクスが話しかけ、気づかせるようなメトリクスを作りたい、というのが思いです。

    それにより、インペディメントを抑え、品質を落とす行動を防いで、チーム全体のレジリエンスを引き出すといった連続した効果を、メトリクスを使ってご紹介します。

    38日間の、アジャイル・トーキング・メトリクスを使った品質のラジエータの旅をお話しします

     

     

  • aki matsuno
    keyboard_arrow_down

    aki matsuno - テストが嫌いでIT業界を離れるはずだったのに〜テスト嫌いが現場で品質改善を実践するまでの物語〜

    aki matsuno
    aki matsuno
    engineer
    -(Coming Soon)
    schedule 7 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    2018年10月、IT業界を離れる決意をした自分は退職願いを会社に出しました。その大きな理由の一つが毎日仕事でやっていたテストでした。
    すんでのところで会社に留まる決断をした自分ですが、テストとは距離を置き続けました。

    月日が経ち、自分はアジャイルを通してテストにもう一度向き合う覚悟を決めました。Agile testing condensedを読み進める所からスタートした自分は、テストに対する意識が少しずつ変わると共に、テスト関連書籍やコミュニティなど、素敵な繋がりが生まれました。
    こうした繋がりは新たな繋がりを生み、現場での成果も少しずつ出るようになっていきました。

    本プレゼンでは、テストが大嫌いだった自分がどのような過程を踏んでテストに対する距離を縮めて品質に興味を持ち、現場にどう適用をしていったのかをお話したいと思います。

  • Kazuki Mori
    keyboard_arrow_down

    Kazuki Mori - ビジネス x テスト。ビジネスのいろんな場所で活きる、アジャイルとテストのエッセンス

    20 Mins
    Talk
    Intermediate

    アジャイルといえば開発、テストと言えばエンジニア。そんな先入観はありませんか?

    事業を創り、プロダクトを創り、チームを創り、セールス(営業)のプロセスを創り、マーケティングをして、売れるビジネスを創る。ソフトウェア開発の外側でも、アジャイルやテストの考え方は活かせるんです。

    このセッションでは、Miro代理店のチーム「オキザリス」が、事業を創ってから、いろんな仮説検証とテストをしてTry & Errorをしてふりかえりまくってきた過程と、みなさんのチームやビジネスに活かるかもしれない話を紹介します。

  • Yoya Kobayashi
    keyboard_arrow_down

    Yoya Kobayashi / Hiroaki Nishijo - 0→1 フェーズで E2E 自動テストを導入した私たちの、これまでとこれから

    45 Mins
    Talk
    Beginner

    アジャイル開発において避けては通れないであろうトピックのひとつが、E2Eテストの自動化です。近年ではSaaSモデルのE2Eテストツールもメジャーとなり、それに伴い導入事例の紹介も多く見受けられるようになりました。

    しかし発表される事例の多くは運用フェーズに入ったプロダクトのテスト自動化であり、結局のところいつからE2E自動テストを導入すれば良いのかという疑問が残ることでしょう。

     

    「マネーフォワード クラウド確定申告」は2020年にフルリニューアル版をローンチしました。

    スクラムチームでインクリメンタルに実装するにあたり、当時のQAリーダーである西條は開発の初期からE2Eテストツール Gauge を導入しました。本セッションの前半では、ツール選定や実装時の困難など導入時のエピソードを紹介します。

     

    後半は、2代目QAリーダーの小林による運用篇です。

    400件近くのシナリオが実装された状態で引き継いだ小林は、開発経験者が自分ひとりのみのQAチームでローコードなE2E自動テストを運用するという課題に直面しました。それを乗り越えるための取り組みと、今後の展望についてお話しします。

  • Masami Morita
    keyboard_arrow_down

    Masami Morita / Takumi Watanabe / yusuke isono - 開発エンジニアに聞いてみよう!QAが開発チームへに潜入し、一緒に品質活動をしているが、ぶっちゃけどう?

    45 Mins
    Talk
    Beginner

    開発チーム外に所属しているQAエンジニアが、開発チームに潜入することに成功しました!そこでは、開発エンジニアに「テスト」という武器を授ける活動を行っています。

    ところで、開発エンジニアはどう思っているのでしょうか?一緒に活動した開発エンジニアをお呼びし、本音を聞いてみましょう。

     

    自分達にもできそうだな!と、一歩踏み出す勇気を与える、栄養ドリンクのような発表を目指します!

  • Koichi Ichikawa
    keyboard_arrow_down

    Koichi Ichikawa - デュアルトラックアジャイル×Agile Testingから見えてきたQAのミライ

    Koichi Ichikawa
    Koichi Ichikawa
    QA
    atama plus
    schedule 7 months ago
    Sold Out!
    45 Mins
    Talk
    Intermediate

    QAのミライ なんて言うと大言壮語で恐縮ですが、デュアルトラックアジャイルという開発プラクティスを実践しながら、Agile Testingを1年ほど実践していて私が感じたQAの動き方の変化(拡張)についてお話できればと思っています。

    • デュアルトラックアジャイルの中でAgile Testingの考え方を取り入れたことでの立ち回り
    • 新規プロダクト開発に初期から開発チームの一員として関わるQAの動き方
      • Dev, UXの橋渡し
      • PM的な立ち回り

     

    品質観点のFBやテストはもちろんのこと、当時の私ができることを探して試行錯誤した当時の様子を、生々しくお話します。

  • Akihisa Koyama
    keyboard_arrow_down

    Akihisa Koyama - E2E自動テスト導入・運用をめぐる先入観と実際に起きたこと

    Akihisa Koyama
    Akihisa Koyama
    QA Engineer
    Cybozu, Inc.
    schedule 8 months ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    20年に渡って開発・メンテナンスされてきたB2BプロダクトへのE2E自動テストの導入・運用に関わる中で、これまで約4年間、試行錯誤を繰り返してきました。
    振り返ってみると、当時の自分は様々な先入観をもってテスト自動化に臨んでいました。そして都度、「あれ、思っていたのと違うぞ?」という発見がありました。
    この発表では、テスト自動化に対して自分がもっていた先入観と、テスト自動化の導入・運用を実際にやってみて起きたこととを振り返り、そこから学んだことを共有します。

  • Tomonari Nakamura ( ikikko )
    keyboard_arrow_down

    Tomonari Nakamura ( ikikko ) - 半年前の僕らを超えろ!自動テストに向き合いながら、一歩ずつ進もうとしている現場のお話

    20 Mins
    Talk
    Intermediate

    (本発表は、スクラムフェス三河2021で発表した現場のその後の話です)

    私たちの現場では、2021年10月時点で、社内TDDBCの開催やユニットテスト環境の整備を通じて、自動テストに関する土台が整ってきたという状況でした。それからおよそ半年後、あの現場はどうなったのでしょう?

    嬉しいことに、自動テストは順調に浸透してきています。テストを書いた経験がないことからくる苦手意識が減ってきました。多少書き過ぎる場合もありながらも、基本的に自動テストを書いていこうという方向に自然となっています。

    もちろん、運用していくに従って、うまく自動テストを活用できている場面もあれば、既存のUIテスト資産も含めてどう扱っていくかを試行錯誤している場面もあります。また、自動テストを実装するという側面だけでなく、そもそも効果的なテスト設計を学んでいこうという取り組みも並行して進んでいます。

    本発表では、効果的な自動テストに取り組み始めた現場が、どう変わっていったかの事例を共有します。半年という長くはない時間の中で、決してうまくいくことばかりではなかった、それでも一歩ずつ進めているチームの生々しい話を共有できればと思います。

  • Terumi Kato
    keyboard_arrow_down

    Terumi Kato - 老舗大企業のアジャイル開発を変えるための第一歩

    Terumi Kato
    Terumi Kato
    engineer
    大日本印刷株式会社
    schedule 8 months ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    大企業でアジャイル開発を取り入れている皆さん、こういったことはありませんか?

    「ミニマムで価値検証したいのに、でかいシステムを開発することになってしまった」「期日までに必ずすべての機能をリリースしないといけない」「方向転換したいけど、沢山投資したため後戻りできない」
    ・・・

    ドキっとした方、心当たりのある方、いらっしゃるのではないでしょうか。私は多々ありました。


    創業145年の大日本印刷では7年前からアジャイル開発を取り入れ、数々のプロダクトを開発しています。
    私は6年前に入社し、そこからずっとアジャイル開発をしているのですが、そのすべてがソフトウェア開発フェーズからアジャイル開発を取り入れたものでした。
    そのためなのか、開発者としてアサインされるタイミングですでに作るものがある程度決まっていて、それをどうシステム化してリリースするかをアジャイル開発で進めていく。
    先にスケジュールも決まっていたため、
    「本当にニーズあるの…?」「もっとミニマムで価値検証してからの方がいいのでは…?」
    という不安があっても、とりあえず目の前の目標である「〇月までにシステムリリース」を達成することを優先してしまっていました。
    無事リリースはできても、ユーザが想像よりも集まらず、すぐには投資金額を回収できるほどの利益も上がらない。
    そして、売り上げが上がらないことから、スクラムチームを維持する予算が取れなくなってカイゼン活動もできなくなる・・・。
    リリース後の立ち上がりが緩やかなのは新規事業では仕方ないことと思いつつ、開発者として良いプロダクト開発のためにできることはなかったのか?POにもっと寄り添えなかったのか?と、終わってから後悔することが多々ありました。

    そういった経験から、
    「うちの会社でミニマムで価値検証をどんどん実施してプロダクト開発をするには、アイディアを考え始める段階からアジャイルで進めた方が効果的なのでは?」
    と考え、アジャイル未経験の企画部門メンバーと共に新規自社サービス開発を始めた結果、
    「いかに企画書で伝えるか」から「あらゆるプロトは作れるだけ作ってみる!ユーザに聞いてみる!」
    と、時には週8でヒアリングしてしまうくらい経験主義なマインドに変化するに至った、山あり谷ありの経験について詳しくお話しできればと思っています。

  • izumi ito
    keyboard_arrow_down

    izumi ito - ソフトウェアテストなんて他人事!
だと思ってた私が始めた小さな取り組み

    20 Mins
    Talk
    Beginner

    10年前の私はソフトウェアテスト(以下「テスト」)は「テスターや品管のしごと」だと思ってました。

    当時私が所属していたプロジェクトでは開発者がテストもやっていましたが、それも「本当はテスターがやる仕事だけどテスターという役割がいないから開発者が変わりにやっているだけ」「本来開発者が注力するべきは設計と実装である」という意識がありました。だから当時の私にとってテストはどこまでも他人事でした。

    そこから時代は移り変わり、『アジャイル開発がふつう』の世の中になりました。

    お客様に価値を届けるためには、何がお客様にとっての価値なのかを考え、価値を落とさないために品質を担保しながらインクリメントし続ける必要があり、そのためにはユーザーストーリーから考えることが大切だと私は考えています。

    まずユーザーストーリーという形で実現したい価値を把握し、そのユーザーストーリーを実現するための設計・実装することよってプロダクトをインクリメントしていくやり方が理想的で、このすべての過程で欠かせないのが実はテストの観点だということに気づきました。

    それからテストに対する私の意識は完全に変わりました。

    スクラムマスターとしてチームの課題と接しているとあらゆる場面でテストの観点の必要性を感じるのです。

    これまで「テストなんて他人事」と思っていた私は、今から何ができるでしょうか?

    他人事と思っていたテストに対する意識の変化と、特にテストが得意でもない私がこれからどうやっていくかということについてお話したいと思います。

     

     

help