JSTQBFL1章 まとめ

おなかすいた

JSTQB FL1章を読みました。
シラバスの文章が長いので引用して大事だと思うところ、テス友で出題された部分を太字にしてまとめてみます。

🐰JSTQBFL1章 まとめ
🐱JSTQBFL2章 まとめ
🦊JSTQBFL3章 まとめ
🐶JSTQBFL4章 まとめ
🐧JSTQBFL5章 まとめ
🐷JSTQBFL6章 まとめ


■シラバス内容抽出/解釈


✔ テストとは何か？

ソフトウェアテストはソフトウェアの品質を評価し、運用環境でソフトウェアの故障が発生するリスクを低減する1つの手段

  • 動的テスト
    テスト対象のコンポーネントやシステムを実行すること

  • 静的テスト
    要件、ユーザーストーリー、ソースコードなどの作業成果物をレビューする活動


✔ よくある誤解

  • テストはソフトウェアを実行し結果を確認するだけだというもの
    ➡テストプロセスは、テストの計画、分析、設計、実装、テスト進捗と結果の報告、テスト対象の品質評価などの作業を含む。

  • テストは要件、ユーザーストーリー、またはその他の仕様の検証に重点を置くことがすべてだというもの
    ➡テストでは、指定されている要件をシステムが 満たすかどうかを確認することに加えて、ユーザーやその他のステークホルダーのニーズを運用環境でシステムが満たしていることの妥当性確認も行う。


✔ テストに共通する目的

すべてのプロジェクトで、テストの目的は以下を含む。

  • 要件、ユーザーストーリー、設計、およびコードなどの作業成果物を評価することによって欠陥を防ぐ

  • 明確にしたすべての要件を満たしていることを検証する

  • テスト対象が完成したことを確認し、ユーザーやその他ステークホルダーの期待通りの動作内容であることの妥当性確認をする

  • テスト対象の品質に対する信頼を積み重ねて、所定のレベルにあることを確証する

  • 欠陥や故障を発見し、ソフトウェアの品質が不適切になるリスクレベルを軽減する

  • ステークホルダーが意志決定できる、特にテスト対象の品質レベルについての十分な情報を提供する

  • 契約上、法律上、または規制上の要件や標準を遵守する、そして/またはテスト対象がそのような要件や標準に準拠していることを検証する

テストの目的は、テスト対象のコンポーネントまたはシステム、テストレベル、ソフトウェア開発ライフサイクルモデルといった要因により異なる。例えば、以下のような相違点がある。

コンポーネントテスト
・コンポーネントテストのコードカバレッジを増やす
・ソフトウェア中の欠陥を早期に特定して修正するためになるべく多くの故障を見つける

受け入れテスト
・システムが期待通りに動作し、要件を満たすことを確認
・指定期日にシステムをリリースすることのリスクについてステークホルダーに情報 を示す

📝コードカバレッジ
テストスイートがソフトウェアのどの部分を実行（網羅）し、どの部分が未実行かを判定する分析手法
📝テストスイート
テストケースやテスト手順のセット 


✔ テストとデバッグ

テストとデバッグは異なる。

  • テスト
    ・実行することでソフトウェアに存在する欠陥に起因する故障を示す
    ・テスト担当者はテスト対象の初回のテストと最終的な確認テストに責任を持つ

  • デバッグ
    ・故障の基となる欠陥を見つけて、解析し、取り除く一連の開発の活動
    ・開発担当者はデバッグと、関連するコンポーネントテスト、およびコンポーネント統合テスト（継続的インテグレ ーション）に責任を持つ

📝継続的インテグレーション（CI）
ソフトウェア開発手順のひとつ。自動化したプロセス内ですべての変更をコミットすると、それらをすぐにマージ、統合、テストする。
※通常システム開発では、記述したソースコードに誤りがなく、問題なく動作するかの動作確認/テストを繰り返し行う。CIでは、その一連の流れ（開発箇所の反映とテスト）を自動化する。


✔ テストの必要性

  1. コンポーネントやシステム、およびドキュメントを厳しくテストすれば、運用環境で問題が発生するリスクを低減できる

  2. システムが稼動する前に欠陥を検出して修正すると、コンポーネントやシステムの品質向上に効果がある

  3. 契約や法律上の要件、および各業界の標準に合致していることを証明す るためにソフトウェアテストが必要になるケースもある

