QA Tips LT会 - vol.2 #QATipslt 参加記録
QA Tips LT会 - vol.2 #QATipslt 参加記録
社内で使っているツールの会社さんなので、ちょいちょい聞いているが、よく勉強会されているなっというイメージ。
ラクスにQAとして入社して
ガンダム好きが多い。。。の？
「試験仕様書」っていうのね。
QA というのがテストという意味が多いかな。
実際のどのようなことを記載しているのだろうか？
どうやってその仕様書を出しているのかを知りたいかったｗ
秘伝のたれという状態というのは開発担当者のノウハウか。
テスト用のドキュメントを作り始めたということで、プロセス・システムの一つの取り組みを始めたということですね。
学生としてQAインターンに殴り込みに行った話
QA ひまじゃね！？
QA ひまじゃねーっすｗ 忙しさっぱねーっす
QA職のインターンが少ないらしい。開発は多い
最近は、インターンがあってすごいね。
サイボウズさんや freeeさんとかあるっぽい。
QA職として働きたいってなかなかですね
『ソフトウェアテスト293の鉄則』鉄則016「認識論を駆使すること」への注釈
鉄則016 認識論を駆使すること
いかにて物事を知るのかという問題を扱っている
証拠と推論について
Epistemology 「知ること」について知ろうとする分野
証拠：知覚できるもの
懐疑論はテストするには大事
推論：証拠から、妥当な結論をだすこと
いかにして物事を知るのか、テストに限らず QA としては大事なマインドだと思う。
そもそも、作るものが妥当なのものなのかとか QA としては重要なこと。
MagicPodで回帰テストを自動化している話
Magic Pod は触ったことがないなぁ
うちでは、回帰テストという概念があまりないので、こういうシステムを導入する機会があまりないんだよね
テストのパターンが数十ぐらいなら自動化という文化にならないんだよね
システム/データ品質保証のための Airflow 活用法
Airflow っていうのを初めて知った
ワークフロー管理システムらしい
データパイプラインにおけるデータの品質担保につかうとのこと
複数に分かれているタスクやスクリプトでテストを実行の順番などを可視化してどこでこけたかを見やすくする。タスクの可視化か。
REST API とかでも実行可能とか。
Jenkins とかのパイプラインとかと同じような感じか。
コマンドラインでいいものが多いので、今度ためしてみようかな
にわかなりにQAの人と携わってみる…
開発担当者としてテストコンテストに出てきた感想。
仕様とか要求とかふわっときめていた、異常同値のテストが難しかったとのこと。
たしかに、目の前のものを作っているときはそうなりそうな気がする。
QAエンジニアになる 必要な知識とスキル
理想のQAエンジニア
プロダクトメンバーとともにプロダクトの品質課題をエンジニアリングで解決
業務課題をエンジニアリングで課題
最新技術を各ワークフローに取り込んで未来のプロダクト品質をQA・QCする
求められるQAエンジニア
テスト自動化
ツールやサービスの検証と導入
QA業務の見直し→課題の可視化→提案→改善
QA業務の俗人化問題改善
テスト業務のひっ迫問題改善
ビックバンリリースQA対策
QA業務引継ぎ・フォローアップサポート
QAエンジニアになる必要な知識とスキル
知識
プロダクトで使われている技術
ソフトウェアテストの基礎と実践
スキル
エンジニアリング（技術を駆使して課題を解決すること、プログラムだけではない）
QA業務
QAエンジニアがプログラマーやテスターの上位互換として表現されているっぽい
ソフトウェアのテスト設計に思うこと 2
ここ最近、機能性部分のテスト設計を行っているが、このテスト設計は開発設計書を補完するものだと思う。
(あくまで機能部分です）
そして、実装した機能に対しての意味付け(理由)を可視化・明示するものほかにならないとは思った。
考え方、見え方次第になるが、バグがあったときに、なぜバグではないのかを説明する義務が発生する。
速度が遅いとかいうのもバグの一つだ。
開発担当者に、なぜこの実装となるのかをしつこく聞く。
結局のところ、これを繰り返すための設計を作り、実装の意味づけをしていくことではないかと思っている。
ソフトウェアのテスト設計に思うこと 1
ソフトウェアのテスト設計の役目って何だろうと思ったこと
そもそも設計書が完璧であれば、チェックシートだけでいいと思う今日この頃。
ただ、設計が100% になることは、そうそうないので、それを補完していくのがテスト設計の役目じゃないかなと思い、ここ最近は設計書の暗黙領域を可視化することに注力している。
そして、テストが複雑になるときは設計の説明を受けるが、この説明が長くなったり、難しくなったりするところは、おそらく何か欠陥が含まれている(ことが多い)。
実際のコードのバグじゃなくても、構造的なバグが含まれていたり再利用できない状態などがある。
これも発見していくのもテスト設計の役目の一つかなと思っている今日この頃でした。
PowerShell でユーザーのパスワードを変更する
PowerShell でパスワード変更
ユーザとグループの管理のあの GUI を出すのがめんどくさいのでコマンドでパスワード変更したいと思ってみた。
powershell net user ユーザID（saMAccountName） "パスワード"
Powershell で実行しなくても、コマンドプロンプトの net コマンドで実行できたみたいね
テスト管理ツール「TestRail」のセミナー参加
はじめに
テクマトリクス様がTestRailの販売をした記念でTestRailのセミナーを開催されていました。
TestLink を利用しているのですが、どうにもこうにもアノわかりにくいUIがなんとかなんのかとか、自動化のテストスクリプト実行結果を連動するときの複雑さとかなんとかならんのか？と思って聞きに行ってきました
「テスト管理ツール「TestRail」のご紹介と日本語版のデモンストレーション」
基本的にエクセルシートに記載したテストケースとの比較で、テストケース管理が困難なことから話が始まる。
会場でテストでエクセルシートを利用している人のインタビューされていたが、約2/3ぐらいの挙手があり、テストケース管理でなんらかのシステムを利用しているところはポツポツしか手が上がらなかった。
エクセルシートで管理に限界を感じているんだろうなっというイメージだった。
テストケース管理やテスト設計の説明で、若干ん？？って思うところもあるんだが、「テストの生産性向上」という意味では同意。
（テストケースを作成すること自体をテスト設計っと言っている気がした。。。）
TestTail では以下でテストケースを管理している。
- プロジェクト
- マイルストーン
- テスト計画
- テストラン
- テストスイート
- セッション
- テストケース
以下にまとまっているページ
TestLinkでは以下で管理しているので、プラットホームを変えたりなど、テスト計画内でなんども同じテストをするのにビルド／バージョンを（疑似的に）分けたり、そもそもテスト計画分けたりで不便だった。
- テストプロジェクト
- テスト計画
- ビルド／バージョン
- テストスイート
- テストケース
このあたりは、よく考えられていると思った。
レポートは TestLink の内容とほぼかわらないが、グラフの色表示は見やすくできている。
自動化については、自動でテスト計画、テストランを作成するところは良い。
ただし、テストスクリプトを実行した後の結果をTestRailに送信するという、TestLinkと同じ方式。テストスクリプトを実行する起点がTestRailだったら楽なのに。。。。と思った
テストケースのバージョニングはできないとのこと。
仕様変更やら機能追加とかあると、これはツラい。。。。
要件との関連付けは、それぞれのテストケースごとに行うが、ドロップダウンからどの要件と関連付けるかを選択できる？
（ここで時間切れ）
The introduction of IDERA Inc. and TestRail
TestLinkの導入実績について、2020年のロードマップ
「TestRail」国内ユーザー様 導入事例の発表 ～「TestRailを利用することで効率化されたクラウド会計システムのテスト管理」
テストケース管理にエクセルシートやスプレッドシード、TestLinkを利用していたが、管理できなくなったり TestLink の保守できる人がいなくなったりで TestRail で管理を始めたとのこと。
CI/CDを利用してデプロイからテストを自動で実施するところを話をされていて、自分たちがだいぶ取り残されている感があったり。
TestRailの価格について
オンプレ版の話しかでなかったが、5ユーザで年間198,000円。
クラウド版もあるが、それはググって参考にした
まとめ
テストケースをまとめる機能は、たしかにTestLinkより優れており、実施しやすさはTestRail のほうがよさそう。グラフなどは、たしかにカラーがあってきれい。
自動化はTestLinkと差異はなくメンテナンスコストは同じかな。
テストケースのバージョニングがないのはイタイ。。。
Game QA Meet Up 参加
Game QA Meet Up
先日、Game会社の品質保証がどのようなかかわり方、どのような考え方をしているかなどの発表があり聞いてきた
株式会社ディー・エヌ・エー様
QAがok出さないとリリースできない体制
カスタマーサポートとQAの部署が同じにあり、カスタマーサポートからのクレームなどをフィードバックしている
開発チームにもの言いやすい体制・風土を大切にしている
株式会社ミクシィ様
ソムリエとQAと比較しながらQAの役割についてを話されていた。
「 ユーザや開発チームから不愉快を取り除き、サービスへの没頭を支援する」
バグによるユーザの不愉快はもちろん、デバッグの時間は本来新機能を開発すべき時間であり
QAにとってだいじなこと
予算、スケジュール、開発規模、技術、品質などを「観察」
観察から得られた情報、QAの技術力などから適切な「判断」
リスクなど判断して要望とは異なる意見を言う「責任」
知識、観察、判断、責任、一人で全てをかねる必要はないが、チームとして持つ必要がある。そして個人がこの概念を理解すること
株式会社バンダイナムコスタジオ様
とにかく元気だったｗｗ
ゲームという特性上魅力的品質が前面に出てテストの存在感が小さい状況。
テスト自体も、ほぼ手動で頑張っていますということで、存在感ない中で手動が大きく、自動が小さく書かれているｗｗｗ
https://www.juse.or.jp/departmental/point02/08.html
狩野モデルをだしつつ当たり前品質がなくなると結局売れなくなるよねということを熱く語っていた
最終的には、だれも見ていないけどテストしてくれてありがとうっといわれる存在になりたいっということでものすごく早くしゃべっていました
グリー株式会社様
障害発生率など明確なKPIを立てて評価している
株式会社アカツキ様
「想定通りに動くのは当たり前 楽しんでもらえる、支持してもらえるのが大事」
そのためにどのようなマインドでテストをしていくか、ミッション、ビジョン、バリューをしっかり持ってQAをする
KLab株式会社様
リリースしているゲームタイトルでの、それぞれについてQAの立ち回りを話してくれました。
「ラブライブは長く運用されているので人依存になっている部分から見える化したりするのがQAのお仕事」、
「テイルズオブクレストリアは、バンナム配信なので予算、規模などを考慮した提供が求められる」
など。
遅れている原因を数値化・可視化 リリース判断をする組織ではなく、判断するための材料を出している
QAは健康診断、各プロダクトで正確に可視化した健康診断を伝えていきたい
まとめ
技術的な話しではなく、QAがどのようなマインドでテストを実施しているかを話してくれた。
どのセッションにも、QAが単にテストをするだけではなく、顧客や社内の開発チームへの価値を提供していく意気込みがすごかったセミナーでした
グリー様の話をちょっと聞きそびれてしまったが、1枠15分？であわただしく発表が進んでました。もうすこしゆっくり聞けてもよかったのかも。
