Testable Infra: Cloud-native技術をフル活用した、「テスト」の諸問題の刷新的解決案

皆さんは、システムのテストをする際に、次のような問題を経験されたことはないでしょうか?

  • テスト環境の準備の工数がバカにならない
  • テストデータを複数人・チームで共有していて、気軽にテストできない
  • 外部サービスと接続できず、必要なテストができない

これらの問題は、開発者・QAなどのシステム関係者にとって、テストに対する非常に大きな技術的・心理的障壁となります。加えて、十分なテストを行えないことによる本番障害の多発にもつながります。

 

私たちのチームは、これらの問題を解決すべく、Cloud-native技術を駆使して、2020年に「Testable Infra」という社内インフラを構築し、運用を開始しました。加えて、これを複数のシステム開発プロジェクトに導入し、実際に上述のテストの諸問題の改善という成果が出始めています。

 

このセッションでは、「Testable Infra」のコンセプト、設計と技術の詳細、およびこれを活用したシステム開発の未来像についてお話しします。

なおこのセッションは、2020年12月に中国で開催された「TOP100 Summit 2020」で発表した『Make testing easier technically and psychologically with Kubernetes - Innovation of testing distributed systems with "Testable Infra" -』を大幅に加筆修正し、日本語で発表します。

 
 

Outline/Structure of the Talk

  • 概要説明(5分)
    • 課題設定:導入として、テストに関する3つの問題(テスト環境・テストデータ・外部システム)を紹介し、これらがテストに対する技術的・心理的障壁となっていることを説明します。
    • 解決方針:上記問題の解決案としての「Testable Infra」を簡潔に紹介し、後続の説明につなげます。
  • 1. コンセプト(10分)
    • 「Testable Infra」の狙いとしての、「Immutable Infrastructureとしてのテスト環境・データ・外部システムのオンデマンドでの利用」について、詳細に説明します。
  • 2. 設計・技術詳細(10分)
    • 「Testable Infra」の全体構成と、Cloud-native技術をどのように活用してコンセプトを実現しているのかについて、実際のコードも含めて詳細に説明します。
  • 3. 導入事例(7分)
    • 「Testable Infra」を導入したシステム開発プロジェクトの事例を通じて、仮説検証結果(成果・課題・改善した点)を説明します。
  • 4. システム開発の未来像(5分)
    • 私たちのチーム・組織が構想している、「Testable Infra」を活用したシステム開発の未来像について説明します。
  • まとめ(3分)
  • 質疑応答(5分)

Learning Outcome

Cloud-native技術を活用した、ソフトウェア開発ライフサイクルの具体的な改善のアイデアとその事例

Target Audience

テストに関する上述の課題認識がある方、およびこれらを解決したい方

Prerequisites for Attendees