✔ 品質保証とテスト

品質保証（または単に QA）という用語がテストを意味するために使われることがある。しかし、品質保証とテストは、関連してはいるが同じではない。『品質マネジメント』という概念 が両者を結び付けている。

  • 品質マネジメント
    品質に関して組織の方針を示し、組織をコントロールするための活動
    ➡品質保証と品質コントロールの両方を含む

  • 品質保証
    品質が適切なレベルに確実に到達するよう、適切なプロセスを遵守すること
    ➡プロセスを適切に遂行すると、これらのプロセスで作成される作業成果物は一般的に高い品質を持つ

  • 品質コントロール
    適切なレベルの品質を達成するために役立つさまざまな活動（テストを含む）

イメージ図（雑）


✔ エラー、欠陥、および故障

人間はエラー（誤り）を犯す。そのエラーがソースコードや他の関連する作業成果物の欠陥（フォールトまたはバグ）となる。
ex ) 要件の導出のエラーは要件欠陥をもたらし、結果的にプログラミングエラーをもたらし、コード内に欠陥をもたらす。

コードの欠陥が実行されると、故障が起きることがあるが、すべての状況で故障が起きるわけではない。欠陥によっては、故障を起こすためにきわめて特別な入力や事前条件が必要である。

エラーは以下のものを含むさまざまな理由によって発生する。 

  • 納期のプレッシャー

  • 人間の誤りを犯しやすい性質

  • プロジェクト参加者の経験不足または技術不足

  • プロジェクト参加者間の誤ったコミュニケーション（要件や設計の誤ったコミュニケーションを含む）

  • コードの複雑さ、設計の複雑さ、アーキテクチャーの複雑さ、解決すべき根本的な問題の複雑さ、そして/または使用する技術の複雑さ

  • システム内またはシステム間のインターフェースに関する誤解（特に、関連するシステムの数が 多い場合）

  • 新しく不慣れな技術

※故障はコード内の欠陥だけでなく、環境条件（放射能、磁気、電界、 汚染）によりファームウェアの誤動作を起こしたり、ハードウェアの構成変更がソフトウェアの実行に影響を与えたりすることがある。


✔ 欠陥、根本原因、および影響

欠陥の根本原因とは、欠陥を埋め込んだ最初の行為または条件のことである。欠陥を分析して根本原因を識別し、類似の欠陥が今後発生しないようにしなければならない。

ex) 1 行のコードの間違いが間違った利子の支払いを引き起こし、顧客の不満を招いたとする。欠陥のあるコードは、プロダクトオーナーが利子の計算方法を誤解しており、ユーザーストーリーが曖昧となったために埋め込まれた。

根本原因 、エラー➡ 「プロダクトオーナーの知識不足」
欠陥 ➡ 「コードでの不適切な計算」
故障 ➡ 「間違った利子の支払い」
影響 ➡ 「顧客の不満」

📝エラー
間違った結果を生み出す人間の行為
📝欠陥（フォールト、バグ）
作業成果物に存在する、要件または仕様を満たさない不備または欠点
📝故障
コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと



