LINE Developer Meetup in Tokyo #39 Presentation

Yasuharu Nishi
Yasuharu Nishi電気通信倧孊
••
むマドキの゜フトりェアのテストやQAの考え方 LINE Developer Meetup in Tokyo #39 Testing & Engineering 2018/6/27氎 電気通信倧孊 倧孊院情報理工孊研究科 情報孊専攻 経営・瀟䌚情報孊プログラム 西 康晎 @YasuharuNishi / Yasuharu.Nishi@uec.ac.jp
Profile • Assistant professor: – the University of Electro-Communications, Tokyo, Japan • President: – Association of Software Test Engineering, Japan - Nonprofit organization (ASTER) • President: – Japan Software Testing Qualifications Board (JSTQB) • National delegate: – ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246) • Founder: – Japan Symposium on Software Testing (JaSST) • Founder: – Testing Engineers’ Forum (TEF: Japanese community on software testing) • Judgement Panel Chair / member: – Test Design Contest Japan, Test Design Competition Malaysia (TDC) • Vice chair: – Software Quality Committee of JUSE (SQiP) • Vice chair: – Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME) • Organizer – QA4AI Consortium • Advisor: – Software Testing Automation Research group (STAR) © NISHI, YasuharuTS-2 p.2
講挔の流れ • ゜フトりェアQAの戊略立案  間違った戊略によるQAは必ず倱敗する – 劎働のスケヌルアップから知のスケヌルアりトぞ – 䟡倀芳や品質のパッケヌゞング – AQUAフレヌムワヌク • ゜フトりェアQAの゚ンゞニアリングアプロヌチ  テストの意図を゚ンゞニアリングしよう – QAアヌキテクチャ – テスト芁求分析ずテストアヌキテクチャ蚭蚈 – テストフレヌムずテスト詳现蚭蚈 – VSTeP導入のコツ – 䞍具合モヌドず探玢的テスト – テストの自動化 © NISHI, YasuharuTS-2 p.3
劎働のスケヌルアップから 知のスケヌルアりトぞ
日本䌁業を取り巻く状況パラダむムシフトぞの远埓 • 劎働のスケヌルアップから知のスケヌルアりトぞ – 劎働のスケヌルアップ • 暙準化、プロセス定矩、手順の確認・ダブルチェック、ムダ取り、䌑憩の圧瞮、 考えるこずの排陀・局所化、掟遣化、オフショアリング、アりト゜ヌシング、有識者の掻甚  • スケヌルアップなので䞀郚の人に負担が倧きくなり、スケヌルにより管理コストが増倧しおサチる – 知のスケヌルアりト • 䞀぀䞀぀の知の質を高める → より本質的な䟡倀に近づける、正解がないので早くたくさん倱敗しお孊ぶ • 䞀぀䞀぀の知を確かにする → 玍埗感の共感アゞャむル • 知でないものを取り陀く → 単玔䜜業の機械化CI • 知の匷化サむクルを぀くる → 正しいカむれンサむクル、違和感のアンドン化、フロントロヌディング • 知を広げる → 倖プロセスずの接続による党䜓最適Industrie4.0、デゞタルツむンDX、モゞュヌル化 • 倖から知を集める → 技術の民䞻化、OSS、オヌプンむノベヌション • スケヌルアりトした知を圧瞮する → IoTビッグデヌタAI • 個々の取り組みだけに囚われるず鶏ず卵になりうたく進めない – 劎働のスケヌルアップ的パラダむムでIndustrie4.0を捉えるず 単なるセンサ付き補造蚭備にしか芋えず、 旧来の開発を無理にスケヌルアップする矜目になる – オヌプンむノベヌションを倧孊ず始めおも論文ばかり曞こうずされお珟堎に圹立おられない © NISHI, YasuharuTS-2 p.5
間違った戊略によるQAは 必ず倱敗する
間違った戊略に基づいた品質保蚌は倱敗する • 間違った戊略に基づいた品質保蚌は、どう珟堎が頑匵っおも必然的に倱敗する – 自組織は劎働のスケヌルアップに基づいた経営をしおいないか • 単玔な「補造業䌁業は゜フトりェア䌁業になれ」「Googleは偉い」論ではない点に泚意するこず • 「属人化の排陀」「スキルはカネで買える」「責任分解点」などを頻繁に口にする組織が倚い – ゜フトりェア開発は劎働のスケヌルアップだず捉えおいないか • りォヌタヌフォヌルなど個別の取り組みが悪いのではない – 知のスケヌルアりトのための個別のアクティビティバズワヌドに振り回されおいないか • アゞャむル開発における品質保蚌やテストはどうするのか、ず考えるので答えが出ない • 劎働のスケヌルアップを保蚌する掻動はおおむね倱敗するずいうこずが、 ここ510幎の日本の補造業および゜フトりェア産業の経隓則である – 個々の技法や仕組みが劎働のスケヌルアップ的パラダむムを招いたのではなく、 それぞれの技法や仕組みを劎働のスケヌルアップ的に䜿っおきたのが問題である • 日本䌁業はどうしおも劎働のスケヌルアップずいう発想で品質保蚌をしおしたいやすい • ハヌドりェアの蚭蚈や品質保蚌は知のスケヌルアりトをしようずしおいおも、 ゜フトりェアの開発や品質保蚌がそれを理解せずに劎働のスケヌルアップずしお衚面的に真䌌おしたう – 欧米で知のスケヌルアりトをしようずしおいる䌚瀟を芋おも 真䌌ができないし、意味すら分からないこずさえある © NISHI, YasuharuTS-2 p.7
品質保蚌戊略ではないもの、あれこれ • そもそも品質保蚌に戊略などない – 「うちは各補品で党然違うみんな垞駐なので、 党瀟ずしおの品質保蚌戊略なんお考えようがないのですよ」 • それは品質ではない – 「そもそも営業が無理な案件を受泚しおいたのが品質䜎䞋の原因なので、 案件受泚審査を厳しくするずいうのが品質保蚌戊略です」 • スロヌガン – 「品質こそ我が瀟のブランド、ずいうのが品質保蚌戊略です」 • 目暙数倀 – 「5幎で品質を倍にする、のが品質保蚌戊略です」 • 組織構造・䜓制図・暩限 – 「これがISO9000甚に描いた䜓制図で、品質保蚌戊略を衚しおいたす」 • アむデンティティの確保 – 「品質保蚌郚の地䜍や発蚀力の向䞊です」 • 機胜や取り組みを䞊べたもの – 「プロセス改善、レビュヌ、テスト、メトリクスが品質保蚌戊略の軞です」 – 「XDDPずHAYST法ずAutomotive SPICEが品質保蚌戊略の構成芁玠です」 • 個別の取り組み – 「䞍具合率算出の粟床向䞊のために○△分析をするこずにしたした」 © NISHI, YasuharuTS-2 p.8
間違った戊略に基づく組蟌みの゜フトりェアQAの闇 • いきなり自組織の問題点を珟堎で掗い出そうずするずこんなものが挙がる – それはそうなんだけど、これではにっちもさっちもいかないよな  • 「PCが遅いです」 • 「窓やトむレが汚いです」 • 「残業が倚いです」 • 「絊料が安いです」 • 「なんかみんな幞せそうに芋えたせん」 • 自組織の状況や問題点を適切に把握できないたた 「品質保蚌戊略ではないもの」に埓っお品質保蚌を始めるが、 圓然ながら成果は出ない – 二蚀目には「品質保蚌のリ゜ヌスが足りなくお」ずグチを垂れる • 成果の出ない品質保蚌ずいう「劎働」を抌し぀けられる珟堎にそっぜを向かれる – 盲埓しおモチベヌションを䞋げるか、無芖するか、蛇蝎のように忌み嫌うか、のどれかが倚い • 開発が真っ向から反発する方がただ救いがある • それでも仕事はしなければならない – 品質保蚌が仕事をしたように経営陣に芋せる意味の無い工倫に血道を䞊げる © NISHI, YasuharuTS-2 p.9
品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような品質保蚌戊略を立おるようにする – より本質的な䟡倀に近づける • 自分たちがお客様に提䟛しおいるものは䜕かをトコトンたで考える – それが必芁なのかそこたで必芁なのか実は他のこずが必芁なのではないか • 品質保蚌掻動によっお組織内に䞎える良い圱響をも品質ず捉え保蚌・促進する – 䟡倀芳、思考様匏、行動様匏、技術やノりハり、組織の質、゚ンゞニアの感情など倚岐に枡る – 正解がないので早くたくさん倱敗しお孊ぶ • 実斜率や充足率で管理せず、倱敗を責めず、たずは思い぀いたこずを蚀いやすい颚土を構築する – 劎働のスケヌルアップに基づく組織は、蚀いたいこずを諊め、呆れ、思考停止しおいるこずが倚い – 倱敗を責めおも成功率は䞊がらず、トラむするこずが枛るだけである – 人を責めるのは原因分析の姿勢が原因なのではなく、原因分析の技術が䜎いこずが原因である – たずえトラむさせるこずができなくおも、抌し぀けず、ごたかさず、 盞手が玍埗したこずを共感できるたで合理的に説明する • 短いサむクルで完結できるように仕事をデザむンする – 仕事を単玔にぶ぀切りにしおも党く意味は無い – その仕事の党䜓像が把握でき、詳现たで芚えおおくこずができ、オヌナヌシップを持぀こずができ、 党員が技術的に䜕を考えおいるのかが理解でき、党員の玍埗感を共感できるサむズにする – 䞀぀䞀぀の仕事ごずに自分たちが成長できたず感じられるのが理想である • 品質保蚌そのものも早くたくさん倱敗しお孊ぶ – 党瀟を䞀床にカむれンしようずしない © NISHI, YasuharuTS-2 p.10
品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような戊略を立おるようにする – 玍埗感の共感を高める • たず郚長や課長がきちんず技術を理解する – 䞊玚管理職が管理屋の組織では知のスケヌルアりトは絶望的である » その堎合は、ミドルダりンアップの戊術を甚いる – 管理指暙や人事斜策は䌚瀟からの非蚀語的だが明確なメッセヌゞであるこずを認識しおもらう • 進捗よりも玍埗感、議事録よりも玍埗感の共感をマネゞメントする – きちんず玍埗せずに進捗するのは䞍具合や技術的負債を生む – 蚀った蚀わないの氎掛け論になっおいる時点でその開発は本質的に倱敗しおいる • 「説明無責任」のために蚀葉を尜くしお蚀い蚳をするのではなく、 盞手が腹萜ちしおしみじみ玍埗したこずを共感できるように蚀葉を尜くす – 客芳的、定量的、数倀的な説明よりも、技術的に合理的で無理のない説明を行う » 「説明無責任」自分が責任を回避するためだけに蚀葉を尜くしお説明をするこず。蚀い蚳。 » メトリクスそのものよりも、その合理性や劥圓性を玍埗し珟堎にその玍埗感を共感しおもらうこずが重芁 • あヌでもないこヌでもない、ず議論するこずは玍埗感を高める䞊でずおも重芁である – 決しお抌し぀けたり通達したり呜什したり説埗したりしない • 暗黙知を無理に圢匏知化しようずするず暗黙知が局所化するので、暗黙知を共感できる取り組みをする – 圢匏知化する際に議事録化させるのではなく、玍埗感を共感する分析や蚘述を行う • 玍埗しおくれたら、品質保蚌のミッションを開発郚隊がシェアしおくれるようになる – SET/SWETのような新しい職皮が必芁になるかもしれない » SET/SWET開発者に自分でテストしおもらうために、テストしやすくする環境を敎備する職皮 © NISHI, YasuharuTS-2 p.11
品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような戊略を立おるようにする – 知の匷化サむクルを぀くる • ゜フトりェア開発を奜きな゚ンゞニアを集める奜きになっおもらう – サラリヌマン゚ンゞニアは劎働のスケヌルアップを奜む • 違和感をアンドン化するあれず思った時にすぐに口に出せるような颚土にする – 違和感を飲み蟌む組織は玍埗感が䜎䞋し劎働のスケヌルアップに向かっおいく • PDCAは質の高いカむれンを玠早く継続的に行うためのものであっお、 怒られない理由づくりのために動きを遅くするものではない、ずいう考え方を培底する – PDCAを「回す」のではなく、「自然に回る」ようになるよう感受性を高める – カむれンされない組織で䞀番怖いのは、カむれンされないこずそのものよりも、 そんなこずしおもムダだず諊め、呆れ、違和感ぞの感受性を捚お去られるこずである – カむれンは「いたダメでも少しず぀倉わっおいけばいい」ずいう赊しである • 䞋流から䞊流にフィヌドバックしたり、䞊流から䞋流に心配事をフィヌドフォワヌドしたり、 䌌たようなカむれンを暪展開し、瞊暪無尜の知の匷化サむクルを぀くる – 単玔䜜業を機械化する • たずぱンゞニアが倚くの単玔䜜業をしおいるのに気付かない、ずいう珟実をなんずかする – 劎働のスケヌルアップに基づく組織では、単玔䜜業ぞの感受性を捚お去っお働いおいるフリをするず誉められる • 協力䌚瀟ずの契玄そのものを芋盎す – 劎働に察する支払いを行う限り、質も䞊がらなければ機械化もなされない • 珟行䜜業をそのたた機械化するのではなく、単玔䜜業を機械化するこずを前提ずしお 補品蚭蚈゜フトりェア蚭蚈開発プロセス開発䜓制を芋盎しおいく – そうしないず鶏ず卵が発生し、い぀たで経っおも前に進めない時期に突入する © NISHI, YasuharuTS-2 p.12
品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような戊略を立おるようにする – 知を集める • 倖から集める前に、゚ンゞニア䞀人䞀人が瀟倖から孊べる環境や制床を敎える – 孊ぶ䜙裕を持っおもらうために、残業をれロにし、就業時間内の業務に䜙裕を持たせる – Github、Slack、Qiita、Slideshare/Speakerdeckなどがブロックされおいる䌚瀟で孊べるわけがない – ゚ンゞニアが孊び議論し倱敗する䜙裕を぀くる – 瀟倖のカンファレンスやコミュニティに行くのを業務にし、瀟倖ぞの貢献を促進する » 瀟倖に貢献しようずする゚ンゞニアは、感受性が高いし圢匏知化力も高く、 瀟内により貢献しようずする – 瀟内でもコミュニティやカンファレンスを日垞にする – OSSは無料の倖泚先ではなく、孊ぶ察象であり、孊ぶ堎であり、䞀緒に育っおいくものである • 倧孊やコンサルタントに投資し、育お、圌らずの成果をフルに掻甚する自分たちの姿勢を鍛える – オヌプンむノベヌションずは技術の調達でも倖泚でも䞞投げでもないし、あなたたちはお客様ではない – そもそも、自分たちが欲しい成果を今すぐ安䟡にきめ现かく提䟛しおくれる䟿利なものはこの䞖に存圚しない – 知を広げる • 開発ず品質保蚌から教育ぞ、゜フトから党瀟ぞ、自瀟内から顧客ぞ、ず広げおいく – 知のスケヌルアりトには内補化が基本であり、 それでも知を提䟛しおくれる協力䌚瀟ずは高倀で付き合う – スケヌルアりトした知を圧瞮するのは圓分先である • 知をスケヌルアりトできるようになるず、様々なパタヌンに気づけるようになる • 自動化のチョコ停䞀郚だけ手動のたたになるをれロにするず、量の倉化が質の倉化になる © NISHI, YasuharuTS-2 p.13
成功する品質保蚌にはパラダむムシフトが重芁である © NISHI, YasuharuTS-2 p.14 劎働のスケヌルアップずいうパラダむムに囚われおいる人たちに 蟛抱匷く、理論歊装しお、実䟋を芋せお、寝技を駆䜿しながら、 知のスケヌルアりトずいうパラダむムを 理解しおもらい玍埗しおもらい共感しおもらい 行動に移しおもらうこずが、䜕より重芁である
FAQ: 「そんなのは品質保蚌の仕事じゃない」 © NISHI, YasuharuTS-2 p.15 それはあなたたちが 品質保蚌ずいう仕事を 勝手に矮小化しおいるだけです
品質ずは、なんですか
゜フトりェア品質保蚌の戊略 • 組織レベルQA戊略の立案ず遂行 – 知のスケヌルアりトを行うのか劎働のスケヌルアップに留たるのかずいう 組織パラダむムを決め、経営トップずコミットメントを取る • 劎働のスケヌルアップに留たろうずするずおおむね倱敗する – 組織党䜓における䟡倀芳や品質に぀いおパッケヌゞングする – 経営が組織パラダむムを䜓珟しおいるか、 組織党䜓における䟡倀芳や品質がパッケヌゞずしお実珟に向かっおいるようQAする – 組織のビゞネス゚ッセンスず目暙、実珟可胜性の怜蚎を 経営からプロゞェクトプロダクト、個人ないしグルヌプたで組織階局間で反埩的に行い、 実珟可胜性が十分確保されおいる階局ごずのビゞネス゚ッセンスず組織目暙に展開する • ビゞネス゚ッセンス 自分たちは誰に䜕の䟡倀を提䟛するのか – 組織党䜓の技術ロゞスティックスを蚭蚈し、きちんず埪環しおいるようQAする – プロゞェクトプロダクトレベルのQAで行う取り組みの母艊ずなる – ゜フトりェアQAそのものをQAする • プロゞェクトプロダクトレベルQA戊略の立案ず遂行 – 組織パラダむム、組織党䜓における䟡倀芳や品質のパッケヌゞ、 ビゞネス゚ッセンス、組織目暙、コンテキストを分析する – フォヌカスを蚭蚈する – 個々の取り組みを実装し、その順序、䜓制に萜ずし蟌む – 浞透させる © NISHI, YasuharuTS-2 p.17
䟡倀芳や品質のパッケヌゞング • 品質ずは䜕か、をきちんず分かっおいる組織は極めお少ない – 欧米的な考え方PMBOKなど • 顧客の芁求に察する合臎床ずいった「開発の結果」である – 日本的な考え方TQM。 • 仕事の質サヌビスの質情報の質工皋の質郚門の質人の質システムの質 䌚瀟の質などこれら党おを含めた「質」 • よく考えるず、ものの「質」にだけ着目しおいるわけではない – TQMは䟡倀的偎面、思考様匏的偎面、人間的偎面の3぀に着目しおいる • JIS Q 9005 における質マネゞメントの12原則顧客䟡倀創造、瀟䌚的䟡倀創造、ビゞョナリヌリヌダヌシップ、 コアコンピタンスの認識、人々の参画、パヌトナヌずの協働、党䜓最適、プロセスアプロヌチ、 事実に基づくアプロヌチ、組織及び個人の孊習、俊敏性アゞリティ、自埋性 • 「質」ずは倚様な偎面から成り立぀耇合抂念であり、組織の䟡倀芳を反映する – 結果的偎面、䟡倀的偎面、思考様匏的偎面、行動様匏的偎面、 内郚技術的偎面、組織的偎面、人間的偎面など • 単䞀の偎面にのみ着目しおも䞊手くいかない • 自組織にずっおの䟡倀芳や品質の意味を掘り䞋げ、 それらの持぀倚様な偎面をパッケヌゞずしおQAは取り扱わなくおはならない – 自組織にずっおの䟡倀芳だからこそ、QAが組織の経営に寄䞎する掻動になる • 倚様な偎面はそれぞれ耇合的に圱響しあうで泚意が必芁である © NISHI, YasuharuTS-2 p.18
組織の䟡倀芳や品質を構成する倚様な偎面の䟋 • このように倚様な偎面から、盞性のよいものをパッケヌゞングする – 結果的偎面 • 結果䞍具合の少なさ、非機胜特性、芁求合臎床など – 䟡倀的偎面 • 感性品質、顧客䟡倀、顧客の顧客の䟡倀、瀟䌚的䟡倀など – 思考様匏的偎面 • 䟡倀創造、目的指向、党䜓俯瞰、融合、アヌキテクチャ、事実に基づくアプロヌチ、 正味䜜業時間、本質、コアコンピタンス、氎平展開、厳密性、玍埗感、分割統治など – 行動様匏的偎面 • カむれン、孊習、アゞリティ、小さい歩幅、自埋、チャレンゞ、少ない手戻り、フロントロヌディング、 未然防止、暙準化、正確さ、再珟性など – 内郚的技術的偎面 • 欠陥の少なさ、蚭蚈のよさ、スゞのよさ/グッドノりハり、悪さのなさなど – 組織的偎面 • 党員参加、䞀䜓感、気配り、パヌトナヌずの協働、顧客巻き蟌み、リヌダヌシップ、 フォロワヌシップ、䞊意䞋達など – 人間的偎面 • 人間性、やりがい/働きがい、よろこび、ワクワク感、プラむド © NISHI, YasuharuTS-2 p.19
コンテキストに合わせお ゜フトりェアQAの戊略を立案しよう AQUAフレヌムワヌク Accelerating project Qualifying value Unveiling weakness Accumulating knowledge
プロゞェクトプロダクトレベルの゜フトりェアQA戊略 • 知のスケヌルアりトを促進するこずが゜フトりェアQAの圹割ずなる – 知のスケヌルアりトずいうパラダむムを瀟内に浞透させる – 自分たちのプロダクトが本圓に䞎える䟡倀は䜕かをバリュヌチェヌンの党員で考え抜く – 早くたくさん倱敗しお孊んだかをマネゞメントする – 玍埗感の共感、感受性、違和感の衚出、などをマネゞメントする – 単玔劎働的QA掻動を機械化し、劎働集玄的な協力䌚瀟を絞る – ゚ンゞニア䞀人䞀人がきちんず孊び成長できおいるこずをマネゞメントする – 受け身の姿勢や䞊から目線では必ず倱敗する • コンテキストによっお゜フトりェアQAで行うべきこずは異なる – コンテキストに合わない゜フトりェアQA掻動を行うず倱敗する • コンテキストずは、垂堎でのプロダクトの存圚感やポゞション、 蚭蚈・゜ヌスコヌドのサむズ・耇雑さ、組織胜力の皋床などから構成される – 䟋えばプロダクトを速くリリヌスしお垂堎を攻略したい時期であれば、 ゜フトりェア品質保蚌は垂堎の攻略や速いリリヌスを促進すべきであり、 じっくり怜蚌しお高い基準の信頌性を達成するゲヌトの圹割をすべきではない – 自分たちのコンテキストを理解した䞊で、 どこにフォヌカスしお知のスケヌルアりトを促すかを蚭蚈し、 個々の取り組みの実装やその順序、䜓制に萜ずし蟌み、 いかに浞透させおいくかを怜蚎するこずが、 プロゞェクトプロダクトレベルの゜フトりェアQAの戊略の立案である © NISHI, YasuharuTS-2 p.21
コンテキストに合わせお゜フトりェアQAの戊略を立案する • AQUAフレヌムワヌク – Accelerating project • ずにかく速く䜕床もリリヌスを行っお垂堎で存圚感を瀺したり、垂堎で孊ぶべき時期に行うQA掻動 – プロダクトサむズは小さく、信頌性や安党性はそれほど芁求されない時期 • 䞻芁な䟡倀やUXが損なわれないこずず、開発スピヌドが䞊がるこず、成長できるチヌムになっおいるこず、 などに品質保蚌をフォヌカスさせる – Qualifying value • プロダクトのポゞションやミッションが分かっおきた段階で、補品の䟡倀を最倧化するQA掻動 – プロダクトサむズが埐々に倧きくなり、機胜は増えUXを重芖するが、䜕を目指しおるのかがブレ始める時期 • 䟡倀が向䞊しおいるこずや、提䟛䟡倀の倚様化に远い぀いおいるこず、耇雑さの増加に察応できおいるこず、 などに品質保蚌をフォヌカスさせる – Unveiling weakness • 倚くのナヌザを獲埗し、垂堎で存圚感を確立した時期に行うQA掻動 – プロダクトサむズがかなり倧きく、開発䜓制も倧芏暡化し、䞀぀のバグの圱響が甚倧になる時期 • 倧芏暡化に察応できおいるこず、䞍具合が出やすい仕様・蚭蚈䞊の匱点に気づき察凊できおいるこず、 玍埗感を共感させる仕組みが浞透しおいるこず、などに品質保蚌をフォヌカスさせる – Accumulating knowledge • 次䞖代、発展型、ファミリ的なプロダクトの開発を怜蚎すべき始めおいる時期に行うQA掻動 – 機胜の远加ず、コア郚分や環境の入れ替えが同時倚発的に頻発し、䞭心メンバが入れ替わる時期 • 俯瞰し芋通しよくできおいるこず、シンプルさを保぀仕組みが保たれおいるこず、 開発から知を獲埗できおいるこず、メンバの知が向䞊し埪環しおいるこず、などに品質保蚌をフォヌカスさせる © NISHI, YasuharuTS-2 p.22
゜フトりェアQAの取り組みに萜ずし蟌む • AQUAフレヌムワヌクの䟋: – Accelerating project • コンテキストずフォヌカス – ずにかく速く䜕床もリリヌスを行っお垂堎で存圚感を瀺したり、垂堎で孊ぶべき時期に行う品質保蚌掻動 » プロダクトサむズは小さく、信頌性や安党性はそれほど芁求されない時期 – 䞻芁な䟡倀やUXが損なわれないこずず、開発スピヌドが䞊がるこず、成長できるチヌムになっおいるこず、 などに品質保蚌をフォヌカスさせる • 取り組みぞの䟋 – プロダクトプロゞェクトマネゞャヌずの察話の開始や、チヌムのずの䟡倀芳の共有を目的ずした朝䌚ぞの参加 – 筋のよい蚭蚈でよいコヌドを曞いおいるずメンバが玍埗感を持おるようにするペアモブプロの促進やDR – 頻繁なリリヌスをためらわず最速の開発に近づいおもらうこずを促すためのKPT/PDCAやTDD、UTレベルのCI – 垂堎の求める䟡倀の理解ず、垂堎からのフィヌドバックに察する反応速床の加速のためのUSMぞの参加 – Qualifying value • コンテキストずフォヌカス – プロダクトのポゞションやミッションが分かっおきた段階で、補品の䟡倀を最倧化する品質保蚌掻動 » プロダクトサむズが埐々に倧きくなり、機胜は増えUXを重芖するが、䜕を目指しおるのかがブレ始める時期 – 䟡倀が向䞊しおいるこずや、提䟛䟡倀の倚様化に远い぀いおいるこず、耇雑さの増加に察応できおいるこず、 などに品質保蚌をフォヌカスさせる • 取り組みの䟋 – 垂堎の求める䟡倀ずその倉化を機胜やふるたいで実珟しおいるこずを実蚌するE2Eテスト – 暗黙知を暗黙知のたた共有し、新しいメンバにも䌝えおいくためのペアモブプロの促進やDR – 頻発する手戻りに察しおデバッグで終わらせず蚭蚈たで戻し蚭蚈の筋をよくするバグ分析ずナビゲヌション – 蚭蚈の耇雑さを増加させないためのデザむンレベルリファクタリングの掚進ずテスタビリティの䜜り蟌み © NISHI, YasuharuTS-2 p.23
゜フトりェアQAの取り組みに萜ずし蟌む • AQUAフレヌムワヌクの䟋 – Unveiling weakness • コンテキストずフォヌカス – 倚くのナヌザを獲埗し、垂堎で存圚感を確立した時期に行う品質保蚌掻動 » プロダクトサむズがかなり倧きく、開発䜓制も倧芏暡化し、䞀぀のバグの圱響が甚倧になる時期 – 倧芏暡化に察応できおいるこず、䞍具合が出やすい仕様・蚭蚈䞊の匱点に気づき察凊できおいるこず、 玍埗感を共感させる仕組みが浞透しおいるこず、などに品質保蚌をフォヌカスさせる • 取り組みの䟋 – 倧芏暡化やSoE/SoRの融合のためのマむクロサヌビス化などのアヌキテクチャレベルリファクタリングの掚進 – 倧芏暡化でも開発速床を保぀ためのE2Eテストの自動化キヌワヌド駆動テスト化ずフルCI – 暗黙知の圢匏知化ず圢匏知の実質化反圢骞化のためのドキュメント化ずレビュヌ – 仕様や蚭蚈䞊の匱点をいぶり出し皆が匱点に気を぀けられるための垂堎バグの根本原因分析ず探玢的テスト – Accumulating knowledge • コンテキストずフォヌカス – 次䞖代、発展型、ファミリ的なプロダクトの開発を怜蚎すべき始めおいる時期に行う品質保蚌掻動 » 機胜の远加ず、コア郚分や環境の入れ替えが同時倚発的に頻発し、䞭心メンバが入れ替わる時期 – 俯瞰し芋通しよくできおいるこず、シンプルさを保぀仕組みが保たれおいるこず、 開発から知を獲埗できおいるこず、メンバの知が向䞊し埪環しおいるこず、などに品質保蚌をフォヌカスさせる • 取り組みの䟋 – プロダクトラむン開発や環境倚様化のためのコア資産の抜出や゚ンゞン化、フレヌムワヌク化、仮想化の掚進 – 耇数チヌムでの共有や俯瞰のためのモデル化、DSL化ずレビュヌ – 䞍具合の未然防止のための工皋内バグや過去バグからの仕様・蚭蚈䞊の匱点の抜出ずフロントロヌディング – 開発党䜓を芋通した俯瞰的なQA掻動の把握のためのQAアヌキテクチャの蚘述 – DRなどの䜜業埋め蟌み型教育、OJT、集合教育の融合 © NISHI, YasuharuTS-2 p.24
取り組みぞの萜ずし蟌みの留意点 • コンテキストやフォヌカスず取り組みずは倚察倚の関係になり、 萜ずし蟌みそのものにもコンテキストが圱響し、適甚郚隊ごずに異なるので、 その蚭蚈に゜フトりェア品質保蚌の知的リ゜ヌスを぀ぎ蟌たなくおはならない – 倖郚のメディアや識者は兞型䟋を瀺すだけで、自組織にそのたた適合するこずはほずんどない • 同じ取り組みでも、取り組みの実装によっお成果は倧きく異なるこずを理解する – 自組織の文化や颚土、歎史にあった実装をする方がよいこずが倚い • コンテキストは垞に倉化し移行するものであり、 耇合しお発生し、先読みも必芁になるため、 ゜フトりェア品質保蚌の取り組みを始めれば終わり、ずはならない – Acceleratingの段階からQualifyの段階の取り組みを先読みしお実斜すべき、 ずいったこずは倚々発生する – 䞀床にたくさんの取り組みを珟堎に匷いおも砎綻する • それは珟堎に時間が無いこずが問題ではなく、取り組みぞの萜ずし蟌みや実装の問題である – ゜フトりェア品質保蚌の組織そのものが垞に成長し戊略的に思考しなければならない © NISHI, YasuharuTS-2 p.25
゜フトりェアQAの取り組みを浞透させる • 品質を保蚌するためには、開発珟堎に取り組みを浞透させる必芁がある – 取り組みが浞透しおいるからこそ、違和感ぞの感受性が高たり、 知がスケヌルアりトするので、プロダクトやプロセスがよりよくなっおいく • 取り組みが実斜されおいるが浞透されおいない組織では、 よく分からずに取り組みを手がけおいるため違和感を抌し殺す習慣ができおしたい カむれンサむクルのスピヌドが遅く空転ばかりするので「カむれン疲れ」が発生する – 劎働のスケヌルアップの組織パラダむムにおいおは、 プロセスや手順曞暙準の定矩、実斜確認、ダブルチェック、プロセスメトリクスの盲進 などによっおQAが実珟されおいたが、゜フトりェア開発ではおおむね倱敗する – 知のスケヌルアりトの組織パラダむムにおいおは、 取り組みが浞透し開発珟堎が玍埗感を共感し、自然に動いおいるようQAする – 取り組みの浞透には、取り組みそのものの浞透ず、取り組みで扱う知の浞透がある • 「なぜそれをやるのか」ず「䜕をやっおいるのか」の䞡方に玍埗し共感しおいなければ、 よい開発などできるわけがない © NISHI, YasuharuTS-2 p.26
゜フトりェアQAの取り組みを浞透させる • 取り組みそのものの浞透「我々はなぜそれをやるのか」 – たず倧事なこずは、組織パラダむム、組織党䜓における䟡倀芳や品質のパッケヌゞ、 ビゞネス゚ッセンス、組織目暙、コンテキストを開発珟堎が玍埗し共感するこずである • 経営陣からの、䌁業理念やトップの蚀葉などによる明瀺的なメッセヌゞや、 人事斜策や組織蚭蚈などによる暗黙的なメッセヌゞが 組織パラダむムなどに䞀臎しおいるこずをQAする • 経営陣からのメッセヌゞを「あヌでもないこヌでもない」ず開発珟堎でかみ砕き、 経営陣ずの反埩的なフィヌドバックや盎接察話などによっお玍埗感を共感できおいるようQAする – 組織文化を醞成しおいるこずを意識するずよい – 組織なりの方蚀があるず玍埗感を共感しやすい気がする • 「これは瀟の方針だから」「これは業務呜什だから」ず抌し぀けおはいけない – しかし手段が目的化した株匏公開などが瀟の方針に – 次に、自分たちの組織目暙やコンテキストを基に、 どのようにフォヌカスを定めどのようにその取り組みに萜ずし蟌んだか、 を開発珟堎が玍埗し共感する必芁がある • 萜ずし蟌みの段階から玍埗感が共感されおいる必芁があるのは蚀うたでもない • 萜ずし蟌みに参画しなかった゚ンゞニアずも「あヌでもないこヌでもない」ず 議論したり䞍満をぶちたけたり思いをぶ぀けあったりしながら玍埗感を共感しおいく © NISHI, YasuharuTS-2 p.27
゜フトりェアQAの取り組みを浞透させる • 取り組みで扱う知の浞透「我々は䜕をやっおいるのか」 – 開発では様々な工皋や䜜業があり、様々な知が飛び亀っおいる • ゜フトりェア開発では、圢匏知化されうるものも、圢匏知化できるが暗黙知のたた留たるものも、 本質的に暗黙知でしか存圚ものも、混圚しおいる – 党おの知を圢匏知化させお浞透させるには限界がある – 劎働のスケヌルアップの考え方は基本的に • どうすれば䞊手くいくかを手順化できない工皋や䜜業がたくさんある – 劎働のスケヌルアップの考え方に基づくQAずはここが倧きく異なる • 反埩的に成長しおいく知がたくさんある – 様々な知を共有し玍埗し共感するこずを、日々の開発䜜業に埋め蟌む • 無駄な圢匏知化をしないよう、どの知をどの範囲で共有するかをしっかり考える • 玍埗し共感できるたで反埩し、反埩し、反埩する – 反埩は違和感を感じ取るトリガになる • 圢匏知化できるほど知がたずたっおおり、圢匏知化できる技術が高く、 圢匏知を自分の呚りの具䜓䟋に詳现化する力が高い組織なら、 圢匏知化の掻動に力をいれおもよい • そうでないなら、暗黙知を暗黙知のたた共有する掻動に力を入れながら、少しず぀圢匏知化しおいく • そこかしこに、あヌでもないこヌでもないず議論したり、違和感の感受性ず衚出力を高める仕掛けを入れる • 日々の開発䜜業に埋め蟌たなければすぐにQAは圢骞化し「攟課埌の掃陀」化するこずを理解する – その開発珟堎にずっお「楜しい」埋め蟌みを行う © NISHI, YasuharuTS-2 p.28
゜フトりェアQAの取り組みを浞透させる • 取り組みぞの萜ずし蟌みの留意点 – プロセスは手段であり容れ物でしかない点を匷く意識する • そもそも゜フトりェア開発は「こうすれば䞊手くいく」が蚘述できないため、手順を決めおも䞊手くいかない – ある思考ぞのむンプットずなる知が十分なのか、思考の際の玍埗感の共感が十分なのか、を蚘述する • CMMiやAutomotive SPICEなどのSPIファミリ、機胜安党ファミリ、ISO9000シリヌズなどによる 倖郚審査内郚監査がビゞネス䞊必芁な組織はプロセスが圢骞化しやすいので特に留意する • プロセスを先に定矩するのではなく、たた自瀟プロセスを芏栌に合わせるのではなく、 各組織にずっお知がスケヌルアりトできる進め方をプロセスずしお曞き出すようにする – プロセスに埓うから知がスケヌルアりトするのではなく、 知がスケヌルアりトできおいるから結果ずしおプロセスに沿っおいる、ずいう構図を厩さない – その組織のどこの誰に聞いおも、その䜜業を行うこずのうれしさや行わない時に困りごずを 自然に蚀えるくらい浞透させる • プロセスは䜜業手順のシヌケンスではなく、各䜜業で必芁ずなるノりハりや知恵、勘所、 技術やツヌルずセットになっお始めお掻甚できるこずを理解する – 囜際芏栌などは、議論可胜か぀審査可胜にするためにあえお手順だけを抜き出しお曞いおあり、 それを鵜呑みにするず圢骞化にたっしぐらずなる – メトリクスは手段であり瞮退衚珟でしかない点を匷く意識する • 䜕をメトリクスずしお枬るか、よりも、なぜそのメトリクスを枬るべきか、 そもそも珟堎でどのような良いこず悪いこずがどのようなメカニズムで起きおいるのか、 を理解しなければ、圢骞化にたっしぐらずなる • QAの仮説怜蚌およびカむれンのためにメトリクスは甚いるべきなので、 枬定察象は垞に倉化しおいなければならない、ず理解する – 統蚈屋は枬定察象の安定化カむれンぞの抵抗を蚀い出すが、 母集団分垃も分散も䞍明なサンプルだけから解釈を抜出しようずする時点でそもそも無理がある © NISHI, YasuharuTS-2 p.29
゜フトりェアQAの取り組みを浞透させる • QAの圹割はコンテキストやフォヌカス、プロゞェクトの状況などによっお 異なるこずを理解する – それらを無芖しお党瀟、もしくは事業郚で䞀埋に同じQAの戊略を 同じように進めようずするのはQAの怠慢に過ぎない – コンテキストやフォヌカス、プロゞェクトの状況に合わせるずQAのリ゜ヌスが足りない、 ずいうグチを蚀っおはいけない • リ゜ヌスが足りないのではなく、QAの戊略がどこかおかしいこずを瀺しおいる堎合の方が倚い • リ゜ヌスが足りないのではなく、QAが開発ず玍埗感を共感できおいないので ミッションをシェアできおいないこずを瀺しおいる堎合の方が倚い – QAの圹割を自分たちで定矩しおおくず考えやすい • 実際にテストなどを行うプレむダヌQA • 開発が自分たちでQAしやすくなるように動くサヌバントQA • 開発ずナヌザが乖離しおいる時にその間を぀なぐグルヌQA • リリヌススピヌドずリリヌス時品質リスクずのバランスを取るナビゲヌタQA × 最埌の砊だけを担うフェヌズゲヌトQAは知のスケヌルアりトを阻害する効果の方が倧きい × プロセスを守らせるポリスQAは知のスケヌルアりトを阻害する効果の方が倧きい – QAは知のスケヌルアりトを促進するこずは䜕でもやらなくおはならない • 自分たちで自分たちの掻動のスコヌプを垞に広げようずする方が正しい – 「それはQAの仕事ではない」ずいうセリフが出おきたら、それは䜕かがおかしいこずを瀺しおいる • 開発の劎働の肩代わりや䟿利屋ずなっおはいけない © NISHI, YasuharuTS-2 p.30
FAQ: 「゜フトりェアQAずしお䜕に取り組めばいいですか」 • 「プロセスなんか、もううんざり」 • 「アゞャむルでスクラムでTDDでCIで探玢的テストの時代なんだよ」 • 「ペアプロモブプロKPT」 
 vs. • 「ミッションクリティカルなんだからプロセスは厳密にするのが圓たり前だ」 • 「『枬定なくしお管理なし』ず昔から蚀うのだよ」 • 「PDCAを回しお再発防止シヌトを曞きたたえ」 
 © NISHI, YasuharuTS-2 p.31
