inomataとともに2/3~4日開催のJaSST'17 Tokyoに行ってきましたのでざっくりとレポートしたいと思います!
A1 : 基調講演: ICT応用S&S製品の 品質不良のリスクと SQuaREシリーズ 国際標準 - その歴史と概要
さまざまな国際標準に携わってこられた東 基衞先生による講演。国際標準はなぜ必要なのかだったり、国際標準はどのようにして作成されてきたのかだったり、さまざまな国際標準において、各団体がどのような意見をもっているのかだったりをお話してくださいました。
この講演で印象に残った言葉は
「要求されない品質は作りこまれない」
という言葉でした。
我々が、今当たり前のように多くの製品で得ている品質は、誰かが要求し、誰かが作りこんでくれたものなんだなと最実感しました。
また、国際標準というのはある一定の人たちが作成し、それを利用するといったことが定着しているようにも思えますし、一部は形骸化しているものもあります。
しかし、この国際標準は何のために作成されたのか、何を解決したかったのかという経緯を当事者の方から聞くことによって、国際標準を使用していないから私には関係がないということではなく、自社内での標準を作成したりすることにより自分が求めたい品質を作りこめばいいのだなと再認識しました。
(レポート:kmt)
D2-1: 次世代システムに求めら れるソフトウェア検証技術 ~静的解析の価値と有効性~
MathWorksさんによる静的解析ツールの説明静的解析ツールによって防げる不具合はたくさんあると思いますので、予算にみあったツールをみつけて効率化を図ってみてはいかがでしょうか?
このセッション以外にも各スポンサーさんがブースをだしてくださってるので興味がある方は話を聞くこともできます。
まだ自社に来てもらうほどではないけど気になるといったものについて聞けるチャンスがあるのはとてもいいことだと思います。
(レポート:kmt)
D2-2: 楽天トラベルの 開発プロセスに関して (楽天株式会社)
楽天トラベルさんの開発プロセスに関してのセッション30人ものQAがいらっしゃるそうで、かなりの数のリリース、バグFIX、バージョンアップをされていました。
楽天トラベルさんのQAには不具合修正に関する優先順位を決定したり、リリースするかどうかを判定する権利があるそうです。
PDMとDEVとQAのパワーバランスを大切にされていて、それが実践できるような開発体制になっているようです。
このパワーバランスが乱れると、リリースが遅れたり、無理なリリースをしてしまったりといったことが発生しやすくなるのでこの体制はとてもすばらしいなと思いました。
自動化も専任の方がいらっしゃり、積極的に進めていらっしゃるようで、クオリティゲートという開発者が既存の自動化を流してからリリーステストを依頼するような仕組みをされていたります。
(レポート:kmt)
チュートリアル1: IoT時代に立ち向かう テスト・ファジング 技術入門
ベリサーブの松木さんによるファジング技術入門ファジングとはセキュリティテスト・脆弱性診断手法の一種で、「ファズ」と呼ばれる通常想定されない入力データをコンピューティングリソースにより半自動的に生成、入力、挙動確認を行うテストのことだそうです。
ファジングの効果・苦手分野・取り巻く環境・実施プロセスについてお話してくださいました。
画像ソフトやネットワーク通信ソフトなどで、ファジングを実施する対象と目的が明確であればコストをかけてでもやる意味・意義のある技術であると感じました。
ただ、結構なコストはかかるであろうと思われますので、エンジニアとしての知見習得としてはアリだとは思いますが、ファジングが有効な対象であったとしても、そこまでのリスクやコストをかける必要がないもので無理にやるものではないです。
(レポート:kmt)
D4-1: 大規模業務システム における再利用可能な テスト自動化の取り組み
良い感じに自動テストのフレームワークを作って効率化した話です。テスト仕様からテストスクリプトに落としていたのでレビューに時間かかる。プロジェクト毎に使っているフレームワークが違ったりするのでノウハウの共有とかできていなくて非効率だった。
などのプロジェクト間の壁が厚い場合に起こりそうな問題を、共通のツールを開発・利用する事でこれらの課題を解消したという話でした。
基盤となるところにプラグイン形式で機能が追加できたり、キーワード駆動っぽいインターフェイスでテストを実行できるみたいで汎用化の高そうなツールでした。
特に、テストの作成がプログラマじゃなくても使える、あるいは読めるという点が、保守チームへの引継ぎにとても効いているとのことです。
やり方が異なるものをツールに落とし込んで共通化し、効率化するというのは、王道ながらも良いアプローチだと思いました。ただ、ツール開発自体はコストが高そうな気もしました。
(レポート:inomata)
補足---プラグインなどはツールが必要なチームが作ったりしているそうですが、基本的にお一人でメンテナンス管理されておられるそうです。一回つくってしまえば、修正自体はほとんどないそうです。このように自分ですすんで効率的なツールを作成される方がいらっしゃるのは組織として本当に強みですね!(kmt)
D4-2: 不具合管理方法の 改善による テスト工程の効率化事例
知識レベルの異なるテスタのチームが効率よくテストする方法についての話です。知識レベルというのはプロダクトのドメイン知識の事で、これが不足する事と
- テストのミスによるバグ報告
- 影響範囲部分のテスト未実施により、同じ問題があとで発覚する
1についてはQ&AのDBを用意し、バグ管理と同じ様に質問管理を行ってバグか仕様かを事前に切り分けた。2についてはバグの原因分析をして影響範囲を特定していったというものです。
組織が大きいくて、開発とテスタの距離が遠いと(物理的にも心理的にも)、こういう施策は効果が高いと思いました。
リーダーミーティングを通してフローを守らせたという話でしたが、バグの原因分析と影響範囲の特定なんかは担当者どうしで話をするよりリーダー間で話あったほうがよさそうです。
(レポート:inomata)
B5: テスト現場の お悩み相談!!
識者が現場で起こりがちな問題に対して解決手段を教えてくれる?セッションでした。席が足りなくなるくらい大盛況で、いかに現場で困っているかが伺えます。マネジメント系の問題が多い印象でした。
お悩みのラインナップ
- 質の低いテストベースからは質の低いテストしか出来ない。
- 仕様が無くても要求はあるはず。なので要求ベースでテストする。
- テストチームが仕様を決める。(開発もやってみないとわからないというのがある)
- クラッシュ、セキュリティ、パフォーマンスなど、ヤバイやつをやる。
- テストベースの質が低くて十分なテストが出来ない
- リリース時期が迫ってるけどテスト終わってない
- もう手遅れ。
- テストの結果をとおしてPMにリスクを伝える。
- バグの原因分析を行う。
それによってどの工程をしっかりやっておくべきかを示す( 今システムテストが遅れてるのは前の結合テストが十分でないから 、など) - 機能を広く触る。次に1つの機能を深くやる。
それでリスク判定をしてもらってリリース後にもテストを継続する かを決めたりする。 - 事前にダメそうとわかっていたら「
最初の3日でダメだったら考えませんか?」 とPMに提案しておく。
- デグレ確認の影響範囲がわからない
- これはテストじゃ解決しない。
- コード、データの観点から影響範囲分析をする。
- 分析しない。そのために自動テストを用意しておく。
- QAから開発に提案して一緒に見てもらう。
開発者は影響範囲を特定したがらない。(全部とか言いがち)
- その他
- Q.バグを直すor直さないの議論が始まる
- A.目指したい品質が合意されて無いから。
そういうのは最初にしておく。 - Q.スーパーテスターの知見を形式化したい
- A.なぜそれをしたのかをインタビューする。
それを不具合ベースのテストに落とし込む。
(レポート:inomata)
D6: TPI NEXT導入の実際
昨年度のJasstでTPI NEXT® のチュートリアルがありましたが、その講師であったASTERの湯本さんとそれを受講されたメルカリの米山さんによる対談形式でのセッション- なぜTPI NEXTを導入しようとおもったのか
- なぜTPI NEXTだったのか
- どういう効果を実感できたのか
- TPI NEXTを導入する場合に専任がいたほうがいいのか?
などざっくばらに話してくださいました。
TPI NEXTはTMMIなどと比較して自己改善ツールとしての側面が強いなと昨年のチュートリアルでも感じましたが、実際にメルカリさんもそのような感じで、より良くしたいという改善という目的に対してたまたま受講したTPI NEXTを選択されたとのことでした。
自己改善も必要だが、リリースのスピードを重視しているので、メルカリさんのような少人数のQA組織の会社にはTPI NEXTの自己改善の思想はかなりマッチしていると思いました。
弊社でも昨年のチュートリアルをうけてTPI NEXTの説明は勉強会で実施したのですが、そこから具体的にすすんでいなかったので、メルカリさんの取り組みはとても尊敬できるものですし、多いに刺激をうけました。
(レポート:kmt)
C6: Web.JaSST ~ Web Service QA Meeting in JaSST ~
Web系のサービスを展開している会社のQAによるLTです。個人的に気になった話をいくつかピックアップします。- QA組織をゼロから作る必要があり圧倒的リソース不足。テストは探索的テストを行う。テストケースは事前に作らない(作成・修正のコスト削減)。レビューは実行結果に対して行う。
- 不具合の報告はエラーログやアクセスログを活用する。
- QAからセキュリティエンジニアになった。"守る"という点で親和性が高い。
- 世の中にAWSのアクセスキーがアプリ内にハードコードされてるものがいっぱいある。これは結構なリスク。
- QAが仕様改善を主導して行ってる。
- サービスの性質からどの品質に着目するかがポイント
- pairworkで属人化を解消した。
- pairworkとは同じタスクを得意な人とそうでない人で行い、ノウハウを伝達する方法。タスク以外にもツールのTIPSが共有できた。相談しやすい環境というのもよかった。
- webと組み込みだと品質の重要視され具合が違う。webは品質と納期・機会利益との戦いになる。
(レポート:inomata)
A7: 招待講演: 品質保証活動の本質
日本においてソフトウェア品質保証やプロセス改善の概念を作った奈良隆正氏による講演です。歴史から説明されて、現在における品質保証のプロセスの全タスクが詰まった講演でした。
品質保証とは組織が行う活動であって作業ではない。テストはプロダクトの品質を評価するための一手段。KPIの取る意味。など改めて品質、組織のあり方について考えさせられる内容でした。
(レポート:inomata)
いかがでしたでしょうか?
今年のJasstでは長年品質保証に携わってこられた方のお話をきくことができました。
日本の品質の歴史を作ってこられた方々の業務経験や考え方はなかなか知ることができないので大変貴重ですね。
他のセッションも内容が濃すぎて概要しか説明できないのが残念です。
テストにかかわる業務をされている方にはぜひ来年度のJasstに足を運んでいただきたいです!