✔ テストの 7 原則

  1. テストは欠陥があることは示せるが、欠陥がないことは示せない
    テストにより、欠陥があることは示せるが、欠陥がないことは証明できない。テストにより、ソフトウェアに残る未検出欠陥の数を減らせるが、欠陥が見つからないとしても、正しさの証明とはならない。

  2. 全数テストは不可能
    すべてをテストすること（入力と事前条件の全組み合わせ）は、ごく単純なソフトウェア以外では非現実的である。全数テストの代わりに、リスク分析テスト、テスト技法、および優先度によりテストにかける労力を集中すべきである。

  3. 早期テストで時間とコストを節約
    早い段階で欠陥を見つけるために、静的テスト活動と動的テスト活動の両方をソフトウェア開発ライフ サイクルのなるべく早い時期に開始すべきである。早期テストは、『シフトレフト』とも呼ばれる。ソフト ウェア開発ライフサイクルの早い時期にテストを行うことにより、コストを低減または削減できる。

  4. 欠陥の偏在
    リリース前のテストで見つかる欠陥や運用時の故障の大部分は、特定の少数モジュールに集中する。

  5. 殺虫剤のパラドックスにご用心
    同じテストを何度も繰り返すと、最終的にはそのテストでは新しい欠陥を見つけられなくなる。この 「殺虫剤のパラドックス」を回避するため、テストとテストデータを定期的に見直して、改定したり新規にテストを作成したりする必要がある。ただし、自動化されたリグレッションテストの場合は、同じテストを繰り返すことでリグレッションが低減しているという有益な結果を示すことができる。

  6. テストは状況次第
    状況が異なれば、テストの方法も変わる。例えば、安全性が重要な産業用制御ソフトウェアのテスト は、e コマースモバイルアプリケーションのテストとは異なる。また、アジャイルプロジェクトとシーケンシャルソフトウェア開発ライフサイクルプロジェクトでは、テストの実行方法が異なる。

  7. 「バグゼロ」の落とし穴
    テスト担当者は可能なテストすべてを実行でき、可能性のある欠陥すべてを検出できると期待する組織があるが、原則2と原則1により、これは不可能である。また、大量の欠陥を検出して修正するだけで システムを正しく構築できると期待することも誤った思い込みである。例えば、指定された要件すべて を徹底的にテストし、検出した欠陥すべてを修正しても、使いにくいシステム、ユーザーのニーズや期 待を満たさないシステム、またはその他の競合システムに比べて劣るシステムが構築されることがある。

✔ テストプロセス

📝テストプロセス
テストの目的を達成する確率を高くする、汎用的なテスト活動のセット

✔ 状況に応じたテストプロセス

テストベースに、計測可能なカバレッジ基準を定義しておくと、非常に役立つ。カバレッジ基準は重要業績評価指標（KPI）として効果的に機能して活動を 推進し、ソフトウェアテストの目的の達成度を示す。

📝テストベース
テスト分析と設計のベースとして使用するあらゆる情報。テストを実際にどのように行うかをまとめた「テストケース」作成時に、その情報源となるもの
ex) モバイルアプリケーションのテストベースは、要件のリストとサポート対象のモバイルデバイスのリストを含むとする。その場合、各要件はテストベースの要素であり、サポート対象の各デバイスもテストベースの要素である。
📝カバレッジ基準
テストにおいて着目する「要素」のことを指す。 カバレッジを出すのに何を基準にするか、という決めごとのようなもの



✔ テストの活動とタスク

テストプロセスを構成する主な活動のグループは以下の通りである。
これらの主なグループの多くは論理的にはシーケンシャルに行われるが、繰り返されることが 多い。

  • テスト計画 

  • テストのモニタリングとコントロール

  • テスト分析 

  • テスト設計

  • テスト実装 

  • テスト実行 

  • テスト完了

アジャイル開発
計画作業を継続的に行いながら、ソフトウェアの設計、ビルド、 テストが連続して行われる活動を、小さな単位で繰り返し行う。このため、このソフトウェア開発アプ ローチでは、テストの活動も反復的に継続して行う。

シーケンシャルソフトウェア開発
主な活動のグループを論理的な順序で段階的に行う場合、重なりあって実行したり、組み合わせて実行したり、 同時に実行したり、実行を省略したりするため、システムやプロジェクトの状況に合わせてこれらの主な活動のグループをテーラリングする必要がある。

📝テーラリング
決められた基準や手順を、プロジェクトに合わせて最適化すること


■ テスト計画
テストの目的と、状況により課せられる制約内でテストの目的を達成するためのアプローチを定義する。
ex) 適切なテスト技法とタスクを指定し、納期に間に合うようにテストスケジュールを作成する
テスト計画書は、モニタリングとコントロールの活動からのフィードバックに応 じて更新をする。

■ テストのモニタリングとコントロール
テストのモニタリング とコントロールは、終了基準（「完了（done）の定義」）の評価により支援される。
テストモニタリング：
テスト計画書で定義したテストモニタリングのメトリクスを使用して、計画した進捗と実際の進捗を継続的に比較する活動
テストコントロール：
テスト計画書の目的に合致させるために対策を講じる活動（テスト計画書の継続的な更新活動も含む）

📝メトリクス
さまざまな活動を定量化し、その定量化したデータを分かりやすく加工した指標

計画に対するテスト進捗は、テスト進捗レポートを使用してステークホルダーへ伝える。このレポートで伝える内容には、計画からの逸脱や、テストの中止を決定するために必要な情報を含む。

