マニュアル QA (品質保証)QAエンジニア（手動テスト、アクセス権）
回答。
アクセス権と役割の手動テストは、異なるタイプのユーザーがアプリケーションの機能とデータに適切なアクセスレベルを持っていることを確認するために行います。
問題の背景
ユーザー数とその操作シナリオが増えるにつれて、単純なアプリケーションでも役割モデルが導入されました。アクセス権のミスは、しばしば重大なデータ漏洩やビジネス操作の制約につながりました。そのため、役割を丁寧に手動でテストする必要が生じました。
問題
- 機密データへのアクセス制限のミス；
- 権限の誤設定により、ユーザーが許可されていない操作を実行できること（たとえば、通常のユーザーによる管理機能へのアクセス）；
- 複合的な役割や非標準のアクセスシナリオの検証の難しさ。
解決策
- すべての既存の役割とそれぞれの役割に関連するアクションを文書化する；
- 各役割のためのテストセットを作成し、条件付きの役割の交差を含める；
- 機能だけでなく、データのさまざまな部分へのアクセスも確認する（CRUD）；
- UI経由だけでなく、直接リンクやAPI経由でのアクセス試行も検証する。
主要な特徴：
- シナリオの包括的なカバー: 各タイプのユーザーは、すべての可能な役割とアクションでテストされるべきです；
- 境界および複合的な役割のテスト: 異なる役割の権限が重なるときにエラーが発生することが多いです；
- 標準インターフェースのバイパスの確認: ユーザーが公式に権限を持っていないページ/アクションへの直接アクセスのテスト。
トリッキーな質問。
基本的な役割（例えば、「管理者」と「ユーザー」）だけをテストすることは十分ですか？
いいえ。特に、中間的であまり使用されない複合的な役割には、欠陥が隠れていることが多いです。
UIの制限（隠されたボタンや要素）は安全性のために十分ですか？
いいえ。UI制御は、アドレスやAPIを介した直接アクセスを妨げるものではなく、権限はサーバーロジックのレベルで制限する必要があります。
アプリケーションの異なるチャネル（例：ウェブとモバイルアプリ）を通じてアクセス権をテストする必要がありますか？
必須です。実装の違いは、振る舞いや権限の制限におけるエラーにつながることがよくあります。
一般的な間違いやアンチパターン
- 標準的な役割だけの確認
- サーバー側の制限を検証せず、外部インターフェースのみに依存すること
- 非標準や複合的な役割を軽視すること
実生活の例
ネガティブケース
UIのみを確認し、3つの主要な役割だけをテストしました。その結果、標準的でない役割の組み合わせを持つユーザーが直接リンクを介して管理機能にアクセスできました。
利点：
欠点：
- 本番環境で発見された重大な脆弱性
- ユーザーのセキュリティと信頼の侵害
ポジティブケース
テストのために、さまざまな役割の組み合わせを持つテストユーザーが作成され、APIおよび直接アクセスの監査が行われました。エラーはリリース前に発見され、修正されました。
利点：
- 高い品質とセキュリティ
- 内部および外部の漏洩リスクの低減
欠点：
- 多数のテストアカウントを作成するための時間コスト
- ドキュメントの量が増え、開発との調整が増す