schedule Submitted 5 days ago

  • Patrick Debois
    keyboard_arrow_down

    Patrick Debois - TBD: DevOps Interview with Q&A

    Patrick Debois
    Patrick Debois
    Father of DevOps
    .
    schedule 3 weeks ago
    Sold Out!
    60 Mins
    Keynote
    Beginner

    TBD

  • Masanori Kawarada (Mark Ward)
    keyboard_arrow_down

    Masanori Kawarada (Mark Ward) - 独立QAチーム1年戦記:スクラムの外からチームと組織の品質を創る道 / An Independent QA Team's 1 Year's War: Way to Create Quality of the Teams and the Organization from the Outside of Scrum

    45 Mins
    Talk
    Intermediate

    English follows:

    「Scrum@Scale(S@S)を取り入れた100名ほどの開発組織で、スクラムに入らない独立したQAチームが活躍している」と聞いたら、もしかしたら奇異な感じを受けるかもしれない。スクラムではチームであらゆることが完結することを理想とするため、当然テスター(QAエンジニア・テストエンジニア ・などなど)もスクラムチームに入るべき、と考える方がスクラム実践者にとっては自然だからである。あえて、その自然に逆らって、私たちQAチームは独自のビジョンを掲げた「ビジョナリー・QA(Visionary QA)」として、独立した立場から品質向上という成果を上げようと奮闘している。このトークではそんな私たちQAチームの1年戦記をありのままに扱いたい。

    開発プロセスの高速化が進み、多くの企業でアジャイル開発が取り入れられ、過去の当たり前が当たり前でなくなっている中で、QA界隈ではどうやって価値を提供するか頭を悩ませている。あくまでもテストにこだわる者もいれば、スクラムマスター・プロダクトオーナーの視野を得るべく資格を目指す者もいる。2009年に翻訳出版されたリサとジャネットによる『実践アジャイルテスト(Agile Testing)』(翔泳社)は国内のテスターに広く読まれているが、最近版元品切になっていることもあり、手に入りにくくなっている。

    さて、テスターは異質な存在のひとつとして見なされている。ご存知の通り、スクラムガイドにはテストやQA活動をどのように行うべきか、言及されていない。3つのロールに「テスター」の文字は無い。よって、テスターのあり方はそれぞれの組織で模索するしかなく、特にテスターをスクラムチームに含めるべきか否かという議論は継続的に行われている。先にもあげたように、スクラム実践者にとってはテスターがスクラムチームに入ることは自然であると感じられ、実際そのようにしている組織が多いが、それぞれにメリット・デメリットがあることから、あらゆる組織で通じる答えは今のところ無さそうだ(テスターとして仕事をしてきたメンバーがスクラムチームの開発者の一員としてどれだけクロスファンクショナルに動けるか、という点が特にネックなように思える)。

    このトークは、独立した立場で動くことを選んだQAチームの話だ。スクラムチームにテスターを迎え入れねばならないと思っている方にはそうでない可能性を示す一方で、やはりスクラムチームに開発者としてテスターを加えるべきだと結論づけるオーディエンスもいらっしゃるかもしれない。スクラムチームとテスターの一筋縄ではいかない関係を、1年間の実例をもとに、一緒に考えようではないか。

    "In a 100-strong software development organization which runs Scrum@Scale, an independent QA team works well." ––it may sound strange to you. Ideally, in Scrum, everything should be done in one scrum team, so it is natural for Scrum practitioners that testers (QA engineers, test engineers, etc.) should join a scrum team. Daring to go an unnatural way, our QA team struggles to achieve quality improvement results from an independent standpoint as "Visionary QA" with its vision. I want to treat our QA team's year-long battle story as it is in this talk.

    Development processes are getting faster and faster. Many companies are incorporating agile development. The commonplace of the past is no longer the norm. In this fast-changing age, the QA industry is struggling to figure out how to deliver value.  Some testers are more concerned with testing, while others aim for the certification to learn a Scrum Master/Product Owner's perspective. The excellent book, "Agile Testing" by Lisa Crispin and Janet Gregory (Addison-Wesley), which was translated in Japan in 2009 by the domestic publisher Shoeisha, has been widely read by testers in our country. Recently, however, it isn't easy to get due to out of print.

    Testers tend to be seen as one of the heterogeneous entities. As you know, there is no mention in the Scrum Guide on how testing and QA activities should be done. There is no "Tester" in the three roles of Scrum. Therefore, each organization has no choice but to explore the nature of testers. In particular, there is an ongoing debate on whether or not testers should be included in Scrum. As mentioned earlier, it seems natural for Scrum practitioners to have testers join Scrum, and indeed many organizations are doing so. Still, since each has its advantages and disadvantages, it seems that we don't have an answer that works for all organizations at the moment. One of the problematic points appears to be how well testers can work cross-functionally as a "Developer" in Scrum.

    With this session, which is about a QA team that chose to work independently, some attendees who feel testers should join a Scrum team may get a chance to notice the other possibility, and others may conclude that Scrum teams should still include testers. Let's take a look at the tricky relationship between Scrum and testers with the help of a year's worth of examples.

  • Woohyeok Aaron Kim
    keyboard_arrow_down

    Woohyeok Aaron Kim - Roll your Product with Kaizen Culture(Let's 'Tech' the initiative (Renewed for 2021))

    45 Mins
    Talk
    Advanced

    Jeff Sutherland氏、Martin Fowler氏、Taichi Ohno氏。世界の業務プロセスに変革を導いた彼らは共通的に「カイゼン」について強調しました。

    彼らの本を読みエンジニアとしての道を歩んできた私たちにとって、「カイゼン」は第一の価値として認識されていると思います。

    皆さんは、今日より良い明日のために何に力を入れてますか?毎日が忙しすぎて、何かを改善するどころかストレスだけ溜まってたりはしてないでしょうか。

    楽天のランキングサービスグループは開発と運用、いわばDevOpsを実践していますが、そのプロセスに対しいくつか問題を抱えていました。開発の段階で発生するボトルネック、効率的だとは言えない運用環境。

    何よりも問題だったのは、こういったボトルネックにおいて改善の文化が定着しにくいということでした。せっかく良いアイデアを思いついても、そのボトルネックから発生するコストの問題で後回しにするしかなく、そうなればなるほどチームの改善力はどんどん下がっていきました。

    私たちランキングチームは2つの解決策を決め、それを同時に進め相乗効果を発生させることでこの状況を乗り越えようとしました。

    ランキングチームが挑戦したトライアルそしてテクニカルな変更によるチームカルチャーの変化。またその後1年間の運用ストーリーまで!

    より安全で良いサービスの提供のために、日々工夫を重ねているあなたのために、私たちのお話を特別に公開します。

  • Mesut Durukal
    keyboard_arrow_down

    Mesut Durukal - 4 Pillars of Successful Agile Test Automation

    20 Mins
    Talk
    Beginner

    Motivation:

    After executing a project to test a cloud-based microservices platform, we experienced a lot of challenges in both technical and social manners and tried to develop solutions to cope with them. Finally, I have wrapped them up to make a list of golden rules to successfully manage a test project. The purpose of this talk is to give insights about how a test automation project is managed.  

     

    Problems:

    • Technically, if not managed properly, automated testing will lead to extra costs and could even be less effective than manual testing.
    • From another aspect, at some point, we had too many complaints in our retrospective meetings about the heavy deployment activities and redundant executions. We had lots of flaky tests, execution lists full of not clear test definitions. Everyone was sick and tired of maintenance issues and the team was not happy. We took actions to improve motivation in the team. 

     

    Solutions:

    • Being truly agile: Adapt new solutions quickly. 
    • Manage the progress: Be aware of what is going on by setting KPIs to track & monitor with tools like CloudWatch, Grafana
    • Technical part: Automation principles for the sake of robustness. Solutions to reduce flaky tests & analysis effort & costs: Code demos on Java API polling libraries, Selenium usage and others.
      • How we solved flaky tests: Adaptations into the code and observing the effect of each application. A few examples are polling mechanisms (safe wait methods) and test design techniques 
      • For maintenance efforts: We keep test history in the pipelines and develop helper methods to improve quality. 
      • Improve coverage from different aspects to reduce escaped bugs.
    • Team spirit! 

     

    Results & Conclusion

    After application of the proposals, we observed that waste is eliminated by prioritization and removing duplicated or dispensable work. After all, we believe that this submission has interesting content which can make great attention. Instead of theoretical claims, we discuss faced challenges and applied solutions. We analyze effects of solutions with before-after situations, graphs and evidence. Instead of what to do, we go over how to do it. 

     
  • クリス Chris Lucian
    keyboard_arrow_down

    クリス Chris Lucian - Mob DevOps & Mob Programming

    45 Mins
    Talk
    Beginner

    Currently in our environment of 27 developers we have no manual tests for the software to deploy to production. We practice continuous integration, and continuous delivery. All infrastructure is written as code. Bugs and defects are top priority with no bugs most of the time. Team members treat each other with psychological safety. We have a 2-hour value stream for our cloud based IOT product. This means a customer can receive changes to the software within 2 hours of the start of the feature.

     

    How did we get to this point? By working collaboratively and practicing Mob DevOps and Mob Programming! In this session we will review the status of the team and how you can iterate toward a similar environment.

  • Pranjal Deo
    keyboard_arrow_down

    Pranjal Deo - Engineering Reliable Mobile Applications

    45 Mins
    Talk
    Intermediate

    In today’s day & age, many services are being accessed by users through a client application on mobile. What’s the point of five 9s of server availability, if the productionized app is unreliable for users? This talk explains the importance, challenges and best practices of client-side reliability.

  • 20 Mins
    Talk
    Beginner

    When I refresh my memory and consider my whole testing life, I again realize that life is full of lessons. Whenever I think about this, I come up with a saying by John W. Gardner: “Life is the art of drawing without an eraser.” We are all making mistakes and it is not possible to manage each single piece of processes perfectly. Still; what we can remember is, with additional brush strokes, those mistakes can evolve into nice colors inside the big picture. Besides, in the next run, we may take precautions against possible mistakes.

    In short, after the quick review of my career, I decided to collect the required soft skills for a tester. Being a tester requires lots of skills, but it is not holding all of them in an unnatural way. We are humans, no supermans.

     
  • Shigeru Tatsuta
    keyboard_arrow_down

    Shigeru Tatsuta - Kubernetes 導入から始める DevOps について

    Shigeru Tatsuta
    Shigeru Tatsuta
    Senior System Engineer
    SoftBank
    schedule 1 month ago
    Sold Out!
    20 Mins
    Talk
    Beginner

    我々の所属するソフトバンクの IT 本部は、主にキャリア事業を支える IT システムの開発、保守、運用を担っています。キャリア事業はユーザーの生活を支える重要なインフラであるため、堅実なキャリア品質のシステム構築として、自社のデータセンターのオンプレミスな環境で稼働するシステムを数多く開発してきました。一方で、近年ではビジネス環境の変化に伴い、Agile や CloudNative な開発にも積極的に取り組んでいます。

    現在、全国のソフトバンクショップではスマホアドバイザーというスマホに関するあらゆる相談に対応するスタッフが在籍しており、スマホ教室などの様々なサービスを提供しています。スマホアドバイザーの業務を支援するシステムにおいて、自動化機能を可能な限り活用して、運用担当者の負荷の軽減を目的として、クラウド、Kubernetes を採用して、システム開発、および運用を行ってまいりました。当初は DevOps を目的としていたわけではありませんが、クラウド、Kubernetes によって、それまでの運用作業の質が変化し、結果として、開発と運用の組織の垣根を越え、運用の在り方、開発と運用の協業等、我々なりの DevOps を考えるきっかけとなりました。

    このセッションでは、我々のスマホアドバイザーのシステム開発において、クラウド/Kubernetes を導入して、1 年程度運用してきて、得た知見、たどり着いた我々なりの DevOps、およびこれからについて共有できればと思います。

  • Ryo Mukai
    keyboard_arrow_down

    Ryo Mukai / Naomichi Shimazu / Susumu Tomita - 「ログイン画面が開きません」から始まるチーム改革の軌跡

    45 Mins
    Talk
    Beginner

    知見も経験も無い大きな壁を前に、ただただ上を見上げるしかない担当者。
    藁にもすがる思いで、頼った先には今まで見たことのない新しい文化があった。

    その新しい文化に刺激を受け、個人としてもチームとしても成長した軌跡をお話します。
    会社をまたいだコラボレーションの結果が生んだ大きな成果、必聴です。

  • Jumpei Ito
    keyboard_arrow_down

    Jumpei Ito - 「お客さん怒ってるから謝ってきて」から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 2 days ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    QAに携わる人は一度は品質問題でお客様から怒られた経験はありませんか?
    私は最近経験しました。

    突然、マネージャーや経営陣に呼ばれて、
    「品質問題起こしてるサービスあるから、品質が語れるQAとしてお客さん先に行ってきて」
    と言われました。
    もちろん今まで自分が担当したことのない製品でした。

    お客様と会話し、開発現場のプロジェクトにどっぷりとハマり、
    見えたものは、お互いが主張するギャップでした。

    このトークでは、QAが開発現場に入って、
    チーム全体でデリバリーできるようなチームビルディングと、
    品質にフォーカスした開発を行うAgile Testingマインドセットを実践し、
    徐々に品質を改善したストーリーを話します。

help