FAQ: 「゜フトりェアQAずしお䜕に取り組めばいいですか」 © NISHI, YasuharuTS-2 p.32 䜕に取り組むかが倧事なのではなく、 なぜそれに取り組むか、ず どうそれに取り組みか、 が倧事なのである
© NISHI, Yasuharup.33 QAも゚ンゞニアリングが必芁 QAアヌキテクチャ
「もうバグは無いんだろうな」 • そもそも品質の保蚌っおどうやるんだろう – 枬定すれば性質が把握できるものは、枬定しお性質を把握しお品質を保蚌できる • ただし通垞はある確率分垃に埓うため、確率的保蚌しかできない – どうすれば䜜業が䞊手くいくかを完党に蚘述できるものは、 手順を完璧に曞き䞋し手順の遂行を確認すれば品質を保蚌できる • しかし実はそんな仕事はほが存圚しない、ずいうこずを 劎働スケヌルアップパラダむムの゜フトりェアQAは理解しおいない • ゜フトりェア開発では、枬定や手順による品質の保蚌はできない – ゜フトりェアは知的人工物のため、枬定しおも性質がよく分からない – ゜フトりェア開発は知的䜜業のため、どうすれば䞊手くいくかを蚘述するこずができない • すなわち「もうバグは無いんだろうな」ずいう質問に 「はい、もうありたせん」ずシンプルに答えるこずはできない – そもそもそれは品質の保蚌の話ではなく、誰かが責任回避をしたいだけだったり、 ビゞネス゚ッセンスを理解しおいないので無理ゲヌをしおるだけだったりする • QAはその質問に察しどう答えればよいのか © NISHI, YasuharuTS-2 p.34
゜フトりェアの品質保蚌の考え方 • ゜フトりェアのQAは以䞋の3x5x3=45皮類の保蚌動䜜を 成果物や郚品、工皋などごずに行うトレヌドオフ行為である – ゜フトりェア開発における品質の保蚌は3皮類ある 出力系怜蚌 䜜業のアりトプットがよいかどうか、悪くないかどうかを怜蚌する 入力系保蚌 䜜業のむンプットずしお必芁なものが揃っおいるかを怜蚌する 環境系保蚌 䜜業を遂行する「装眮」である頭脳が最適に働いおくれるような環境条件が敎っおいるこずを怜蚌する – 怜蚌には5レベルある レベル5) 内容を理解しお、きちんずできおいるこずず、ダバそうなこずを防いでいるこずに自信を持぀ レベル4) 内容を理解しお、きちんずできおいるこずに自信を持぀ レベル3) 内容は理解せず、特定の性質だけから定量化しお比范する レベル2) 内容は理解せず性質の把握すら行わないが、トレヌサビリティを確認する レベル1) 内容は理解せず、存圚しおいるこずのみを確認する – 怜蚌の察象には3皮類ある 最終成果物怜蚌 最終成果物そのもの – 動䜜実瞟を積み䞊げるこずはできるが、積み䞊げおない動䜜を倖挿的に予想するこずは難しい ナニット怜蚌 最終成果物を構成する郚品ナニットコンポヌネント矀 – 「合成の誀謬郚品が党お正しくおも組み䞊げたら䞍具合が出る」が発生する可胜性がある 入力・䞭間成果物怜蚌 最終成果物の基ずなる入力成果物䞭間成果物 – 入力成果物ず出力成果物が倚察倚になる堎合、入力成果物のよさは出力成果物のよさを瀺すずは限らない – 䞭間成果物の通りに぀くられるずは限らない © NISHI, YasuharuTS-2 p.35
゜フトりェアの品質保蚌の考え方 • 45皮類の保蚌動䜜を組み合わせたり重ね合わせたりトレヌドオフをするこずで、 ビゞネス゚ッセンスに基づく䟡倀が提䟛できるかどうか自信を持぀行為が ゜フトりェアのQAである – 䟋えば、芁求レビュヌ → 蚭蚈レビュヌ → UT → IT → STずいう䌝統的な゜フトりェアQAは、 入力成果物や出力成果物から再垰的ナニット、最終成果物に察しお出力系怜蚌を行うこずを 意図しおいる • これだけでは入力系怜蚌や環境系怜蚌が䞍足するので、教育やプロセスで補完しおいる – 䟡倀が提䟛できればどのようにトレヌドオフを構成しおも構わない • 入力成果物や䞭間成果物の質が高く、 ゚ンゞニアがモチベヌションや集䞭力を高め垞に玍埗感を共感しおいられる環境があり、 党おのUTを自動化しおおり、構造がシンプルなので合成の誀謬が発生するリスクがずおも䜎く、 䞍具合があっおもすぐに切り戻せる機構があるのなら、E2Eのテストは䞍芁ずいうトレヌドオフをしおもよい – シフトレフトやシフトラむトは目的や朮流なのではなく、トレヌドオフの結果に過ぎない – 䟡倀はプロダクトの質だけではないこずを垞に意識する • TDDは䌝統的なナニットの出力系怜蚌の自動化ず捉えるよりも、 ゚ンゞニアのリズムを䜜り玍埗床を高めるずいったナニットの環境系怜蚌であり、 小さい歩幅ずいう行動様匏に関する出力系怜蚌ず捉える方がよい – そう捉えた堎合、TDDでカバレッゞカバレッゞず求めるのは䞍適切である • © NISHI, YasuharuTS-2 p.36
QAにも゚ンゞニアリングアプロヌチが必芁である • 劎働のスケヌルアップのパラダむムの組織では、 ゜フトりェアQAは「管理屋」になりやすい – 䞀芧衚やマトリクスを䜜り、人間が確認し、曞棚にしたい、印鑑を確認する – ゜フトりェアQAの”担圓者“が「自分のスキルずは䜕か」で悩むケヌスは少なくない • 知のスケヌルアりトのパラダむムの組織では、 ゜フトりェアQAを゚ンゞニアリングずしお捉えるべきである – ゜フトりェアQAは「QA゚ンゞニア」「QAアヌキテクト」などになる – ゜フトりェア開発ず同じように、゚ンゞニアリングスキルが必芁になる • ゜フトスキルももちろん必芁である • ゚ンゞニアリングアプロヌチずは – ゜フトりェア開発ず同じように、゜フトりェアQAもモデルを構築し自動化を進めおいく • モデリングによっお理解が深たり䌝達しやすくなるため、玍埗感を共感しやすくなる • 様々な蚭蚈原則によっおモデルのよさを高めるこずができ、思考を研ぎ柄たすこずができるようになる • モデルを構築するず、デザむンパタヌンずいった゜フトりェア工孊の様々な技術を適甚できるようになる • 自動化を進めるず、人間が頭を䜿うべきずころに人間のリ゜ヌスを集䞭できる • モデリングず自動化を進めるず、ムダな思考や䜜業が自然ず浮き出おくるようになる – ゚ンゞニアリングは属人化の排陀ではないし、枬定の目的化でもない • 属人化を排陀しようずするず必ずスキルの高い人がやりにくくなる • 枬定は前近代におけるデゞタルトランスフォヌメンションの䞀圢態でしかない © NISHI, YasuharuTS-2 p.37
QAぞの゚ンゞニアリングアプロヌチの䟋QAアヌキテクチャ • 成果物や郚品、工皋などに関しお 保蚌動䜜を組み合わせたり重ね合わせたりトレヌドオフをするためには、 党䜓像を俯瞰する必芁がある – QA芳点モデル • プロダクトの品質を保蚌するために知っおおく考えおおく気を぀けおおくべきこずをQA芳点ず呌ぶ – アヌキテクチャ、負荷、同時アクセス、呚蟺機噚、蚭定、性胜、操䜜性、セキュリティなど倚岐に枡る • QA芳点を敎理したものをQA芳点モデルスむヌトず呌ぶ – QA芳点ずいうオブゞェクトを「抜象化」しおクラス図やQFDのように敎理する – 耇数のモデルで分析・衚珟する堎合もある – QAパむプラむンモデル • 工皋に保蚌すべきしおいるQA芳点を察応づけたものをQAパむプラむンモデルず呌ぶ – 蚭蚈やコヌディング、レビュヌ、デプロむ前のテスト、デプロむ埌のテストなどにQA芳点をマッピングする – QA芳点ずいう工皋の「責務」を適切に分担させるようデザむンする – 補造業におけるQC工皋衚やQAネットワヌク保蚌の網である © NISHI, YasuharuTS-2 p.38 SUT
QAアヌキテクチャにおける責務の分担パむプラむン化 © NISHI, YasuharuTS-2 p.39 工皋の責務を敎理するず、どのQA芳点のパむプラむンを 自動化やフロントロヌディングによっお高速化でき、 か぀どの芳点は手動テストで保蚌しなくおはならないのか、 ずいったこずが俯瞰的に把握できるようになる 自動化で velocityを向䞊させ リズムを生み出す
QAアヌキテクチャにおける責務の分担シフトレフト © NISHI, YasuharuTS-2 p.40 工皋の責務を敎理するず、どのQA芳点のパむプラむンを 自動化やフロントロヌディングによっお高速化でき、 か぀どの芳点は手動テストで保蚌しなくおはならないのか、 ずいったこずが俯瞰的に把握できるようになる フロントロヌディングで テストを軜量化し、 自動化でvelocityを向䞊させお リリヌスサむクルを短くする
QAアヌキテクチャにおける責務の分担シフトラむト © NISHI, YasuharuTS-2 p.41 工皋の責務を敎理するず、どのQA芳点のパむプラむンを 自動化やフロントロヌディングによっお高速化でき、 か぀どの芳点は手動テストで保蚌しなくおはならないのか、 ずいったこずが俯瞰的に把握できるようになる リリヌス リリヌス
QAぞの゚ンゞニアリングアプロヌチの䟋SaPID • 管理屋アプロヌチでなぜなぜ分析を行っおも党く圹に立たない – ○○工皋を増やす、ダブルチェックをする、厳しくする、気を぀ける が「根本原因」ずしお頻出し、 たずもな察策が取られるこずは極めお皀である • モデリングを行うず様々なこずが分かる – 問題や原因の埪環構造鶏ず卵が把握できる – 䞀぀の結果には耇数の原因があるこずがあるず分かる – 䞀぀の原因から耇数の結果に぀ながるこずがあるず分かる – 個々の原因→結果の関係が雑なこずが分かる – 「なぜ」の答えは必ずしも原因→結果ずは 限らないこずが分かる – 根本原因にも色々あるこずが分かる – 根本原因ず察策が぀ながっおないこずが分かる © NISHI, YasuharuTS-2 p.42 「システムズアプロヌチに基づくプロセス改善メ゜ッドSaPIDが意図するコト」 http://www.jaspic.org/event/2012/SPIJapan/session3A/3A3_ID009.pdf
テストの意図を゚ンゞニアリングする テスト芳点図によるテスト芁求モデリング
テストにも゚ンゞニアリングアプロヌチが必芁である • 劎働のスケヌルアップのパラダむムの組織では、 ゜フトりェアテスタヌは「軜䜜業掟遣」になりやすい – 䞀芧衚やマトリクスを埋め、人間が絚毯爆撃し、スクショを取り、ずいう賜の河原 – 探玢的テストずいう名で化粧されたド玠人によるモンキヌテストやアドホックテスト • 知のスケヌルアりトのパラダむムの組織では、 ゜フトりェアテストを゚ンゞニアリングずしお捉えるべきである – テスタヌは「テスト゚ンゞニア」「テストアヌキテクト」などになる – ゜フトりェア開発ず同じように、゚ンゞニアリングスキルが必芁になる • ゜フトスキルももちろん必芁である • ゚ンゞニアリングアプロヌチずは – ゜フトりェア開発ず同じように、゜フトりェアテストもモデルを構築し自動化を進めおいく • モデリングによっお理解が深たり䌝達しやすくなるため、玍埗感を共感しやすくなる • 様々な蚭蚈原則によっおモデルのよさを高めるこずができ、思考を研ぎ柄たすこずができるようになる • モデルを構築するず、デザむンパタヌンずいった゜フトりェア工孊の様々な技術を適甚できるようになる • 自動化を進めるず、人間が頭を䜿うべきずころに人間のリ゜ヌスを集䞭できる • モデリングず自動化を進めるず、ムダな思考や䜜業が自然ず浮き出おくるようになる – ゚ンゞニアリングは属人化の排陀ではないし、枬定の目的化でもない • 属人化を排陀しようずするず必ずスキルの高い人がやりにくくなる • 枬定は前近代におけるデゞタルトランスフォヌメンションの䞀圢態でしかない © NISHI, YasuharuTS-2 p.44
テストにも゚ンゞニアリングアプロヌチが必芁である • 䟋えば開発の堎合、゚ンゞニアリングアプロヌチは 趣味で小さいプログラムをいきなりコヌディングするなら䞍芁だが、 きちんずビゞネスずしお倧芏暡な゜フトりェアの開発を行うなら必芁である – コヌディングは、アルゎリズムずプログラミング蚀語を分かっおいればできる • 埓来のテスト蚭蚈も、テスト蚭蚈技法ず文曞フォヌマットを分かっおいればできる • 経隓豊富でセンスのある人が芏暡の小さいプログラムを曞くのであれば別に䞍芁である – ゜フトりェア開発は、芁求を把握し蚭蚈原則を理解・適甚しお、 段階的に詳现化しながら順序立おお反埩的に進めおいく必芁がある • テスト開発も、テスト芁求を把握しテスト蚭蚈原則を理解・適甚しお、 段階的に詳现化しながら順序立おお反埩的に進めおいく必芁がある • ゚ンゞニアリングアプロヌチを取らないず、劎働の集積になっおしたいブラック化する • ゚ンゞニアリングアプロヌチは「属人化の排陀」ではなく、 皆の経隓ずセンスを結集しお゜フトりェアを開発するために必芁な抂念や技術、メ゜ドロゞである • テストの開発のための方法論の䞀぀にVSTePがある – Viewpoint-based Software Test Process – ほかにもHAYST法やゆも぀よメ゜ッドなど色々あり、それぞれに匷みがある © NISHI, YasuharuTS-2 p.45
テストぞの゚ンゞニアリングアプロヌチに必芁なもの • ゚ンゞニアリングアプロヌチを取らないず䜕が起こるか – 知恵が蓄積されない – ゎチャゎチャになる – 考えがふんわりする – 考える範囲が狭くなる – 自動化が進たない – 特定のツヌルやメ゜ドロゞにロックむンされる • テストの゚ンゞニアリングアプロヌチには䜕が必芁か – 知恵を蓄積しお䌝達しやすいアプロヌチ → テストの「知恵」のモデル化 – 責務の分担を適切に行えるアプロヌチ → テストの知恵ず工皋の関係のモデル化 – 抜象化・具䜓化を適切に行えるアプロヌチ → 抜象床を「調敎」できるモデルの導入 – 考えるべきこずを限定しないアプロヌチ → メタモデルず参照モデルの分離 – 自動化すべきこずを切り分けやすいアプロヌチ → 工皋ごずのモデリング察象の抂念の分離 – ツヌルやメ゜ドロゞを仮想化しやすいアプロヌチ → モデルず蚘法、プロセス、ツヌルの分類 © NISHI, YasuharuTS-2 p.46
テストぞの゚ンゞニアリングアプロヌチの䟋VSTeP • 工皋ごずのモデリング察象の抂念の分離「テスト開発プロセス」 – 説明のためにWFで描いおいるが、実際は反埩的に行う方がよい © NISHI, YasuharuTS-2 p.47 テスト アヌキテクチャ 蚭蚈 テスト実斜テスト蚭蚈or テスト蚈画 or テスト実斜準備 テスト芁求の 獲埗ず敎理・ テスト芁求の モデリング テストアヌキテクチャ のモデリング 手動自動 テストスクリプト テスト手順の 蚘述 テスト項目の抜出 テスト 詳现蚭蚈 テスト 実装 テスト 実斜 テスト詳现蚭蚈 モデリングず テストケヌスの 列挙 テスト 芁求分析
テストぞの゚ンゞニアリングアプロヌチの䟋VSTeP • テストケヌスを開発成果物ず捉え、 ゜フトりェア開発ラむフサむクルず ゜フトりェアテスト開発ラむフサむクルを察応させる ゜フト芁求分析  テスト芁求分析 ゜フトアヌキテクチャ蚭蚈  テストアヌキテクチャ蚭蚈 ゜フト詳现蚭蚈  テスト詳现蚭蚈 ゜フト実装  テスト実装 • テストケヌスがどの工皋の成果物かを考えるために、 各ラむフサむクルの成果物を察応させよう ゜フト芁求仕様芁求モデル  テスト芁求仕様芁求モデル ゜フトアヌキテクチャモデル  テストアヌキテクチャモデル ゜フトモゞュヌル蚭蚈  テスト詳现蚭蚈モデルずテストケヌス プログラム  手動自動化テストスクリプトテスト手順 © NISHI, YasuharuTS-2 p.48
テストぞの゚ンゞニアリングアプロヌチの䟋VSTeP • テスト芳点ずテストケヌスずテストスクリプトをきちんず区別する – テスト芳点 • 䜕をテストするのかテストケヌスの意図のみを端的に蚘述したもの – 䟋正䞉角圢 – テストケヌス • そのテスト芳点でテストするのに必芁な倀などのみを特定したもの – 䟋 (1,1,1), (2,2,2), (3,3,3)
 • 䜕らかのテスト詳现蚭蚈モデルに埓っお、䜕らかの網矅基準に沿っおテスト倀が導出される – 䟋 「敎数の蟺から構成される正䞉角圢」だっお立掟なモデルである – 䟋 状態遷移モデルに埓っお、1スむッチカバレッゞ基準で、状態シヌケンスを導出する • テスト詳现蚭蚈モデルが耇数組み合わさるなど耇雑なテストケヌスが必芁なこずもある – テストスクリプトテスト手順 • そのテストケヌスを実行するために必芁な党おが曞かれたもの – 䟋1. PCを起動する 2. マむコンピュヌタからC:Â¥sampleÂ¥Myers.exeを起動する  • 手動でのテスト手順曞の堎合もあれば、自動テストスクリプトの堎合もある • 耇数のテストケヌスを集玄しお䞀぀のテストスクリプトにするこずもある • これらを区別し、異なる文曞に蚘述し、 異なる開発工皋に割り圓おるこずによっお、 テスト芳点のみをじっくり怜蚎するこずができるようになる © NISHI, YasuharuTS-2 p.49
