史跡めぐり 平泉~衣川、つわものどもが夢の跡(2)

JaSST Tohokuへ行ったついでに平泉、衣川へ行ってきました。ちょうど今年は大河ドラマでも平泉が出てきたこともあって一度訪れてみたかったのです。せっかくなので一日がっつり観光してきました。むしろ一日では足りなかったので再訪したい。

中尊寺

有名な金色堂のある中尊寺にも参拝してきました。参道沿いにあるお堂にお参りしながら月見坂を上っていきます。そこそこ長い坂なので、熱い時期はつらいかもしれません。タクシーだと坂の上にある金色堂のそばまで上がれるという話を聞いたので、体力に自信がなかったり気候がイマイチなときに行く方はタクシー利用が良さそうです。

月見坂。道沿いの木が立派

お堂色々

初めての中尊寺ということもあって、月見坂沿いに点在しているお堂やビューポイントを巡りながら登ることにしました。

月見坂沿いにある弁慶堂。他にもお堂がいくつもあります。
弁慶堂のあたりから見た風景。北上川とそれに注ぐ衣川が見えます。衣川は水面見えてませんが文字を付けたあたりから北上川方面に伸びてる緑のラインが川の土手です。
弁財天堂。黄色のあやめが咲いていて綺麗でした。もみじの時期も美しいと思う。

讃衡蔵

往時は大伽藍だったそうですが当時のものの多くは焼失しており、建立当時から現存する建物は金色堂と経蔵のみになります。ただ、寺宝のいくつかは今も伝えられており、一部は中尊寺の宝物館である讃衡蔵(さんこうぞう)で拝観できます。私が行ったときには、古くから伝わる仏像とか、中尊寺経という名前でも知られる紺紙金銀字交書一切経などが展示されていました。
当時から伝わる品々は本当に贅を尽くしたという感じでした。平泉のガイダンスセンターで藤原清衡の生涯と中尊寺建立の願文に触れていたので、月並みな感想ですが、彼が平和を祈って本当にできる限りのことを中尊寺に注いだのだろうなということが窺えました。

金色堂

藤原清衡が一番力を入れていたのではないかと思うのが、やはり金色堂です。

金色堂。内部は撮影禁止なのでここからのアングルのみ。

お堂の中に入ると、ガラスケースの向こう側に金色堂が見えます(仕方のないことなんですが、ガラスケースの向こうにあるとどうも「展示品」っぽく見えてしまう)とはいえ、建物全体が金箔に覆われ、内陣も金箔や蒔絵、螺鈿で飾られて贅を尽くしたものでした。讃衡蔵で読んだ解説によると、螺鈿に使われる夜行貝は沖縄あたりで採れるものだそうなので、奥州藤原氏が独自の交易ルートを持っていたことが分かるそうです。
奥州藤原氏三代の遺体と四代目泰衡の首級もこちらに安置されています。金色堂は一度訪れてみたかったところなので今回訪問できて本当に良かったです。

経蔵

金色堂と並んで建立当時から残っているのが経蔵です。往時はこちらに「中尊寺経」が収蔵されていたそうです。

経蔵。静かな佇まいがきれいでした。

覆堂

かつて金色堂を覆うために建てられたのが覆堂(おおいどう)です。(覆堂が建つまでは金色堂がそのまま風雪にさらされる形で立っていたのもすごい気がします。金閣寺のような感じだったのでしょうか)金色堂の保護という役割から内部に柱がない独特の構造となっているとのことでした。

覆堂は人が多くて正面の写真が撮れなかったので、松尾芭蕉銅像と覆堂側面の写真です。

平泉文化遺産センター

中尊寺から毛越寺への近道の途中にある文化施設で、敷地内には蔵王権現堂の跡と伝わる花立廃寺跡もあります。

この下に花立廃寺の遺構が埋まっています。

展示内容はガイダンスセンターと重複するところもありますが、こちらでは中尊寺ハスの剥製が見られます。

中尊寺ハスの花

中尊寺ハスは奥州藤原氏の四代目・泰衡の首桶の中に収められていたハスの種を、研究者の方が時を越えて発芽させたものです。800年前の種を発芽させられるのすごいですね。
泰衡の首に誰がどんな思いでハスの種を供えたのか想像すると色々なドラマがありそうです。結果的に泰衡の代で奥州藤原氏が滅亡してしまったので当主としてはあまりよい評価はされてないように思いますが、ハスの種を供えて先祖代々の傍に葬ってくれた人はいたということですよね。
中尊寺ハスは一度実物が咲いているのを見てみたいです(しかしハスの咲く時期は暑いのがネック)

無量光院跡

無量光院は奥州藤原氏三代目の藤原秀衡が建立した寺院です。往時は宇治の平等院鳳凰堂を模したお堂が建っていたとのことですが、現在は池のみが復元されています。平泉の信仰の山である金鶏山がちょうど西の背後になるよう建てられており、西方浄土を表したものだったそうです。
ここは午前中に立ち寄る予定だったのが、ルートを間違えて午後3時頃に訪れました。結果的にちょうど西に日が傾きだした時間帯になり、西の金鶏山から光が差してくる形になってよい雰囲気でした。たぶん夕方日の沈む時間帯に訪れると綺麗だと思います。

無量光院跡の復元された池。逆光気味ですが、金鶏山方向にかかる雲とその向こうの太陽で雰囲気のある写真になった気がします。

観自在王院

観自在王院跡は奥州藤原氏の2代目・藤原基衡正室が基衡の死後に建立したお寺です。現在は残っていませんが、舞鶴が池を中心にお庭が復元されています。平安時代の御庭造りの教科書『作庭記』によると「池は鶴か亀の形に掘るべし」を基にしたと考えられているそうです。

南門跡。写真で見えている範囲はほぼ観自在王院の境内にあたります。広大!
舞鶴が池。ちょうどお花が咲いていて優美な雰囲気でした。

毛越寺

毛越寺藤原基衡・秀衡が建立したお寺で、観自在王院の隣にあります。夫の基衡が建立した毛越寺の隣に、彼の死後正室観自在王院を建立したという時系列だそうです。建立当時から残る建物はありませんが、毛越寺庭園、特に大泉が池とそこに注ぐ鑓水は平安末期の浄土庭園の姿が良好に残っているのだとか。

毛越寺本堂
池。海岸線の荒々しいあたりを模したもの(だったと思います)
池に注ぐ鑓水。蛇行していたり急流と緩やかな流れがあったり、『作庭記』に記された技法が使われてる様子をそのまま見ることができる。曲水の宴も催される。
池に浮かぶ龍船。右のあたりは州浜といって海の波の緩やかなあたりを模したもの
常行堂。青モミジが綺麗でした。

義経公妻子の墓

