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.

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.

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

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

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

English follows:

「[email protected]（[email protected]）を取り入れた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 [email protected], 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.

自動車に代表される日本のハードウェアは高品質だ、と何となく思っている方は多いと思います。そうした製造業の企業は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?"

Preferred Networks（PFN）は深層学習などの最先端の技術を最短路で実用化することで、これまで解決が困難であった現実世界の課題解決を目指しています。コンピュータビジョン、自然言語処理、音声認識、ロボティクス、コンパイラ、分散処理、専用ハードウェア、バイオインフォマティクス、ケモインフォマティクスといった幅広い分野で研究開発を行っており、それを支えているのが Kubernetes を用いて構築しているオンプレミス/ベアメタルの GPU クラスタです。

本セッションでは、PFN が Kubernetes を用いてクラスタを運用するなかでどのような障害が起きるのかを紹介し、また障害対応をどのように自動化しているのかを具体的に使用/開発したソフトウェアを含めてご紹介します。また Kubernetes クラスタの管理、アップグレードの自動化にも取り組んでおり、それを実現する Cluster API についてもご紹介します。

Agile Testingのチーム全体アプローチではチーム全員でテストや品質のことを考えていく必要があります。

チームメンバーは会話をしながら相互に理解を深めていくのですが、会話を促進するツールがいくつかあります。例えば、RSGT2021でJanetさんが提案していた品質スライダーや実例マッピング※などです。

今回はチームの会話を促進するツールの一つとしてテスト観点図※を紹介をします。
テスト観点図はチームメンバーが必要だと考えるテストの観点を集め、構造化したものです。

プログラマとテスターとプロダクトオーナーそして運用はそれぞれ製品に対して気にするところが違うのが普通です。
このテスト観点図をチームメンバー全員で早期に作成し、お互いの気になっていることを理解することでプログラマが設計、コーディングの前に必要な品質を意識することができ、バグの予防に役立ちます。

テスト観点図は価値のある成果物ですが、成果物そのものよりもそれを作り上げていくプロセスにこそさらなる価値があります。

※実例マッピング
実例マッピングについてはブロッコリーのブログに詳しく載っています。
https://nihonbuson.hatenadiary.jp/entry/ExampleMapping

※テスト観点図
テスト観点図はVSTePという手法の成果物の一つで、テスト観点を構造化した図です。
VSTePとは電通大の西康晴氏が提唱しているテスト開発の方法論です。
テスト対象についてチームでテスト観点を出し、構造化してテスト観点図を作ります。
そのテスト観点をベースにテストをどのように実施していくかを表した「テストコンテナ図」やテストケースのひな形になる「テストフレーム」を作り、チームとして納得感のあるテストを開発していきます。
http://www.jasst.jp/symposium/jasst16tohoku/pdf/S1.pdf

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

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

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

この継続的テストの図のうち、画像の左半分、特に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部分に対するテストをどうすれば良いかまで考えている人は少ないかもしれません。また、Feature Flag以外にどのような手法があるのか知らない人も多いかもしれません。

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

あなたのチームは「こんなテストでいいのかな？」と不安を持ったことがありませんか？
あなたの組織は「これが我々の品質保証だ！」と自信を持って進められていますか？

• スクラムチームのテストが上手くいっていない感じがするが、打つ手が見つからなくなってきた
• 所属している組織の品質を上げたいが頭打ち感がある
• テストや品質保証で外の力を借りようとしたが、イマイチだった（上手くいかなかった）

この発表では、ソフトウェアテストや品質保証に漠然とした悩みや不安を抱えている方に向けて、自信を持ってテスト活動を進めていくスタートラインをいくつかの例を使ってお伝えします。

この発表で扱う予定の例：

• テストケースを行き当たりばったりで作り続けてきたが、増やしても増やしても不安が消えないチーム
• あるチームで行ったテスト自動化を組織に横展開してみたが、メンテナンスコストが増える一方で品質が上がっている気がしない
• プロダクトの開発規模拡大のために外部のテスト専門会社にテストを依頼したが、期待したようなテストをやってもらえなかった

この発表で特にお伝えしたい点：

• テスト・品質保証のスキルは大きく4つに分類できる
  • Domain Knowledge：ドメイン知識…プロダクトに関わる固有知識・技術
  • IT Skills：ITスキル…開発そのものの技術（テスト自動化の環境構築なども含む）
  • Test Skills：テストスキル…モデリングやロジカルシンキング、パターン化能力、質問力などの技術（※ひたすら入力・打鍵・実行する作業スキルではない）
  • Soft Skills：ソフトスキル…コミュニケーションやファシリテーションなど他のスキルの下支えとなる技術
• どのスキルを使っているか？重視するか？を分析することで漠然とした不安から抜け出せる
• 足りないスキルを埋めるために何ができるか
• ソフトウェアテストは広大だ！

あなたが抱えるソフトウェアテスト・品質保証の漠然とした不安や頭打ち感を、この発表を通して一緒に紐解いてみませんか？
自信を持ってテスト活動を進めるためのスタートラインに一緒に立ちましょう！

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

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

お客様と会話し、開発現場のプロジェクトにどっぷりとハマり、見えたものは、
お客様とチームとのギャップ、またチーム内のメンバー同士が主張するギャップでした。

書籍『Agile Testing Condensed』では「Whole-Team」の定義を「whoever you need to deliver the product」と提唱しています。
また、「Whole-Team Approach」は「all team members are responsible for the quality of thier product」と提唱しています。
つまりプロダクトをデリバリーする際に関連するメンバー全員が「Whole-Team」であり、Whole-Teamのメンバーは全員がプロダクトに対する品質の責任があります。

このトークでは、QAが品質問題を抱えている開発現場に入って、プロダクトマネージャーやチームメンバーとの信頼関係を構築して、徐々にWhole-Team（チーム全体）としてプロダクトをデリバリーできるようなチームになった話をします。

また、品質にフォーカスした開発を行うAgile Testingマインドセットを実践し、顧客との会話で得たビッグピクチャー（全体像）とユースケースの重要性を理解して、徐々に品質を改善したストーリーを話します。