VSTePを分かりやすく理解するず • テスト戊略立案 – STD – AQUAフレヌムワヌクをテストに適甚しよう • 䞀般の「テスト戊略」よりも䞊䜍である点に泚意 • テスト芁求分析 - TRA – テスト芳点を思い浮かべお、線で぀なげよう • テストアヌキテクチャ蚭蚈コンテナ蚭蚈 - TAD – テストコンテナにたずめお䞊べよう • テストアヌキテクチャ蚭蚈フレヌム蚭蚈 – テストケヌスのひな圢テストフレヌムを䜜ろう • テスト詳现蚭蚈 - TDD – テストケヌスのひな圢に具䜓的な倀を入れよう • 普通のやり方ず同じでよい • テスト実装 - TI – テストケヌスをテスト手順に具䜓化しよう • 普通のやり方ず同じでよい © NISHI, YasuharuTS-2 p.50 ざっくり考えお図にするず 芋やすいし敎理しやすい GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
テスト芳点の䟋組蟌みの堎合 • 機胜テスト項目のトリガ – ゜フトずしおの機胜 • 音楜を再生する – 補品党䜓ずしおの機胜 • 走る • パラメヌタ – 明瀺的パラメヌタ • 入力された緯床ず経床 – 暗黙的パラメヌタ • ヘッドの䜍眮 – メタパラメヌタ • ファむルの倧きさ – ファむルの内容 • ファむルの構成、内容 – 信号の電気的ふるたい • チャタリング、なたり • プラットフォヌム・構成 – チップの皮類、ファミリ – メモリやファむルシステムの皮類、速床、信頌性 – OSやミドルりェア – メディア • HDDかDVDか – ネットワヌクず状態 • 皮類 • 䜕ずいく぀぀ながっおいるか – 呚蟺機噚ずその状態 • 倖郚環境 – 比范的倉化しない環境 • 䜍眮、呚囲の干枉物 – 比范的倉化しやすい環境 • 枩床、湿床、光量、電源 TS-2 p.51 © NISHI, Yasuharu テスト芳点はテストケヌスの「意図」を衚しおいる
テスト芳点の䟋組蟌みの堎合 • 状態 – ゜フトりェアの内郚状態 • 初期化凊理䞭か安定動䜜䞭か – ハヌドりェアの状態 • ヘッドの䜍眮 • タむミング – 機胜同士のタむミング – 機胜ずハヌドりェアのタむミング • 性胜 – 最も遅そうな条件は䜕か • 信頌性 – 芁求連続皌働時間 • セキュリティ • GUI・操䜜性 – 操䜜パス、ショヌトカット – 操䜜が犁止される状況は䜕か – ナヌザシナリオ、10モヌド – 操䜜ミス、初心者操䜜、子䟛 • 出荷先 – 電源電圧、気枩、ナヌザの䜿い方 – 蚀語、芏栌、法芏 • 障害察応性 – 察応すべき障害の皮類 • 氎没 – 察応動䜜の皮類 • ハザヌドや䜜り蟌みそうな欠陥 TS-2 p.52 © NISHI, Yasuharu テスト芳点はテストケヌスの「意図」を衚しおいる
テスト芳点図によるテスト芁求分析の䟋 © NISHI, YasuharuTS-2 p.53 どんな意図で テストすべきかを 敎理する GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
NGTによるテスト芳点図の蚘述 • NGT/VSTePではテスト芳点図を䞭心にしお進めおいく – NGT (Notation for Generic Testing) ずいう蚘法を定矩しおいる – テスト芳点を階局的に蚘述しおいく – はテスト芳点、 はテスト察象を衚す – は詳现化関係を衚す – は組み合わせテストの必芁性などテスト芳点間の関連を衚す – は順序䟝存など方向を持った関係を衚す – 新たな関係や詳现な関係を 定矩したり分かりやすくするために <<stereotype>> ステレオタむプを䜿っおもよい • マむンドマップやロゞックツリヌで VSTePを進めおも構わない – UTP2UML Testing Profile 2.0を䜿っお 自動テストアヌキテクチャず 䞀緒にモデリングしおももちろん構わない © NISHI, YasuharuTS-2 p.54 GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
• テスト芁求モデルの党䜓像をどう敎理すればいいか、 に唯䞀絶察の解はない – 仕様ベヌスモデル – 機胜ベヌスモデル – 画面ベヌスモデル – 正垞系異垞系モデル – 品質特性モデル – 䞀般テストタむプモデル – CIBFWモデル • Condition / Item / Behaviour / Fault / World – 䞉銃士モデル • 䞖界芳・コンテキスト・実装ナヌザ感情 • 党䜓像の構造によっお モデリングの質がかなり巊右される テスト芁求モデルの党䜓像の皮類 © NISHI, YasuharuTS-2 p.55
テスト芳点のモデリングのTips • 仕様曞に曞いおある仕様や文、単語を曞き写しおもテスト芳点は網矅できない – 仕様曞は通垞䞍完党でありもしくは存圚せず、特に臎呜的なバグは 仕様曞に曞かれおいないテスト芳点でしか芋぀けられないこずがある • ここたで䟋に挙げたテスト芳点は、皆さんの組織の仕様曞に党お曞いおありたしたか • テスト芳点は倚面的に挙げる – 入力に関するテスト芳点だけを挙げたり、期埅結果やその芳枬に関するテスト芳点 だけを挙げたり、品質特性だけをテスト芳点ずしお採甚するず、挏れが発生する • テスト芳点を挙げただけでバグが芋぀かるこずがある – 開発者が考慮しおいなかったテスト芳点はバグの枩床であり、 テストしなくおもバグだず分かるこずも倚々ある – 期埅結果に関するテスト芳点を挙げたり詳现化するず、仕様の抜けが分かるこずがある • テストケヌスにも期埅結果を必ず曞くのを忘れないこず • 「正しく動䜜するこず」は期埅結果ではない • 網矅した颚のテスト芳点の文曞や玍品物を䜜ろうずせず 網矅しようず倚面的に様々なこずを考え尜くそうずする – あヌでもないこヌでもないずワむワむ議論したアむデアのリポゞトリがテスト芳点図である • 芋逃したバグを芋぀けうるテスト芳点を気軜に远加しお敎理するこずも倧事である – 最初から網矅しようず気匵るず倧事なテスト芳点を芋逃す • そもそも網矅するこずが必芁なのか © NISHI, YasuharuTS-2 p.56
テスト芳点のモデリングのTips • 同じテスト芳点名を皆が同じように理解しおいるずは限らない – 子芳点が明瀺するず理解の霟霬は解消しやすい • 芳点が通り䞀遍で関連が倚いモデルは理解床が䜎いこずが倚い – 䞍安だから責任を取りたくないから組み合わせおおかなきゃ、ず発想しおいるこずが倚い – なぜその関連をテストすべきだず思ったのか、ずいう掘り䞋げを行い、 可胜なら関連をテスト芳点に倉換するず、よりテストの意図が明確になる • 詳现化のステレオタむプを明瀺するずよいモデルを぀くりやすい – その芪ず子はどういう関係なのか、はステレオタむプを明瀺しないず䞍明確になりやすい – 異なるステレオタむプの詳现化が混ざっおいるず網矅しにくい • 抜象床は䞁寧に萜ずしお具䜓化しおいく – 子の数は認知的マゞックナンバヌの範囲内にできるずよい • 網矅できた確信が持おないずころにはノヌトを貌っおおく – モデリングの途䞭では「その他」ずいう䞀時的なテスト芳点を挙げおおいおもよい • 埌で適切な芳点ずしおきちんずモデリングするこず – 抜け萜ちの危険性が消倱するこずが䞀番怖い • 探玢的テストにおけるチャヌタヌの蚘述ずテストの気づいた点の蚘録は テスト芳点モデルを甚いるず衚珟しやすい © NISHI, YasuharuTS-2 p.57
テスト芳点モデルのリファむンのテクニックの䟋 • 様々なリファむンを䜕床も行いながら質の高いモデルに向かっおいく – 網矅化MECE分析 • 子芳点がMECEに列挙されおいるかどうかをレビュヌし、䞍足しおいる子芳点を远加する • MECEにできない堎合、必芁に応じお「その他」の子芳点を远加し非MECEを明瀺する • 子芳点をMECEにできるよう、適切な抜象床の芳点を芪芳点ず子芳点ずの間に远加する – 網矅化ステレオタむプ分析 • MECE性を高めるために、詳现化のステレオタむプを明瀺し子芳点を分類する – 敎理 • 読む人によっお意味の異なるテスト芳点を特定し、名前を倉曎する • テスト芳点や関連の移動、分割、統合、名前の倉曎、パタヌンの適甚、 芳点ず関連ずの倉換、芳点ず網矅基準ずの倉換などを行う • 本圓にその関連が必芁なのかどうかの粟査を行う必芁もある – 剪定 • ズヌムむン・アりト、芳点や関連の芋盎し、網矅基準や組み合わせ基準の緩和によっお、 テスト項目数ずリスクずのトレヌドオフを倧たかに行う – 確定 • 子芳点および関連が党お網矅的に列挙されおいるかどうかをレビュヌするこずで、 テスト芁求モデル党䜓の網矅性を明瀺し、芋逃しリスクを確定する © NISHI, YasuharuTS-2 p.58
• モデリングをせずに行き圓たりばったりでテストをするず テスト芳点図が真っ黒になる – 自分たちがなにをテストしおいるのか、が分かっおいない堎合が倚い テスト芳点図のリファむンの䟋 © NISHI, YasuharuTS-2 p.59
モデリングによっおテストの再利甚性を高める • バヌゞョンごずの仕様の違いを テスト芳点図で敎理するず再利甚しやすくなる © NISHI, YasuharuTS-2 p.60
テストにも アヌキテクチャがある テストアヌキテクチャモデリング
テストコンテナ図によるテストアヌキテクチャ蚭蚈の䟋 © NISHI, YasuharuTS-2 p.62 テストレベルやテストタむプ、 テストサむクルを蚭蚈する
テストレベルやテストタむプは自分たちで蚭蚈するものである © NISHI, YasuharuTS-2 p.63 Difficulty validation by beginner Automated testing for Gacha (gamble) probability Exhaustive automated testing for payment for various items Business model suitability Validation Business model suitability Validation Business model suitability Validation Business model suitability Validation Model of World suitability validation Background Story suitability Validation Equipment and items suitability Validation Movement reality validation User thrill & relax validation Automated testing for wall penetration Addiction validation Distraction validation Resumption validation Various payment verification Mainstream devices verification Minor devices verification SUT update testing Interruption of other apps testing Delightful payment validation Shot&dead timing validation Movement sync. verification Payment security verification Difficulty validation by expert Catharsis validation Buzz-ability validation Platform certification testing Marketing materials suitability verification Balance breaker exploratory testing Competitor comparison verification Compliance verification Complicated payment flow verification Load testing for payment Basic network verification Various network verification Multi server handoff verification Load testing for play
テストレベルやテストタむプは自分たちで蚭蚈するものである © NISHI, YasuharuTS-2 p.64 Difficulty validation by beginner Automated testing for Gacha (gamble) probability Exhaustive automated testing for payment for various items Business model suitability Validation Business model suitability Validation Business model suitability Validation Business model suitability Validation Model of World suitability validation Background Story suitability Validation Equipment and items suitability Validation Movement reality validation User thrill & relax validation Automated testing for wall penetration Addiction validation Distraction validation Resumption validation Various payment verification Mainstream devices verification Minor devices verification SUT update testing Interruption of other apps testing Delightful payment validation Shot&dead timing validation Movement sync. verification Payment security verification Difficulty validation by expert Catharsis validation Buzz-ability validation Platform certification testing Marketing materials suitability verification Balance breaker exploratory testing Competitor comparison verification Compliance verification Complicated payment flow verification Load testing for payment Basic network verification Various network verification Multi server handoff verification Load testing for play Holistic emotional impression test level Particular emotional impression test level Basic env. test level Various env. test level Actual env. test level Real usage test level Monetization test type Business test type
1. Coupling 2. Cohesion 3. Maintainability 4. Automatability 5. Circumstance consistency 6. Development consistency 7. Describability 8. Design direction 9. Design positiveness 10. Execution velocity consistency テストアヌキテクチャ蚭蚈で気にすべき性質 © NISHI, YasuharuTS-2 p.65 性胜枬定 倧芏暡負荷 テスト 負荷分散 機胜確認 テスト DoSアタック テスト 性胜テスト 適切に 「責務の分担」 がなされおいるだろうか
テスト芁求分析やテストアヌキテクチャ蚭蚈で䜕を怜蚎するか • SPLIT – Scope - テストの察象範囲をどこにするか / TRA – Phase - テストのどの段階in dev. / in prod.に焊点を圓おるか / TAD – Level - どのレベルたでオヌトメヌションを進化させるか / TSD&TAD – sIze - 察象の範囲をどう切り分けお実行するか / TAD – Type - どのような皮類の目的でテストを行うか / TRA © NISHI, YasuharuTS-2 p.66 https://logmi.jp/282805 https://thinkit.co.jp/article/13346
テストケヌスを導出する テストフレヌムによるテスト詳现蚭蚈
テストフレヌム図によるテストケヌスの構造の明瀺 • 「テストケヌスの構造」には単玔なものから耇雑なものたで色々ありうる – テストケヌスの構造をテスト芳点で衚したものを「テストフレヌム」ず呌ぶ – 耇雑なテストケヌスが偉いわけでもバグを芋぀けやすいわけでもないこずに 泚意する必芁がある • どのくらい耇雑なテストフレヌムを組むかによっおテスト蚭蚈の良し悪しが倉わるので、 どういうトレヌドオフをどう考えおから、もしくはどういう意図で この耇雑さのテストフレヌムにしたか、はきちんず説明できないずいけない © NISHI, YasuharuTS-2 p.68 【単玔なテストフレヌムの䟋】 【耇雑なテストフレヌムの䟋】
テストフレヌムはテストケヌスのスケルトンである • テストフレヌムの芁玠を芋出しずしお衚を䜜るずテストケヌスになる – テストフレヌムをきちんず考えないず、 「倧項目䞭項目小項目」ずいう芋出しで敎理した気になっおいるけど、 ちっずも敎理されおおらず網矅しにくいテストケヌス衚ができあがる – マむンドマップやUMLツヌルなどを䜵甚するず描きやすいが、 党郚䞀芧衚やマトリクスでも構わない © NISHI, YasuharuTS-2 p.69 【テストフレヌムの䟋】 【テストケヌス衚の䟋】
テスト詳现蚭蚈テスト芳点からテスト倀を網矅する • テスト倀の網矅は以䞋の手順で行う – テスト芳点がどのタむプの「テストモデル」なのかを芋極める • 十分詳现化されたテスト芳点が「テストパラメヌタ」ずなる – 網矅基準カバレッゞ基準を定める – 定めた網矅基準でテストパラメヌタを網矅するようにテスト倀を蚭蚈する • テストモデルのタむプには4぀ある – 範囲タむプ、䞀芧衚タむプ、マトリクスタむプ、グラフタむプ • テスト倀には2皮類あるので泚意する必芁がある – 盎接テスト倀テスト倀が盎接テスト手順の䞀郚テストデヌタずしお実斜できるもの • 䟋 3蟺の長さ (3, 3, 3) – 間接テスト倀テスト倀からさらにテストデヌタを導く必芁があるもの • 䟋 制埡パス – 制埡パスを網矅しお、その埌にそれぞれの制埡パスを通すテストデヌタを䜜成する • テストパラメヌタやテストモデルを特定せずに 闇雲にテストケヌスをあげるのは、質の高いテストずはいえない © NISHI, YasuharuTS-2 p.70
範囲タむプのテストモデルの網矅 • 範囲タむプのテストモデルは、 ある連続した範囲を意味するテスト芳点を網矅する時に甚いる – 䟋 蟺の長さ0以䞊65535以䞋の敎数倀 – 範囲のこずを「同倀クラス」ず呌び、同倀クラスを導出する技法を同倀分割ず呌ぶ • 範囲タむプのテストモデルの網矅基準は以䞋の通り – 党網矅 • 䟋 0, 1, 2, 3, 4, 5, 6, 7 
 100 
 10000 
 65534, 65535 • 挏れは無いが、テスト倀が膚倧になるため珟実的では無い – 境界倀網矅 • 䟋 0, 65535, -1, 65536 • 境界倀分析や境界倀テスト、ドメむンテストなど独立した技法ずしお説明されるこずが倚い • 有効境界倀だけでなく無効境界倀もわすれないこず • 範囲が開いおいる䞊限や䞋限が定たっおいない時は、自分で定める必芁があるが、 よほどよく怜蚎しないず挏れが発生しやすくなる – 代衚倀網矅 • 䟋 3 • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.71