ここは行こうかどうか迷ってたのですが、毛越寺を見学し終わった後まだ時間があったので「よし、行けるぞ!」ということで行ってきました。平泉の信仰の山である金鶏山の中腹にあります。けっこうな坂道を上るので電動アシスト付き自転車じゃなければ多分諦めてました。

金鶏山登山口

金鶏山への登山道入り口近くに小さなお墓が二基あります。そっと手を合わせて参りました。

ひっそりたたずむ義経公妻子のお墓

少しだけですが山の中に入るので、日の高いうちに行くのがお勧めです。

おまけ

ランチ@Cafe SEKIMIYA

お昼はネットで調べていたCafe SEKIMIYAさんへ。ちょっと路地を入ったところにある静かな雰囲気のカフェです。岩手のブランド豚である佐助豚を使ったメニューがあるとのことでこちらにしました。お肉は柔らかく、付け合わせの野菜も美味しかったです。

佐助豚のポワレがジューシーで美味しかったです。こちらのほかにスープ、デザート、ドリンクがついて1,300円でした。

こがね屋菓子店

駅からちょこっと歩いたところにあるお菓子屋さんです。入って正面のショーケースは洋生菓子が並んでますが、お土産にできそうな和菓子もあります。今回は一音(いっとん)という和菓子を購入しました。胡麻がたっぷり乗った焼餅に、平泉らしく金粉があしらわれています。上品な甘さで美味しかったです。

一音の外袋
焼餅の上に胡麻がたっぷり、写真ではちょっと分かりにくいけど金粉もあしらわれています。

史跡めぐり 平泉~衣川、つわものどもが夢の跡(1)

JaSST Tohokuへ行ったついでに平泉、衣川へ行ってきました。ちょうど今年は大河ドラマでも平泉が出てきたこともあって一度訪れてみたかったのです。せっかくなので一日がっつり観光してきました。むしろ一日では足りなかったので再訪したい。

平泉駅

駅前にレンタサイクル屋さんがあるので、一日予定でレンタルします。こちらでは自転車借りたら手荷物は無料で預かってくれます。これを知らずにコインロッカーに預けてしまった。。。
普通の自転車と電動アシスト付きのものが選べますが、体力に自信のない方は無理せず電動アシスト付き自転車を借りるのがお勧めです。平泉中心部以外にも足を延ばす予定があったり、中尊寺から毛越寺へ近道を通る場合には結構な坂道を通ります。

この日一日お世話になった電動アシスト付き自転車。とてもアシストしてもらった。

伽羅御所跡

まずは平泉駅にほど近い伽羅御所跡へ。こちらは現在住宅地になっていますので案内板くらいしかありません。

伽羅御所跡の案内板

柳御所跡、平泉ガイダンスセンター

案内板を通過して柳御所跡と平泉ガイダンスセンターへ。

ガイダンスセンターの裏側の外観(表の道路側からの外観は撮り忘れました)

こちらで平泉の歴史の概要が学べます。施設も新しくきれいで、入館料無量、なんと音声ガイドも無料で貸し出していただけました。出土品の展示や映像資料も充実してて一時間くらい見いってしまいました。
私は源義経から平泉に興味を持ち、それ以前の安部氏や藤原三代にはあまり詳しくなかったので、こちらで平泉の歴史を学べてよかったです。

特に奥州藤原氏の初代である藤原清衡については知っておくとよいと思います。

清衡が建立した中尊寺の願文の中に建立にかけた思いを想像させる一節があるので、長いですが引用します。

この鐘の一音が及ぶ所は、世界のあらゆる所に響き渡り、苦しみを抜き、楽を与え、生きるものすべてのものにあまねく平等に響くのです。(奥州の地で は)官軍の兵に限らず、エミシの兵によらず、古来より多くの者の命が失われました。それだけではありません。毛を持つ獣、羽ばたく鳥、鱗を持つ魚も数限り なく殺されて来ました。命あるものたちの御霊は、今あの世に消え去り、骨も朽ち、それでも奥州の土塊となっておりますが、この鐘を打ち鳴らす度に、罪もな く命を奪われしものたちの御霊を慰め、極楽浄土に導きたいと願うものであります。

中尊寺落慶願文 より現代語訳版をお借りしました)

藤原清衡は結果的に最後まで生き残ったことで、その過程で色々見たり、どうしようもなく飲み込んだことなどもあったのだろうなあと思われます。願文はもっと長いのですが、個人的にこの部分が一番言いたいことだったのではないかと思っています。ガイダンスセンターでは、この願文の解説のほかにも藤原三代をダイジェストで紹介する映像資料などもあり平泉を巡る予習にばっちりです。

また、ガイダンスセンターのすぐそばの柳の御所跡は柱の跡とかがほとんどなので、ここの解説で当時を想像するヒントになります。
さて、予習を終えてガイダンスセンターの裏手に出ると、そこから柳の御所跡が広がっています。堀や建物の柱跡が復元整備されており、大変広大で当時を偲ばせます。

復元された堀。水のない空堀だったそうです。
中心建物と考えられるあたりの柱跡


御所の池の跡も復元されていました。

池の跡。ガイダンスセンターで見た情報によると池は改修工事があったらしく、復元されているのは初期のバージョンの池だそうです。

ちゃんとごみ処理施設、穴掘って埋めただけのものだけど、もあって、ここで生活していたんだなーという妙な感慨がありました。

汚物廃棄穴群。分かりやすく復元されているのは4つですが、もっとあったらしいです。

高館義経

源義経最後の地・高館があったといわれるところです。北上川を見下ろせる高台の上にあり、小さな資料館と義経堂があります。松尾芭蕉の「夏草やつわものどもが夢の跡」という句でも有名な場所で、句碑もありました。

義経の木像が祀られてるお堂
高館から眺めた北上川。「夏草や つわものどもが 夢の跡」

義経最後の地がどこかは確定してないらしいのですが、ここの高台は館を建てるにはあまりスペースなさそうに見えました。(個人的には、この後にめぐった接待館の方が何となくそれらしい気がします)

衣川地区 接待館

平泉から衣川を越えて衣川地区に向かいます。衣川という地名について深く考えたことはなかったのですが、衣川という川があってその川が流れているあたりの地名も衣川というようです。衣川(川の名前)を挟んで南側が平泉、北川が衣川地区となっています。

衣川(川の名前)。奥の方に見える山には5月末でまだ雪が残っていました。

衣川を越えてから、しばらく衣川沿いに自転車を走らせると接待館跡に着きます。一見すると普通の野原のように見えるので、案内板がなければ見過ごしそうになります。

接待館跡の案内板。発掘で明らかになった内容が解説されてます。

