location_city Tokyo schedule Apr 16th 01:00 - 01:20 PM place Hall B people 8 Interested

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.


Outline/Structure of the Talk

What I will talk about is:

  • What I learnt from my very early testing time: As a junior tester, what I faced? Which ways to act I learnt from those experiences.
  • What I learnt from switching projects/products frequently.
  • How did I survive in different environments?
  • What other aspects did I experience after I was a team leader?
  • What were the difficulties stemming from working in global studies?

Learning Outcome

In this talk, I collected 25 soft skills that I decided a tester should have from my personal story.

  • Attendees will see a summarized set of soft skills, collected from real life scenarios.

Target Audience

Testers, Team Leaders, Software Developers

Prerequisites for Attendees

No requirement

schedule Submitted 6 months ago

Public Feedback

  • Yasunobu Kawaguchi
    By Yasunobu Kawaguchi  ~  5 months ago

    Thank you for submitting proposals.
    We have reorganized the topic categories to make them easier to understand.
    This is also reflected in the topics of this proposal.

  • クリス Chris Lucian

    クリス Chris Lucian - Mob DevOps & Mob Programming

    45 Mins

    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.

  • Hiroyuki Ito

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

    Hiroyuki Ito
    Hiroyuki Ito
    Agile Coach, DevOps Consultant
    schedule 5 months ago
    Sold Out!
    45 Mins


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



    私たちのチームは、これらの問題を解決すべく、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)

    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

    English follows:

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

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



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

  • Yasuharu Nishi

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

    45 Mins


    - 品質という終わりなき旅
    - 全員を愚直で賢くする
    - 納得感の共感を高める
    - 弱さに寄り添う


    - 品質を高め続けられる組織になるための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?"

  • Cheshire Cat

    Cheshire Cat - Infrastructure as Code の静的テスト戦略

    Cheshire Cat
    Cheshire Cat
    Software Engineer
    schedule 4 months ago
    Sold Out!
    45 Mins

    Infrastructure as Code を導入してみたはいいけれど、デプロイしてみたらなぜか上手く動かない。そんな経験はありませんか? 本セッションでは、実際の環境を構築する「前」に、IaC のコード自体に対してテストを行う手法について解説します。

    ご存知の通り Infrastructure as Code (IaC) は、インフラをコードで定義することを通し、アプリケーション開発のベストプラクティスをインフラ領域にも輸入しようとする方法論です。IaC の考え方は近年急速に普及し、開発フローの一部として種々の IaC ツールを利用することは半ば常識のような状態にあります。

    しかし同時に、IaC は銀の弾丸ではありません。特に組織的な導入を考えようとすると、得てして「なぜか上手くいかない」「余計に運用が辛くなってしまった」という声を聞くこともよくあります。

    なぜこんな事態に陥ってしまうのでしょうか? 本セッションの前半ではこの問題を言語化するために、「予測可能性」という考え方を導入します。IaC のデプロイ結果の予測しづらさがなぜ運用の辛さに繋がるのか、その構造を図解した上で、予測可能性を担保するための原理・原則を解説します。

    では、具体的にその予測可能性を担保するにはどうしたらよいのでしょう? セッションの後半では AWS を取り上げ、IaC の実践の中でいかにインフラの予測可能性を担保するのか、方法論や具体的なツールの適用について解説します。

    IaC 特有の辛さに疲れてしまったあなたが、もう一度 IaC に光明を見い出すためのセッションです。

  • Fujihara Dai

    Fujihara Dai - 輝くみらいを抱きしめて! アジャイル・DevOps時代のテストと品質保証(完全版)

    45 Mins





    私はアジャイルコーチとして10年活動してきましたが、 最近話題の「DX(デジタルトランスフォーメーション)」の影響か、 開発に速さがより求められるようになってきたように感じています。

    そして、その影響もあってか「テストがボトルネックになりがち」や 「マニュアルテストのチームがコストセンターになってしまった」という相談をよく受けるようになりました。


    • 現在
    • 戦略と戦術
    • 組織未来



  • Noriyuki Nemoto

    Noriyuki Nemoto - テスト観点図でチームの知を集める方法

    Noriyuki Nemoto
    Noriyuki Nemoto
    senior engineer
    Agile Sapporo
    schedule 4 months ago
    Sold Out!
    20 Mins

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







  • Yuya Kazama

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

    Yuya Kazama
    Yuya Kazama
    QA Engineer
    BizReach Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins




    また、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のテストについてご紹介します。

  • Kaori Tokiwa

    Kaori Tokiwa - 手探りのソフトウェアテスト・品質保証から抜け出そう!~自信を持ってテスト活動を進めるためのスタートライン

    45 Mins


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



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


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


  • Hiroyuki TAKAHASHI

    Hiroyuki TAKAHASHI / Kentaro Arakawa / Yasuko NAITO - 文化的負債との戦い: 老舗ソフトウェア開発会社でアジャイル変革を仕掛けた8年間

    45 Mins




    書籍「Effective DevOps ―4本柱による持続可能な組織文化の育て方」では次のように表現されています。

    【技術的負債とは、システム設計、ソフトウェアアーキテクチャー、ソフトウェア開発、技術の選択などの技術的な決定が最終的に生み出すもののことだ。一方で、文化的負債は、採用や解雇の決定、コミュニティの基準の制定や施行、組織の階層構造、価値観といった文化的な決定が最終的に生み出しているもののことである。 文化的負債にも技術的負債と同じことが当てはまる。つまり、いつか返済しなければいけないし、負債の原因となっている問題を長期に渡って手付かずにしていればいるほど、利息が蓄積して、将来負債から抜け出すことが難しくなる。(p314)】


  • Jumpei Ito

    Jumpei Ito - 品質問題から始まったWhole-TeamアプローチとAgile Testingマインドセットの改善物語

    Jumpei Ito
    Jumpei Ito
    QA Engineer
    WingArc1st Inc.
    schedule 5 months ago
    Sold Out!
    45 Mins




    書籍『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」と提唱しています。


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

  • Mesut Durukal

    Mesut Durukal - 4 Pillars of Successful Agile Test Automation

    20 Mins


    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.  



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



    • 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

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


    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.

  • Pranjal Deo

    Pranjal Deo - Engineering Reliable Mobile Applications

    45 Mins

    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.