䞀芧衚タむプのテストモデルの網矅 • 䞀芧衚タむプのテストモデルは、 耇数の芁玠からなる集合を意味するテスト芳点を網矅する時に甚いる – 䟋 ブラりザ • 䞀芧衚タむプのテストモデルの網矅基準は以䞋の通り – 党網矅 • 䟋 Chrome, Firefox, Safari, Internet Explorer, Edge • 挏れは無く、通垞はテスト倀もそれほど膚倧にはならないが、 組み合わせになったら無芖できない皋床にテスト倀が倚くなっおしたう – 境界倀網矅 • 䟋 䞀番昔にリリヌスされたブラりザず䞀番最近リリヌスされたブラりザ • 芁玠の䜕らかの属性がある連続した範囲の堎合に その属性の境界倀を持぀芁玠を境界倀芁玠ずみなすこずができなくもないが、 よほどよく怜蚎しないず挏れが発生しやすくなる – 代衚倀網矅 • 䟋 Chrome • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.72
マトリクスタむプのテストモデルの網矅 • マトリクスタむプのテストモデルは、 2぀以䞊のテスト芳点の組み合わせを網矅するずきに甚いる – 䟋 OSずブラりザの組み合わせ – 組み合わせたいテスト芳点の数をここでは段数ず呌ぶ • マトリクスタむプのテストモデルの網矅基準は以䞋の通り – 党網矅 • 䟋 (XP, Chrome), (Vista, Chrome) 
 (Win8.1, Edge, (Win10, Edge) • 挏れは無いが、掛け算によりテスト倀が膚倧になるため珟実的では無い • 犁則無効な組み合わせに泚意する – N-wise網矅 • N+1以䞊の段数の組み合わせの網矅を意図的に無芖するこずによっお、 珟実的な数でNたでの組み合わせを党網矅する方法 • N=2の時をPairwiseず呌ぶ • All-pairsなどN-wise系の網矅手法ず、盎亀配列衚を甚いた網矅手法がある • Nたでの組み合わせの網矅で十分かどうかを怜蚎しないず挏れが発生する – 代衚倀網矅 • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.73
グラフタむプのテストモデルの網矅 • グラフタむプのテストモデルは、 䞞ず線で図が描けるようなテスト芳点を網矅するずきに甚いる – 䟋 プログラムのロゞック、状態遷移図、シヌケンス図、ナヌザシナリオ、地䞋鉄の路線図 • 折れ線グラフや棒グラフのグラフではない – 䞞ず線で描ける図をフロヌグラフ、䞞をノヌド、線をリンク、䞞ず線による経路をパスず呌ぶ • 間接テスト倀になるこずが倚い • 制埡フロヌパステストプログラムのロゞックのテストの堎合は、 if文の耇合刀定条件の真理倀衚の網矅ず組み合わせるこずがあるC2網矅 • グラフタむプのテストモデルの網矅基準は以䞋の通り – 党パス網矅 • 挏れは無いが、テスト倀が膚倧になるため珟実的では無い – MC/DCModified Condition/Decision Coverage • 航空宇宙業界などで䜿われる – Nスむッチ網矅 • 連続するN個のリンクの組み合わせを網矅する方法 / N+1以䞊のスむッチのテスト挏れが発生する – リンク網矅0スむッチ網矅、C1網矅 • グラフのリンクを網矅するようにパスを生成する / 1以䞊のスむッチのテスト挏れが発生する – ノヌド網矅C0網矅 • グラフのノヌドを網矅するようにパスを生成する / リンクのテスト挏れが発生する – 代衚パス網矅 • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.74
講挔の流れ • ゜フトりェアQAの戊略立案  間違った戊略によるQAは必ず倱敗する – 劎働のスケヌルアップから知のスケヌルアりトぞ – 䟡倀芳や品質のパッケヌゞング – AQUAフレヌムワヌク • ゜フトりェアQAの゚ンゞニアリングアプロヌチ  テストの意図を゚ンゞニアリングしよう – QAアヌキテクチャ – テスト芁求分析ずテストアヌキテクチャ蚭蚈 – テストフレヌムずテスト詳现蚭蚈 – VSTeP導入のコツ – 䞍具合モヌドず探玢的テスト – テストの自動化 © NISHI, YasuharuTS-2 p.75
開発ずQAが 䞀䜓ずなっお バグを探す旅をする
ピンポむントなテスト芳点の䟋䞍具合モヌド • ピンポむント型怜出型テストや探玢的テストでは、 バグを分析しおパタヌン化するこずが技術的基盀ずなる – しかしバグ分析を䞊手にできおいる組織は意倖に少ない • 䜕かしらの分析結果は出るが、圹に立たせるこずができない • そもそも珟象なのか原因なのかなど、䜕を分析しおいるか分かっおいない堎合も倚い • 責任远求型の裁刀的犯人捜しの分析䌚議は隠蔜を生むだけで䜕もメリットは無い – バグ分析が䞋手な組織は、なぜなぜ分析やRCA根本原因分析も䞋手である – 同様にFMEAやFTAも䞋手である • 特に゜フトの故障モヌドをきちんず理解しお分析し蓄積しおいる組織はずおも少ない – 故障モヌドが蓄積できおいないず、DRBFMは倉化点解析に成り䞋がっおしたう • モゞュヌルの機胜䞍動䜜・誀動䜜を故障モヌドず捉えおも䞊手にパタヌン化はできない – 挔算間違いや遅延ずいう故障モヌドは圹立぀バグのパタヌンではない – バグのパタヌンをフィヌドバックしおフロントロヌディングしお開発プロセスを 改善したり、教育組織に展開しお教育コンテンツを改善する必芁がある • 䞍具合が䜜り蟌たれやすい仕様・蚭蚈・コヌドのパタヌンを きちんず分析しお蓄積する技術を確立する必芁がある – 䞍具合が䜜り蟌たれやすいコヌドのパタヌンはコヌディングガむドラむンなどから埗られる • 蚭蚈のパタヌンの蓄積は蚭蚈力に䟝存し、仕様のパタヌンの蓄積はより難しい © NISHI, YasuharuTS-2 p.77
䞍具合モヌドによるピンポむントなテストの蚭蚈 • 䞍具合が䜜り蟌たれそうな「匱点」を特定するように、 よく発生する過去のバグを分析しパタヌン化するず、 ゜フトりェア開発のための質のよい「故障モヌドのようなもの」が埗られる – 圓該工皋だけでなく、埌工皋でバグを䜜り蟌む原因ずなりうる郚分もパタヌン化する – QAが備えるべき知恵やスキルである • 開発者がどう間違えるかに着目しお 開発者が陥りやすい「眠」をパタヌン化する – 人間の思考の誀謬ず、誀謬を匕き起こしやすいパタヌンをセットで明らかにする • 䟋埌から远加された䟋倖的な仕様は、蚭蚈挏れを匕き起こしやすい • 䟋優先順䜍の衚珟で1高い5䜎いず5高い1䜎いが混圚するず混同しやすい • 䟋異なるサブシステムでリ゜ヌスの確保・解攟を行うずリヌクしやすい • 䟋「備考」にはバグが倚い – 䌌たようなパタヌンのバリ゚ヌションをツリヌ状に敎理する • 「共感」を軞にしおバグの分析を行う – 適切なパタヌン化ができた瞬間は、分析䌚議の参加者が 「その眠にはみんなひっかかるよね」ず共感するようになる – バグを䜜り蟌んだ人ずいう扱いではなく、 眠の情報を提䟛しおくれる人ずしお尊敬を前面に出すず、前向きの䌚議になっお共感しやすくなる © NISHI, YasuharuTS-2 p.78
䞍具合分析のアンチパタヌンず効果の薄い察策 • Vaporizationその堎限りの簡単なミスずしお片付けおしたう – コヌディングミス スキルを向䞊させるよう教育を行う – 考慮䞍足 しっかり考慮したかどうかレビュヌ時間を増やし確認する – うっかりミス うっかりしおいないかどうかレビュヌ時間を増やし確認する • Exhaustion䞍完党な実斜や単なる䞍足を原因ずしおしたう – しっかりやらない しっかりやったかどうかレビュヌ時間を増やし確認する – スキル䞍足 スキルを向䞊させるよう教育を行う – 経隓䞍足 経隓を補うためにスキルを向䞊させるよう教育を行う • Escalation䞊䜍局に責任を転嫁しおしたう – マネゞメントの責任 トップを含めた品質文化を醞成する • Imposition倖郚組織に責任を転嫁しおしたう – パヌトナヌ䌁業の責任 パヌトナヌ䌁業を含めた品質文化を醞成する • Culturalization文化的問題に垰着しおしたう – 品質意識品質文化の欠劂 党瀟的な品質文化を醞成する © NISHI, YasuharuTS-2 p.79
探玢的テストずは • ゚キスパヌトによる非蚘述的なテストを探玢的テストず呌ぶ – テスト゚ンゞニアが五感ず経隓によっお埗られたパタヌンず感受性を駆䜿するこずで バグを出すこずに集䞭するこずで創造性を発揮するテストの方法である – ゚キスパヌトが探玢しながら孊習しおいくため、事前にしっかりしたテスト蚭蚈は行わない • メモやマむンドマップ、倧たかなテスト芳点図などでアむデアや仮説を思い浮かべおおくこずはある – 「ただ觊るだけ」のモンキヌテストやアドホックテストではない • 玠人に觊らせお品質が向䞊するほどQAは甘くない – 「玠人がしそうな操䜜ミス」「玠人はどう思うか」ずいう明確なテスト芳点に絞る堎合は䟋倖だが、 その堎合でも探玢的テストやアドホックテストずは呌ばない • チャヌタヌずセッションでマネゞメントを行う – 倧たかにどの蟺をテストするか、どんなこずをテストするか、を䌝える「チャヌタヌ」を甚いお マネゞメントを行う • チャヌタヌを现かく曞きすぎるず創造性が枛るし、粗すぎおもマネゞメントできない • チャヌタヌを䜿わないフリヌスタむルずいうやり方もある – テスト゚ンゞニアが集䞭力を高めおおける時間を1぀の「セッション」ずいう単䜍で捉え、 マネゞメントを行う • 60120分皋床ず蚀われおいる © NISHI, YasuharuTS-2 p.80
探玢的テストのポむント • 探玢的テストで䜕に着目するかぱキスパヌトに䟝存する – バグの出そうな仕様や぀くりに着目する人がいる – プロゞェクトの状況や゚ンゞニアの玍埗床に着目する人がいる – バグの出方に着目する人がいる – ナヌザの䜿い方や、そう䜿うずは想像しない䜿い方に着目する人がいる – 出おほしくないバグや起こっおほしくないハザヌド・アクシデントに着目する人がいる – ふるたいの䞀瞬の揺れなど怪しい動䜜に着目する人がいる – などなど • 探玢的テストは䞇胜ではない – 探玢的テストず蚘述的テストは補完させるべきである • 探玢的テストだけでテストを構成するのは極めお危険である – アゞャむルだから探玢的テスト、ず短絡的に考える組織はおそらくアゞャむル開発がちゃんずできおいない • 蚘述的テストを受泚する第3者テスト䌚瀟でも50%近くを探玢的テストで行う堎合もある – 探玢的テスト䞭にテスト゚ンゞニアがテスト察象に぀いお孊習し、 野生に還ったかどうか感受性を鋭敏にしたかどうかをマネゞメントするずよい • 網矅性や䞀貫性などを求めおはいけない – 探玢的テスト埌にテスト゚ンゞニアが仲間ずそのセッションに぀いおおしゃべりするずよい • 孊習した結果や気付いた怪しい動䜜、蚀語化しにくい経隓ベヌスのパタヌン化を蚀語化するチャンスである • 高い感受性で開発者ず察話ができるように心理的安党を確保しおおく必芁がある © NISHI, YasuharuTS-2 p.81
Fully-automated VSTePずは
VSTePのいいずころ • 䞞や四角ず線で絵を描くず゚ンゞニアのように芋える – ゚ンゞニア魂を刺激しお 「自分は軜䜜業掟遣ではなくクリ゚ィティブな゚ンゞニアなんだ」 ず自芚しおもらいモチベヌションを䞊げおもらえる • テスト条件や期埅結果を抜象化しおテストの意図を明瀺するこずで、 党䜓像をコミュニケヌションしやすくなったり知恵を蓄積しやすくなる – プロゞェクト個別の情報を削陀しお、知恵づくりに必芁な情報だけを残すこずができる – 党䜓像を把握しやすいように可芖化されるのでコミュニケヌションしやすくなる – 知恵の質がモデルによっお比范可胜になる – ゜フトりェア゚ンゞニアリングの様々な技術を応甚しやすくなる – テストだけでなく、レビュヌや開発䞊流も含めた開発考慮事項を蓄積できるようになる • 頭を䜿うずころず手を動かせばいいずころを明確に分離できる – 違う頭を䜿うずころは異なる工皋になっおいる – 頭を䜿うこずを鍛えるずいう意識が無いず、テストがよくならない • 銀の匟䞞を求めおいる組織には向いおいない – 単玔䜜業は自動化するこずに頭を䜿うようにする © NISHI, YasuharuTS-2 p.83
反埩開発におけるVSTePのコツ • むテレヌションごずに テスト芁求モデルずテストアヌキテクチャモデルを反埩的に改善しおいきながら、 むテレヌションナビゲヌションを行う – むテレヌションごずに䜕をテストするのかを、テストコンテナ図を地図のように䜿っおナビゲヌションしおいく • テストケヌスずしお実行したテスト芳点の皮類ず網矅床、バグの出方、 開発者の理解床・玍埗床などによっお次に䜕をするかを動的に決める • コンテナに色を぀けおいくず盎感的になる – 最初は曖昧なコンテナ図になっおも構わないが、進むに埓っお地図の粟床を䞊げおいく – 埌半は暪䞲を通すようなテストが増えおくるため、むテレヌションごずの開発芏暡を枛らすか、 テストチヌムによるテスト甚のむテレヌションを぀くるか、などの遞択が必芁になるので、 コンテナ図を甚いるなどしお早めに予想しお事前に仮刀断しおおく • 1回のむテレヌションコンテナに、スクリプトテストず探玢的テストを䞡方入れる – スクリプトテストの深掘り的な探玢ばかりするず仕様の埌远いになりがちでよくない – むテレヌションの時期に応じおスクリプトテストず探玢的テストのバランスを倉える • バグの状況が把握しやすく䜙裕がある時は“スクリプト重→探玢重→スクリプト重”のパタヌンで、 把握しにくく䜙裕が無い時は“探玢重→スクリプト重→探玢重”のパタヌンになる • 1回のむテレヌションで必ずテスト芳点リフレクションの時間を取る – リフレクションによっおテスト芳点図やテストコンテナ図を曞き換えお曞き加えおいく – モデルの質を高く保っおおかないずすぐに䜕をテストしおいるのか分からなくなる © NISHI, YasuharuTS-2 p.84
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
LINE Developer Meetup in Tokyo #39 Presentation
1 of 90

LINE Developer Meetup in Tokyo #39 Presentation

••
Software

A presentation for LINE Developer Meetup in Tokyo #39 on paradigm shift to and testing methodology for modern software development.

Yasuharu Nishi
Yasuharu Nishi電気通信倧孊

Recommended

Re-collection of embedded software qa in the last decade by
Re-collection of embedded software qa in the last decadeRe-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeYasuharu Nishi
5.3K views•89 slides
゚ムスリヌのQAチヌムが目指すもの by
゚ムスリヌのQAチヌムが目指すもの゚ムスリヌのQAチヌムが目指すもの
゚ムスリヌのQAチヌムが目指すものYuki Shiromoto
6.3K views•36 slides
modern software qa - draft 1 by
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1Yasuharu Nishi
3.7K views•30 slides
What should you shift left by
What should you shift leftWhat should you shift left
What should you shift leftYasuharu Nishi
1.8K views•27 slides
車茉゜フトりェアの品質保蚌のこれから by
車茉゜フトりェアの品質保蚌のこれから車茉゜フトりェアの品質保蚌のこれから
車茉゜フトりェアの品質保蚌のこれからYasuharu Nishi
2.7K views•26 slides
テスト芳点に基づくテスト開発方法論 VSTePの抂芁 by
テスト芳点に基づくテスト開発方法論 VSTePの抂芁テスト芳点に基づくテスト開発方法論 VSTePの抂芁
テスト芳点に基づくテスト開発方法論 VSTePの抂芁Yasuharu Nishi
9.6K views•69 slides

More Related Content

What's hot

What is quality culture? Is it something tasty? by
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?Yasuharu Nishi
1.8K views•17 slides
クラシフィケヌション・ツリヌ法入門 by
クラシフィケヌション・ツリヌ法入門クラシフィケヌション・ツリヌ法入門
クラシフィケヌション・ツリヌ法入門H Iseri
21.9K views•44 slides
Software-company Transformation by
Software-company TransformationSoftware-company Transformation
Software-company TransformationYasuharu Nishi
918 views•24 slides
What is quality engineer? Is it something tasty? by
What is quality engineer? Is it something tasty?What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?Yasuharu Nishi
4.1K views•22 slides
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう by
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしようYasuharu Nishi
5.7K views•28 slides
QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌 by
QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌
QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌Yasuharu Nishi
24.9K views•95 slides

What's hot(20)

What is quality culture? Is it something tasty? by Yasuharu Nishi
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?
Yasuharu Nishi•1.8K views
クラシフィケヌション・ツリヌ法入門 by H Iseri
クラシフィケヌション・ツリヌ法入門クラシフィケヌション・ツリヌ法入門
クラシフィケヌション・ツリヌ法入門
H Iseri•21.9K views
Software-company Transformation by Yasuharu Nishi
Software-company TransformationSoftware-company Transformation
Software-company Transformation
Yasuharu Nishi•918 views
What is quality engineer? Is it something tasty? by Yasuharu Nishi
What is quality engineer? Is it something tasty?What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
Yasuharu Nishi•4.1K views
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう by Yasuharu Nishi
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう
日本のテスト産業の囜際競争力 日本を゜フトりェアテスト立囜にしよう
Yasuharu Nishi•5.7K views
QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌 by Yasuharu Nishi
QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌
QAアヌキテクチャの蚭蚈による 説明責任の高いテスト・品質保蚌
Yasuharu Nishi•24.9K views
Agile Quality アゞャむル品質パタヌン (QA2AQ) by Hironori Washizaki
Agile Quality アゞャむル品質パタヌン (QA2AQ)Agile Quality アゞャむル品質パタヌン (QA2AQ)
Agile Quality アゞャむル品質パタヌン (QA2AQ)
Hironori Washizaki•6.5K views
JaSST'15 Tokyo 初心者向けチュヌトリアル -初心者からの脱出- by 厇 山
JaSST'15 Tokyo 初心者向けチュヌトリアル -初心者からの脱出-JaSST'15 Tokyo 初心者向けチュヌトリアル -初心者からの脱出-
JaSST'15 Tokyo 初心者向けチュヌトリアル -初心者からの脱出-
厇 山•4K views
テストの組み立お方 by kauji0522
テストの組み立お方テストの組み立お方
テストの組み立お方
kauji0522•4.5K views
テストを分類しおみよう! by Kenji Okumura
テストを分類しおみよう!テストを分類しおみよう!
テストを分類しおみよう!
Kenji Okumura•29K views
Software Frontloading and QA by Yasuharu Nishi
Software Frontloading and QASoftware Frontloading and QA
Software Frontloading and QA
Yasuharu Nishi•7.3K views
Is No More QA Idealist Practical and Something Tasty? by Yasuharu Nishi
Is No More QA Idealist Practical and Something Tasty?Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?
Yasuharu Nishi•1.2K views
゜フトりェアの品質保蚌の基瀎ずこれから by Yasuharu Nishi
゜フトりェアの品質保蚌の基瀎ずこれから゜フトりェアの品質保蚌の基瀎ずこれから
゜フトりェアの品質保蚌の基瀎ずこれから
Yasuharu Nishi•21.9K views
Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿 by Yasuharu Nishi
Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿
Tomorrow's software testing for embedded systems 明日にでも蚪れおしたう組蟌みシステムのテストの姿
Yasuharu Nishi•3.5K views
゜フトハりスの品質保蚌のり゜ホント by Yasuharu Nishi
゜フトハりスの品質保蚌のり゜ホント゜フトハりスの品質保蚌のり゜ホント
゜フトハりスの品質保蚌のり゜ホント
Yasuharu Nishi•5.8K views
パタヌン QA to AQ: 䌝統的品質保蚌Quality Assuranceからアゞャむル品質Agile Qualityぞ by Hironori Washizaki
パタヌン QA to AQ: 䌝統的品質保蚌Quality Assuranceからアゞャむル品質Agile Qualityぞパタヌン QA to AQ: 䌝統的品質保蚌Quality Assuranceからアゞャむル品質Agile Qualityぞ
パタヌン QA to AQ: 䌝統的品質保蚌Quality Assuranceからアゞャむル品質Agile Qualityぞ
Hironori Washizaki•3.1K views
Paradigm shifts in QA for AI products by Yasuharu Nishi
Paradigm shifts in QA for AI productsParadigm shifts in QA for AI products
Paradigm shifts in QA for AI products
Yasuharu Nishi•599 views
テスト分析・蚭蚈を䜓感しよう マむンドマップを掻甚しおテスト芳点を発想しよう by Akira Ikeda
テスト分析・蚭蚈を䜓感しよう マむンドマップを掻甚しおテスト芳点を発想しようテスト分析・蚭蚈を䜓感しよう マむンドマップを掻甚しおテスト芳点を発想しよう
テスト分析・蚭蚈を䜓感しよう マむンドマップを掻甚しおテスト芳点を発想しよう
Akira Ikeda•9.1K views
60分お゙わかった気になるISO29119 #wacate by Kinji Akemine
60分お゙わかった気になるISO29119 #wacate60分お゙わかった気になるISO29119 #wacate
60分お゙わかった気になるISO29119 #wacate
Kinji Akemine•19.5K views
探玢的テスト入門 by H Iseri
探玢的テスト入門探玢的テスト入門
探玢的テスト入門
H Iseri•31.4K views

Similar to LINE Developer Meetup in Tokyo #39 Presentation

リヌン原則ず゜フトりェア開発 by
リヌン原則ず゜フトりェア開発リヌン原則ず゜フトりェア開発
リヌン原則ず゜フトりェア開発
2.3K views•40 slides
リヌンスタヌトアップ、アゞャむル開発導入事䟋 by
リヌンスタヌトアップ、アゞャむル開発導入事䟋リヌンスタヌトアップ、アゞャむル開発導入事䟋
リヌンスタヌトアップ、アゞャむル開発導入事䟋Arata Fujimura
3.7K views•82 slides
ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門 by
ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門
ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門陜䞀 滝川
14.1K views•137 slides
DeNA QA night #2 presentation by
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentationYasuharu Nishi
17.9K views•13 slides
はじめおのテスト技法 by
はじめおのテスト技法はじめおのテスト技法
はじめおのテスト技法Tatsuya Saito
1.9K views•15 slides
デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕 by
デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕
デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕Developers Summit
2.7K views•32 slides

Similar to LINE Developer Meetup in Tokyo #39 Presentation(20)

リヌン原則ず゜フトりェア開発 by 
リヌン原則ず゜フトりェア開発リヌン原則ず゜フトりェア開発
リヌン原則ず゜フトりェア開発
•2.3K views
リヌンスタヌトアップ、アゞャむル開発導入事䟋 by Arata Fujimura
リヌンスタヌトアップ、アゞャむル開発導入事䟋リヌンスタヌトアップ、アゞャむル開発導入事䟋
リヌンスタヌトアップ、アゞャむル開発導入事䟋
Arata Fujimura•3.7K views
ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門 by 陜䞀 滝川
ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門
ずりあえず30分お゙ひずずおり分かった気にはなれるアジャむル入門
陜䞀 滝川•14.1K views
DeNA QA night #2 presentation by Yasuharu Nishi
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
Yasuharu Nishi•17.9K views
はじめおのテスト技法 by Tatsuya Saito
はじめおのテスト技法はじめおのテスト技法
はじめおのテスト技法
Tatsuya Saito•1.9K views
デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕 by Developers Summit
デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕
デブサミ2014【13-B-L】テスト自動化を芋盎そう自動化ぞの投資が開発チヌムをクリ゚むティブにする安竹由起倫〔コベリティゞャパン〕
Developers Summit•2.7K views
地図を捚おおコンパスを頌りに進め by Dai FUJIHARA
地図を捚おおコンパスを頌りに進め地図を捚おおコンパスを頌りに進め
地図を捚おおコンパスを頌りに進め
Dai FUJIHARA•7.5K views
地図を捚おおコンパスを頌りに進め by Rakuten Group, Inc.
地図を捚おおコンパスを頌りに進め地図を捚おおコンパスを頌りに進め
地図を捚おおコンパスを頌りに進め
Rakuten Group, Inc.•1.7K views
CEDEC2015講挔 チヌム開発をスムヌズにするために by Takafumi Ikeda
CEDEC2015講挔 チヌム開発をスムヌズにするためにCEDEC2015講挔 チヌム開発をスムヌズにするために
CEDEC2015講挔 チヌム開発をスムヌズにするために
Takafumi Ikeda•12.7K views
「事実にもずづく管理」による゜フトりェア品質の改善  ヒンシツ倧孊 Evening Talk #04 by Makoto Nonaka
「事実にもずづく管理」による゜フトりェア品質の改善  ヒンシツ倧孊 Evening Talk #04「事実にもずづく管理」による゜フトりェア品質の改善  ヒンシツ倧孊 Evening Talk #04
「事実にもずづく管理」による゜フトりェア品質の改善  ヒンシツ倧孊 Evening Talk #04
Makoto Nonaka•4.6K views
Scrum,Test,Metrics #sgt2016 by kyon mm
Scrum,Test,Metrics #sgt2016Scrum,Test,Metrics #sgt2016
Scrum,Test,Metrics #sgt2016
kyon mm•20.2K views
むノベヌションスプリント2011 infragisticsにおける䞖界分散アゞャむル開発事䟋 communication matters  by InnovationSprint2011
むノベヌションスプリント2011 infragisticsにおける䞖界分散アゞャむル開発事䟋 communication matters むノベヌションスプリント2011 infragisticsにおける䞖界分散アゞャむル開発事䟋 communication matters 
むノベヌションスプリント2011 infragisticsにおける䞖界分散アゞャむル開発事䟋 communication matters 
InnovationSprint2011•1K views
公開資料 バグレポヌトの改善に向けた問題事䟋の調査ずアンチパタヌンの䜜成 Rev10 by しょうご すずき
公開資料 バグレポヌトの改善に向けた問題事䟋の調査ずアンチパタヌンの䜜成 Rev10公開資料 バグレポヌトの改善に向けた問題事䟋の調査ずアンチパタヌンの䜜成 Rev10
公開資料 バグレポヌトの改善に向けた問題事䟋の調査ずアンチパタヌンの䜜成 Rev10
しょうご すずき•1.7K views
XP祭り関西2011 森厎 修叞「プラクティスが有効にはたらく前提は明らかになっおいたすか」 by Shuji Morisaki
XP祭り関西2011 森厎 修叞「プラクティスが有効にはたらく前提は明らかになっおいたすか」XP祭り関西2011 森厎 修叞「プラクティスが有効にはたらく前提は明らかになっおいたすか」
XP祭り関西2011 森厎 修叞「プラクティスが有効にはたらく前提は明らかになっおいたすか」
Shuji Morisaki•1.6K views
研修担圓者に聞く、孊生のうちに孊ぶべきこず by Hiromu Shioya
研修担圓者に聞く、孊生のうちに孊ぶべきこず研修担圓者に聞く、孊生のうちに孊ぶべきこず
研修担圓者に聞く、孊生のうちに孊ぶべきこず
Hiromu Shioya•1.4K views
AgileTourOsaka2011 関係者に理解しおもらえるアゞャむル開発にむけお by Shuji Morisaki
AgileTourOsaka2011 関係者に理解しおもらえるアゞャむル開発にむけおAgileTourOsaka2011 関係者に理解しおもらえるアゞャむル開発にむけお
AgileTourOsaka2011 関係者に理解しおもらえるアゞャむル開発にむけお
Shuji Morisaki•1.6K views
倧芏暡゜フトりェア開発ずテストの経隓に぀いお by Rakuten Group, Inc.
倧芏暡゜フトりェア開発ずテストの経隓に぀いお倧芏暡゜フトりェア開発ずテストの経隓に぀いお
倧芏暡゜フトりェア開発ずテストの経隓に぀いお
Rakuten Group, Inc.•4.8K views
2015/10/14 JJUGナむトセミナヌ「テスト駆動開発ここが聞きたい」 by Hiroyuki Ohnaka
2015/10/14 JJUGナむトセミナヌ「テスト駆動開発ここが聞きたい」2015/10/14 JJUGナむトセミナヌ「テスト駆動開発ここが聞きたい」
2015/10/14 JJUGナむトセミナヌ「テスト駆動開発ここが聞きたい」
Hiroyuki Ohnaka•6.2K views
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation by Kenji Hiranabe
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese TranslationEric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Eric Ries at Startup Lessons Learned sllconf 2011 - Japanese Translation
Kenji Hiranabe•32.9K views
コミュニケヌションスキルを重芖した゜フトりェア技術者教育手法の研究 by Yuichiro Saito
コミュニケヌションスキルを重芖した゜フトりェア技術者教育手法の研究コミュニケヌションスキルを重芖した゜フトりェア技術者教育手法の研究
コミュニケヌションスキルを重芖した゜フトりェア技術者教育手法の研究
Yuichiro Saito•7.3K views

More from Yasuharu Nishi

Demystifying quality management for large scale manufacturing in modern context by
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextYasuharu Nishi
4.1K views•30 slides
CommentScreeen is good by
CommentScreeen is goodCommentScreeen is good
CommentScreeen is goodYasuharu Nishi
298 views•7 slides
Demystifying quality management for large scale manufacturing in modern context by
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextYasuharu Nishi
1.1K views•28 slides
Teaser - Re-collection of embedded software QA in the last decade by
Teaser - Re-collection of embedded software QA in the last decadeTeaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decadeYasuharu Nishi
733 views•13 slides
Tomorrow's software testing for embedded systems by
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsYasuharu Nishi
2.7K views•22 slides
QA4AI JaSST Tokyo 2019 by
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019Yasuharu Nishi
7K views•33 slides

More from Yasuharu Nishi(11)

Demystifying quality management for large scale manufacturing in modern context by Yasuharu Nishi
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
Yasuharu Nishi•4.1K views
CommentScreeen is good by Yasuharu Nishi
CommentScreeen is goodCommentScreeen is good
CommentScreeen is good
Yasuharu Nishi•298 views
Demystifying quality management for large scale manufacturing in modern context by Yasuharu Nishi
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
Yasuharu Nishi•1.1K views
Teaser - Re-collection of embedded software QA in the last decade by Yasuharu Nishi
Teaser - Re-collection of embedded software QA in the last decadeTeaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decade
Yasuharu Nishi•733 views
Tomorrow's software testing for embedded systems by Yasuharu Nishi
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systems
Yasuharu Nishi•2.7K views
QA4AI JaSST Tokyo 2019 by Yasuharu Nishi
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019
Yasuharu Nishi•7K views
LINE Developer Meetup in Tokyo #39 Trailer by Yasuharu Nishi
LINE Developer Meetup in Tokyo #39 TrailerLINE Developer Meetup in Tokyo #39 Trailer
LINE Developer Meetup in Tokyo #39 Trailer
Yasuharu Nishi•1.3K views
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D... by Yasuharu Nishi
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D... Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Viewpoint-based Test Requirement Analysis Modeling and Test Architectural D...
Yasuharu Nishi•4K views
IoT時代ず第3者怜蚌 by Yasuharu Nishi
IoT時代ず第3者怜蚌IoT時代ず第3者怜蚌
IoT時代ず第3者怜蚌
Yasuharu Nishi•1.9K views
同倀分割っおなんだろう by Yasuharu Nishi
同倀分割っおなんだろう同倀分割っおなんだろう
同倀分割っおなんだろう
Yasuharu Nishi•3.2K views
ちょっず明日のテストの話をしよう by Yasuharu Nishi
ちょっず明日のテストの話をしようちょっず明日のテストの話をしよう
ちょっず明日のテストの話をしよう
Yasuharu Nishi•7.6K views

LINE Developer Meetup in Tokyo #39 Presentation

  • 1. むマドキの゜フトりェアのテストやQAの考え方 LINE Developer Meetup in Tokyo #39 Testing & Engineering 2018/6/27氎 電気通信倧孊 倧孊院情報理工孊研究科 情報孊専攻 経営・瀟䌚情報孊プログラム 西 康晎 @YasuharuNishi / Yasuharu.Nishi@uec.ac.jp
  • 2. Profile • Assistant professor: – the University of Electro-Communications, Tokyo, Japan • President: – Association of Software Test Engineering, Japan - Nonprofit organization (ASTER) • President: – Japan Software Testing Qualifications Board (JSTQB) • National delegate: – ISO/IEC JTC1/SC7/WG26 Software testing (ISO/IEC(/IEEE) 29119, 33063, 20246) • Founder: – Japan Symposium on Software Testing (JaSST) • Founder: – Testing Engineers’ Forum (TEF: Japanese community on software testing) • Judgement Panel Chair / member: – Test Design Contest Japan, Test Design Competition Malaysia (TDC) • Vice chair: – Software Quality Committee of JUSE (SQiP) • Vice chair: – Society of Embedded Software Skill Acquisition for Managers and Engineers (SESSAME) • Organizer – QA4AI Consortium • Advisor: – Software Testing Automation Research group (STAR) © NISHI, YasuharuTS-2 p.2
  • 3. 講挔の流れ • ゜フトりェアQAの戊略立案  間違った戊略によるQAは必ず倱敗する – 劎働のスケヌルアップから知のスケヌルアりトぞ – 䟡倀芳や品質のパッケヌゞング – AQUAフレヌムワヌク • ゜フトりェアQAの゚ンゞニアリングアプロヌチ  テストの意図を゚ンゞニアリングしよう – QAアヌキテクチャ – テスト芁求分析ずテストアヌキテクチャ蚭蚈 – テストフレヌムずテスト詳现蚭蚈 – VSTeP導入のコツ – 䞍具合モヌドず探玢的テスト – テストの自動化 © NISHI, YasuharuTS-2 p.3
  • 5. 日本䌁業を取り巻く状況パラダむムシフトぞの远埓 • 劎働のスケヌルアップから知のスケヌルアりトぞ – 劎働のスケヌルアップ • 暙準化、プロセス定矩、手順の確認・ダブルチェック、ムダ取り、䌑憩の圧瞮、 考えるこずの排陀・局所化、掟遣化、オフショアリング、アりト゜ヌシング、有識者の掻甚  • スケヌルアップなので䞀郚の人に負担が倧きくなり、スケヌルにより管理コストが増倧しおサチる – 知のスケヌルアりト • 䞀぀䞀぀の知の質を高める → より本質的な䟡倀に近づける、正解がないので早くたくさん倱敗しお孊ぶ • 䞀぀䞀぀の知を確かにする → 玍埗感の共感アゞャむル • 知でないものを取り陀く → 単玔䜜業の機械化CI • 知の匷化サむクルを぀くる → 正しいカむれンサむクル、違和感のアンドン化、フロントロヌディング • 知を広げる → 倖プロセスずの接続による党䜓最適Industrie4.0、デゞタルツむンDX、モゞュヌル化 • 倖から知を集める → 技術の民䞻化、OSS、オヌプンむノベヌション • スケヌルアりトした知を圧瞮する → IoTビッグデヌタAI • 個々の取り組みだけに囚われるず鶏ず卵になりうたく進めない – 劎働のスケヌルアップ的パラダむムでIndustrie4.0を捉えるず 単なるセンサ付き補造蚭備にしか芋えず、 旧来の開発を無理にスケヌルアップする矜目になる – オヌプンむノベヌションを倧孊ず始めおも論文ばかり曞こうずされお珟堎に圹立おられない © NISHI, YasuharuTS-2 p.5
  • 7. 間違った戊略に基づいた品質保蚌は倱敗する • 間違った戊略に基づいた品質保蚌は、どう珟堎が頑匵っおも必然的に倱敗する – 自組織は劎働のスケヌルアップに基づいた経営をしおいないか • 単玔な「補造業䌁業は゜フトりェア䌁業になれ」「Googleは偉い」論ではない点に泚意するこず • 「属人化の排陀」「スキルはカネで買える」「責任分解点」などを頻繁に口にする組織が倚い – ゜フトりェア開発は劎働のスケヌルアップだず捉えおいないか • りォヌタヌフォヌルなど個別の取り組みが悪いのではない – 知のスケヌルアりトのための個別のアクティビティバズワヌドに振り回されおいないか • アゞャむル開発における品質保蚌やテストはどうするのか、ず考えるので答えが出ない • 劎働のスケヌルアップを保蚌する掻動はおおむね倱敗するずいうこずが、 ここ510幎の日本の補造業および゜フトりェア産業の経隓則である – 個々の技法や仕組みが劎働のスケヌルアップ的パラダむムを招いたのではなく、 それぞれの技法や仕組みを劎働のスケヌルアップ的に䜿っおきたのが問題である • 日本䌁業はどうしおも劎働のスケヌルアップずいう発想で品質保蚌をしおしたいやすい • ハヌドりェアの蚭蚈や品質保蚌は知のスケヌルアりトをしようずしおいおも、 ゜フトりェアの開発や品質保蚌がそれを理解せずに劎働のスケヌルアップずしお衚面的に真䌌おしたう – 欧米で知のスケヌルアりトをしようずしおいる䌚瀟を芋おも 真䌌ができないし、意味すら分からないこずさえある © NISHI, YasuharuTS-2 p.7
  • 8. 品質保蚌戊略ではないもの、あれこれ • そもそも品質保蚌に戊略などない – 「うちは各補品で党然違うみんな垞駐なので、 党瀟ずしおの品質保蚌戊略なんお考えようがないのですよ」 • それは品質ではない – 「そもそも営業が無理な案件を受泚しおいたのが品質䜎䞋の原因なので、 案件受泚審査を厳しくするずいうのが品質保蚌戊略です」 • スロヌガン – 「品質こそ我が瀟のブランド、ずいうのが品質保蚌戊略です」 • 目暙数倀 – 「5幎で品質を倍にする、のが品質保蚌戊略です」 • 組織構造・䜓制図・暩限 – 「これがISO9000甚に描いた䜓制図で、品質保蚌戊略を衚しおいたす」 • アむデンティティの確保 – 「品質保蚌郚の地䜍や発蚀力の向䞊です」 • 機胜や取り組みを䞊べたもの – 「プロセス改善、レビュヌ、テスト、メトリクスが品質保蚌戊略の軞です」 – 「XDDPずHAYST法ずAutomotive SPICEが品質保蚌戊略の構成芁玠です」 • 個別の取り組み – 「䞍具合率算出の粟床向䞊のために○△分析をするこずにしたした」 © NISHI, YasuharuTS-2 p.8
  • 9. 間違った戊略に基づく組蟌みの゜フトりェアQAの闇 • いきなり自組織の問題点を珟堎で掗い出そうずするずこんなものが挙がる – それはそうなんだけど、これではにっちもさっちもいかないよな  • 「PCが遅いです」 • 「窓やトむレが汚いです」 • 「残業が倚いです」 • 「絊料が安いです」 • 「なんかみんな幞せそうに芋えたせん」 • 自組織の状況や問題点を適切に把握できないたた 「品質保蚌戊略ではないもの」に埓っお品質保蚌を始めるが、 圓然ながら成果は出ない – 二蚀目には「品質保蚌のリ゜ヌスが足りなくお」ずグチを垂れる • 成果の出ない品質保蚌ずいう「劎働」を抌し぀けられる珟堎にそっぜを向かれる – 盲埓しおモチベヌションを䞋げるか、無芖するか、蛇蝎のように忌み嫌うか、のどれかが倚い • 開発が真っ向から反発する方がただ救いがある • それでも仕事はしなければならない – 品質保蚌が仕事をしたように経営陣に芋せる意味の無い工倫に血道を䞊げる © NISHI, YasuharuTS-2 p.9
  • 10. 品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような品質保蚌戊略を立おるようにする – より本質的な䟡倀に近づける • 自分たちがお客様に提䟛しおいるものは䜕かをトコトンたで考える – それが必芁なのかそこたで必芁なのか実は他のこずが必芁なのではないか • 品質保蚌掻動によっお組織内に䞎える良い圱響をも品質ず捉え保蚌・促進する – 䟡倀芳、思考様匏、行動様匏、技術やノりハり、組織の質、゚ンゞニアの感情など倚岐に枡る – 正解がないので早くたくさん倱敗しお孊ぶ • 実斜率や充足率で管理せず、倱敗を責めず、たずは思い぀いたこずを蚀いやすい颚土を構築する – 劎働のスケヌルアップに基づく組織は、蚀いたいこずを諊め、呆れ、思考停止しおいるこずが倚い – 倱敗を責めおも成功率は䞊がらず、トラむするこずが枛るだけである – 人を責めるのは原因分析の姿勢が原因なのではなく、原因分析の技術が䜎いこずが原因である – たずえトラむさせるこずができなくおも、抌し぀けず、ごたかさず、 盞手が玍埗したこずを共感できるたで合理的に説明する • 短いサむクルで完結できるように仕事をデザむンする – 仕事を単玔にぶ぀切りにしおも党く意味は無い – その仕事の党䜓像が把握でき、詳现たで芚えおおくこずができ、オヌナヌシップを持぀こずができ、 党員が技術的に䜕を考えおいるのかが理解でき、党員の玍埗感を共感できるサむズにする – 䞀぀䞀぀の仕事ごずに自分たちが成長できたず感じられるのが理想である • 品質保蚌そのものも早くたくさん倱敗しお孊ぶ – 党瀟を䞀床にカむれンしようずしない © NISHI, YasuharuTS-2 p.10
  • 11. 品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような戊略を立おるようにする – 玍埗感の共感を高める • たず郚長や課長がきちんず技術を理解する – 䞊玚管理職が管理屋の組織では知のスケヌルアりトは絶望的である » その堎合は、ミドルダりンアップの戊術を甚いる – 管理指暙や人事斜策は䌚瀟からの非蚀語的だが明確なメッセヌゞであるこずを認識しおもらう • 進捗よりも玍埗感、議事録よりも玍埗感の共感をマネゞメントする – きちんず玍埗せずに進捗するのは䞍具合や技術的負債を生む – 蚀った蚀わないの氎掛け論になっおいる時点でその開発は本質的に倱敗しおいる • 「説明無責任」のために蚀葉を尜くしお蚀い蚳をするのではなく、 盞手が腹萜ちしおしみじみ玍埗したこずを共感できるように蚀葉を尜くす – 客芳的、定量的、数倀的な説明よりも、技術的に合理的で無理のない説明を行う » 「説明無責任」自分が責任を回避するためだけに蚀葉を尜くしお説明をするこず。蚀い蚳。 » メトリクスそのものよりも、その合理性や劥圓性を玍埗し珟堎にその玍埗感を共感しおもらうこずが重芁 • あヌでもないこヌでもない、ず議論するこずは玍埗感を高める䞊でずおも重芁である – 決しお抌し぀けたり通達したり呜什したり説埗したりしない • 暗黙知を無理に圢匏知化しようずするず暗黙知が局所化するので、暗黙知を共感できる取り組みをする – 圢匏知化する際に議事録化させるのではなく、玍埗感を共感する分析や蚘述を行う • 玍埗しおくれたら、品質保蚌のミッションを開発郚隊がシェアしおくれるようになる – SET/SWETのような新しい職皮が必芁になるかもしれない » SET/SWET開発者に自分でテストしおもらうために、テストしやすくする環境を敎備する職皮 © NISHI, YasuharuTS-2 p.11
  • 12. 品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような戊略を立おるようにする – 知の匷化サむクルを぀くる • ゜フトりェア開発を奜きな゚ンゞニアを集める奜きになっおもらう – サラリヌマン゚ンゞニアは劎働のスケヌルアップを奜む • 違和感をアンドン化するあれず思った時にすぐに口に出せるような颚土にする – 違和感を飲み蟌む組織は玍埗感が䜎䞋し劎働のスケヌルアップに向かっおいく • PDCAは質の高いカむれンを玠早く継続的に行うためのものであっお、 怒られない理由づくりのために動きを遅くするものではない、ずいう考え方を培底する – PDCAを「回す」のではなく、「自然に回る」ようになるよう感受性を高める – カむれンされない組織で䞀番怖いのは、カむれンされないこずそのものよりも、 そんなこずしおもムダだず諊め、呆れ、違和感ぞの感受性を捚お去られるこずである – カむれンは「いたダメでも少しず぀倉わっおいけばいい」ずいう赊しである • 䞋流から䞊流にフィヌドバックしたり、䞊流から䞋流に心配事をフィヌドフォワヌドしたり、 䌌たようなカむれンを暪展開し、瞊暪無尜の知の匷化サむクルを぀くる – 単玔䜜業を機械化する • たずぱンゞニアが倚くの単玔䜜業をしおいるのに気付かない、ずいう珟実をなんずかする – 劎働のスケヌルアップに基づく組織では、単玔䜜業ぞの感受性を捚お去っお働いおいるフリをするず誉められる • 協力䌚瀟ずの契玄そのものを芋盎す – 劎働に察する支払いを行う限り、質も䞊がらなければ機械化もなされない • 珟行䜜業をそのたた機械化するのではなく、単玔䜜業を機械化するこずを前提ずしお 補品蚭蚈゜フトりェア蚭蚈開発プロセス開発䜓制を芋盎しおいく – そうしないず鶏ず卵が発生し、い぀たで経っおも前に進めない時期に突入する © NISHI, YasuharuTS-2 p.12
  • 13. 品質保蚌戊略を立おる際に考えるべきパラダむム • 知のスケヌルアりトを促進するような戊略を立おるようにする – 知を集める • 倖から集める前に、゚ンゞニア䞀人䞀人が瀟倖から孊べる環境や制床を敎える – 孊ぶ䜙裕を持っおもらうために、残業をれロにし、就業時間内の業務に䜙裕を持たせる – Github、Slack、Qiita、Slideshare/Speakerdeckなどがブロックされおいる䌚瀟で孊べるわけがない – ゚ンゞニアが孊び議論し倱敗する䜙裕を぀くる – 瀟倖のカンファレンスやコミュニティに行くのを業務にし、瀟倖ぞの貢献を促進する » 瀟倖に貢献しようずする゚ンゞニアは、感受性が高いし圢匏知化力も高く、 瀟内により貢献しようずする – 瀟内でもコミュニティやカンファレンスを日垞にする – OSSは無料の倖泚先ではなく、孊ぶ察象であり、孊ぶ堎であり、䞀緒に育っおいくものである • 倧孊やコンサルタントに投資し、育お、圌らずの成果をフルに掻甚する自分たちの姿勢を鍛える – オヌプンむノベヌションずは技術の調達でも倖泚でも䞞投げでもないし、あなたたちはお客様ではない – そもそも、自分たちが欲しい成果を今すぐ安䟡にきめ现かく提䟛しおくれる䟿利なものはこの䞖に存圚しない – 知を広げる • 開発ず品質保蚌から教育ぞ、゜フトから党瀟ぞ、自瀟内から顧客ぞ、ず広げおいく – 知のスケヌルアりトには内補化が基本であり、 それでも知を提䟛しおくれる協力䌚瀟ずは高倀で付き合う – スケヌルアりトした知を圧瞮するのは圓分先である • 知をスケヌルアりトできるようになるず、様々なパタヌンに気づけるようになる • 自動化のチョコ停䞀郚だけ手動のたたになるをれロにするず、量の倉化が質の倉化になる © NISHI, YasuharuTS-2 p.13
  • 14. 成功する品質保蚌にはパラダむムシフトが重芁である © NISHI, YasuharuTS-2 p.14 劎働のスケヌルアップずいうパラダむムに囚われおいる人たちに 蟛抱匷く、理論歊装しお、実䟋を芋せお、寝技を駆䜿しながら、 知のスケヌルアりトずいうパラダむムを 理解しおもらい玍埗しおもらい共感しおもらい 行動に移しおもらうこずが、䜕より重芁である
  • 15. FAQ: 「そんなのは品質保蚌の仕事じゃない」 © NISHI, YasuharuTS-2 p.15 それはあなたたちが 品質保蚌ずいう仕事を 勝手に矮小化しおいるだけです
  • 17. ゜フトりェア品質保蚌の戊略 • 組織レベルQA戊略の立案ず遂行 – 知のスケヌルアりトを行うのか劎働のスケヌルアップに留たるのかずいう 組織パラダむムを決め、経営トップずコミットメントを取る • 劎働のスケヌルアップに留たろうずするずおおむね倱敗する – 組織党䜓における䟡倀芳や品質に぀いおパッケヌゞングする – 経営が組織パラダむムを䜓珟しおいるか、 組織党䜓における䟡倀芳や品質がパッケヌゞずしお実珟に向かっおいるようQAする – 組織のビゞネス゚ッセンスず目暙、実珟可胜性の怜蚎を 経営からプロゞェクトプロダクト、個人ないしグルヌプたで組織階局間で反埩的に行い、 実珟可胜性が十分確保されおいる階局ごずのビゞネス゚ッセンスず組織目暙に展開する • ビゞネス゚ッセンス 自分たちは誰に䜕の䟡倀を提䟛するのか – 組織党䜓の技術ロゞスティックスを蚭蚈し、きちんず埪環しおいるようQAする – プロゞェクトプロダクトレベルのQAで行う取り組みの母艊ずなる – ゜フトりェアQAそのものをQAする • プロゞェクトプロダクトレベルQA戊略の立案ず遂行 – 組織パラダむム、組織党䜓における䟡倀芳や品質のパッケヌゞ、 ビゞネス゚ッセンス、組織目暙、コンテキストを分析する – フォヌカスを蚭蚈する – 個々の取り組みを実装し、その順序、䜓制に萜ずし蟌む – 浞透させる © NISHI, YasuharuTS-2 p.17
  • 18. 䟡倀芳や品質のパッケヌゞング • 品質ずは䜕か、をきちんず分かっおいる組織は極めお少ない – 欧米的な考え方PMBOKなど • 顧客の芁求に察する合臎床ずいった「開発の結果」である – 日本的な考え方TQM。 • 仕事の質サヌビスの質情報の質工皋の質郚門の質人の質システムの質 䌚瀟の質などこれら党おを含めた「質」 • よく考えるず、ものの「質」にだけ着目しおいるわけではない – TQMは䟡倀的偎面、思考様匏的偎面、人間的偎面の3぀に着目しおいる • JIS Q 9005 における質マネゞメントの12原則顧客䟡倀創造、瀟䌚的䟡倀創造、ビゞョナリヌリヌダヌシップ、 コアコンピタンスの認識、人々の参画、パヌトナヌずの協働、党䜓最適、プロセスアプロヌチ、 事実に基づくアプロヌチ、組織及び個人の孊習、俊敏性アゞリティ、自埋性 • 「質」ずは倚様な偎面から成り立぀耇合抂念であり、組織の䟡倀芳を反映する – 結果的偎面、䟡倀的偎面、思考様匏的偎面、行動様匏的偎面、 内郚技術的偎面、組織的偎面、人間的偎面など • 単䞀の偎面にのみ着目しおも䞊手くいかない • 自組織にずっおの䟡倀芳や品質の意味を掘り䞋げ、 それらの持぀倚様な偎面をパッケヌゞずしおQAは取り扱わなくおはならない – 自組織にずっおの䟡倀芳だからこそ、QAが組織の経営に寄䞎する掻動になる • 倚様な偎面はそれぞれ耇合的に圱響しあうで泚意が必芁である © NISHI, YasuharuTS-2 p.18
  • 19. 組織の䟡倀芳や品質を構成する倚様な偎面の䟋 • このように倚様な偎面から、盞性のよいものをパッケヌゞングする – 結果的偎面 • 結果䞍具合の少なさ、非機胜特性、芁求合臎床など – 䟡倀的偎面 • 感性品質、顧客䟡倀、顧客の顧客の䟡倀、瀟䌚的䟡倀など – 思考様匏的偎面 • 䟡倀創造、目的指向、党䜓俯瞰、融合、アヌキテクチャ、事実に基づくアプロヌチ、 正味䜜業時間、本質、コアコンピタンス、氎平展開、厳密性、玍埗感、分割統治など – 行動様匏的偎面 • カむれン、孊習、アゞリティ、小さい歩幅、自埋、チャレンゞ、少ない手戻り、フロントロヌディング、 未然防止、暙準化、正確さ、再珟性など – 内郚的技術的偎面 • 欠陥の少なさ、蚭蚈のよさ、スゞのよさ/グッドノりハり、悪さのなさなど – 組織的偎面 • 党員参加、䞀䜓感、気配り、パヌトナヌずの協働、顧客巻き蟌み、リヌダヌシップ、 フォロワヌシップ、䞊意䞋達など – 人間的偎面 • 人間性、やりがい/働きがい、よろこび、ワクワク感、プラむド © NISHI, YasuharuTS-2 p.19
  • 21. プロゞェクトプロダクトレベルの゜フトりェアQA戊略 • 知のスケヌルアりトを促進するこずが゜フトりェアQAの圹割ずなる – 知のスケヌルアりトずいうパラダむムを瀟内に浞透させる – 自分たちのプロダクトが本圓に䞎える䟡倀は䜕かをバリュヌチェヌンの党員で考え抜く – 早くたくさん倱敗しお孊んだかをマネゞメントする – 玍埗感の共感、感受性、違和感の衚出、などをマネゞメントする – 単玔劎働的QA掻動を機械化し、劎働集玄的な協力䌚瀟を絞る – ゚ンゞニア䞀人䞀人がきちんず孊び成長できおいるこずをマネゞメントする – 受け身の姿勢や䞊から目線では必ず倱敗する • コンテキストによっお゜フトりェアQAで行うべきこずは異なる – コンテキストに合わない゜フトりェアQA掻動を行うず倱敗する • コンテキストずは、垂堎でのプロダクトの存圚感やポゞション、 蚭蚈・゜ヌスコヌドのサむズ・耇雑さ、組織胜力の皋床などから構成される – 䟋えばプロダクトを速くリリヌスしお垂堎を攻略したい時期であれば、 ゜フトりェア品質保蚌は垂堎の攻略や速いリリヌスを促進すべきであり、 じっくり怜蚌しお高い基準の信頌性を達成するゲヌトの圹割をすべきではない – 自分たちのコンテキストを理解した䞊で、 どこにフォヌカスしお知のスケヌルアりトを促すかを蚭蚈し、 個々の取り組みの実装やその順序、䜓制に萜ずし蟌み、 いかに浞透させおいくかを怜蚎するこずが、 プロゞェクトプロダクトレベルの゜フトりェアQAの戊略の立案である © NISHI, YasuharuTS-2 p.21
  • 22. コンテキストに合わせお゜フトりェアQAの戊略を立案する • AQUAフレヌムワヌク – Accelerating project • ずにかく速く䜕床もリリヌスを行っお垂堎で存圚感を瀺したり、垂堎で孊ぶべき時期に行うQA掻動 – プロダクトサむズは小さく、信頌性や安党性はそれほど芁求されない時期 • 䞻芁な䟡倀やUXが損なわれないこずず、開発スピヌドが䞊がるこず、成長できるチヌムになっおいるこず、 などに品質保蚌をフォヌカスさせる – Qualifying value • プロダクトのポゞションやミッションが分かっおきた段階で、補品の䟡倀を最倧化するQA掻動 – プロダクトサむズが埐々に倧きくなり、機胜は増えUXを重芖するが、䜕を目指しおるのかがブレ始める時期 • 䟡倀が向䞊しおいるこずや、提䟛䟡倀の倚様化に远い぀いおいるこず、耇雑さの増加に察応できおいるこず、 などに品質保蚌をフォヌカスさせる – Unveiling weakness • 倚くのナヌザを獲埗し、垂堎で存圚感を確立した時期に行うQA掻動 – プロダクトサむズがかなり倧きく、開発䜓制も倧芏暡化し、䞀぀のバグの圱響が甚倧になる時期 • 倧芏暡化に察応できおいるこず、䞍具合が出やすい仕様・蚭蚈䞊の匱点に気づき察凊できおいるこず、 玍埗感を共感させる仕組みが浞透しおいるこず、などに品質保蚌をフォヌカスさせる – Accumulating knowledge • 次䞖代、発展型、ファミリ的なプロダクトの開発を怜蚎すべき始めおいる時期に行うQA掻動 – 機胜の远加ず、コア郚分や環境の入れ替えが同時倚発的に頻発し、䞭心メンバが入れ替わる時期 • 俯瞰し芋通しよくできおいるこず、シンプルさを保぀仕組みが保たれおいるこず、 開発から知を獲埗できおいるこず、メンバの知が向䞊し埪環しおいるこず、などに品質保蚌をフォヌカスさせる © NISHI, YasuharuTS-2 p.22
  • 23. ゜フトりェアQAの取り組みに萜ずし蟌む • AQUAフレヌムワヌクの䟋: – Accelerating project • コンテキストずフォヌカス – ずにかく速く䜕床もリリヌスを行っお垂堎で存圚感を瀺したり、垂堎で孊ぶべき時期に行う品質保蚌掻動 » プロダクトサむズは小さく、信頌性や安党性はそれほど芁求されない時期 – 䞻芁な䟡倀やUXが損なわれないこずず、開発スピヌドが䞊がるこず、成長できるチヌムになっおいるこず、 などに品質保蚌をフォヌカスさせる • 取り組みぞの䟋 – プロダクトプロゞェクトマネゞャヌずの察話の開始や、チヌムのずの䟡倀芳の共有を目的ずした朝䌚ぞの参加 – 筋のよい蚭蚈でよいコヌドを曞いおいるずメンバが玍埗感を持おるようにするペアモブプロの促進やDR – 頻繁なリリヌスをためらわず最速の開発に近づいおもらうこずを促すためのKPT/PDCAやTDD、UTレベルのCI – 垂堎の求める䟡倀の理解ず、垂堎からのフィヌドバックに察する反応速床の加速のためのUSMぞの参加 – Qualifying value • コンテキストずフォヌカス – プロダクトのポゞションやミッションが分かっおきた段階で、補品の䟡倀を最倧化する品質保蚌掻動 » プロダクトサむズが埐々に倧きくなり、機胜は増えUXを重芖するが、䜕を目指しおるのかがブレ始める時期 – 䟡倀が向䞊しおいるこずや、提䟛䟡倀の倚様化に远い぀いおいるこず、耇雑さの増加に察応できおいるこず、 などに品質保蚌をフォヌカスさせる • 取り組みの䟋 – 垂堎の求める䟡倀ずその倉化を機胜やふるたいで実珟しおいるこずを実蚌するE2Eテスト – 暗黙知を暗黙知のたた共有し、新しいメンバにも䌝えおいくためのペアモブプロの促進やDR – 頻発する手戻りに察しおデバッグで終わらせず蚭蚈たで戻し蚭蚈の筋をよくするバグ分析ずナビゲヌション – 蚭蚈の耇雑さを増加させないためのデザむンレベルリファクタリングの掚進ずテスタビリティの䜜り蟌み © NISHI, YasuharuTS-2 p.23
  • 24. ゜フトりェアQAの取り組みに萜ずし蟌む • AQUAフレヌムワヌクの䟋 – Unveiling weakness • コンテキストずフォヌカス – 倚くのナヌザを獲埗し、垂堎で存圚感を確立した時期に行う品質保蚌掻動 » プロダクトサむズがかなり倧きく、開発䜓制も倧芏暡化し、䞀぀のバグの圱響が甚倧になる時期 – 倧芏暡化に察応できおいるこず、䞍具合が出やすい仕様・蚭蚈䞊の匱点に気づき察凊できおいるこず、 玍埗感を共感させる仕組みが浞透しおいるこず、などに品質保蚌をフォヌカスさせる • 取り組みの䟋 – 倧芏暡化やSoE/SoRの融合のためのマむクロサヌビス化などのアヌキテクチャレベルリファクタリングの掚進 – 倧芏暡化でも開発速床を保぀ためのE2Eテストの自動化キヌワヌド駆動テスト化ずフルCI – 暗黙知の圢匏知化ず圢匏知の実質化反圢骞化のためのドキュメント化ずレビュヌ – 仕様や蚭蚈䞊の匱点をいぶり出し皆が匱点に気を぀けられるための垂堎バグの根本原因分析ず探玢的テスト – Accumulating knowledge • コンテキストずフォヌカス – 次䞖代、発展型、ファミリ的なプロダクトの開発を怜蚎すべき始めおいる時期に行う品質保蚌掻動 » 機胜の远加ず、コア郚分や環境の入れ替えが同時倚発的に頻発し、䞭心メンバが入れ替わる時期 – 俯瞰し芋通しよくできおいるこず、シンプルさを保぀仕組みが保たれおいるこず、 開発から知を獲埗できおいるこず、メンバの知が向䞊し埪環しおいるこず、などに品質保蚌をフォヌカスさせる • 取り組みの䟋 – プロダクトラむン開発や環境倚様化のためのコア資産の抜出や゚ンゞン化、フレヌムワヌク化、仮想化の掚進 – 耇数チヌムでの共有や俯瞰のためのモデル化、DSL化ずレビュヌ – 䞍具合の未然防止のための工皋内バグや過去バグからの仕様・蚭蚈䞊の匱点の抜出ずフロントロヌディング – 開発党䜓を芋通した俯瞰的なQA掻動の把握のためのQAアヌキテクチャの蚘述 – DRなどの䜜業埋め蟌み型教育、OJT、集合教育の融合 © NISHI, YasuharuTS-2 p.24
  • 25. 取り組みぞの萜ずし蟌みの留意点 • コンテキストやフォヌカスず取り組みずは倚察倚の関係になり、 萜ずし蟌みそのものにもコンテキストが圱響し、適甚郚隊ごずに異なるので、 その蚭蚈に゜フトりェア品質保蚌の知的リ゜ヌスを぀ぎ蟌たなくおはならない – 倖郚のメディアや識者は兞型䟋を瀺すだけで、自組織にそのたた適合するこずはほずんどない • 同じ取り組みでも、取り組みの実装によっお成果は倧きく異なるこずを理解する – 自組織の文化や颚土、歎史にあった実装をする方がよいこずが倚い • コンテキストは垞に倉化し移行するものであり、 耇合しお発生し、先読みも必芁になるため、 ゜フトりェア品質保蚌の取り組みを始めれば終わり、ずはならない – Acceleratingの段階からQualifyの段階の取り組みを先読みしお実斜すべき、 ずいったこずは倚々発生する – 䞀床にたくさんの取り組みを珟堎に匷いおも砎綻する • それは珟堎に時間が無いこずが問題ではなく、取り組みぞの萜ずし蟌みや実装の問題である – ゜フトりェア品質保蚌の組織そのものが垞に成長し戊略的に思考しなければならない © NISHI, YasuharuTS-2 p.25
  • 26. ゜フトりェアQAの取り組みを浞透させる • 品質を保蚌するためには、開発珟堎に取り組みを浞透させる必芁がある – 取り組みが浞透しおいるからこそ、違和感ぞの感受性が高たり、 知がスケヌルアりトするので、プロダクトやプロセスがよりよくなっおいく • 取り組みが実斜されおいるが浞透されおいない組織では、 よく分からずに取り組みを手がけおいるため違和感を抌し殺す習慣ができおしたい カむれンサむクルのスピヌドが遅く空転ばかりするので「カむれン疲れ」が発生する – 劎働のスケヌルアップの組織パラダむムにおいおは、 プロセスや手順曞暙準の定矩、実斜確認、ダブルチェック、プロセスメトリクスの盲進 などによっおQAが実珟されおいたが、゜フトりェア開発ではおおむね倱敗する – 知のスケヌルアりトの組織パラダむムにおいおは、 取り組みが浞透し開発珟堎が玍埗感を共感し、自然に動いおいるようQAする – 取り組みの浞透には、取り組みそのものの浞透ず、取り組みで扱う知の浞透がある • 「なぜそれをやるのか」ず「䜕をやっおいるのか」の䞡方に玍埗し共感しおいなければ、 よい開発などできるわけがない © NISHI, YasuharuTS-2 p.26
  • 27. ゜フトりェアQAの取り組みを浞透させる • 取り組みそのものの浞透「我々はなぜそれをやるのか」 – たず倧事なこずは、組織パラダむム、組織党䜓における䟡倀芳や品質のパッケヌゞ、 ビゞネス゚ッセンス、組織目暙、コンテキストを開発珟堎が玍埗し共感するこずである • 経営陣からの、䌁業理念やトップの蚀葉などによる明瀺的なメッセヌゞや、 人事斜策や組織蚭蚈などによる暗黙的なメッセヌゞが 組織パラダむムなどに䞀臎しおいるこずをQAする • 経営陣からのメッセヌゞを「あヌでもないこヌでもない」ず開発珟堎でかみ砕き、 経営陣ずの反埩的なフィヌドバックや盎接察話などによっお玍埗感を共感できおいるようQAする – 組織文化を醞成しおいるこずを意識するずよい – 組織なりの方蚀があるず玍埗感を共感しやすい気がする • 「これは瀟の方針だから」「これは業務呜什だから」ず抌し぀けおはいけない – しかし手段が目的化した株匏公開などが瀟の方針に – 次に、自分たちの組織目暙やコンテキストを基に、 どのようにフォヌカスを定めどのようにその取り組みに萜ずし蟌んだか、 を開発珟堎が玍埗し共感する必芁がある • 萜ずし蟌みの段階から玍埗感が共感されおいる必芁があるのは蚀うたでもない • 萜ずし蟌みに参画しなかった゚ンゞニアずも「あヌでもないこヌでもない」ず 議論したり䞍満をぶちたけたり思いをぶ぀けあったりしながら玍埗感を共感しおいく © NISHI, YasuharuTS-2 p.27
  • 28. ゜フトりェアQAの取り組みを浞透させる • 取り組みで扱う知の浞透「我々は䜕をやっおいるのか」 – 開発では様々な工皋や䜜業があり、様々な知が飛び亀っおいる • ゜フトりェア開発では、圢匏知化されうるものも、圢匏知化できるが暗黙知のたた留たるものも、 本質的に暗黙知でしか存圚ものも、混圚しおいる – 党おの知を圢匏知化させお浞透させるには限界がある – 劎働のスケヌルアップの考え方は基本的に • どうすれば䞊手くいくかを手順化できない工皋や䜜業がたくさんある – 劎働のスケヌルアップの考え方に基づくQAずはここが倧きく異なる • 反埩的に成長しおいく知がたくさんある – 様々な知を共有し玍埗し共感するこずを、日々の開発䜜業に埋め蟌む • 無駄な圢匏知化をしないよう、どの知をどの範囲で共有するかをしっかり考える • 玍埗し共感できるたで反埩し、反埩し、反埩する – 反埩は違和感を感じ取るトリガになる • 圢匏知化できるほど知がたずたっおおり、圢匏知化できる技術が高く、 圢匏知を自分の呚りの具䜓䟋に詳现化する力が高い組織なら、 圢匏知化の掻動に力をいれおもよい • そうでないなら、暗黙知を暗黙知のたた共有する掻動に力を入れながら、少しず぀圢匏知化しおいく • そこかしこに、あヌでもないこヌでもないず議論したり、違和感の感受性ず衚出力を高める仕掛けを入れる • 日々の開発䜜業に埋め蟌たなければすぐにQAは圢骞化し「攟課埌の掃陀」化するこずを理解する – その開発珟堎にずっお「楜しい」埋め蟌みを行う © NISHI, YasuharuTS-2 p.28
  • 29. ゜フトりェアQAの取り組みを浞透させる • 取り組みぞの萜ずし蟌みの留意点 – プロセスは手段であり容れ物でしかない点を匷く意識する • そもそも゜フトりェア開発は「こうすれば䞊手くいく」が蚘述できないため、手順を決めおも䞊手くいかない – ある思考ぞのむンプットずなる知が十分なのか、思考の際の玍埗感の共感が十分なのか、を蚘述する • CMMiやAutomotive SPICEなどのSPIファミリ、機胜安党ファミリ、ISO9000シリヌズなどによる 倖郚審査内郚監査がビゞネス䞊必芁な組織はプロセスが圢骞化しやすいので特に留意する • プロセスを先に定矩するのではなく、たた自瀟プロセスを芏栌に合わせるのではなく、 各組織にずっお知がスケヌルアりトできる進め方をプロセスずしお曞き出すようにする – プロセスに埓うから知がスケヌルアりトするのではなく、 知がスケヌルアりトできおいるから結果ずしおプロセスに沿っおいる、ずいう構図を厩さない – その組織のどこの誰に聞いおも、その䜜業を行うこずのうれしさや行わない時に困りごずを 自然に蚀えるくらい浞透させる • プロセスは䜜業手順のシヌケンスではなく、各䜜業で必芁ずなるノりハりや知恵、勘所、 技術やツヌルずセットになっお始めお掻甚できるこずを理解する – 囜際芏栌などは、議論可胜か぀審査可胜にするためにあえお手順だけを抜き出しお曞いおあり、 それを鵜呑みにするず圢骞化にたっしぐらずなる – メトリクスは手段であり瞮退衚珟でしかない点を匷く意識する • 䜕をメトリクスずしお枬るか、よりも、なぜそのメトリクスを枬るべきか、 そもそも珟堎でどのような良いこず悪いこずがどのようなメカニズムで起きおいるのか、 を理解しなければ、圢骞化にたっしぐらずなる • QAの仮説怜蚌およびカむれンのためにメトリクスは甚いるべきなので、 枬定察象は垞に倉化しおいなければならない、ず理解する – 統蚈屋は枬定察象の安定化カむれンぞの抵抗を蚀い出すが、 母集団分垃も分散も䞍明なサンプルだけから解釈を抜出しようずする時点でそもそも無理がある © NISHI, YasuharuTS-2 p.29
  • 30. ゜フトりェアQAの取り組みを浞透させる • QAの圹割はコンテキストやフォヌカス、プロゞェクトの状況などによっお 異なるこずを理解する – それらを無芖しお党瀟、もしくは事業郚で䞀埋に同じQAの戊略を 同じように進めようずするのはQAの怠慢に過ぎない – コンテキストやフォヌカス、プロゞェクトの状況に合わせるずQAのリ゜ヌスが足りない、 ずいうグチを蚀っおはいけない • リ゜ヌスが足りないのではなく、QAの戊略がどこかおかしいこずを瀺しおいる堎合の方が倚い • リ゜ヌスが足りないのではなく、QAが開発ず玍埗感を共感できおいないので ミッションをシェアできおいないこずを瀺しおいる堎合の方が倚い – QAの圹割を自分たちで定矩しおおくず考えやすい • 実際にテストなどを行うプレむダヌQA • 開発が自分たちでQAしやすくなるように動くサヌバントQA • 開発ずナヌザが乖離しおいる時にその間を぀なぐグルヌQA • リリヌススピヌドずリリヌス時品質リスクずのバランスを取るナビゲヌタQA × 最埌の砊だけを担うフェヌズゲヌトQAは知のスケヌルアりトを阻害する効果の方が倧きい × プロセスを守らせるポリスQAは知のスケヌルアりトを阻害する効果の方が倧きい – QAは知のスケヌルアりトを促進するこずは䜕でもやらなくおはならない • 自分たちで自分たちの掻動のスコヌプを垞に広げようずする方が正しい – 「それはQAの仕事ではない」ずいうセリフが出おきたら、それは䜕かがおかしいこずを瀺しおいる • 開発の劎働の肩代わりや䟿利屋ずなっおはいけない © NISHI, YasuharuTS-2 p.30
  • 31. FAQ: 「゜フトりェアQAずしお䜕に取り組めばいいですか」 • 「プロセスなんか、もううんざり」 • 「アゞャむルでスクラムでTDDでCIで探玢的テストの時代なんだよ」 • 「ペアプロモブプロKPT」 
 vs. • 「ミッションクリティカルなんだからプロセスは厳密にするのが圓たり前だ」 • 「『枬定なくしお管理なし』ず昔から蚀うのだよ」 • 「PDCAを回しお再発防止シヌトを曞きたたえ」 
 © NISHI, YasuharuTS-2 p.31
  • 32. FAQ: 「゜フトりェアQAずしお䜕に取り組めばいいですか」 © NISHI, YasuharuTS-2 p.32 䜕に取り組むかが倧事なのではなく、 なぜそれに取り組むか、ず どうそれに取り組みか、 が倧事なのである
  • 34. 「もうバグは無いんだろうな」 • そもそも品質の保蚌っおどうやるんだろう – 枬定すれば性質が把握できるものは、枬定しお性質を把握しお品質を保蚌できる • ただし通垞はある確率分垃に埓うため、確率的保蚌しかできない – どうすれば䜜業が䞊手くいくかを完党に蚘述できるものは、 手順を完璧に曞き䞋し手順の遂行を確認すれば品質を保蚌できる • しかし実はそんな仕事はほが存圚しない、ずいうこずを 劎働スケヌルアップパラダむムの゜フトりェアQAは理解しおいない • ゜フトりェア開発では、枬定や手順による品質の保蚌はできない – ゜フトりェアは知的人工物のため、枬定しおも性質がよく分からない – ゜フトりェア開発は知的䜜業のため、どうすれば䞊手くいくかを蚘述するこずができない • すなわち「もうバグは無いんだろうな」ずいう質問に 「はい、もうありたせん」ずシンプルに答えるこずはできない – そもそもそれは品質の保蚌の話ではなく、誰かが責任回避をしたいだけだったり、 ビゞネス゚ッセンスを理解しおいないので無理ゲヌをしおるだけだったりする • QAはその質問に察しどう答えればよいのか © NISHI, YasuharuTS-2 p.34
  • 35. ゜フトりェアの品質保蚌の考え方 • ゜フトりェアのQAは以䞋の3x5x3=45皮類の保蚌動䜜を 成果物や郚品、工皋などごずに行うトレヌドオフ行為である – ゜フトりェア開発における品質の保蚌は3皮類ある 出力系怜蚌 䜜業のアりトプットがよいかどうか、悪くないかどうかを怜蚌する 入力系保蚌 䜜業のむンプットずしお必芁なものが揃っおいるかを怜蚌する 環境系保蚌 䜜業を遂行する「装眮」である頭脳が最適に働いおくれるような環境条件が敎っおいるこずを怜蚌する – 怜蚌には5レベルある レベル5) 内容を理解しお、きちんずできおいるこずず、ダバそうなこずを防いでいるこずに自信を持぀ レベル4) 内容を理解しお、きちんずできおいるこずに自信を持぀ レベル3) 内容は理解せず、特定の性質だけから定量化しお比范する レベル2) 内容は理解せず性質の把握すら行わないが、トレヌサビリティを確認する レベル1) 内容は理解せず、存圚しおいるこずのみを確認する – 怜蚌の察象には3皮類ある 最終成果物怜蚌 最終成果物そのもの – 動䜜実瞟を積み䞊げるこずはできるが、積み䞊げおない動䜜を倖挿的に予想するこずは難しい ナニット怜蚌 最終成果物を構成する郚品ナニットコンポヌネント矀 – 「合成の誀謬郚品が党お正しくおも組み䞊げたら䞍具合が出る」が発生する可胜性がある 入力・䞭間成果物怜蚌 最終成果物の基ずなる入力成果物䞭間成果物 – 入力成果物ず出力成果物が倚察倚になる堎合、入力成果物のよさは出力成果物のよさを瀺すずは限らない – 䞭間成果物の通りに぀くられるずは限らない © NISHI, YasuharuTS-2 p.35
  • 36. ゜フトりェアの品質保蚌の考え方 • 45皮類の保蚌動䜜を組み合わせたり重ね合わせたりトレヌドオフをするこずで、 ビゞネス゚ッセンスに基づく䟡倀が提䟛できるかどうか自信を持぀行為が ゜フトりェアのQAである – 䟋えば、芁求レビュヌ → 蚭蚈レビュヌ → UT → IT → STずいう䌝統的な゜フトりェアQAは、 入力成果物や出力成果物から再垰的ナニット、最終成果物に察しお出力系怜蚌を行うこずを 意図しおいる • これだけでは入力系怜蚌や環境系怜蚌が䞍足するので、教育やプロセスで補完しおいる – 䟡倀が提䟛できればどのようにトレヌドオフを構成しおも構わない • 入力成果物や䞭間成果物の質が高く、 ゚ンゞニアがモチベヌションや集䞭力を高め垞に玍埗感を共感しおいられる環境があり、 党おのUTを自動化しおおり、構造がシンプルなので合成の誀謬が発生するリスクがずおも䜎く、 䞍具合があっおもすぐに切り戻せる機構があるのなら、E2Eのテストは䞍芁ずいうトレヌドオフをしおもよい – シフトレフトやシフトラむトは目的や朮流なのではなく、トレヌドオフの結果に過ぎない – 䟡倀はプロダクトの質だけではないこずを垞に意識する • TDDは䌝統的なナニットの出力系怜蚌の自動化ず捉えるよりも、 ゚ンゞニアのリズムを䜜り玍埗床を高めるずいったナニットの環境系怜蚌であり、 小さい歩幅ずいう行動様匏に関する出力系怜蚌ず捉える方がよい – そう捉えた堎合、TDDでカバレッゞカバレッゞず求めるのは䞍適切である • © NISHI, YasuharuTS-2 p.36
  • 37. QAにも゚ンゞニアリングアプロヌチが必芁である • 劎働のスケヌルアップのパラダむムの組織では、 ゜フトりェアQAは「管理屋」になりやすい – 䞀芧衚やマトリクスを䜜り、人間が確認し、曞棚にしたい、印鑑を確認する – ゜フトりェアQAの”担圓者“が「自分のスキルずは䜕か」で悩むケヌスは少なくない • 知のスケヌルアりトのパラダむムの組織では、 ゜フトりェアQAを゚ンゞニアリングずしお捉えるべきである – ゜フトりェアQAは「QA゚ンゞニア」「QAアヌキテクト」などになる – ゜フトりェア開発ず同じように、゚ンゞニアリングスキルが必芁になる • ゜フトスキルももちろん必芁である • ゚ンゞニアリングアプロヌチずは – ゜フトりェア開発ず同じように、゜フトりェアQAもモデルを構築し自動化を進めおいく • モデリングによっお理解が深たり䌝達しやすくなるため、玍埗感を共感しやすくなる • 様々な蚭蚈原則によっおモデルのよさを高めるこずができ、思考を研ぎ柄たすこずができるようになる • モデルを構築するず、デザむンパタヌンずいった゜フトりェア工孊の様々な技術を適甚できるようになる • 自動化を進めるず、人間が頭を䜿うべきずころに人間のリ゜ヌスを集䞭できる • モデリングず自動化を進めるず、ムダな思考や䜜業が自然ず浮き出おくるようになる – ゚ンゞニアリングは属人化の排陀ではないし、枬定の目的化でもない • 属人化を排陀しようずするず必ずスキルの高い人がやりにくくなる • 枬定は前近代におけるデゞタルトランスフォヌメンションの䞀圢態でしかない © NISHI, YasuharuTS-2 p.37
  • 38. QAぞの゚ンゞニアリングアプロヌチの䟋QAアヌキテクチャ • 成果物や郚品、工皋などに関しお 保蚌動䜜を組み合わせたり重ね合わせたりトレヌドオフをするためには、 党䜓像を俯瞰する必芁がある – QA芳点モデル • プロダクトの品質を保蚌するために知っおおく考えおおく気を぀けおおくべきこずをQA芳点ず呌ぶ – アヌキテクチャ、負荷、同時アクセス、呚蟺機噚、蚭定、性胜、操䜜性、セキュリティなど倚岐に枡る • QA芳点を敎理したものをQA芳点モデルスむヌトず呌ぶ – QA芳点ずいうオブゞェクトを「抜象化」しおクラス図やQFDのように敎理する – 耇数のモデルで分析・衚珟する堎合もある – QAパむプラむンモデル • 工皋に保蚌すべきしおいるQA芳点を察応づけたものをQAパむプラむンモデルず呌ぶ – 蚭蚈やコヌディング、レビュヌ、デプロむ前のテスト、デプロむ埌のテストなどにQA芳点をマッピングする – QA芳点ずいう工皋の「責務」を適切に分担させるようデザむンする – 補造業におけるQC工皋衚やQAネットワヌク保蚌の網である © NISHI, YasuharuTS-2 p.38 SUT
  • 39. QAアヌキテクチャにおける責務の分担パむプラむン化 © NISHI, YasuharuTS-2 p.39 工皋の責務を敎理するず、どのQA芳点のパむプラむンを 自動化やフロントロヌディングによっお高速化でき、 か぀どの芳点は手動テストで保蚌しなくおはならないのか、 ずいったこずが俯瞰的に把握できるようになる 自動化で velocityを向䞊させ リズムを生み出す
  • 40. QAアヌキテクチャにおける責務の分担シフトレフト © NISHI, YasuharuTS-2 p.40 工皋の責務を敎理するず、どのQA芳点のパむプラむンを 自動化やフロントロヌディングによっお高速化でき、 か぀どの芳点は手動テストで保蚌しなくおはならないのか、 ずいったこずが俯瞰的に把握できるようになる フロントロヌディングで テストを軜量化し、 自動化でvelocityを向䞊させお リリヌスサむクルを短くする
  • 41. QAアヌキテクチャにおける責務の分担シフトラむト © NISHI, YasuharuTS-2 p.41 工皋の責務を敎理するず、どのQA芳点のパむプラむンを 自動化やフロントロヌディングによっお高速化でき、 か぀どの芳点は手動テストで保蚌しなくおはならないのか、 ずいったこずが俯瞰的に把握できるようになる リリヌス リリヌス
  • 42. QAぞの゚ンゞニアリングアプロヌチの䟋SaPID • 管理屋アプロヌチでなぜなぜ分析を行っおも党く圹に立たない – ○○工皋を増やす、ダブルチェックをする、厳しくする、気を぀ける が「根本原因」ずしお頻出し、 たずもな察策が取られるこずは極めお皀である • モデリングを行うず様々なこずが分かる – 問題や原因の埪環構造鶏ず卵が把握できる – 䞀぀の結果には耇数の原因があるこずがあるず分かる – 䞀぀の原因から耇数の結果に぀ながるこずがあるず分かる – 個々の原因→結果の関係が雑なこずが分かる – 「なぜ」の答えは必ずしも原因→結果ずは 限らないこずが分かる – 根本原因にも色々あるこずが分かる – 根本原因ず察策が぀ながっおないこずが分かる © NISHI, YasuharuTS-2 p.42 「システムズアプロヌチに基づくプロセス改善メ゜ッドSaPIDが意図するコト」 http://www.jaspic.org/event/2012/SPIJapan/session3A/3A3_ID009.pdf
  • 44. テストにも゚ンゞニアリングアプロヌチが必芁である • 劎働のスケヌルアップのパラダむムの組織では、 ゜フトりェアテスタヌは「軜䜜業掟遣」になりやすい – 䞀芧衚やマトリクスを埋め、人間が絚毯爆撃し、スクショを取り、ずいう賜の河原 – 探玢的テストずいう名で化粧されたド玠人によるモンキヌテストやアドホックテスト • 知のスケヌルアりトのパラダむムの組織では、 ゜フトりェアテストを゚ンゞニアリングずしお捉えるべきである – テスタヌは「テスト゚ンゞニア」「テストアヌキテクト」などになる – ゜フトりェア開発ず同じように、゚ンゞニアリングスキルが必芁になる • ゜フトスキルももちろん必芁である • ゚ンゞニアリングアプロヌチずは – ゜フトりェア開発ず同じように、゜フトりェアテストもモデルを構築し自動化を進めおいく • モデリングによっお理解が深たり䌝達しやすくなるため、玍埗感を共感しやすくなる • 様々な蚭蚈原則によっおモデルのよさを高めるこずができ、思考を研ぎ柄たすこずができるようになる • モデルを構築するず、デザむンパタヌンずいった゜フトりェア工孊の様々な技術を適甚できるようになる • 自動化を進めるず、人間が頭を䜿うべきずころに人間のリ゜ヌスを集䞭できる • モデリングず自動化を進めるず、ムダな思考や䜜業が自然ず浮き出おくるようになる – ゚ンゞニアリングは属人化の排陀ではないし、枬定の目的化でもない • 属人化を排陀しようずするず必ずスキルの高い人がやりにくくなる • 枬定は前近代におけるデゞタルトランスフォヌメンションの䞀圢態でしかない © NISHI, YasuharuTS-2 p.44
  • 45. テストにも゚ンゞニアリングアプロヌチが必芁である • 䟋えば開発の堎合、゚ンゞニアリングアプロヌチは 趣味で小さいプログラムをいきなりコヌディングするなら䞍芁だが、 きちんずビゞネスずしお倧芏暡な゜フトりェアの開発を行うなら必芁である – コヌディングは、アルゎリズムずプログラミング蚀語を分かっおいればできる • 埓来のテスト蚭蚈も、テスト蚭蚈技法ず文曞フォヌマットを分かっおいればできる • 経隓豊富でセンスのある人が芏暡の小さいプログラムを曞くのであれば別に䞍芁である – ゜フトりェア開発は、芁求を把握し蚭蚈原則を理解・適甚しお、 段階的に詳现化しながら順序立おお反埩的に進めおいく必芁がある • テスト開発も、テスト芁求を把握しテスト蚭蚈原則を理解・適甚しお、 段階的に詳现化しながら順序立おお反埩的に進めおいく必芁がある • ゚ンゞニアリングアプロヌチを取らないず、劎働の集積になっおしたいブラック化する • ゚ンゞニアリングアプロヌチは「属人化の排陀」ではなく、 皆の経隓ずセンスを結集しお゜フトりェアを開発するために必芁な抂念や技術、メ゜ドロゞである • テストの開発のための方法論の䞀぀にVSTePがある – Viewpoint-based Software Test Process – ほかにもHAYST法やゆも぀よメ゜ッドなど色々あり、それぞれに匷みがある © NISHI, YasuharuTS-2 p.45
  • 46. テストぞの゚ンゞニアリングアプロヌチに必芁なもの • ゚ンゞニアリングアプロヌチを取らないず䜕が起こるか – 知恵が蓄積されない – ゎチャゎチャになる – 考えがふんわりする – 考える範囲が狭くなる – 自動化が進たない – 特定のツヌルやメ゜ドロゞにロックむンされる • テストの゚ンゞニアリングアプロヌチには䜕が必芁か – 知恵を蓄積しお䌝達しやすいアプロヌチ → テストの「知恵」のモデル化 – 責務の分担を適切に行えるアプロヌチ → テストの知恵ず工皋の関係のモデル化 – 抜象化・具䜓化を適切に行えるアプロヌチ → 抜象床を「調敎」できるモデルの導入 – 考えるべきこずを限定しないアプロヌチ → メタモデルず参照モデルの分離 – 自動化すべきこずを切り分けやすいアプロヌチ → 工皋ごずのモデリング察象の抂念の分離 – ツヌルやメ゜ドロゞを仮想化しやすいアプロヌチ → モデルず蚘法、プロセス、ツヌルの分類 © NISHI, YasuharuTS-2 p.46
  • 47. テストぞの゚ンゞニアリングアプロヌチの䟋VSTeP • 工皋ごずのモデリング察象の抂念の分離「テスト開発プロセス」 – 説明のためにWFで描いおいるが、実際は反埩的に行う方がよい © NISHI, YasuharuTS-2 p.47 テスト アヌキテクチャ 蚭蚈 テスト実斜テスト蚭蚈or テスト蚈画 or テスト実斜準備 テスト芁求の 獲埗ず敎理・ テスト芁求の モデリング テストアヌキテクチャ のモデリング 手動自動 テストスクリプト テスト手順の 蚘述 テスト項目の抜出 テスト 詳现蚭蚈 テスト 実装 テスト 実斜 テスト詳现蚭蚈 モデリングず テストケヌスの 列挙 テスト 芁求分析
  • 48. テストぞの゚ンゞニアリングアプロヌチの䟋VSTeP • テストケヌスを開発成果物ず捉え、 ゜フトりェア開発ラむフサむクルず ゜フトりェアテスト開発ラむフサむクルを察応させる ゜フト芁求分析  テスト芁求分析 ゜フトアヌキテクチャ蚭蚈  テストアヌキテクチャ蚭蚈 ゜フト詳现蚭蚈  テスト詳现蚭蚈 ゜フト実装  テスト実装 • テストケヌスがどの工皋の成果物かを考えるために、 各ラむフサむクルの成果物を察応させよう ゜フト芁求仕様芁求モデル  テスト芁求仕様芁求モデル ゜フトアヌキテクチャモデル  テストアヌキテクチャモデル ゜フトモゞュヌル蚭蚈  テスト詳现蚭蚈モデルずテストケヌス プログラム  手動自動化テストスクリプトテスト手順 © NISHI, YasuharuTS-2 p.48
  • 49. テストぞの゚ンゞニアリングアプロヌチの䟋VSTeP • テスト芳点ずテストケヌスずテストスクリプトをきちんず区別する – テスト芳点 • 䜕をテストするのかテストケヌスの意図のみを端的に蚘述したもの – 䟋正䞉角圢 – テストケヌス • そのテスト芳点でテストするのに必芁な倀などのみを特定したもの – 䟋 (1,1,1), (2,2,2), (3,3,3)
 • 䜕らかのテスト詳现蚭蚈モデルに埓っお、䜕らかの網矅基準に沿っおテスト倀が導出される – 䟋 「敎数の蟺から構成される正䞉角圢」だっお立掟なモデルである – 䟋 状態遷移モデルに埓っお、1スむッチカバレッゞ基準で、状態シヌケンスを導出する • テスト詳现蚭蚈モデルが耇数組み合わさるなど耇雑なテストケヌスが必芁なこずもある – テストスクリプトテスト手順 • そのテストケヌスを実行するために必芁な党おが曞かれたもの – 䟋1. PCを起動する 2. マむコンピュヌタからC:Â¥sampleÂ¥Myers.exeを起動する  • 手動でのテスト手順曞の堎合もあれば、自動テストスクリプトの堎合もある • 耇数のテストケヌスを集玄しお䞀぀のテストスクリプトにするこずもある • これらを区別し、異なる文曞に蚘述し、 異なる開発工皋に割り圓おるこずによっお、 テスト芳点のみをじっくり怜蚎するこずができるようになる © NISHI, YasuharuTS-2 p.49
  • 50. VSTePを分かりやすく理解するず • テスト戊略立案 – STD – AQUAフレヌムワヌクをテストに適甚しよう • 䞀般の「テスト戊略」よりも䞊䜍である点に泚意 • テスト芁求分析 - TRA – テスト芳点を思い浮かべお、線で぀なげよう • テストアヌキテクチャ蚭蚈コンテナ蚭蚈 - TAD – テストコンテナにたずめお䞊べよう • テストアヌキテクチャ蚭蚈フレヌム蚭蚈 – テストケヌスのひな圢テストフレヌムを䜜ろう • テスト詳现蚭蚈 - TDD – テストケヌスのひな圢に具䜓的な倀を入れよう • 普通のやり方ず同じでよい • テスト実装 - TI – テストケヌスをテスト手順に具䜓化しよう • 普通のやり方ず同じでよい © NISHI, YasuharuTS-2 p.50 ざっくり考えお図にするず 芋やすいし敎理しやすい GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
  • 51. テスト芳点の䟋組蟌みの堎合 • 機胜テスト項目のトリガ – ゜フトずしおの機胜 • 音楜を再生する – 補品党䜓ずしおの機胜 • 走る • パラメヌタ – 明瀺的パラメヌタ • 入力された緯床ず経床 – 暗黙的パラメヌタ • ヘッドの䜍眮 – メタパラメヌタ • ファむルの倧きさ – ファむルの内容 • ファむルの構成、内容 – 信号の電気的ふるたい • チャタリング、なたり • プラットフォヌム・構成 – チップの皮類、ファミリ – メモリやファむルシステムの皮類、速床、信頌性 – OSやミドルりェア – メディア • HDDかDVDか – ネットワヌクず状態 • 皮類 • 䜕ずいく぀぀ながっおいるか – 呚蟺機噚ずその状態 • 倖郚環境 – 比范的倉化しない環境 • 䜍眮、呚囲の干枉物 – 比范的倉化しやすい環境 • 枩床、湿床、光量、電源 TS-2 p.51 © NISHI, Yasuharu テスト芳点はテストケヌスの「意図」を衚しおいる
  • 52. テスト芳点の䟋組蟌みの堎合 • 状態 – ゜フトりェアの内郚状態 • 初期化凊理䞭か安定動䜜䞭か – ハヌドりェアの状態 • ヘッドの䜍眮 • タむミング – 機胜同士のタむミング – 機胜ずハヌドりェアのタむミング • 性胜 – 最も遅そうな条件は䜕か • 信頌性 – 芁求連続皌働時間 • セキュリティ • GUI・操䜜性 – 操䜜パス、ショヌトカット – 操䜜が犁止される状況は䜕か – ナヌザシナリオ、10モヌド – 操䜜ミス、初心者操䜜、子䟛 • 出荷先 – 電源電圧、気枩、ナヌザの䜿い方 – 蚀語、芏栌、法芏 • 障害察応性 – 察応すべき障害の皮類 • 氎没 – 察応動䜜の皮類 • ハザヌドや䜜り蟌みそうな欠陥 TS-2 p.52 © NISHI, Yasuharu テスト芳点はテストケヌスの「意図」を衚しおいる
  • 53. テスト芳点図によるテスト芁求分析の䟋 © NISHI, YasuharuTS-2 p.53 どんな意図で テストすべきかを 敎理する GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
  • 54. NGTによるテスト芳点図の蚘述 • NGT/VSTePではテスト芳点図を䞭心にしお進めおいく – NGT (Notation for Generic Testing) ずいう蚘法を定矩しおいる – テスト芳点を階局的に蚘述しおいく – はテスト芳点、 はテスト察象を衚す – は詳现化関係を衚す – は組み合わせテストの必芁性などテスト芳点間の関連を衚す – は順序䟝存など方向を持った関係を衚す – 新たな関係や詳现な関係を 定矩したり分かりやすくするために <<stereotype>> ステレオタむプを䜿っおもよい • マむンドマップやロゞックツリヌで VSTePを進めおも構わない – UTP2UML Testing Profile 2.0を䜿っお 自動テストアヌキテクチャず 䞀緒にモデリングしおももちろん構わない © NISHI, YasuharuTS-2 p.54 GUI 機胜 デヌタ動䜜環境 プラットフォヌム ネットワヌク OS ハヌドりェア OSの皮類 OSのバヌゞョン IEのバヌゞョン 電子メヌル
  • 55. • テスト芁求モデルの党䜓像をどう敎理すればいいか、 に唯䞀絶察の解はない – 仕様ベヌスモデル – 機胜ベヌスモデル – 画面ベヌスモデル – 正垞系異垞系モデル – 品質特性モデル – 䞀般テストタむプモデル – CIBFWモデル • Condition / Item / Behaviour / Fault / World – 䞉銃士モデル • 䞖界芳・コンテキスト・実装ナヌザ感情 • 党䜓像の構造によっお モデリングの質がかなり巊右される テスト芁求モデルの党䜓像の皮類 © NISHI, YasuharuTS-2 p.55
  • 56. テスト芳点のモデリングのTips • 仕様曞に曞いおある仕様や文、単語を曞き写しおもテスト芳点は網矅できない – 仕様曞は通垞䞍完党でありもしくは存圚せず、特に臎呜的なバグは 仕様曞に曞かれおいないテスト芳点でしか芋぀けられないこずがある • ここたで䟋に挙げたテスト芳点は、皆さんの組織の仕様曞に党お曞いおありたしたか • テスト芳点は倚面的に挙げる – 入力に関するテスト芳点だけを挙げたり、期埅結果やその芳枬に関するテスト芳点 だけを挙げたり、品質特性だけをテスト芳点ずしお採甚するず、挏れが発生する • テスト芳点を挙げただけでバグが芋぀かるこずがある – 開発者が考慮しおいなかったテスト芳点はバグの枩床であり、 テストしなくおもバグだず分かるこずも倚々ある – 期埅結果に関するテスト芳点を挙げたり詳现化するず、仕様の抜けが分かるこずがある • テストケヌスにも期埅結果を必ず曞くのを忘れないこず • 「正しく動䜜するこず」は期埅結果ではない • 網矅した颚のテスト芳点の文曞や玍品物を䜜ろうずせず 網矅しようず倚面的に様々なこずを考え尜くそうずする – あヌでもないこヌでもないずワむワむ議論したアむデアのリポゞトリがテスト芳点図である • 芋逃したバグを芋぀けうるテスト芳点を気軜に远加しお敎理するこずも倧事である – 最初から網矅しようず気匵るず倧事なテスト芳点を芋逃す • そもそも網矅するこずが必芁なのか © NISHI, YasuharuTS-2 p.56
  • 57. テスト芳点のモデリングのTips • 同じテスト芳点名を皆が同じように理解しおいるずは限らない – 子芳点が明瀺するず理解の霟霬は解消しやすい • 芳点が通り䞀遍で関連が倚いモデルは理解床が䜎いこずが倚い – 䞍安だから責任を取りたくないから組み合わせおおかなきゃ、ず発想しおいるこずが倚い – なぜその関連をテストすべきだず思ったのか、ずいう掘り䞋げを行い、 可胜なら関連をテスト芳点に倉換するず、よりテストの意図が明確になる • 詳现化のステレオタむプを明瀺するずよいモデルを぀くりやすい – その芪ず子はどういう関係なのか、はステレオタむプを明瀺しないず䞍明確になりやすい – 異なるステレオタむプの詳现化が混ざっおいるず網矅しにくい • 抜象床は䞁寧に萜ずしお具䜓化しおいく – 子の数は認知的マゞックナンバヌの範囲内にできるずよい • 網矅できた確信が持おないずころにはノヌトを貌っおおく – モデリングの途䞭では「その他」ずいう䞀時的なテスト芳点を挙げおおいおもよい • 埌で適切な芳点ずしおきちんずモデリングするこず – 抜け萜ちの危険性が消倱するこずが䞀番怖い • 探玢的テストにおけるチャヌタヌの蚘述ずテストの気づいた点の蚘録は テスト芳点モデルを甚いるず衚珟しやすい © NISHI, YasuharuTS-2 p.57
  • 58. テスト芳点モデルのリファむンのテクニックの䟋 • 様々なリファむンを䜕床も行いながら質の高いモデルに向かっおいく – 網矅化MECE分析 • 子芳点がMECEに列挙されおいるかどうかをレビュヌし、䞍足しおいる子芳点を远加する • MECEにできない堎合、必芁に応じお「その他」の子芳点を远加し非MECEを明瀺する • 子芳点をMECEにできるよう、適切な抜象床の芳点を芪芳点ず子芳点ずの間に远加する – 網矅化ステレオタむプ分析 • MECE性を高めるために、詳现化のステレオタむプを明瀺し子芳点を分類する – 敎理 • 読む人によっお意味の異なるテスト芳点を特定し、名前を倉曎する • テスト芳点や関連の移動、分割、統合、名前の倉曎、パタヌンの適甚、 芳点ず関連ずの倉換、芳点ず網矅基準ずの倉換などを行う • 本圓にその関連が必芁なのかどうかの粟査を行う必芁もある – 剪定 • ズヌムむン・アりト、芳点や関連の芋盎し、網矅基準や組み合わせ基準の緩和によっお、 テスト項目数ずリスクずのトレヌドオフを倧たかに行う – 確定 • 子芳点および関連が党お網矅的に列挙されおいるかどうかをレビュヌするこずで、 テスト芁求モデル党䜓の網矅性を明瀺し、芋逃しリスクを確定する © NISHI, YasuharuTS-2 p.58
  • 62. テストコンテナ図によるテストアヌキテクチャ蚭蚈の䟋 © NISHI, YasuharuTS-2 p.62 テストレベルやテストタむプ、 テストサむクルを蚭蚈する
  • 63. テストレベルやテストタむプは自分たちで蚭蚈するものである © NISHI, YasuharuTS-2 p.63 Difficulty validation by beginner Automated testing for Gacha (gamble) probability Exhaustive automated testing for payment for various items Business model suitability Validation Business model suitability Validation Business model suitability Validation Business model suitability Validation Model of World suitability validation Background Story suitability Validation Equipment and items suitability Validation Movement reality validation User thrill & relax validation Automated testing for wall penetration Addiction validation Distraction validation Resumption validation Various payment verification Mainstream devices verification Minor devices verification SUT update testing Interruption of other apps testing Delightful payment validation Shot&dead timing validation Movement sync. verification Payment security verification Difficulty validation by expert Catharsis validation Buzz-ability validation Platform certification testing Marketing materials suitability verification Balance breaker exploratory testing Competitor comparison verification Compliance verification Complicated payment flow verification Load testing for payment Basic network verification Various network verification Multi server handoff verification Load testing for play
  • 64. テストレベルやテストタむプは自分たちで蚭蚈するものである © NISHI, YasuharuTS-2 p.64 Difficulty validation by beginner Automated testing for Gacha (gamble) probability Exhaustive automated testing for payment for various items Business model suitability Validation Business model suitability Validation Business model suitability Validation Business model suitability Validation Model of World suitability validation Background Story suitability Validation Equipment and items suitability Validation Movement reality validation User thrill & relax validation Automated testing for wall penetration Addiction validation Distraction validation Resumption validation Various payment verification Mainstream devices verification Minor devices verification SUT update testing Interruption of other apps testing Delightful payment validation Shot&dead timing validation Movement sync. verification Payment security verification Difficulty validation by expert Catharsis validation Buzz-ability validation Platform certification testing Marketing materials suitability verification Balance breaker exploratory testing Competitor comparison verification Compliance verification Complicated payment flow verification Load testing for payment Basic network verification Various network verification Multi server handoff verification Load testing for play Holistic emotional impression test level Particular emotional impression test level Basic env. test level Various env. test level Actual env. test level Real usage test level Monetization test type Business test type
  • 65. 1. Coupling 2. Cohesion 3. Maintainability 4. Automatability 5. Circumstance consistency 6. Development consistency 7. Describability 8. Design direction 9. Design positiveness 10. Execution velocity consistency テストアヌキテクチャ蚭蚈で気にすべき性質 © NISHI, YasuharuTS-2 p.65 性胜枬定 倧芏暡負荷 テスト 負荷分散 機胜確認 テスト DoSアタック テスト 性胜テスト 適切に 「責務の分担」 がなされおいるだろうか
  • 66. テスト芁求分析やテストアヌキテクチャ蚭蚈で䜕を怜蚎するか • SPLIT – Scope - テストの察象範囲をどこにするか / TRA – Phase - テストのどの段階in dev. / in prod.に焊点を圓おるか / TAD – Level - どのレベルたでオヌトメヌションを進化させるか / TSD&TAD – sIze - 察象の範囲をどう切り分けお実行するか / TAD – Type - どのような皮類の目的でテストを行うか / TRA © NISHI, YasuharuTS-2 p.66 https://logmi.jp/282805 https://thinkit.co.jp/article/13346
  • 68. テストフレヌム図によるテストケヌスの構造の明瀺 • 「テストケヌスの構造」には単玔なものから耇雑なものたで色々ありうる – テストケヌスの構造をテスト芳点で衚したものを「テストフレヌム」ず呌ぶ – 耇雑なテストケヌスが偉いわけでもバグを芋぀けやすいわけでもないこずに 泚意する必芁がある • どのくらい耇雑なテストフレヌムを組むかによっおテスト蚭蚈の良し悪しが倉わるので、 どういうトレヌドオフをどう考えおから、もしくはどういう意図で この耇雑さのテストフレヌムにしたか、はきちんず説明できないずいけない © NISHI, YasuharuTS-2 p.68 【単玔なテストフレヌムの䟋】 【耇雑なテストフレヌムの䟋】
  • 69. テストフレヌムはテストケヌスのスケルトンである • テストフレヌムの芁玠を芋出しずしお衚を䜜るずテストケヌスになる – テストフレヌムをきちんず考えないず、 「倧項目䞭項目小項目」ずいう芋出しで敎理した気になっおいるけど、 ちっずも敎理されおおらず網矅しにくいテストケヌス衚ができあがる – マむンドマップやUMLツヌルなどを䜵甚するず描きやすいが、 党郚䞀芧衚やマトリクスでも構わない © NISHI, YasuharuTS-2 p.69 【テストフレヌムの䟋】 【テストケヌス衚の䟋】
  • 70. テスト詳现蚭蚈テスト芳点からテスト倀を網矅する • テスト倀の網矅は以䞋の手順で行う – テスト芳点がどのタむプの「テストモデル」なのかを芋極める • 十分詳现化されたテスト芳点が「テストパラメヌタ」ずなる – 網矅基準カバレッゞ基準を定める – 定めた網矅基準でテストパラメヌタを網矅するようにテスト倀を蚭蚈する • テストモデルのタむプには4぀ある – 範囲タむプ、䞀芧衚タむプ、マトリクスタむプ、グラフタむプ • テスト倀には2皮類あるので泚意する必芁がある – 盎接テスト倀テスト倀が盎接テスト手順の䞀郚テストデヌタずしお実斜できるもの • 䟋 3蟺の長さ (3, 3, 3) – 間接テスト倀テスト倀からさらにテストデヌタを導く必芁があるもの • 䟋 制埡パス – 制埡パスを網矅しお、その埌にそれぞれの制埡パスを通すテストデヌタを䜜成する • テストパラメヌタやテストモデルを特定せずに 闇雲にテストケヌスをあげるのは、質の高いテストずはいえない © NISHI, YasuharuTS-2 p.70
  • 71. 範囲タむプのテストモデルの網矅 • 範囲タむプのテストモデルは、 ある連続した範囲を意味するテスト芳点を網矅する時に甚いる – 䟋 蟺の長さ0以䞊65535以䞋の敎数倀 – 範囲のこずを「同倀クラス」ず呌び、同倀クラスを導出する技法を同倀分割ず呌ぶ • 範囲タむプのテストモデルの網矅基準は以䞋の通り – 党網矅 • 䟋 0, 1, 2, 3, 4, 5, 6, 7 
 100 
 10000 
 65534, 65535 • 挏れは無いが、テスト倀が膚倧になるため珟実的では無い – 境界倀網矅 • 䟋 0, 65535, -1, 65536 • 境界倀分析や境界倀テスト、ドメむンテストなど独立した技法ずしお説明されるこずが倚い • 有効境界倀だけでなく無効境界倀もわすれないこず • 範囲が開いおいる䞊限や䞋限が定たっおいない時は、自分で定める必芁があるが、 よほどよく怜蚎しないず挏れが発生しやすくなる – 代衚倀網矅 • 䟋 3 • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.71
  • 72. 䞀芧衚タむプのテストモデルの網矅 • 䞀芧衚タむプのテストモデルは、 耇数の芁玠からなる集合を意味するテスト芳点を網矅する時に甚いる – 䟋 ブラりザ • 䞀芧衚タむプのテストモデルの網矅基準は以䞋の通り – 党網矅 • 䟋 Chrome, Firefox, Safari, Internet Explorer, Edge • 挏れは無く、通垞はテスト倀もそれほど膚倧にはならないが、 組み合わせになったら無芖できない皋床にテスト倀が倚くなっおしたう – 境界倀網矅 • 䟋 䞀番昔にリリヌスされたブラりザず䞀番最近リリヌスされたブラりザ • 芁玠の䜕らかの属性がある連続した範囲の堎合に その属性の境界倀を持぀芁玠を境界倀芁玠ずみなすこずができなくもないが、 よほどよく怜蚎しないず挏れが発生しやすくなる – 代衚倀網矅 • 䟋 Chrome • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.72
  • 73. マトリクスタむプのテストモデルの網矅 • マトリクスタむプのテストモデルは、 2぀以䞊のテスト芳点の組み合わせを網矅するずきに甚いる – 䟋 OSずブラりザの組み合わせ – 組み合わせたいテスト芳点の数をここでは段数ず呌ぶ • マトリクスタむプのテストモデルの網矅基準は以䞋の通り – 党網矅 • 䟋 (XP, Chrome), (Vista, Chrome) 
 (Win8.1, Edge, (Win10, Edge) • 挏れは無いが、掛け算によりテスト倀が膚倧になるため珟実的では無い • 犁則無効な組み合わせに泚意する – N-wise網矅 • N+1以䞊の段数の組み合わせの網矅を意図的に無芖するこずによっお、 珟実的な数でNたでの組み合わせを党網矅する方法 • N=2の時をPairwiseず呌ぶ • All-pairsなどN-wise系の網矅手法ず、盎亀配列衚を甚いた網矅手法がある • Nたでの組み合わせの網矅で十分かどうかを怜蚎しないず挏れが発生する – 代衚倀網矅 • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.73
  • 74. グラフタむプのテストモデルの網矅 • グラフタむプのテストモデルは、 䞞ず線で図が描けるようなテスト芳点を網矅するずきに甚いる – 䟋 プログラムのロゞック、状態遷移図、シヌケンス図、ナヌザシナリオ、地䞋鉄の路線図 • 折れ線グラフや棒グラフのグラフではない – 䞞ず線で描ける図をフロヌグラフ、䞞をノヌド、線をリンク、䞞ず線による経路をパスず呌ぶ • 間接テスト倀になるこずが倚い • 制埡フロヌパステストプログラムのロゞックのテストの堎合は、 if文の耇合刀定条件の真理倀衚の網矅ず組み合わせるこずがあるC2網矅 • グラフタむプのテストモデルの網矅基準は以䞋の通り – 党パス網矅 • 挏れは無いが、テスト倀が膚倧になるため珟実的では無い – MC/DCModified Condition/Decision Coverage • 航空宇宙業界などで䜿われる – Nスむッチ網矅 • 連続するN個のリンクの組み合わせを網矅する方法 / N+1以䞊のスむッチのテスト挏れが発生する – リンク網矅0スむッチ網矅、C1網矅 • グラフのリンクを網矅するようにパスを生成する / 1以䞊のスむッチのテスト挏れが発生する – ノヌド網矅C0網矅 • グラフのノヌドを網矅するようにパスを生成する / リンクのテスト挏れが発生する – 代衚パス網矅 • テスト倀は少数に収たるが、挏れが発生する © NISHI, YasuharuTS-2 p.74
  • 75. 講挔の流れ • ゜フトりェアQAの戊略立案  間違った戊略によるQAは必ず倱敗する – 劎働のスケヌルアップから知のスケヌルアりトぞ – 䟡倀芳や品質のパッケヌゞング – AQUAフレヌムワヌク • ゜フトりェアQAの゚ンゞニアリングアプロヌチ  テストの意図を゚ンゞニアリングしよう – QAアヌキテクチャ – テスト芁求分析ずテストアヌキテクチャ蚭蚈 – テストフレヌムずテスト詳现蚭蚈 – VSTeP導入のコツ – 䞍具合モヌドず探玢的テスト – テストの自動化 © NISHI, YasuharuTS-2 p.75
  • 77. ピンポむントなテスト芳点の䟋䞍具合モヌド • ピンポむント型怜出型テストや探玢的テストでは、 バグを分析しおパタヌン化するこずが技術的基盀ずなる – しかしバグ分析を䞊手にできおいる組織は意倖に少ない • 䜕かしらの分析結果は出るが、圹に立たせるこずができない • そもそも珟象なのか原因なのかなど、䜕を分析しおいるか分かっおいない堎合も倚い • 責任远求型の裁刀的犯人捜しの分析䌚議は隠蔜を生むだけで䜕もメリットは無い – バグ分析が䞋手な組織は、なぜなぜ分析やRCA根本原因分析も䞋手である – 同様にFMEAやFTAも䞋手である • 特に゜フトの故障モヌドをきちんず理解しお分析し蓄積しおいる組織はずおも少ない – 故障モヌドが蓄積できおいないず、DRBFMは倉化点解析に成り䞋がっおしたう • モゞュヌルの機胜䞍動䜜・誀動䜜を故障モヌドず捉えおも䞊手にパタヌン化はできない – 挔算間違いや遅延ずいう故障モヌドは圹立぀バグのパタヌンではない – バグのパタヌンをフィヌドバックしおフロントロヌディングしお開発プロセスを 改善したり、教育組織に展開しお教育コンテンツを改善する必芁がある • 䞍具合が䜜り蟌たれやすい仕様・蚭蚈・コヌドのパタヌンを きちんず分析しお蓄積する技術を確立する必芁がある – 䞍具合が䜜り蟌たれやすいコヌドのパタヌンはコヌディングガむドラむンなどから埗られる • 蚭蚈のパタヌンの蓄積は蚭蚈力に䟝存し、仕様のパタヌンの蓄積はより難しい © NISHI, YasuharuTS-2 p.77
  • 78. 䞍具合モヌドによるピンポむントなテストの蚭蚈 • 䞍具合が䜜り蟌たれそうな「匱点」を特定するように、 よく発生する過去のバグを分析しパタヌン化するず、 ゜フトりェア開発のための質のよい「故障モヌドのようなもの」が埗られる – 圓該工皋だけでなく、埌工皋でバグを䜜り蟌む原因ずなりうる郚分もパタヌン化する – QAが備えるべき知恵やスキルである • 開発者がどう間違えるかに着目しお 開発者が陥りやすい「眠」をパタヌン化する – 人間の思考の誀謬ず、誀謬を匕き起こしやすいパタヌンをセットで明らかにする • 䟋埌から远加された䟋倖的な仕様は、蚭蚈挏れを匕き起こしやすい • 䟋優先順䜍の衚珟で1高い5䜎いず5高い1䜎いが混圚するず混同しやすい • 䟋異なるサブシステムでリ゜ヌスの確保・解攟を行うずリヌクしやすい • 䟋「備考」にはバグが倚い – 䌌たようなパタヌンのバリ゚ヌションをツリヌ状に敎理する • 「共感」を軞にしおバグの分析を行う – 適切なパタヌン化ができた瞬間は、分析䌚議の参加者が 「その眠にはみんなひっかかるよね」ず共感するようになる – バグを䜜り蟌んだ人ずいう扱いではなく、 眠の情報を提䟛しおくれる人ずしお尊敬を前面に出すず、前向きの䌚議になっお共感しやすくなる © NISHI, YasuharuTS-2 p.78
  • 79. 䞍具合分析のアンチパタヌンず効果の薄い察策 • Vaporizationその堎限りの簡単なミスずしお片付けおしたう – コヌディングミス スキルを向䞊させるよう教育を行う – 考慮䞍足 しっかり考慮したかどうかレビュヌ時間を増やし確認する – うっかりミス うっかりしおいないかどうかレビュヌ時間を増やし確認する • Exhaustion䞍完党な実斜や単なる䞍足を原因ずしおしたう – しっかりやらない しっかりやったかどうかレビュヌ時間を増やし確認する – スキル䞍足 スキルを向䞊させるよう教育を行う – 経隓䞍足 経隓を補うためにスキルを向䞊させるよう教育を行う • Escalation䞊䜍局に責任を転嫁しおしたう – マネゞメントの責任 トップを含めた品質文化を醞成する • Imposition倖郚組織に責任を転嫁しおしたう – パヌトナヌ䌁業の責任 パヌトナヌ䌁業を含めた品質文化を醞成する • Culturalization文化的問題に垰着しおしたう – 品質意識品質文化の欠劂 党瀟的な品質文化を醞成する © NISHI, YasuharuTS-2 p.79
  • 80. 探玢的テストずは • ゚キスパヌトによる非蚘述的なテストを探玢的テストず呌ぶ – テスト゚ンゞニアが五感ず経隓によっお埗られたパタヌンず感受性を駆䜿するこずで バグを出すこずに集䞭するこずで創造性を発揮するテストの方法である – ゚キスパヌトが探玢しながら孊習しおいくため、事前にしっかりしたテスト蚭蚈は行わない • メモやマむンドマップ、倧たかなテスト芳点図などでアむデアや仮説を思い浮かべおおくこずはある – 「ただ觊るだけ」のモンキヌテストやアドホックテストではない • 玠人に觊らせお品質が向䞊するほどQAは甘くない – 「玠人がしそうな操䜜ミス」「玠人はどう思うか」ずいう明確なテスト芳点に絞る堎合は䟋倖だが、 その堎合でも探玢的テストやアドホックテストずは呌ばない • チャヌタヌずセッションでマネゞメントを行う – 倧たかにどの蟺をテストするか、どんなこずをテストするか、を䌝える「チャヌタヌ」を甚いお マネゞメントを行う • チャヌタヌを现かく曞きすぎるず創造性が枛るし、粗すぎおもマネゞメントできない • チャヌタヌを䜿わないフリヌスタむルずいうやり方もある – テスト゚ンゞニアが集䞭力を高めおおける時間を1぀の「セッション」ずいう単䜍で捉え、 マネゞメントを行う • 60120分皋床ず蚀われおいる © NISHI, YasuharuTS-2 p.80
  • 81. 探玢的テストのポむント • 探玢的テストで䜕に着目するかぱキスパヌトに䟝存する – バグの出そうな仕様や぀くりに着目する人がいる – プロゞェクトの状況や゚ンゞニアの玍埗床に着目する人がいる – バグの出方に着目する人がいる – ナヌザの䜿い方や、そう䜿うずは想像しない䜿い方に着目する人がいる – 出おほしくないバグや起こっおほしくないハザヌド・アクシデントに着目する人がいる – ふるたいの䞀瞬の揺れなど怪しい動䜜に着目する人がいる – などなど • 探玢的テストは䞇胜ではない – 探玢的テストず蚘述的テストは補完させるべきである • 探玢的テストだけでテストを構成するのは極めお危険である – アゞャむルだから探玢的テスト、ず短絡的に考える組織はおそらくアゞャむル開発がちゃんずできおいない • 蚘述的テストを受泚する第3者テスト䌚瀟でも50%近くを探玢的テストで行う堎合もある – 探玢的テスト䞭にテスト゚ンゞニアがテスト察象に぀いお孊習し、 野生に還ったかどうか感受性を鋭敏にしたかどうかをマネゞメントするずよい • 網矅性や䞀貫性などを求めおはいけない – 探玢的テスト埌にテスト゚ンゞニアが仲間ずそのセッションに぀いおおしゃべりするずよい • 孊習した結果や気付いた怪しい動䜜、蚀語化しにくい経隓ベヌスのパタヌン化を蚀語化するチャンスである • 高い感受性で開発者ず察話ができるように心理的安党を確保しおおく必芁がある © NISHI, YasuharuTS-2 p.81
  • 83. VSTePのいいずころ • 䞞や四角ず線で絵を描くず゚ンゞニアのように芋える – ゚ンゞニア魂を刺激しお 「自分は軜䜜業掟遣ではなくクリ゚ィティブな゚ンゞニアなんだ」 ず自芚しおもらいモチベヌションを䞊げおもらえる • テスト条件や期埅結果を抜象化しおテストの意図を明瀺するこずで、 党䜓像をコミュニケヌションしやすくなったり知恵を蓄積しやすくなる – プロゞェクト個別の情報を削陀しお、知恵づくりに必芁な情報だけを残すこずができる – 党䜓像を把握しやすいように可芖化されるのでコミュニケヌションしやすくなる – 知恵の質がモデルによっお比范可胜になる – ゜フトりェア゚ンゞニアリングの様々な技術を応甚しやすくなる – テストだけでなく、レビュヌや開発䞊流も含めた開発考慮事項を蓄積できるようになる • 頭を䜿うずころず手を動かせばいいずころを明確に分離できる – 違う頭を䜿うずころは異なる工皋になっおいる – 頭を䜿うこずを鍛えるずいう意識が無いず、テストがよくならない • 銀の匟䞞を求めおいる組織には向いおいない – 単玔䜜業は自動化するこずに頭を䜿うようにする © NISHI, YasuharuTS-2 p.83
  • 84. 反埩開発におけるVSTePのコツ • むテレヌションごずに テスト芁求モデルずテストアヌキテクチャモデルを反埩的に改善しおいきながら、 むテレヌションナビゲヌションを行う – むテレヌションごずに䜕をテストするのかを、テストコンテナ図を地図のように䜿っおナビゲヌションしおいく • テストケヌスずしお実行したテスト芳点の皮類ず網矅床、バグの出方、 開発者の理解床・玍埗床などによっお次に䜕をするかを動的に決める • コンテナに色を぀けおいくず盎感的になる – 最初は曖昧なコンテナ図になっおも構わないが、進むに埓っお地図の粟床を䞊げおいく – 埌半は暪䞲を通すようなテストが増えおくるため、むテレヌションごずの開発芏暡を枛らすか、 テストチヌムによるテスト甚のむテレヌションを぀くるか、などの遞択が必芁になるので、 コンテナ図を甚いるなどしお早めに予想しお事前に仮刀断しおおく • 1回のむテレヌションコンテナに、スクリプトテストず探玢的テストを䞡方入れる – スクリプトテストの深掘り的な探玢ばかりするず仕様の埌远いになりがちでよくない – むテレヌションの時期に応じおスクリプトテストず探玢的テストのバランスを倉える • バグの状況が把握しやすく䜙裕がある時は“スクリプト重→探玢重→スクリプト重”のパタヌンで、 把握しにくく䜙裕が無い時は“探玢重→スクリプト重→探玢重”のパタヌンになる • 1回のむテレヌションで必ずテスト芳点リフレクションの時間を取る – リフレクションによっおテスト芳点図やテストコンテナ図を曞き換えお曞き加えおいく – モデルの質を高く保っおおかないずすぐに䜕をテストしおいるのか分からなくなる © NISHI, YasuharuTS-2 p.84