案内板によると、発掘で土塁や宴会に使う「かわらけ」が大量に出土し重要な施設だったことが分かったとのこと。今は見学しやすく草は刈られていますが野原になっているので、ここでも兵どもが夢の跡感を味わえます。

案内板の背後に一段高くなってる部分がありました。発掘終わった後に保護のため埋めた?
この下に接待館の遺構が埋まっています

ちなみにこの接待館近辺は当時市が立って賑わっていたあたりだそうで、衣川七日市場という地名が残っています。

衣川地区 伝並木屋敷跡

接待館から少し自転車を走らせると、伝並木屋敷跡に到着します。こちらは奥州藤原氏の前に東北に勢力を持っていた安部氏の館跡と伝わっています。前九年の役で衣川の柵が落ちるときに源義家と安部貞任の「衣のたてはほころびにけり」「年を経し糸の乱れの苦しさに」のやりとりに詠まれた「衣川の館」ですね。
衣のたての話は、こちらの 『古今著聞集』 衣のたて | 二階の窓から に詳しく紹介されていますのでぜひ。

伝並木屋敷跡の案内板

案内板によると昔は桜並木に囲まれており、政治の中心だったそうです。今はほぼ田んぼと畑になっています。

接待館から並木屋敷までの道沿いにあった田んぼ。この時期の田んぼは空が映りこんで綺麗ですね。

※ちなみに平泉は観光地ですが、衣川に入るとほとんど田園と住宅になるので自販機とかお手洗いはなくなります。接待館と伝並木屋敷跡だけ程度であれば自転車なら一時間程度で回れますが、他の遺構も回りたい場合はご注意ください。駐車場もあまりないので自転車が一番便利だと思います。

中尊寺毛越寺にも行ったのですが、ちょっと長くなったのでに別記事に分けます。

JaSST'22 Tohokuに参加してきました!

5/27(金)に行われたJaSST'22 Tohokuに参加してきました! 開催地・盛岡で久々に現地参加してきたので、会場の熱気も感じられました。

会場のウェルカムボード。てす政宗がかわいい

基調講演

自動化に取り組むにあたり

松尾 和昭さん

講演メモ
  • スコープを区切る
    • テスト範囲を狭めることで、問題発生時の原因の特定を補助、実行時間の短縮などメリットが
  • デモ
    • UI 40s
    • Integration 3s
    • Unit 0.001s
  • 自動化を学んで行くために
    • 社内の助けを得ることが可能な技術から始めるとよいことが多い
    • OSS、公式ドキュメント

  
Q. テストピラミッドの構築具合を可視化したい
A. やりやすいのは件数ベース。
 他には実行時間、UIテストの環境依存の失敗率、変更してないのに失敗しているテストの数

感想

テストの実行時間、対象の性質上差はあるのは理解してたんですが、あまり意識できてなかったので数字でぱっと見せてもらうとこんなに差が出るのかと驚きました。現状で自分のやってる範囲はUIがほとんどなので、目的と実現可能性を考えて範囲を分けられるようになりたい。

ランチセッション

  • 松尾さんに実行委員の根本さんがインタビューしていく形式
  • 事前に集めた質問がmiroに貼ってあり、インタビューが進むにつれてそこにグラフィックレコードが加えられていく
    • なぜアメリカに行ったのかの話からスキルの話まで率直に答えていただけた
    • グラレコが的確でイラストがかわいい。これをリアルタイムにやるの本当にすごい。
  • 根本さんのぶっこんだ質問にも答えていただけて、ランチ時間も充実した楽しめるセッション!
  • オンライン参加だとランチ時間はわりともくもくご飯を食べることが多いけど、これだとオンラインも楽しめて良さそう!

事例セッション

テスト自動化導入後の課題の改善のビフォアアフター

江村 禎昭さん

江村さんの発表資料はこちら。
qiita.com

講演メモ
  • テスト自動化の利用状況
    • 毎日実施、各サービスは2~3週に一度リリース
  • 小さいチーム(サービス)- マニュアルテスト
  • チームの拡大- サービス複数、テストも並行
    • →各サービスのテストが不明確、自動化が仕様変更で失敗増える
  • Phase1 組織が大きくなる- 自動化チームの役割がさまよう
    • 自動テストの責任の範囲を明確に
    • 既存リグレッションと、仕様変更で修正が入る既存機能
    • 新規機能は余裕があれば、プロジェクト内で終わらせる必要はなく次の仕様変更までに使えるようにという優先度を置く
    • テストが成功している限り気にしないが、実行時間がかかるようになってきた
      • 原因:テストデータ等が肥大化、テスト間の依存関係
  • Phase2 テスト自動化の問題があるのに気づかない
    • データの蓄積、可視化
  • phase3 オペレーションの問題
    • 失敗したときに調べる手間がかかる
    • テスト自動化の運用工数が、スクリプト数に比例する
      • 失敗の7割を占める一時的な不安定さの場合、AutoHealingの仕組みを作り再実行を自動化
感想

各段階で取り組まれている内容やさらっとAutoHealingの仕組みを構築してるのもすごいし、改善のビフォアアフターをちゃんと数値で出せるよう準備できてるのすごいですよね(つい取り組みを先にやっちゃってデータとってないことが多いという自戒を込めて)

リグレッションテストをほぼ100%自動化した話

橋本 悠我さん

講演メモ
  • 自動化前 テスト以降は一気にやっている(アジャイルになりきってない)
    • テスト結果のフィードバックが遅い
    • MagicPodと契約があった
  • ステップ(もう少しあった気がする。メモ抜けてました)
    • 現状のテストの見直し
    • 環境の準備
    • 手動→自動へのテストステップ見直し
    • 実際の自動スクリプト作成
  • 目的としていた部分以外の変化
    • 開発者からの信頼を得られた E2Eが強力
    • PR単位で実行することでFBが速くなる
  • いつ自動テストやるの?今でしょ!
    • 「最大のリスクはリスクを取らないことだ!」
感想

自動化取り組み前の現状の見直しや、手動のテストの見直しをきっちりされている点が良いなあと思いました。E2Eが強力で開発者からの信頼が得られるのも素敵な流れ。
あと講演最後のメッセージが熱くて素敵でした!

初めての自動化導入は慎重に、計画的に

二河 亮さん

講演メモ
  • E2E初心者の壁 未経験ゆえの漠然とした不安感
    • 壁の原因の深堀

1. どう自動化するのかから考える必要あり
  →小さな一歩から試す
  テスト自動化にこだわらず身近な作業から自動化
  効果が出た。壁が下がった
2. ノウハウがない
  過去の失敗から学ぶ(アンチパターンの研究)
  アンチパターン
3. コーディングスキルなどの技術不足による不安感
  ツールベンダー(Autify)のサポートを利用
  スクリプトに対する不安感も薄れる

  • 不安感を解消していった結果、次のステップも明確になる
