filter_list help_outline
  • Patrick Debois
    keyboard_arrow_down

    Patrick Debois - TBD: DevOps Interview with Q&A

    Patrick Debois
    Patrick Debois
    Father of DevOps
    .
    schedule 1 month ago
    Sold Out!
    60 Mins
    Keynote
    Beginner

    TBD

  • Hiroyuki Ito/伊藤 宏幸
    keyboard_arrow_down

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

    45 Mins
    Talk
    Advanced

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

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

    これらの問題は、開発者・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" -』を大幅に加筆修正し、日本語で発表します。

  • 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. 

     
  • 20 Mins
    Talk
    Beginner

    We all observe that software testing continues to grow, proving that it is a living organism. 

    Scope:

    Software testing processes are started to be adapted into Software Development Life Cycle (SDLC) in waterfall (1) approaches. At the end of the development activities, verification and validation are performed to check the product before shipment to customers. What was the problem with Waterfall methodology? Testing activities were scheduled at the end of timeline and testers were out of time since previous activities are shifted.

     

    Then, in agile (2) methodologies, we see testing activities in all phases of the Software Development Life Cycle (SDLC). It starts from the first sprint. In this point, challenges are bigger since it is a very dynamic environment with lots of changes in a short duration. 

     

    To cope with complex scope to be verified in a limited time, automated testing started to appear in our life. Nowadays we meet lots of “Continuous X” terms, such as Continuous Integration, Deployment and Testing in terms of Devops (3) approaches. Can we go home and get some rest when we automate all cases? Of course not. We have to continue to track test results, maintain flaky results and keep quality in high standard. Still we have many manual tasks on healing, maintenance and analysis.

     

    Nowadays, researches are looking for adaptation of Machine Learning (4) algorithms and other hot topics to testing processes to reduce the manual effort and improve quality. To sum up, improvement of software testing never ends, but sometimes the growth confuses people. What is the deal of Scrum? Why are people crazy about continuous integration and continuous delivery (CI/CD)? What is the difference between Agile and DevOps? We will go over lots of this kind of questions.

     

    Results & Conclusion

    Objective of the talk is: To provide some insights about the growth of software testing. Starting from the early times of software testing, we will try to overview the big picture and finally we will discuss what we can face in the future.

  • Yasuharu Nishi
    keyboard_arrow_down

    Yasuharu Nishi - 製造業の品質管理の考え方をイマドキのスタイルで読み解いてみよう

    45 Mins
    Talk
    Intermediate

    自動車に代表される日本のハードウェアは高品質だ、と何となく思っている方は多いと思います。そうした製造業の企業はTQM(総合的品質管理)という品質管理の原則を確立し、ハードウェアの開発・生産をよりよくしてきました。しかし時代は変わり、彼らは今やソフトウェアが重要な役割を果たしたり、サービスと一体化し、アジャイル開発やDevOpsといったイマドキのスタイルを必要とする製品開発に、四苦八苦して品質管理の原則を適用しようとしています。

    この発表では、発表者の経験から、高品質を生み出すTQMの考え方を以下の4つのマインドセットにまとめ、説明していきます。
    - 品質という終わりなき旅
    - 全員を愚直で賢くする
    - 納得感の共感を高める
    - 弱さに寄り添う

    またこの発表では、品質を高め続けられる組織になるために、テスターはテストの技術や作業にのみ囚われてはいけない、というメッセージをお届けします。

    この発表で特にお伝えしたい点:
    - 品質を高め続けられる組織になるための4つのマインドセット
    - TQMの考え方と、アジャイル開発やDevOpsといったイマドキのスタイルの類似性
    - 知恵を生み出すために「矛盾ヲ抱擁セヨ」

    この発表に興味を持って頂けそうな方々:
    - 開発から疎まれているQAの方々
    - ハードウェアとソフトウェアの両方を開発する組織のQAを再構築したいと思っている方々
    - 「自分はテスターなのかQAなのか?」と悩んでいるテスターの方々


    You have a vague impression that many Japanese hardware manufacturers develop high quality products such as automobile. They have established principles of quality management, called TQM, and optimized their process for large-scale hardware design and production. But as time flies, they are struggling to apply the principles to modern development such as agile and devops for software-intensive and service-oriented hardware products. Nishi will share his experiences in re-establishment of quality management in modern context for several large-scale manufacturers in Japan. He summarizes the concepts of TQM into four mindesets below:
    - Journey into quality forever
    - Make everyone perseveringly smarter
    - Enhance co-confidence
    - Nestle weakness
    Nishi will also compare tester and QA, and suggest QA should be unchained from testing activities to establish a high quality organization.

    The talk will focus on:
    - Mindsets in high quality manufacturers in Japan
    - Similarity between TQM and modern concepts, e.g. agile and devops
    - To embrace conflicts and make insights for QA

    Who will be interested:
    - QA who has lost developer's trust 
    - QA who will establish company-wide QA organization for both hardware and software 
    - Test engineers who wonders "am I a tester or a QA?"

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - [Remote] Leading Engineers To Water: The Art, Science, and Culture of Technical Coaching

    45 Mins
    Talk
    Beginner

    Software engineering may be difficult, but fostering a working environment that enables skilled engineers to perform their best can sometimes seem downright impossible. Every day, many engineering teams are battling a messy whirlwind of forces like unmovable deadlines, imposter syndrome, psychological safety issues, personnel/leadership conflicts, fierce technological preferences, and more. With teams more distributed all over the world than ever before, cultural differences can exacerbate many of these difficulties.

    In this presentation, I’ll discuss tips, tricks, and techniques that technical leaders and managers alike can utilize to better coach engineering teams, including concepts like the definition of empathy (and, more importantly, what doesn’t count), the trust-influence relationship model, introducing new technologies in a meaningful and consumable way, and a 5-step process to provide teams confidence to own their new solutions moving forward.

    ** 日本語版もあります。

  • クリス 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.

  • Kohsuke Kawaguchi
    keyboard_arrow_down

    Kohsuke Kawaguchi - 育児的ソフトウェア開発

    Kohsuke Kawaguchi
    Kohsuke Kawaguchi
    CTO
    CloudBees, Inc.
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    私は、Jenkinsプロジェクトの創始者、CloudBeesの創業者の一人として欧米の様々なソフトウェア開発の現場を見てきました。この経験から、雇用形態、ソフトウェア開発組織の作られ方、CI/CDなどの技法、cloud nativeなどのテクノロジの勃興の間に、密接な繋がりがある事がわかってきました。この発表では、これらの知見をまとめてアメリカ式のソフトウェア開発プロセスがどのように構築されているかを紹介します。

    また、僕はここ数年日本のソフトウェア開発を世界水準へと思い色々な活動をしていますが、アメリカ式をただ輸入すればいいと思っているわけではありません。まずは、日本式のソフトウェア開発がどのような合理性に基づいてどのように行われているのか、日本式のソフトウェア開発のプロである皆さんから学びたいと思っています。その上で、皆さんと日本のソフトウェア開発プロセスはどのように進化していくべきなのか、一緒に考えを深めたいと思っています。

  • Jayne Groll
    Jayne Groll
    CEO
    DevOps Institute
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    Site Reliability Engineering (SRE) is rising quickly as the most innovative approach to IT Service Management (ITSM) since the early days of ITIL. This session will explore SRE from an ITSM perspective, including how SRE approaches common processes such as Service Level Management, Change Management, Incident Management, Capacity Management, and more.

    In this webinar, you’ll learn:

    • The history and definition of Site Reliability Engineering
    • SRE Guiding Principles
    • The importance of meeting Service Level Objectives
    • SRE guidance for ITSM processes
    • Why toil reduction and an engineering approach is important
    • About the role of the Site Reliability Engineer
    • Details of the SRE Foundation certification
  • 45 Mins
    Talk
    Beginner

    Psychological safety has been identified as the topmost feature of a successful and innovative organization. At the same time, we need to learn from failure and prevent recurrence of mistakes. These two practices seem to contradict each other, but is there a way to achieve them both?

  • 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.

     
  • Ricardo Castro
    keyboard_arrow_down

    Ricardo Castro - Treat your infrastructure code with respect

    45 Mins
    Talk
    Intermediate

    Infrastructure as code (IaC) is the management and provisioning of infrastructure through machine-readable definition files. It’s the process of defining network rules, spinning up servers, configuring servers and services, among other things, by using code instead of manual changes in a repeatable and idempotent way.

    In what shape is your infrastructure code documentation? Do you have architecture diagrams for your infrastructure layout? How do you test those changes? How good is your code coverage? Is your IaC automated? 

    In sum, what’s your Software Development Life Cycle (SDLC) for Infrastructure/Operations code?

  • Yuya Kazama
    keyboard_arrow_down

    Yuya Kazama - DevOpsの組織におけるテスト活動の在り方

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 1 week ago
    Sold Out!
    45 Mins
    Talk
    Beginner

    ここ最近、私の周りでは、テスト活動の範囲が広がっている事例が出てきているように感じます。

    例えば、テストマニフェストでは、「ずっとテストし続ける」「品質に対してはチームが責任を持つ」と示しています。つまり、テストとはQAやテスターだけの取り扱いではなく、チーム全体でテストを常に考え続けることを表しています。

    20200418161646.png

    また、Dan AshbyのDevOpsにおける継続的テストの図では、実装前であるPlanの部分から本番環境適用後のMonitorまで、あらゆるところでテストができることを表現しています。

    model-2.jpg?w=820

    この継続的テストの図のうち、画像の左半分、特にPlanやBranchといった部分や更に前段階のIdeaの部分にテスト活動を持っていくことをShift leftのテストと呼んでいます。一方、画像の右半分の部分にテスト活動を持っていくことをShift rightのテストと呼んでいます。

    私は今まで、RSGTやScrum Fest Osakaでの発表を通じて、Shift leftの事例を紹介していきました。また、書籍『Agile Testing Condensed』にもShift leftのテストを行う方法が多く紹介されています。

    一方で、Shift rightのテストはどうでしょうか?実は開発者やSREチームではFeature Flagといった手法を用いることによってShift rightのテストを行う準備ができているかもしれません。ですが、Feature Flag部分に対するテストをどうすれば良いかまで考えている人は少ないかもしれません。

     

    そこで本発表では、書籍『Agile Testing Condensed』と書籍『Testing in DevOps』を参考にして、Shift leftおよびShift rightのテストについてご紹介します。

    また、我々の組織で行っているShift rightのテストの事例もご紹介できればと考えています。

  • Geovanne Bertonha
    Geovanne Bertonha
    Solutions Architect
    CI&T
    schedule 2 months ago
    Sold Out!
    60 Mins
    Workshop
    Beginner

    REST is definitely the main software architecture style followed when it comes to application-to-application communication. If you have already worked on any web application  you certainly had to either develop and provide an API or consume some service from third parties. Moreover decoupled architectures such as microservices have gained a lot of traction in the past years which just reinforces the importance of REST in the present days. 

    No matter how big your application is, one thing that you should do is to ensure that your RESTful endpoints are always online and being continuously tested, specially because in some cases we are providing services to other parties that cannot be disrupted by outages or malfunction. Furthermore, the earlier you identify issues caused by code changes the easier is to have it fixed without having serious consequences.

    There are no excuses for not automating your RESTful API tests anymore! No matter if you are a beginner or advanced user, during this hands-on workshop you will be able to follow a few steps and get your RESTful API test automated in 60 minutes, using Postman, Newman and Jenkins.

    uc?export=view&id=1nP92cT4fF8kSs_VJ7nkoiYmf5ZAbc36R

  • Michael Migliacio
    keyboard_arrow_down

    Michael Migliacio - [Remote] Beyond the Brain Teaser: Technical Interviewing with RESPECT

    20 Mins
    Talk
    Beginner

    "How would you move Mount Fuji?"  

    Great question, but does an engineer need to know the answer in order to write great code?  No?  I don't think so either.

    The technical interview is one of the most controversial, challenging, and stressful parts of an engineer's career. The more senior the engineering position, the  less relevant the brain teasers, algorithm quizzes, and puzzles that make up these interviews are to the evaluation of a potential candidate. And although this interview style first became famous at large tech corporations like Microsoft and Google, it has propagated across the industry to the point that courses are springing up in college campuses and bootcamps showing candidates exactly how to "crack" these interviews.

    In the past, I’ve worked at a number of companies as a lead developer and in that role I spent a lot of time interviewing folks for technical positions. We weren’t allowed to choose our own process and had to follow the company’s rules. In that time I learned a lot about what works, and what doesn't work, for judging technical aptitude in an interview setting.

    In this presentation I will talk about the difficulties of technical interviewing from both the interviewee and interviewer's point of view, and provide several helpful tools using the acronym RESPECT to improve the interviewing experience across the board.

    ** 日本語版もあります。

  • Tomoaki Takaichi
    keyboard_arrow_down

    Tomoaki Takaichi - デプロイメントパイプラインを構築する基本概念・テスト戦略を考える

    45 Mins
    Talk
    Intermediate

    今回は、私が経験した一般的な Web アプリケーションを開発する際のデプロイメントパイプラインについて発表しようと思います。

    昨今では Jenkins, Screwdriver, CircleCI など数々の CI / CD ツールが登場しています。CI / CD を含めたソフトウェアをバージョン管理にチェックインしてからユーザーの手に渡すまでのデプロイメントパイプラインと呼びます。このデプロイメントパイプラインを構築するにあたり、どのような点を意識すればよいか、どのようなテスト戦略を取るべきかということをお悩みの方は多いのではないでしょうか。

    この発表では、「継続的デリバリー」本、「アジャイルテストの4象限」「テスト自動化のピラミッド」などの文献を参考にしながら、どのようにデプロイメントパイプラインを構築し、どのような自動テストを実装していくかという点について考えるセッションにしたいと考えております。

    また、この発表では「ソフトウェアテスト自動化カンファレンス2020」で発表させていただいた「CI パイプラインでのテスト戦略とその実現方法」の内容に加え、キャパシティテストや継続的デリバリー自体の管理という内容も付け加えた内容にしたいと考えています。

    ※ slide, video には本発表のベースとなる「ソフトウェアテスト自動化カンファレンス2020」で発表させていただいた「CI パイプラインでのテスト戦略とその実現方法」の資料と動画を掲載しております。

help