全数テストは不可能
全数テストは不可能
これはテストの原則のひとつで、
ソフトウェアのすべてをテストすることは非現実的だ
と古くから言われているらしい
不可能だから、非現実的だからと諦める話ではなくて、
不可能だからこそ覚悟をキメて、
必要だと思う範囲を定めたり、判断したりして要る分だけテストがんばろうね
ということだと理解している
この範囲や判断が独りよがりだと誰の不安も取り除けなくて
不可能な全部をテストしたくなってしまうので、
わたしたちがちゃんと説明することでチーム内で安心しよう
ということだと思う
わたしはテストを考えるなかで、この原則がいちばん
自分のテストを「これでいい」と思える後押しをしてくれる気がしていて、
なにかあると立ち返っている気がするのでもう少しいろいろ言ってみたい
「いつまでにこれ全部テストしといて」
こういうニュアンスのことを言われたとき
無理だ！何を言っているんだ全部テストなんて無理なんやぞ と内心即答してしまう
そもそも全部ってなんや適当なこと言うな
全数テストは不可能だ と知っているから
「全部」の範囲を定めるために
特に心配なところ、起きてほしくないこと、つくるのが難しかったり揉めたりしたところ
などを聞いてみることにしてる
ここまでなら全部できるよ、と合意をとる
「あれもこれもそこも念のため全部見ておきます」
こら勝手に約束するな！！
自分で自分たちの首をしめてどうする
全部見ることなんてできないんだから
そういうのは大体3分の1見れば済む
見るところを絞るのに頭使うけど、
不可能な全部を片付けることと比べたら楽に思える
もっと楽しよう
「テストの何から手を付けたらいいかわからない」
そらそうや、テストしたいものが現れたときはだいたいこうなる
こういうときは全部とおぼしきものを前にして手が止まっている
動き出せないときは情報が足りないせいであることが多いので、
わからないものは扱える大きさまで小さくしたり、似ているものをまとめたりすることが必要だ
戦略的にいこう
全数テストは不可能
ソフトウェアテストをするときに知っておいたほうがいいお約束のひとつ
ちょっと強引にでもみんなに伝えたかったです 以上です
とのの（@tonono2587）でした
このポエムはソフトウェアテストのアドベントカレンダー16日目の記事です
スーパーで鍛えた段取り力
ごきげんよう、とのの（@tonono2587）です。
こちらは ソフトウェアテストの小ネタのカレンダー 7日目の記事です
今回のテーマ：スーパーで鍛えた段取り力
小ネタということでソフトウェアテストに関係なさそうな話をしてみたくなりました
はじめに思い出話から
スーパーにいたよ
とののはテスターデビューする前は スーパーマーケットチェーンで店舗の担当者をしていました
（ちらっと JaSST Online で話しましたよ）
スーパーといえばレジを思い浮かべると思いますが、
わたしの担当はレジではなく 生鮮・お惣菜以外全部！みたいな部門でした
お菓子、缶詰、牛乳、パン、お豆腐、ジュースなどなど
お店の面積にすると結構な広範囲担当なので、だからこそのノウハウをいろいろ学んだように思います
段取りを組むやり方を学んだよ
具体的に学んだことの一つが、「段取りを組んでタスクを捌く」ことかなと思っていて
きれいに説明できるかわからないけどします
まず店員さんが1日にやる主なタスクは以下みたいな感じ
- ★定番売り場チェック
- ★売り場から減っていて在庫があれば品出し
- ★商品が棚の手前にくるようきれいに並べる
- 売り場を切り替えるための準備
- 売り場切り替え（できるだけサッと）
- 発注
- 在庫管理
- 納品
- 事務作業
（★タスクはサビなので繰り返し）
これらのタスクを 「お客さんが集まる時間（ピークタイム）」にあわせてやる必要があります
お客さんが一番くる時間に売り場がきれいでないと売るチャンスを逃す という考え方です
★は軽くて細かいタスクなんですが、放置すると売り場崩壊リスクがあるので意外とおろそかにできないやつです
ピークタイムには売り場をきれいな状態にしておきたい
（そのために）出せる商品があるなら出さないといけない
（そのために）売り場切り替えは終わっていないといけない
（あるかわかるために）売り場に何がどのくらいあるか見ないといけない
（出すために）裏の在庫を把握しておかないといけない
（在庫管理しやすいように）発注量を考えないといけない
ああああ… 並べただけで疲れる
当たり前かもしれないけどいろんなタスクは連鎖しているんですよね
こういった仕事を上手いことまわすのが「段取り」だと考えていて、
いちばん大事なことを決めて、それに必要な準備を洗い出して、止まらないように配置する
みたいなことを毎日やることで、段取りを組んでタスクを捌く/まわす 力がついたなと思っています
テストに役立ってるかも
こうしてついた筋肉はソフトウェアテストにも生きているような感覚があって
テストプロセスをふんでいこうね っておおざっぱに言うとたぶん段取りを組もうね ということですよね（ですかね？）
いつまでに何をどうしたいからこれをやらないといけなくて というような
テストの内容自体もそうですし、
ここのテストをいつまでにやりたいから誰さんに何を頼んでおいて… とかをいつも考えながら仕事してます
ただテストでは段取り組むのに必要な、要件とか大事なことを決めるのがめちゃ難しくて
細かくしたり相談したりしながら決めるのが大事だよね〜 って思っています
さいごに
直接ソフトウェアテストに関係なさそうな筋肉を鍛えた話を書きました
ほかの筋肉も仕上げていきましょうね
お疲れさまでした (^o^)
もうちょっと昔話している記事はこちら tonono.hatenablog.com
明日もお楽しみに！
【豆寄席】アジャイル開発におけるQAエンジニアの関わり方 メモ
ごきげんよう、とのの（@tonono2587）です。
お久しぶりでございます。 元気です。
今回のテーマ：アジャイル開発におけるQAエンジニアの関わり方 参加したのでメモ
こちらに参加しました
自身が最近アジャイル開発チームのメンバーになったので
わたし向けだ！と思って参加しました。
聴講メモ
話の流れ
アジャイル開発とテスト
■前提として、「上手いテストをする」というのは「テストの活動をクリティカルパスにしないこと」
どゆこと？
- 「テスト」は品質マネジメントの一手段だから
- テストと、他の品質マネジメント手段との住み分けをしてスコープは明らかに
- テスト技術次第になるよ
- テスト設計、テスト戦略：テスト対象の確認をより少ない量で確実に行う技術
- 開発ライフサイクル次第になるよ
- テストの成熟度を高めようとすればするほど開発の状況が前提条件になるから
■ソフトウェアテストの7つの原則 からみたとき
- 欠陥があることは示せるが…とか全数テストは不可能、とかはいつの時代でもアジャイルでもそうじゃなくても変わらない
- 「網羅して！」って言われたらちゃんと言い返せないとだめ
- 言い返す/説明する/納得してもらうためにモデリング能力とかが必要
- テストは状況（context）次第：開発トレンドとテストへの影響どんなのあるか
■テストは状況（context）次第：開発トレンドとテストへの影響
□オープンソース中心の開発
- 開発に合わせたテストツール
- 組み合わせの変更をテスト
- 自分で責任が取れるようテスト
□クラウド
- 本番環境でのテスト（コスト削減のため）
- 機能トグルを使ったテスト（フラグの切り替え）
- 性能や信頼性をモニタリング
□アジャイル
- 意識合わせしながらテスト
- リグレッションテストが主役
- メトリクスが変わる：フル機能じゃないけどリリースしちゃう。1回リリースしたら終わり、という開発はなくなる
- 継続的にメトリクスをとるほうが価値のあるテストになる
□マイクロサービスアーキテクチャ
- ユニット→サービス→E2E
- 結合点の保証方法をテスト
- 適応度関数で保証する
■そしたら、テストをどう変えるか
- QAがチームに内在するアプローチにする
→チーム自身が品質に対する判断をする - いまどきの品質リスク許容度合いにする
→すぐに修正/リリースできる欠陥は許容する
10分でリバートできます！とか、技術とあわせて - 逐次テストにする
→リリース直前のテスト量を減らすために早期から少しづつテストをする
”ログイン”など一部分だけ先につくってもらいテストするとか
反対は「ビッグバンテスト」
機能が揃ってからのほうが効率よく思えるが、それだとバグがいっぱい出たらリリースまで1ヶ月かかってしまう、とかになるので - 継続的品質改善をしていく
→リリースとは関係なく常にチーム全員が品質をよくしていく(メトリクスを変える)
■メトリクスについて
□開発規模と予想欠陥数
□テスト実行カバレッジ
欠陥対応状況とテスト合格率
- リスクを合意してテスト数を変える
- 機能がドロップすることがあるのでテスト数は可変する
- 重篤度で修正するか判断し、修正しない欠陥が多くなることがある
- 欠陥は複数のリリースをまたいで対処していく
DRE（欠陥除去率）
毎月の エンジニアが出した 欠陥の数
QAが出した欠陥の数
顧客から出された欠陥の数
→「顧客から出された欠陥の数」が下がっていってるか？
QAのアジャイル開発への貢献事例
※※※※※※※打つのめんどくなった；；；；；；
QAエンジニアに求めること
開発チームの一員として価値がある行動をしよう！
テストするだけじゃなく、品質がよくなることはコード以外なんでもやる
QAは鏡みたいなもの、お出かけ前に整ってるかみる的な
重症な場合は、やばい顔をそのまま写してあげないと
きれいだったらそれもちゃんとそういってあげる
QAだけが品質をよくするわけではない。チームみんなでやることを考えるリリースされる前に、ユーザーと同じ目線でプロダクトに最も触れているのは自分なんだ、と自負できるようにしよう
競合製品使う
上辺だけでなく、システム構造を理解する
ユーザーとしてリリースされたプロダクトを使うチームのみんなに、思っていることを言葉で伝えるように
仕様はどうなりますか？はやめよう
仕様はこうだと思っているけど、想定と違う 理由はこう という発言の仕方をする
どうだかわからないんだけど、の場合も意思を伝えるテストの"変えないでほしいこと"、”変わらないこと” →テストプロセス
プロセス自体は変わらない
変わらないからちゃんとやる。具体的にやることは、コンテキストによって変わるので変える- 技術者として、やらないといけないことを効率よくやる
- アジャイル開発でのQAでいちばん変わるのはコミュニケーションかも
■質問らへんのメモ
感想
- テストプロセス自体は変わらない。状況によって変わるところに対して技術でよくしてく
- 様子みてたせいか遠慮してたかも 特に「仕様どうなりますか？」って発言してたかも、前までそんなこと言ってなかったのに〜
- 前のほうがよっぽどアジャイルチームのQAぽい動きしてた気がしてきた、戻そとおもった
- アジャイル開発ってはやいことに意味があるから考え方で足りてないのはそのへんかもしれない
- どうテストプロセス踏むか的な考え方になってしまっていたかも？はやいことよりそっちが重くなってたかもしれない
- 考え方がちょっと変わった気がした
- 受け入れ要件を自分で書くのよさそう！すぐできそう
おつかれさまでした！
JaSST Online EdelweissのLT資料
こんにちは、とのの（@tonono2587）です。
JaSST Online EdelweissのLT資料です。
あわせて当日の参加レポをしておこうと思います。
内容
- オープニング
- LTセッション
- パネルディスカッション
- グループトーク
- ふりかえりワーク
- クロージング
リンク
ひとみさん資料
資料公開しました！https://t.co/orO2lbhtxb #jasstonline
— Hitomi (@hitomi___kt) 2023年1月28日
かとあずさん資料
LT資料公開しました。#JaSSTOnlinehttps://t.co/i3boQozaay
— かとあず (@kato_az) 2023年1月28日
とのの資料は先述のとおりです
よかったことメモ
- 日報でよかった/困ったを書いて、他メンバーの様子みるのよさそう
- ちょっとずつでも公開してなくても、記録あると次に進むヒントにできそう
- まわりを巻き込んで、業務として勉強時間つくるのよさそう
- 勉強をMAX100％いかすのも結構難しいので、打率1割くらいだったりしても凹みすぎない
sli.do勝手に答える
若手を勉強会や資格取得にモチベートするためのコツはありますか？
「勉強してみる会」という名前で、
あまり堅苦しい感じじゃない軽いテンションのものをまず企画して、やってみたりしました。
こんな小さなことでも勉強会って思っていいんだ！というくらいハードルを下げて、
何回かやると立派な勉強会だと自他ともに思えるようになると思っています。
堅苦しくしないコツは座学にしないこと…？一方向じゃなくて双方向でわいわいすること
資格取得に対しては、"勉強会"になってきたあたりで この延長だから挑戦してみたら？と自然な流れにできるのが理想かなとぼんやり思いました。
JSTQB FL を取ったばかりの人に、おすすめの本はありますか？
『マインドマップから始めるソフトウェアテスト』が好きです。
先輩と若手が一緒に進めていく方式になっているので、少し実践を思い描きやすいかなと思っています。
勉強会参加などがんばっているのになんとなく実務は残念な感じの後輩の育成、どうする？
参加した勉強会の内容がうまくささってないのかも？
その後輩の「残念」な点がどういうところか考えて、ヒントになりそうなものがないか探してみると思います。
反対に、残念に見えない楽しそうなところとか上手いところを探しておいて、
その人の得意そうな文脈に合うような表現でフィードバックする。
実際似たことをしたことがあって、あのときとののさんが言ってたことだと思いました！って言ってくれたときはうれしかったです
テスト分析・設計・実装・実施までやってるがプラスで要件定義段階からジョインして、仕様、VDの指摘までやっています。
これがテストエンジニアの道としてあっているのか迷子なのでアドバイスほしいです。 自動化してない（できない）
→テスト対象の品質（言葉広そうですが；）がいいほうがテストつくるのも何をするにも楽だと思うので、
自分の仕事を楽にするという意味で、いい道なんじゃないかな〜と個人的には思いました。
実際わたしも自動化はしたことないので偉そうなことは言えないです🥺
ですが自動化した先に何かよさが見えているなら、
自動化込みの仕様をつくることをしやすいポジションにいらっしゃるのでは？職権行使しちゃえ〜と思いました。
テストエンジニアになって半年たちました。どのプロジェクトに入っても品質のことを気にしてられない。
本で読んだことや、JSTQBでまなんだことを実践に直接的に反映させるにはどうすればいいんでしょう。 品質について考えながら作業するためにはどうすればいいでしょうか？
→Ask the Speaker でもそんな話が出ていた気がしていて、
最初はわからなくて、あとからわかることも多いから はじめは暗記的な勉強でもいいんじゃない？というお話でした。
すぐに反映させるという考え方とは別に、何度も振り返っているうちにあとから「こういうことか〜」「あのとき言ってたことか」
とふっとわかるときがくるから、そのときまで持っておく。
あとは、ゴールを決めるまでの移動手段（ドリブル/パス/ポジショニング）がままならないという感じの話かもしれないので
無意識にできる（自分の言葉で説明できる）くらいまで基礎練をするとか…？
設計をうまく作るコツはありますか？
コツ知りたい…わたしもまだまだ勉強中の身ですが、
自分以外にもスッとわかるように説明できるくらい、シンプルなアウトプットにすることを心がけています。
図をかいてみて、うまくかけないところは複雑だからもっと小さい単位で整理して、とか…！
家庭の事情で学習時間の確保が難しいのですが、どのように時間を作っていますか？
ひとみさんの 業務の一部に巻き込むこと、
かとあずさんの 時間がある人に出てもらって、教えてもらう
どっちもとっても素敵だと思いました！
自分に向いているキャリアの見つけ方やエキスパートの方が歩んでいるキャリアが知りたいです
あまり自身がエキスパートという感覚がないのであれですが…
実行委員の方が言っていたように、タグや実行委員がフォローしている人のTwitterをみると
いろんなキャリアの方がいらっしゃるので知れるかもしれません
自分に向いているかどうかは、やってみて、つらくないかどうかだと個人的には思います！
自分に抜けている知識や技術, 経験がないか不安なとき、なにかしていることがあれば知りたいです
「JaSST Tokyo」で何が話されているか を気にしているように思います。
新聞読む、みたいな感覚かもしれない？
プロダクトへの理解を深めるのに工夫していることを伺いたいです。特に QA 観点で力を入れていることがあればぜひお願いします！
to C のプロダクトに関わることばかりだったので、「実際に使う」ことをしています。
あまり身近じゃないプロダクトの場合は、そのプロダクトがそもそもどう使われているか、
どんな人が使うのかを調べたりとか
あとは、似たプロダクトにどんなものがあるか調べたりしている気がします
皆さんに質問です。テスターから開発者に転身したいと思ったことはありますか？それはどのような理由ですか？
転身したいと思ったことはとくにないかもです。
手段が違うだけでつくっているものは同じな気がするので、あんまり「転身」という意識がないかも…？
みなさんテスターを担当した後テストチームの立ち上げなどは経験されたのでしょうか。もしそうであれば、立ち上げの際に苦労した点など教えて頂きたいです。
立ち上げのときは複数人で動くときに必要なものを揃えるのが大変でした。
作業がかぶらないようにする仕組みとか、次の日への申し送りがしやすい作業環境とか…！
あとは、テストチームが何をしたいのか、他チームにわかってもらうことに苦労しました。
いろんなところに顔を出しているうちに覚えてもらえて、やりやすくなっていったなという思い出です
to とののさん：「勉強会の内容を、自分用にカスタムする」のために、どのように工夫していますか？エピソードがあれば、教えていただけたら嬉しいです。（from とろ）
まさにEdelweissオープニングで言われたとおり、「目標・目的」をたてておくこと
を心がけています。こういうことが知りたい/ここがモヤる/これを持って帰りたい/これおもしろそう など
それをもって参加すると、中身やふりかえりの際に自分に引っかかりやすくなるなと思ってます。
とののさんの発表に「テストがうまくなりたい」という言葉がたくさん出てきましたが、どうなると「テストがうまい」という状態になるんでしょうか？何か具体的な目標はありますか？
え むずい… ノリで生きててすみません🥺笑
直感的に言うと 市場バグが出ない とか、出ても痛くないとか…？
テストという手段に限らず、いいものを（自信がもてるものを）つくりたい＝仕事上手くなりたい かもなと、言われて思いました。
自分で上手いと思っちゃったら打ち止めかなと思うので、満足せずにいたいなと思います。
テスターとして働いていますが、「ものづくりに関われている」という実感がまるで持てません。
誰かが作ったものを、ユーザーが使う前に代わりに使って、おかしなことが起きてないことを確認している感じです。 とののさんは、どんな時に「自分がクリエイティブにものづくりに関われている」と感じましたか？
→おかしさ（反対の、正しさ）に疑問をもち始めたときかもしれません。
無駄なことはしたくない→意味のない遷移や挙動を確認したくない→このプロダクトでほんとうにやりたいことはなんだっけ
→他の手段はないか→こうしたほうがキレイじゃない？よくない？→それを開発や企画へフィードバックする
こういう動きを繰り返しているうちに、チーム内での「相談」になっていって、
一緒につくっている感じがあります。
2023/1/28 現在のとののの気持ちはこんな感じでした！
時間が経ったら、他の人の意見を聴いたりしたらまた違うことを思うかも！
ぜひご意見ください〜
それでは、ここまで読んでいただきありがとうございました。
【JaSST'22 Tokyo】参加記録2日目分
こんにちは、とのの（@tonono2587）です。
JaSST行ってきたのでメモのこします！
続きです
■日時
2022-03-10〜11の2日間
＠オンライン
■公式サイト
http://jasst.jp/symposium/jasst22tokyo/timetable.html
アーカイブくん、まってる
2日目
聴講セッション
- 新しい品質保証の形を目指して
- テストエンジニアの育成
- 招待講演：世界に普及可能な日本発の高品質サイバー技術の生産手段の確立
メモとか感想とか
QMファンネル
軸A
TE：テストエンジニア
PE：パイプラインエンジニア
QA：クオリティアシュアランス
軸B
スプリット
インプロセス
コーチ
コンサルタント/サービス
プロモーター
軸C
人数？
★テストは品質アップのいち手段だから、やりたいことが増えると
人はいずれQAになる、みたいに思っていたかもしれない
採用の事例とかを聞いているうちに、そうじゃないものだと思ってきて、
次はQAエンジニアなんだからこれできるようになるやろ？みたいな考え方は合わないなとわかってきた
ねこはねこ、カレーはカレーだと思ってきた（何を言ってるかわからないけど意味はない）
バランスをとらないとうまく回らない
足りないものの埋め方が間違ってたかも
テストエンジニアの育成
「自立」するミドルを育てたい
2：6：2 で分布する、真ん中の6狙い
チャンスは平等にするけどコストをかけることの差別化はする
壁の壊し方
1. 環境を変える
違う仕事へのアサイン
視野を広げるようなアクション
2. 周りに正直に話す、オープンになる
教えるというより「気づかせる」
気づきを与えるのが教育の根本
ハイ層はオリジナリティを持ってる
領域に関わらず再現性がある
自分がやりたいこと
自分ができること
会社がやらせたいこと
のバランス
★教えるの苦手、でも
教えなくてもいいのか、気づいてもらえるように動いてみればいいのか！ってなった
教えようと思うと指示になってしまいストレスがすごい。
気づいてもらうのが目的なら、響かなくてもいいと思える
勝手にちょっと楽になった
けしからん
正統派：大規模なものを維持する
超正統派：ゼロから1へ
埋もれている人を遊んでいいよと分離してあげること
正統派が壁をやぶるきっかけ
- こんなおもしろいものがあるんや！
- もっとさわりたい
- 勉強をはじめる
広く浅く興味をもって勉強する、読書
★長い目で見れば問題と向き合って頭使ったほうが楽
という話があった気がする、わたしもそう思った
話についていけてたかは自信がないけど、前向きでおもしろく感じた！
ハムスターにIPアドレス貼った話が好きだった。
二日間のまとめ
そら上手くいかないぜ〜みたいな気持ちになるときがちょこちょこあって、
いままでと違うことを試してみたくなった
ただ正直JaSSTハイなだけかもなので、一つ試してみてからが本番だと思う。
【JaSST'22 Tokyo】参加記録1日目分
こんにちは、お久しぶりですとのの（@tonono2587）です。
JaSST行ってきたのでメモのこします！
JaSST'22 Tokyo に参加したのでメモ
■日時
2022-03-10〜11の2日間
＠オンライン
■公式サイト
http://jasst.jp/symposium/jasst22tokyo/timetable.html
参加前
タイムテーブルをみて、ゲームのテストの話が多くて
これは参加せねば！となりました。
残念ながら興味のある裏番組が多くてそっちをみたのでアーカイブに超超超期待しています
1日目
聴講セッション
- 基調講演：Competing with Unicorns
- ゲーム業界に転生してゲームテスト大百科を作ってみた～ぼくたちの1つの物語～
- テスト支援ツールのアジャイル開発とビジネス化の課題に関する事例
- PdMと考えるQAとプロダクトマネジメント
メモとか感想とか
基調講演
プロジェクトを進めずに「ミッション」をすすめる。
ミッションは、指示のもと動くのではなくてボトムアップで目的(ゴール)に向かって動く
どうやったらゴールへ到達できるかは会社じゃなくてチームが考える
お金に対する考え方も違う。
レースをしてるから、ゴールへよりはやく到達するためなら、
チームの生産性が上がるならなんでも買っていい
顧客に焦点がある。製品を多くの人が使っているか、
数あるなかで自社のプロダクトを選んで使ってもらえるかが大事
人を雇用するときは価値観にあう人、
体現できるひとを大事にする
チームのみんながそのソフトウェアの品質に確信をもった状態で取り組めるようにする
★聞いているだけで生き生き働いてそうな会社だなとおもった。
いい働き方だとおもった。けどにわとりとたまごどっちが先なんだろう。
こういう働き方の会社はどうやって生まれるんだろう
ゲームテスト大百科
★この本ほしい！はやく出てほしい。
自分もそうだけどずばりこの本そのものがほしくて待ってる人いっぱいいるとおもう。
もしチームで勉強会するってなったら構成を参考にしようかな
深い細かい話は今回のセッションの目的から外れるっぽかったけど、
詳しく聞きたいところがいくつかあった。
魅力的品質へのテストとか、
課金意向、継続意向に関する視点とか
テスト支援ツール
開発はできても、ビジネスができるかは話が別
1：限られたリソースでやっていくためのやりくり
顧客セグメントの詳細化と優先順位づけ
2：市場成熟度が高まるまで鉄板の方法論の確立と啓蒙活動
★なるほど！
どうして進みが遅いのかとかはやっぱりちゃんと考えたほうがいい
プロダクトマネジメント
PdM：顧客の成果を大きくし続ける役割
根本問題を定義する、課題をよりよく解決する、みんなをわくわくさせる
QA：プロダクトの品質を司る担当
SWE：プロダクトビジネスの成果を具現化する担当
知っている情報の粒度が極力ないように
★ここでも、持っている情報はみんなほぼ同じにできるように みたいな話してた気がする
自分で動くためには同じ情報を揃えるのが肝なのかも
オープンに
二日目に続く
ソシャゲQA体操第一
みなさまおはようございます。
本日もがんばってまいりましょう。
まずは指を上下左右に振ってスクロール/スワイプ運動〜
いっちにーさんし ごーろくしっちはち
続けて美麗カードイラスト凝視の運動〜〜
ピンチイン♪ピンチアウト♫
親指と人差し指でつまむように縮めて〜
のばして〜〜〜
（音楽変わる）
好きなボタンを決めて画面のタップ運動〜
いっちに さんし ごーろっくしーちはち
はい連打〜〜（テンポよく）
もっかい連打〜！！
（音楽もどる）
推しSSR実装された！ガチャ画面開いて閉じる 開いて閉じる
ネットが落ちた！Wifiみなおし、Wifiみなおし…
アプリのタスクをきって再起動の運動〜
いっちにーさんし ごーろくしっちはち
さいごに〜〜
胸の前で手を組み息を大きく吸って〜〜〜〜〜
SSRを願う祈りの運動〜
♫♫☆☆☆☆☆
（音楽止まる）
はい。本日もお疲れさまでした。ごきげんよう
☆この記事はソフトウェアテストの小ネタアドベントカレンダー2日目の記事です。