感想

不安なところを一つずつ解消していって結果につなげていく過程が分かりやすかったです。漠然とした不安感で止まってしまうことは自動化に限らず多いと思うので、不安に感じている理由を丁寧に分解して対処した点が素敵でした。

ワークショップ

あなたの1票が未来を決める、参加者投票式マルチエンディングストーリーなワークを行います。テスト自動化にまつわるストーリーを体験する、ゲームブック形式のセッションです。選択にDiscordを使用します。(JaSST Tohokuサイトより)

ワークだったこともあってあまりメモできてないけど、楽しみながら自動化の勉強できるよう構成されていてすごかったです。こちらのワークの内容は後日ゲームで公開されるとのことなのでワクワクしながら待っています!以下メモと感想。

  • ゲームブック形式で自動化の進め方を学べるワークショップ
  • 参加者の選択で自動化のプロジェクトが進められ、プロジェクトをハッピーエンドに導けるか?というストーリー
  • シチュエーションと提示される選択肢があるあるな内容でリアル
  • 参加者もある程度経験のある人の割合が多いからかだいたい正解の選択肢を選ぶが、バッドエンドが見たい勢が一定数いるようだったw(カバレッジ100%にしたいというか、ストーリー全部回収したいというか気持ちはよく分かりますw)
  • 選択肢の内容について、なぜそれが正解と考えられるのか、失敗と考えられるのかの解説があり面白さと勉強と納得感があって工夫がすごい
  • かまいたちの夜」をオマージュしたグラフィックも音声もあって演出が素敵

招待講演

テスト自動化の成功を支えるためのチームと仕組み

井芹 洋輝さん

井芹さんの発表資料はこちら
speakerdeck.com

講演メモ
  • テスト自動化の目的
    • 妥当な対価で目的を達成すること
      • 費用・効果・目的が釣り合う
  • 適切な目的を立てる
    • その時のチームにとって有益で実現可能な目的を設定
    • 広い活動スコープでも目的を設定する(テスト担当→開発+テストに広げる→ビジネスを巻き込む)
  • ステップバイステップで目的達成を目指す
    • 成功しやすいものから始める。持続可能性が重要
    • 自動テストにとってのテスタビリティを高める
  • 費用対効果を改善する
    • 自動テストにとってのテスタビリティを高める
  • テストの妥当性を高める 自動化する価値のあるテストケース
  • 自動テストの内部品質を作りこむ
  • テスト自動化の計画とアプローチを工夫する
    • リソース確保、リスクのコントロール
    • 自動テストの活用の頻度と幅を広げる
    • 自動化インフラに自動テストを統合する
    • 監視とコントロール、保守で自動手うとを維持・改善する
  • テスト自動化の成功を支えるチームと仕組み
    • 開発とテスト
    • テスト自動化の成功を支えるチーム文化の指向性

  1.チームのテスト自動化の能力を確保し高める
  2. Whole Teamでテスト自動化を推進する
  3. チームでの自動テストの責務を確立する
  4. チームにとっての自動テストの価値を高める
  5. チームで自動テストの持続可能性を保つ
  6. チームでテスト自動化の動機付けを行う

感想

自動化の成功に必要なことを、担当→チーム→ビジネスと視野を広げていく形で整理・解説いただけて本当に良かったです。本当はビジネスの視点から考えられるのが良いと思うのだけど、担当の立場だとつい目の前のことに目が行きがちなので、この公講演で全体感をみえるようにしてもらえる感覚がありました。すごくよいお話だったのでJaSSTの次の月曜に早速社内に紹介しました!

全体的な感想

久々の会場参加でリアル拍手ができたのが、なんだか感慨深かったです。ついオンラインのイベントの癖で、ついセッションが終わるとチャンネルに「88888888」を書き込もうと思ってしまいました。
基調講演から事例発表、ワーク、招待講演まで自動化にどっぷり浸れて勉強になることが多々ありました。とくに招待講演の内容でそれまでの講演がつながって一つにまとまる感覚があってよかったです。

会場とオンラインのハイブリッド開催はとても大変だと思うので、実行委員の方々には感謝しかないです。素敵な会をありがとうございました!

おまけ

盛岡滞在時間は短かったので、あまりご当地グルメを楽しむ暇がなかったのですがドーミーインのご当地メニューにあった盛岡冷麺はしっかり食べてきました。キムチがいいアクセントになってて美味しかったです。

盛岡冷麺。ドーミーインの朝食はご当地グルメにも力を入れてるのがいいですよね。

城めぐり 中世武士の館・足利氏宅跡「鑁阿寺」

室町幕府の将軍家・足利氏の本拠である足利荘の足利氏宅跡を訪問してきました。現在は鑁阿寺(ばんなじ)というお寺になっています。

お城の概要

見どころ

日本史の教科書でよく出てくる中世武士の館のイメージほぼそのままです。地図で見ると堀が周囲を巡っているのが良く分かる通り、堀と土塁が周囲を巡る方形館になります。いわゆる「城」とはイメージが違いますが、日本百名城にも入っています。

現在の堀は鴨や鯉が泳いでて穏やかな様子。敷地の角の部分から見ると土塁が結構高さがありそうなのが窺えます。

f:id:yuki_shiro:20211127133852j:plain

門はお寺になってからのものだと思いますが、反橋と門が大変美しいです。

f:id:yuki_shiro:20211127142510j:plain

本堂は国宝に指定されています。屋根の上部に足利家の家紋(右が足利二つ引、左が五七の桐、真ん中は菊の紋みたいだったけど由来は分からず)がかかげられています。百名城スタンプとか御城印とかはこちらの本堂でいただける模様。

f:id:yuki_shiro:20211127134416j:plain

鑁阿寺本堂

重要文化財の経堂は行事の時以外は公開してないそうなのですが、行ったときにはたまたま公開されてました。足利十五代将軍の木像も公開されてて、拝観することができました。巡り合わせ良き! 内部の輪蔵(お経を納めた蔵)は回せるようになっていて、受付の方が「回し始めは重いから手伝いますよ」と言って手を貸してくださり一周回せました。お経を読んだのと同じだけの功徳が得られるそうです。

f:id:yuki_shiro:20211127135210j:plain

一切経

いつの時代のものかは正確には分かりませんが土塁もしっかり残っていて登れます。土塁の向こう側の家の1階部分がしっかり隠れているので高さは2メートル強くらいかな?

f:id:yuki_shiro:20211127141041j:plain

鑁阿寺東側の土塁

f:id:yuki_shiro:20211127141110j:plain

土塁の上から東門と堀を眺めた様子

 

駅からのアクセスも良く、周りには坂東の大学と称された足利学校もあり、ぶらぶら歩くのによいところでした。