■ テスト分析
テスト可能なフィーチャーを識別し、テスト条件を決めるためにテストベースを分析する。言い換えると、テスト分析では計測可能なカバレッジ基準から見た「何をテストするか」を決定する。

📝フィーチャー
ソフトウェアやシステムの持つ機能・特徴のこと

  • テストレベルごとに適切なテストベースを分析する。

  • テストベースとテストアイテムを評価して、さまざまな種類の欠陥を識別する。

  • テストすべきフィーチャーとフィーチャーのセットを識別する。
    ➡ 各フィーチャーのテスト条件を決めて優先度を割り当てる。
    ➡ テストベースの各要素と関連するテスト条件の間に双方向のトレーサビリティを確立する。

📝トレーサビリティ
過程などが追跡可能である状態のこと

テスト分析プロセスにてブラックボックス、ホワイトボックス、および経験ベースのテスト技法を適用することは、重要なテスト条件の欠落を防止し、精度と正確性が高いテスト条件の特定に役立つ。

・振る舞い駆動開発（BDD）
・受け入れテスト駆動開発 （ATDD）
➡ コーディングの前にユーザーストーリーや受け入れ基準からテスト条件やテス トケースを作成する。これらの技法はまた、ユーザーストーリーや受け入れ基準を検証および妥当性確認をして、欠陥を検出する。

■ テスト設計
テスト設計では、テスト条件をハイレベルテストケース、ハイレベルテストケースのセット、およびそ の他のテストウェアへ落とし込む。つまり「それをどうテストするか」を決定する。

  • テストケースおよびテストケースのセットを設計し、優先度を割り当てる

  • テスト条件とテストケースを支援するために必要なテストデータを識別する

  • テスト環境を設計し、必要なインフラストラクチャーやツールを識別する

  • テストベース、テスト条件、テストケースの間で双方向のトレーサビリティを確立する

■テスト実装
テスト実行に必要なテストウェアを作成、および/または完成させる。そこにはテストケースの順序を決定してテスト手順を作成することが含まれる。つまり、「テストの実行に必要なものすべてを準備したか」の答えである。

  • テスト手順を開発して優先度を割り当てる。場合によっては、自動化テストスクリプトを作成する

  • テスト手順や（存在する場合）自動化テストスクリプトからテストスイートを作成する

  •  効率的にテスト実行ができるように、テスト実行スケジュール内でテストスイートを調整する

  • テスト環境（これには、テストハーネス、サービスの仮想化、シミュレーター、およびその他の インフラストラクチャーアイテムが含まれる）を構築する。また、必要なものすべてが正しくセットアップされていることを確認する

  • テストデータを準備し、テスト環境に適切に読み込ませてあることを確認する

  • テストベース、テスト条件、テストケース、テスト手順、テストスイートの間での双方向トレーサビリティを検証し更新する

※テスト設計とテスト実装は一緒に行うことがある。
※探索的テストやその他の種類の経験ベースのテストの場合：
テスト設計とテスト実装は、テスト実行の一部となり、ドキュメントもまとめて作る場合がある。探索的テストでは（テスト分析の一環として作り出した）テストチャーターに基づいて、テスト設計とテスト実装を行いながらテスト実行をする。

📝テストチャーター
テストの目的を完了できたと判断するための指針


■ テスト実行
テスト実行スケジュールに従ってテストスイートを実行する。

  • テストアイテムまたはテスト対象、テストツール、テストウェアのID とバージョンを記録する。

  • 手動で、またはテスト実行ツールを使用してテストを実行する

  • 実行結果と期待結果を比較する

  • 不正を分析して、可能性のある原因を特定する（故障はコード内の欠陥によって発生する可能性があるが、偽陽性が発生することもある。）

  • 故障を観察し、観察に基づいて欠陥を報告する。

  • テスト実行の結果（合格、不合格、ブロックなど）を記録する。 

  • 不正への対応の結果、または計画したテストの一環として、テスト活動を繰り返す（修正したテストケースによるテスト、確認テスト、および/またはリグレッションテストの実行）

  • テストベース、テスト条件、テストケース、テスト手順、テスト結果の間で双方向のトレーサビリティを検証し更新する。