おまけ

一休みしに入ったカフェ・八蔵の「喫茶店のプリン」。固めでカラメルとよくあって美味でした。

f:id:yuki_shiro:20211127154049j:plain

 

JaSST'21 Tokyoに参加してきました!(1日目編)

日本最大級のソフトウェアテストのイベントJaSST '21 Tokyoが3/15(月)~16(火)に行われたので行ってきました!
こちらは1日目のセッションメモまとめです!
目次

基調講演 "Being Agile about Architecture"

Joseph W. Yoder 氏(Refactory CEO)

Agileアーキテクチャ

Agile
  • 常に短いループでフィードバックをもらう
  • テスラなどのハードウェア企業でも使われてる
  • 常に学習して自らを振り返る
Agileの神話

SimpleがBestかというとそうでもない(機械学習とかを取り入れると複雑になるがそうした方がいい場合もある)
速さだけでなくフォーカスを当てることが大事

Agile/Leanの価値
  • 継続的な改善、改善を投入していく
  • 価値があるから練習する
パターンとは?
  • パターンはGood Practice
  • 既知のテクニック、ソリューションを再利用できるかも

→繰り返してきちんとできるようになったら普通のプラクティスになる

  • プロジェクトの一番初めに考えるべき、ずっと考え続ける必要もある

価値はプラクティスを推進する。価値は人によって異なる