■ テスト完了
完了したテストの全活動のデータを集め、プロジェクトから得たこと、テスト ウェア、およびその他の関連する情報すべてをまとめる。
・ソフトウェアシステムが リリースされたとき
・テストプロジェクトが完了（または打ち切り）したとき
・ アジャイルプロジェク トのイテレーションが完了したとき
・ テストレベルが完了したとき
・ メンテナンス版のリリースが完了 したとき

  • すべての欠陥レポートがクローズしていることを確認する。または、テスト実行の終了時に未解決として残されている欠陥について変更要求またはプロダクトバックログアイテムを作成する

  • テストサマリーレポートを作成して、ステークホルダーに提出する

  • テスト環境、テストデータ、テストインフラストラクチャー、その他のテストウェアを次回も使えるように整理し保管する。 

  • テストウェアをメンテナンスチーム、他のプロジェクトチーム、および/またはその使用により 利益を得る可能性のある他のステークホルダーに引き継ぐ。 

  • 完了したテスト活動から得られた教訓を分析し、次回のイテレーションやリリース、プロジェク トのために必要な変更を決定する。

  • 収集した情報をテストプロセスの成熟度を改善するために利用する



テストプロセス
分析　⇒　設計　⇒　仕様作成　⇒　手順作成　⇒　実施
※分析、設計(=テスト設計仕様の作成)、テストケース(＝テストケース仕様)の作成、テスト手順(=テスト手順仕様)の作成、実行(＝実施)
↑「仕様」とは、テスト設計仕様、テストケース仕様、テスト手順仕様を総称している


✔ テスト作業成果物

テスト作業成果物は、テストプロセスの一環として作成する。

■ テスト計画の作業成果物
含まれるもの↓
・1 つ以上のテスト計画書（テスト計画書にはテストベースに関する情報）
・トレーサビリティに関する情報
・テストのモニタリングとコントロールで使用する終了基準（または完了 （done）の定義）

■テストのモニタリングとコントロールの作業成果物
含まれるもの↓
・さまざまな種類のテストレポート
∟ 定期的に作成するテスト進捗レポート
∟ さまざまな完了マイルストーンで作成するテストサマリーレポート

※タスクの完了、リソースの割り当てや使用状況、工数などプロジェクトマネジメントにて取り扱う事項にも言及する。

■テスト分析の作業成果物
含まれるもの↓
・決定して優先順位を付けたテスト条件

※探索的テストのテスト分析では、テストチャーターを作成する場合がある。
※テスト分析では、 テストベースに含まれる欠陥を検出した結果をレポートする場合もある。

■テスト設計の作業成果物
含まれるもの↓
・テスト分析で決定したテスト条件を実行するためのテストケースとテストケース のセット
・必要なテストデータの設計、および/または識別
・ テスト環境の設計
・インフラストラクチャーとツールの識別

※具体的な入力データと期待結果の値を記載しないハイレベルテストケースを設計することがよい実践例。ハイレベルテストケースは、テストサイクルに応じた具体的な値を指定して複数のテストサイクルで再利用できる上に、テストケースの範囲を適切に文書化できる。

📝ハイレベルテストケース
抽象的な事前条件、入力データ、期待結果、事後条件、およびアクション（該当する場合）を含むテストケース
（同義語：論理的テストケース、抽象的テストケース）

■テスト実装の作業成果物
含まれるもの↓
・テスト手順とそれらの順序付け
・テストスイート
・ テスト実行スケジュール
※ツールを使用して作成する作業成果物（サービス仮想化など）を作成することもあれば、ツールで使用される作業成果物（自動化テストスクリプトなど）を作成することもある。
※テストデータやテスト環境の作成や検証を行うこともある。

テストデータは、テストケースの具体的な入力値や期待結果を割り当てる役割となる。具体的なテストデータに関連する具体的な期待結果は、テストオラクルを使用して識別する。

📝テストオラクル
テスト対象の実行結果と比較可能な具体的なテストデータや期待結果が掲載されている情報元

■テスト実行の作業成果物
含まれるもの↓
・テストケースまたはテスト手順のステータスに関するドキュメント
ex) テスト実行可能、 合格、不合格、ブロック、意図的にスキップなど 
・欠陥レポート
・テストアイテム、テスト対象、テストツール、テストウェアに関するドキュメント