<プロジェクトのはじめに考えること>

  • 巨人の肩に乗る:どのようなフレームワークやDBを使うかなど、これまでのリファレンスを基にする
  • 自分たちで追加でやる必要のある事を明確にする(信頼性、性能などなど)
  • どこが一番問題があるのかに従って計画する
  • 最終責任地点
  • アーキテクチャのロードマップを作成する際に品質を一緒に考える(例:モバイルのセキュリティはいつ考える?な()
  • アーキテクチャそのものを検証する(アーキテクチャの進化の方向、品質にも影響を与える)
  • テストアーキテクチャを構築する(プロジェクト中でも時々戻って考えたり確認したりする必要あり)
  • 最大責任点を計画する

<プロジェクト中に考えること>

  • バックログを作成して優先度を考える(色分けして考えると便利)
  • 重要な品質が見えるようにする
  • アーキテクチャのトリガーを設定しておく(測定しておいてフィードバックする)
  • アーキテクチャのスパイク*1を設定しておく

- どのフレームワークがうまくいくか分からないとき、実験してどれがよいか意思決定するするタイミングを決定しておく?小規模な実験をたくさんやることを予め計画に入れておく

  • 大きな泥団子(技術的負債)ができてしまうかも。できてしまうと後から綺麗にするのが難しい
  • 見えないものは改善できない
  • 横断的に可視化する

- 立場(開発者、マネージャー)によって見たいものが異なる
- 技術的な判断はビジネスの価値を踏まえて下すべき

  • 継続的なインスペクション

- 効率的な運用に適用される自動化は、効率を倍増させる。非効率的な運用に適用される自動化は、非効率性を倍増させる by ビル・ゲイツ

  • イノベーションのためにはちょっと止まる時間も必要(この時間もプロセスに入れておく)

- 新しいことを考えたり、好きなことを試してみたりする時間

  • 速さと生産性はイコールではない

「よいアーキテクチャが高くつくと思うなら、悪いアーキテクチャを試してみなさい」

質疑応答

Q. ユーザビリティはどのように可視化するか?
A. ユーザビリティのラボなどがあれば、キーストロークやユーザの視線などのログをとって追跡することもある。シナリオを構築して実験しフィードバックを得る。難しいが数字に落とし込むことは可能。

Q. 進化性の定義と測定する方法があれば教えてほしい
A. ビルドからリリースまでどのくらいかかったかを記録して比較する

Q. SREについてどのくらい優先度を与えるべきか?
A. 対象の製品によって異なる。人の命にかかわるものでは信頼性の優先度が高い。

Q. 技術的負債の対応はどのようにする?
A. ビジネス上のインパクトをきちんと見せるべき(例:負債がたまるとDelivery Speedが下がる)。ビジネス、エンジニア、QAみんなで対応する

Q. 技術的負債やアーキテクチャレビューをどの頻度でやるか?
A. 日常的に行う

感想

プロジェクトのはじめからプロセスに入れておくべきことや、進行中に絶えずやり続けることまで網羅されていて勉強になりました。勉強不足でいくつか用語とかが分からないところがあったので、twitterで補足いただいた方々に大分助けられながらの聴講でした。まだまだ勉強が足りない。
終盤の「よいアーキテクチャが高くつくと思うなら、悪いアーキテクチャを試してみなさい」がツボでした。根幹になるところは時間かけて考えないといけないところなんですけど、最初の方には見えてないこともあってなかなか難しいと思ってます。それもあっての「立ち止まる時間もプロセスにいれておく」なんでしょうね。よく抜けてしまうところなので、実験の時間を入れておくのは意識します。
(この講演は時間を置いた後にもう一度見たい。Yoderさんの別の講演動画でも見てみようかな)

アジャイル・DevOps時代のテストと品質保証 輝く未来を抱きしめて!技術やツールが変えてしまうこと、変えられないこと」

藤原 大 氏(mabl Japan)
発表資料:アジャイル・DevOps時代のテストと品質保証 - 輝く未来を抱きしめて!技術やツールが変えてしまうこと、変えられないこと / Tech and Tool for Testing and Quality Assurance in Agile and DevOps Era - Speaker Deck

  • 顧客が本当に欲しいのは結果
  • 自動化できるものを自動化(自動化できないものもある)
  • マニュアルテストの自動化はアンチパターンになりがち
  • 技術の恩恵を受ける 例:パイプライン実行
  • 品質保証をビジネス全体の活動にする
  • QAチームを作るのではなく、活動に(QAチームがすべてをやるのは不可能)
技術の進化(AI/MLの利用)
  • ペルソナを使った探索的テストの自動化
  • 自然言語でテストケースを作成 例:「アレクサ、音楽かけて」
  • ユーザ操作を学習してテスト作成
  • シフトレフトよりも境界を越えよう
  • 「バグというモグラを手でたたき続けるか、ユーザーに真の価値を提供するか」

「カスタマーサポートエンジニアの品質貢献」

登壇された方々(敬称略)

モデレータ:
 城風 智(KIOXIA)

パネリスト:
 加藤 敏之(LINE Fukuoka)
 齋藤 由佳(Autify)
 田向 祐介(ヴェルク)
 山田 恭平(日本マイクロソフト
Q. カスタマーサポートとコールセンターは違うの?
A.

  • コールセンターがマニュアルに沿ってお答えするというイメージなら違う。お客さんの困りごとを解決するのが仕事。最終的には安心感とか好印象を持ってもらいたい。QAにもお客さんがどこでつまづいているのかという観点を得るのに、カスタマーサポートを行ってもらいたい
  • お客様とのコミュニケーション「どういう状況で何に困られてるのか?」
  • 顧客の困っていることをいかに引き出すのか、がポイント。「〇〇機能がほしい」と言われたときに、それが欲しい理由をきちんと聞けること。
  • 問い合わせ対応時に、過程を言語化してお伝えすることも大事。(問合せしてくださった方も、さらに先のエンドユーザーさんに調査に時間をもらうことを納得いただく必要があったりする)

Q. カスタマーサポートエンジニアがソフトウェアの品質に貢献していると思う瞬間
A.

  • ユーザーの温度感(ここつまづきやすそうだな、みたいなこと)を開発者にフィードバックする→該当部分の問い合わせが減り、サービスとしての品質向上につながる
  • 開発に伝えた後もフォロー

Q. カスタマーサポートにとっての成功とは?
A.

  • お客様が口コミで評判を広げてくださること(例:「問合せしたらすごくよく対応してくれた」)
  • サポートがいいからここの製品を使おうと思ってもらえること
  • お客さんにファンになってもらうこと。お客さんがテストを効率化できることにどれだけ貢献できたか
  • 違和感を拾って聞いてみたところ、問合せのあった事象の手前に問題があった(サービスの仕様を誤解していて間違った使い方をしていた)話を聞いて解決につなげられた
  • 「お客さんの声がもともとベクトルが間違ってることがあって、それに対して真摯に対応してはいけないパターン」
  • 問い合わせをいただいた時点で、サポートを頼ってでもサービスを使いたいと思っていただいている

Q. 品質という視点でサポートチームから開発、QAにお願いしたいことは?
A.

  • 仕様や画面の変なところに事前に気づけるくらいの引き出しを持ってほしい
  • お客さんのことを考えた回答が欲しい。事実だけではなく、提案とかもあると嬉しい。ユーザのことを想像する力を持ってほしい
  • 調査時点で、どういう状況で何に時間がかかるのかを開発からCSに共有してもらえると、いいサイクルになる(海外だと時差があるので特に)
質疑応答

Q. サポートチーム内でどのようにナレッジを共有しているか
A.

  • 問合せ、回答、注意事項のDBを作っている。問い合わせ時にはそこを見て対応。マニュアルは敢えて作らない
  • 社内FAQを用意している。対応時に感じたことや注意点も記載

Q. サイレントカスタマー対策は何かしているか?
A.

  • サイレントカスタマー(不満は持ってるけど声を上げない顧客)は問い合わせないので、SNSなどを確認している

Q. 開発とサポート担当で期待が違う場合調整はどうしているか?
A.

  • 顧客からの不具合レポートを開発とサポートでレビューしていく。
  • 既存のお客さんが使いやすくなるような改善と、サービスの進化方向のバランス

Q. お客様とのコミュニケーション面で技術支援以外で工夫していることは?
A.

  • 共感する力をあげていく。
感想

私自身はQAですが、カスタマーサポートの問い合わせにも時々目を通すので楽しみにしていたセッションでした。ユーザーが本当は何に困ってるのかを聞きだしたり、問い合わせ対応時に対応状況を相手にお伝えしておくなど、確かにそうだなと思う共感ポイントがいくつかあって楽しく聞けました!

「テストプロセス改善のお悩み相談室 リターンズ ~テストプロセス改善技術の導入で悩んでいる皆さん、悩みを共有しませんか?~」

登壇された方々(敬称略)

モデレータ:
 田井 康平(ノハナ)

モデレータ補助:
 雨宮 寿幸(ベリサーブ)

パネリスト:
 上田 卓(ソーバル
 大段 智広(豆蔵)
 山﨑 崇(ベリサーブ)

参考資料:
http://aster.or.jp/business/testprocess_sg/pdf/ASTER_TPIGuide_v1.0.0.pdf

お悩み1

テレワークに移行してからコミュニケーションが減ってしまい、仕様の理解不足や認識齟齬が発生している
テレワークに移行して生産性が下がってしまった

お答え1

特性要因図を使って要因を洗い出す
→TPI NEXTとテストプロセス関連の要因を紐づける
 TPI NEXTのチェックリストと要因を合わせてテーラリングしてみる

お悩み2

システムテストを行っているが、テストケースは秘伝のたれ状態で何をテストしているか分からない。改善したいが周りが話を聞いてくれない

お答え2
  • 可能性1:硬直化したお役所仕事パターン

- 対処:仲間を作る、自分が偉くなる

  • 可能性2:独善的な改善パターン(社外活動のハシカ)

- 対処:相手の立場の関心事で語る、自分のやりたいことと組織の関心事を整合させる

改善を回す際に、全体観をもって客観しできているか

  • 提案内容は相手の関心事に沿った文脈か
  • 組織やプロジェクトの制約や前提を考慮しているか
  • 相手に寄り添うマインドになっているか
  • やりたいことではなく、やることによる価値を伝えられているか

ビジネスゴール⇔ITゴール⇔BDTPI

お悩み3

組み込み業界で結合、統合テストの自動化で書く工程、製品ごとにプロセスがバラバラで無駄が多いと感じている。組織全体でプロセスを作りたい
TPI NEXTは読んだけどよくわかっていない

お答え3

各工程、各プロセスでどんなテストをやっているのか可視化
1. プロジェクトプロファイル
2. 問題の絞り込み
3. アセスメント実施
4. 問題の検証

フィッシュボーン図で問題を整理し、アセスメントモデルを使って視野を広げるのが良さそう

質疑応答

Q. 「プロセス改善前に現場を可視化しようというと「工数かさ増ししているのでは?」 と言われる問題」
A. 怒る/喧嘩するところ。可視化して問題を特定する前に着手すると結果的に苦しむことになる

Q. 社外活動のハシカにかからないようにするには?
A. 正直難しい。かかってしまったら、周りの反応とかからいち早く気付くようにする

Q. テスト改善というとすぐ「テスト自動化」と言われる。それ以前の問題が山積みの場合の説得は?
A. 開発全体で改善するべきところはないか、自動化以前の問題はないか、モデルを使って示す。
イケてないテストを自動化してもイケてないテストが高速化されるだけ。
上位層の説得にアセスメントモデルは便利

感想

どれもあり得そうなお悩みで、お答えも納得しながら聞けました。質疑応答に上がってきたお悩みもこれまたリアルでよかったです。カスタマーサポートのお話でも「本当は何に困ってるのか」を聞くのが大事という話が出ていて、本当の問題は何かを可視化するのがどこの過程でも同じなんだなと思いました。それだけ難しいということですよね。

*1:この文脈でのスパイクって何だろうとつぶやいたら スクラムにおける技術的スパイクの進め方 | Ryuzee.comを教えていただきました

JaSST Online Bergamotに参加してきました!

10/3(土)に開催された JaSSTソフトウェアテストシンポジウム-JaSST Online Bergamot に参加しました! 今回のテーマは「探索的テスト」!

セッション1:探索的テスト

<概要>
業務で探索的テストをされている nemorin さんに事前に録画してもらった探索的テストの様子を見ながら、質問者の方が適宜止めて気になるところを質問していくというスタイルで行われました。今回のテスト対象はtwitterライクなtestitterというWebアプリ。LIFULL株式会社さん提供だそうです。
※事前に質問者オプションを購入された方が質問できる形でした。面白そうだったので買えばよかった。

<nemorinさんのテストの様子メモ>
※雑にメモしたものなので、nemorinさんの言ってた内容と参加者の質問が混ざってる可能性があります。

  • 今回はチャーターは作ってない、仕様書を3分程度眺めた程度(読み込むと頭の中でテスト設計を始めるので探索っぽくないかという意図)
  • 探索テストの時間は1時間。当初の意図は30分程度で学習してあたりを付ける意図
  • 最初はHappy Pathを通す。メイン機能を一通り見る。
  • CRUDを見る
  • 動かしながら出てきた点は、バグ、気になるところ(問い合わせ要)、メモの3つに分けてメモ
  • 誤った操作も大事(ユーザも操作ミスする可能性があるので)
  • 仕様書も古かったりするので唯一信じられるのは自分でやった結果(ただ、たまに押し間違ったりするので自分が信じられないときもある)
  • (業務でやるときも)探索的テストを録画しておくのはよさそう

<感想>
探索的テストをしているときに何を考えてるか、を見ることはほとんどないので貴重な機会でした。時間区切って探索的テストやっている中で、このくらいの時間経過したときに何を考えているか、とか聞く機会ないので、質問者の方々の質問もありがたかったです。探索的テストで自分もやっていることもあれば、「なるほど、そういうアプローチなのかー」と思うところもあり、興味深いものでした。後ほどOSTでのお話によると、普段はチャーターを作ってるそうですが今回は未知のものなので作らなかったとのことでした。

様々な参加者がいる中でのオンライン視聴なので、全員の前提知識をそろえるのがすごく大変そうです。その点、探索的テストの対象選定からセッションの進め方まで、運営の方々がすごく考えて構成してくださってるなと感じました。nemorinさんも運営の方々にも大変感謝です!

セッション2:OST(Open Space Technology )

参加者駆動のセッション。最初に参加者で話したいテーマがある人がテーマを出し合い、みんなでアジェンダを作るところから始まり、話したいテーマのところに行って話したり、聞いたりするという形式です。

探索的テストをやるタイミングはいつにしてますか?

セッション1中に聞いてみたくなったのでセッションホストやらせてもらいました。参加者のみなさんからいただいたご意見をざっとまとめます。

<お題:探索的テストいつやる? 目的は?>

  • テスト開始前
    • 仕様書がないシステムの場合、対象を学習・理解するために実施
    • 仕様書がある場合もイメージをつかむために実施
  • テスト中
    • テスト工程進行中にこれ以上進まなそうなとき(開発に差し戻すが、致命的なバグを洗い出して)
    • スクリプトテストと並行して実施する
    • テスト実施者の中にバグだしのうまい人がいたら、その人にはずっと探索的テストをやってもらう
  • テスト終了後
    • これ以上バグがないか確かめたい
    • バグをもっと出したい(計画したテストケースは終わったけど何かありそうな予感)
探索的テストどうやって勉強しますか? 指導しますか?

とろさんのセッションでした。

印象的だったのは、どなたかが言っていた「憑依系探索的テスト」。miwaさんが言っていた、高齢の方の手の震えによって発生するバグの話から想起された話です。なるべくユーザーの状況を想像し、なりきってテストをするパターンや、「悪いことやろうと思って操作する」というパターンが聞けました。「憑依系」はなかなかパワーワードですねw

<感想>
OSTの参加も、セッションホストも初めてやりました! ホストやった時は、沈黙が続いちゃうタイミングがあったらどうしようかと、ちょっとドキドキしてました。ですが、参加者の皆さんが積極的に自分のエピソード話してくださったり、途切れたタイミングで別の質問を出してくださったりで、盛り上がれてよかったです! 対象となるシステムや仕様書の整備具合、あとはシステムに対して知識がどのくらいあるかによって、探索的テストをどう実施するか、参考になる意見が色々聞けました。セッションに来てくださった方々ありがとうございます!
とろさんのセッションでも「憑依系」のパワーワードが飛び出したりと楽しめました! オンラインだと話し合いの輪の物理制約がないので、わいわいしやすくていいなーという気がします。話すネタはないんだけど聞いてみたい方にも、ハードルが低そうな印象があります。

全体通した感想として、ほぼ探索的テストだけをネタに盛り上がるという貴重な機会をもらって、すごく楽しかったです。nemorinさん、運営の方々、参加者の方々、ありがとうございました! 自分の仕事で探索的テストをどうしているかは別途言語化してみようと思います。

JaSST'20 Kansaiに参加してきました!

9/12(土)にオンラインで行われたJaSSTソフトウェアテストシンポジウム-JaSST'20 Kansaiに参加したので、気になったセッションをレポートします! 関西は初参加!
今回のテーマは「テストについての分解・再構築」です。
本文中にリンク貼った書籍や資料は、当日のTwitterで教えていただきました。
当日のまとめはこちら
JaSST'20 Kansaiまとめ(オンライン) - Togetter


「テストの視点でシステムを分析する」

見えないものと取っ組み合う

望月 信昭(ウェブレッジ)さん
<概要>
テストベース分析で困りがちなこと

  • ソフトウェアは目に見えない → 何となく理解した感じで作業を進めてしまう

対象をテスト視点で理解する

  • モデル化してみる(図を描く)
  • 記法とかがハードル高いと感じる人は「テスト技法を使って問題を解いてみる」と考えてみるのも手(対象を理解するためのツール)
  • ただし対象に対してどの技法を使うのが適切かを選ぶのもハードル高い
  • →ちょっと使ってみて考える。失敗してもこの対象にはこの技法は会わないという学びをゲット

対象の振る舞いを理解して、見えないものを見えるようにすることができる

テストの視点でシステムを分析する

堀川 透陽(ベリサーブ)さん
<概要>
テストのシフトレフト
前提

  • ビジネスモデルキャンバス(ビジネスゴールを導くためのツール)

顧客・tesuto 対象をビジネス視点で書き出していく

  • PEST分析 仮想課題から気付きを得る

外部環境の変化から生まれる要求、見直される要求があるのではないか

USDM(要求仕様記述手法)による要求と仕様の再構築
言葉にする→言葉にかけないものを作ってはいけない
メリット

  • 要求と背景が明確になることで、テストのゴールも明確化される
  • 合意形成しながら進めることで、仕様の妥当性があがる

デメリット

  • 作成に熟練を要する(作り直し)
  • 合意形成のための工夫が必要

USDM作成→テスト設計HYST法のFV表、FL表へ接続できる


<講演中で触れられてたことの参考文献など>
USDM参考書籍

テキストマイニングによるテスト分析、リスクベースドテストへの応用の詳しい事例
https://www.veriserve.co.jp/asset/pdf/tim-verinavi-vol19.pdf

テストの視点でシステムを分析する ~アジャイル開発を例に

江添 智之(バルテス)さん

  • 仕様化以前の状態で品質を考える
  • 何ができればOKか を上流工程から考える
  • エピック→スプリントに入りきらないユーザーストーリー → 受け入れ条件を考えるとユーザーストーリ―に分割できる
  • 要求の「完成」の定義と受け入れ条件で整理する

「スペックアウト」でソースコードを理解しよう

池田 祐一(AFFORDD関西部会)さん

スペックアウトとは

設計書の不足を補うために、ソースコードから必要な設計書を起こす行為
知りたい機能、知りたいこと、必要な調査資料、投入できる時間etcを目的を明確にして取り掛かる
 

スペックアウトの手順例

1. 資料やソースファイルの一覧を用意する
資料、内容、用途などを表にする
2. 関数の一覧を用意する ファイル名、関数名、説明(目的語と動詞を各)を表にする
3. 変数の一覧を容易 ファイル名、変数名、説明(名詞を書く)

4. データ参照関係を調査する 関数と変数のマトリクスにCRUDのどれを行っているのかをつけていく
5. 知りたい機能の処理構造を調査する 変数名表からあたりを付けて構造図に落とす
6. 必要に応じて処理手順を調査する(複雑なパターンなど) 処理パターンを抽出してPADフローに表現
7. 要求仕様を復元する コードや構造図を参照しながら、イベントから始まる一連の動作を表現する
8. テスト仕様を作成する
9. テスト結果を記入する

<講演中で触れられてたことの参考文献など>

テクノロジーセッション

「試験に役立つモデリングのススメ」

渡邉 豊幹(サイボウズ)さん
サイボウズさんの米国市場向けの販売管理システム開発チームの話

問題点

  • 影響範囲が把握しにくい
  • 新規メンバー/他チームへの教育コストが高い

対策

  • モデルを作成してみる。文書より図の方が人間には分かりやすい

モデルとして残すもの

  • Keeps

- システム全体の構造shisutemuzentainokouzou
- 業務で扱う対象とそれらのつながり
- システムの(ユースケース図、コミュニケーション図)渡されるデータや実行APIを記載

それ以外はTempsとして一時的な資料、メンテナンス等はあまり考えない

結果

  • 概要が把握しやすい、俯瞰しやすい
  • モニタリング対象の洗い出しやE2Eテスト

「Global QAチームを目指して ~日本とシンガポールの2拠点QAチームを築く上での気づきと大切にしたこと~」

角 尚美(チームスピリット)さん

シンガポールで採用

QAエンジニアの役割定義をアップデート

  • コアスキル(ISTQBのFLレベル)
  • スペシャリスト(ISTQBのFLレベル+α)

の2軸で定義

リモートでも2か月で立ち上げ
 開発チーム全体でSG-QAのオンボーディングのサポート

招待講演

「ゆもつよメソッドによるテスト分析の成り立ちと狙い」

湯本 剛(freee / ytte Lab)さん

例:西暦和暦変換アプリのテスト

テスト分析

テスト対象フィーチャ:和暦西暦変換
テスト条件(仕様と期待結果):西暦の年月日から和暦へ変換した日付を出力する

テスト設計方針
テストケース:この辺で一般的なテスト設計技法を活用

分析と設計について

分析:対象を把握する→分析結果は客観的、誰が見ても分かる
設計:枠組みを考える、アイディアを決定する→設計結果は主観的。人によって答えが異なる

要求分析:システム要求を分析して仕様を作成する

あー、テスト分析だと確かにインプットするものの名前じゃないので分かりにくいのかも。文脈にもよるだろうけど、より正確にはテスト要求分析というと誤解がないのかな

テスト分析では理解したことを以下のように整理する
  • 仕様項目の特定と列挙
  • 期待結果の特定と列挙
  • テストパラメータ列挙(テスト設計時により明確に定義していけばよい)

テストカテゴリー
 テスト条件を見つける際に一貫性のある解釈をするために論理的昨日構造の各要素にテスト対象から見てふさわしい名前付けをしたもの
テストカテゴリと意味づけ

テスト設計
テスト設計方針を決める→テストパラメータ導出方法、同値のサイズ、組み合わせ方法

テスト条件を網羅するためのテストケース設計モデルの選択をする 技法の選択とか

モデル化する:必要なものを取り出し、不要なものを削る

テスト設計の変遷
テストカテゴリーをベースにしたテスト分析の方法

テスト分析手法の概要
  • ドキュメントフォーマットと実施順序のルール化/テスト分析マトリクス
  • 論理的機能構造→テストカテゴリー
  • 仕様項目特定パターン(研究中)

メリット
大きくとらえてテスト対象を網羅しているかが分かりやすい
テストしなければならないことを先に洗いだすことができる
→テスト条件(仕様項目)の段階でテストが十分か、漏れがないか、といった確認が可能になる

ドキュメントフォーマットと実施順序のルール化

複数人でテスト設計するときの記述内容を合わせる
テストカテゴリーは確認箇所を汎用化させたもの

論理的機能構造

テストカテゴリーになるべきものを決めるためのモデル

  • メンバ全員が参照モデルを深く理解する必要はない、テストカテゴリに対する認識合わせが最も重要
仕様項目特定パターン

テスト実行時のデータ入出力パターンですべて特定
テスト実行によって呼び出される小機能の結果確認

感想

「自分たちが扱っているシステムやプロダクトで何がしたいか」をどう整理すればよいかを改めて考える機会になりました。
色々な手法があるけど、どうとらえてチームでどう納得するか、というところがミソなんだろうなと思います。
ゆもつよメソッドの話をちゃんと聞いたのは今回が初めてだったんですが、論理的機能構造をどう作っていくかが私の中で落とし込めてないので、そこをもうちょっと深めたいです。

関西は今回が初でしたが、オンラインで開催していただけて自宅から参加でき、移動ゼロで素敵なお話が聞けてありがたかったです!
登壇者、運営の方々、参加者の皆様ありがとうございました!