■テスト完了の作業成果物
含まれるもの↓
・テストサマリーレポート
・後続するプロジェクトまたはイテレーションを改善するためのアクションアイテム
・変更要求またはプロダクトバックログアイテム
・変更に対応して最終的に完成したテストウェア



✔ テストベースとテスト作業成果物との間のトレーサビリティ
テストカバレッジの評価に加えて、優 れたトレーサビリティが役に立つことは以下の通りである。

  • 変更の影響度を分析する 

  • テストを監査可能にする

  • IT ガバナンス基準を満たす

  • テストベースの要素のステータス（例えば、テストが合格となった要件、テストが不合格となった要件、テストを保留している要件）を含めることで、テスト進捗レポートとテストサマリーレ ポートの理解しやすさを向上する

  • テストの技術的な側面をステークホルダーにとってなじみのある言葉で説明する

  • ビジネスゴールに対するプロダクトの品質、プロセス能力およびプロジェクト進捗の評価に関する情報を提供する

📝ITガバナンス
IT業務の活動を監視・統制するための仕組みやルール



✔ テストの心理学

ソフトウェア開発は、ソフトウェアテストを含めて人が行うため、人の心理がソフトウェアテストに重要な影響を及ぼす。

✔ 人の心理とテスト
要件のレビュー、およびユーザーストーリーの洗練をするセッションなど、静的テスト中に欠陥を見つ けることや、動的テスト実行中に故障を見つけることは、プロダクトおよびプロダクトの開発担当者に対する非難と解釈されることがある。

『確証バイアス』と呼ばれる人の心理の要素は、持っている信念に合わない情報を受け入れがたくする。
ex) 開発担当者は、コードは正しいという思い込みがあるの で、確証バイアコードが正しくないということを受け入れがたい。

確証バイアスに加えて、 他の認知バイアスがテストからの情報の理解または受け入れを困難にする場合がある。さらに、テストからの情報は悪いニュースを含んでいることが多く、悪いニュースをもたらす人は非難される傾向がある。

■ コミュニケーションを適切に行う方法

  • 対決ではなく、協調姿勢で開始する

  • 全員のゴールは、高品質のシステムであることを再認識するとよい

  • テストの利点を強調する。
    ex)
    開発担当者：欠陥情報は、作業成果物の品質向上と開発担当者のスキル向上に役立つ
    組織：欠陥をテストで検出して修正すると、時間と経費の節約になり、プロダクト品質の全体的なリスクも減る

  • テスト結果や他の発見事項は、中立な立場で、事実に焦点をあてて伝え、欠陥を作りこんだ担当者を非難しないようにする

  • 客観的かつ事実に基づいた欠陥レポートを書いたり、発見事項をレ ビューしたりする。

  • 他人の気持ちや、他人が情報に対して否定的に反応した理由を理解するように努力する。

  • 自分の言ったことを他人が理解し、他人の言ったことを自分が理解していることを確認する


✔ テスト担当者と開発担当者のマインドセット
開発担当者とテスト担当者は、異なった考え方をすることが多い。両者のマインドセットを組み合わせることで、より高いレベルのプロダクト品質 を達成できる。

💗テスト担当者：好奇心、プロとしての悲観的な考え、批判的な視点、細部まで見逃さない注意力、良好で建設的なコミュニケーションと関係を保つモチベーションが必要となる。

💗開発担当者：解決策に問題があるかを考えるよりも、解決策の設計と構築により大きな関心がある。また、確証バイアスが、自分自身の犯したエラーに気づくことを困難にする。正しいマインドセットを持って自身のコードをテストする必要がある。

独立したテスト担当者がテスト活動のいくつかを担うと効果的な欠陥検出ができる。
➡ 独立したテスト担当者は、作業成果物の作成者（ビジネスアナリスト、プロダクトオーナー、設計者、および開発者）とは異なる認知バイアスと観点を持つため


✔ 個人メモ

「テストの活動とタスク」の理解が曖昧。テスト分析やテスト実装などの各段階でやるべきことは、現場で行っていることならぼんやり分かっているが、シラバスに沿った認識で完全に覚えられていない。
文章で示されると、「あれ、どれがどのときに行うことだっけ。。。」となるので問題で出たら多分躓く。
各段階の作業成果物もそれぞれしっかりと覚えないと。。。（><；）

この記事が気に入ったらサポートをしてみませんか？