＜ネットワークランチサービス＞(事前申込制)
昨年から始めた「ネットワークランチサービス」。好評であったため、今年も会場にてお召し上がり頂ける、美味しい雅叙園のお弁当を販売致します。お弁当は事前申込となっております。 （参加申込時にお申し込みください）
＜展示ブースツアー＞(ネットワークランチサービス参加者限定 先着順)
今年は、食事会場で来場者同士のコミュニケーションを図っていただくだけではなく、ネットワークランチサービスに申し込まれた方限定で展示ブースを回る「展示ブースツアー」を実施します。
JaSST実行委員がツアーガイドとなり、ランチを食べながら興味ある内容を語り合った後、展示ブースめぐりに出発します。
JaSSTではご協力いただいているスポンサー企業さんに、我々テストエンジニアに大いに役に立つツールやサービスを展示していただいています。展示ブースに興味はあるけど・・・という方。
参加者の方々とテストツールやサービスの話をしてみたいという方。展示ブースツアーに参加してみませんか？
展示ブースツアーへの参加は、当日昼食会場で先着順に受付いたします。興味がある方はお早めに食事会場へ！
最善と考えるテスト計画を立てたにも関わらず、想定外の開発遅延や仕様変更、テスト環境の制約などにより、当初の計画を変更せざるを得ないことは多々ある。
複数ある選択肢から、いかに最適な判断を行うか、リーダーの決断はプロジェクトの成否に大きく関わる。
当ワークショップでは、幾つかの制約の中で如何に最適解を導き出すかを、現場目線に重きを置いたグループ形式で演習する。
テストのスキルを「Ｃ言語ができること」「業務知識を知っていること」「Excelを使えること」などで判断しているソフトウェアテストの現場は多い。
この現状に一石を投じるべく、ASTER(NPO法人 ソフトウェアテスト技術振興協会)およびIVIA(一般社団法人 ＩＴ検証産業協会)により、ソフトウェアテストを行う上で真に必要なスキルとは何かを分析、
テストスキル標準(Test.SSF)を開発し、JaSST'10 TOKYO にて概要を発表した。
Test.SSFを解説するだけでなく、現場でどのように活用すればよいのかの紹介も併せて行い、具体的に理解しやすい構成とした。現場に持ち帰ってすぐに役立てることができるであろう。
テスト初心者を対象に、知識・センス（感覚）を高めて頂くことを目的としたセッションです。
ソフトウェアテストに関する名著・良書を紹介するとともに、その書籍のエッセンスを演習によって学習していきます。
初心者のテスト駆動開発プロセスを記録し、経験者の開発プロセスと比較することで、テスト駆動開発の効率のよい教育方法を考える。 第一段階として プロセスを記録するためのツールを開発し、経験者のプロセスデータを収集・解析した。 本稿では記録されたデータフォーマットの詳細について説明し、現在までに収集されたデータについて解析結果を報告する。
テスト実装・実施フェーズにおける取り組みはテスト分析・設計フェーズと比較すると少ないのが現状である。
しかし、実際の現場で分析・設計の取り組みを実現しているのはテスト実装・実施フェーズの創意工夫によるものである。
本稿ではテスト実施のための作業容易性に着目し、テスト実装に関する検討を行う。
リスクベーステストをやってみると、次の事柄に強いモチベーションを感じました。
マスターテストプランを書こう。テスト設計でどうリスクを盛り込むか考えよう。リスクからテストケースまでのトレーサビリティが重要だ。テストのモニタリングでリスクの変化を表そう。
リスクをベースにした報告をしていこう。本論文では、この中で、テストのモニタリングに注目し、その意義と効果を事例を交えながら議論していきます。
ツールを提供するベンダ、リセラとツールを使うユーザとで、「日本でテストツールが浸透しない理由はなぜ？」また、「テストツールがエンジニアに本当に有益なのか？」といった熱い議論を繰り広げます。 食べず嫌い/食わず嫌いなのか、本当においしくないのか？パネルディスカッションで答えが出るかもしれません。こうご期待！
Exploratory testing is testing technique that emphasizes the freedom and responsibility of the tester to continually optimize the value of his work. It is the process of three mutually supportive activities performed simultaneously-learning, test design, and test execution. The tester designs and executes tests while exploring the product. With skill and practice, exploratory testers typically uncover considerably more defects than when the same amount of effort is spent in scripted testing. In exploratory testing, the tester controls the design of test cases as they are performed rather than days, weeks, or even months before. In addition, the information the tester gains from executing a set of tests then guides him in designing and executing the next set of tests. Lee Copeland describes specific heuristics and techniques of exploratory testing to help you get the most from this highly productive approach.
探索的テストとは、テストという仕事の価値を最適化し続けるため、テスト担当者の責務と独立性を重要視したテスト技法で、「学習」、「テスト設計」そして「テスト実行」といった、
相互に補完し合う３つの活動を同時に行うプロセスです。
テスト担当者は対象となるプロダクトを探索しながらテストを設計し、実行します。
探索的テストを行うテスト担当者は、スキルや経験に基づき、スクリプトテストと同じ労力で、スクリプトテストよりも、通常かなり多くの欠陥を見つけ出します。
探索的テストにおいて、テスト担当者は数日前、数週間前、あるいは数ヶ月前ではなくテストケースが実施されている時に、テスト設計を行います。
さらに、ひと組のテストを実行することでテスト担当者が得る情報が、次のひと組のテストを設計し、実行する上で役立ちます。
リー・コープランドは、探索的テストの特定のヒューリスティックと技法を説明することで、この生産性の高いアプローチを最大限に活用できるようお手伝いします。
なお、参加者全員に本チュートリアルのベースとなる講演者の著作「はじめて学ぶソフトウェアのテスト技法」(和書)を差し上げます
みなさんのソフトウェアシステム、自社内で開発したソースコードの割合はどれぐらいでしょうか？
現在のソフトウェア開発では、外部発注したソフトウェアや、オープンソースなど開発元の違うソフトウェアが流通し混在しているのが当然となっています。 異なる開発を経たソースコード群の品質は信頼できるレベルにあるのでしょうか？
実はこのような複雑なソフトウェアのサプライチェーンにおける不具合の検出において、静的解析技術を有効利用することができます。 本セミナーでは、Android カーネルソースコードなどの解析結果を例にとり、現実に起こりうるコード不具合をご紹介します。
2009年1月。JaSST'09東京のクロージングパネルにて、テストのメソドロジに関するアツい議論が交わされ、「智美塾」の活動が始まりました。
目標は全ての塾生が各々の"テスト開発方法論"を築き上げること。
月1回、熱心な議論が交わされています。
テスト開発とは、テストを単なる労働とみなすのではなく、テストケース群をクリエイティブな知的成果物とみなし、ソフトウェア開発のようにテスト開発も要求の分析からはじまり、アーキテクチャ設計、詳細設計、
実装といったライフサイクルとして捉えるという考え方です。
テストの技術をさらに進化させるためのパラダイムとも言えるでしょう。
そして2010年1月。JaSST'10東京の智美塾セッションにて、塾生同士の議論の様子をご披露しました。その後、智美塾ではテスト開発方法論の中核をなす"テストアーキテクチャ"について検討を重ねてきました。
今回はその成果として、テストアーキテクチャという概念の提案と、テストアーキテクチャ設計の考え方について智美塾なりの解説を行います。
テストアーキテクチャ設計は、ASTERとIVIAで共同提案しているテストのスキル標準Test.SSFにおいても重要視されている技術です。
"テスト開発"の中心となるテストアーキテクチャ。議論は抽象度の高いものですが、より良いテスト設計を行う上での手助けになることと思います。現在も、智美塾では新たな仲間を求めています。 智美塾に少しでも興味のある方、ぜひ、本セッションへ参加して智美塾へ！
※智美塾についての詳細は下記を訪れてみてください。
https://aster.or.jp/activities/satomijuku.html
JSTQBでは、2010年8月に「テストマネージャ」専門領域を対象としたAdvanced Level(AL)のトライアル試験を実施し、2011年には本試験の開催を予定しています。
本セッションでは、今後のAL試験の受験を希望される方や実際の業務でテストマネジメントを行われている方、さらにはテストマネジメントに興味のあるテストマネージャ予備軍の方に向けて、
テストマネージャに必要不可欠な技術要素や考え方をALシラバスから取り上げて解説します。また、実際の開発（テスト）において問題が発生した時に、テストマネージャとしてどのような判断、
解決をすべきかといったノウハウを、実務経験に基づいて紹介します。
今年もやりますライトニングトークス！5分間の真剣勝負。まだまとまってないアイデア、ちょっとした小技、ノウハウ、そんなものを大募集。論文とか堅苦しいのはちょっと辛いけどみんなに聞いて欲しい小ネタがある、
旅先でふと気づいた品質への思いや、各地でのコミュニティ活動報告なんてものでもＯＫです。あくまでも「トーク」です、好きなことを語ってください、歌ってください。
条件はひとつだけ、テストや品質がテーマになっていること。ウケ狙いのネタが楽しいのもライトニングトークスならではの魅力です。
ライトニングトークスは、観るだけでも楽しめますが、実際に語ってみるとさらに楽しめます。また、コミュニケーションを活性化するためのツールとしても有効です。 職場のコミュニケーションを活性化したいと思っている方、 明るく元気な職場にしたいと考えている方、ぜひミニワークショップを通じてライトニングトークスの楽しさを体感してみませんか。そして、グループや組織、会社などで実際にライトニングトークスをやってみませんか。
今回は、巷で評判のＬＴをご招待する企画（オブジェクト倶楽部イベントのベストトーカーなど）や、JaSST東京ＬＴ常連の田中氏によるミニワークショップも行います。みなさんのご参加をお待ちしています！
今日様々なプラットフォーム上で提供される、ゲームやエンターテイメント系のコンテンツをテストする上で、熟練評価者の知見は非常に重要な役割を果たします。 本報告では、当社で実施した「熟練評価者がなぜ成果を出しているのか」を分析する活動を通じて抽出された行動様式やスキルセットのご説明、及びその知見を共有する為の試みについて事例を紹介いたします。
ソフトウェア開発ではしばしば仕様の追加や変更が発生し、テスト設計・テスト実施をやり直すなどテスト工数が増加する場合がある。 この問題を解決する手段のひとつとして、原因結果グラフ技法に分割の概念を導入した。本発表では、分割と類似したズームアウトの概念との違いを解説するとともに、原因結果グラフの例を使って分割パターンを整理する。 また、支援ツール「CEGTest」に本概念を実装して、その実践方法を示す。
直交表・All-Pair法などを用いた組合せテストはある程度の専門的な知識を必要とするため、社内の普及が困難である。
弊社では、「組合せテストケースの生成支援ツール」を積極的に活用し、身近なテーマを使って組合せテストを体験してもらったところ、参加者全員（１５名）が使いこなせるようになった。
そのノウハウと工夫した点、また新たに取り組んだ「状態遷移のある動作テストに組合せを適用した方法」等を紹介する。
テストツールの購入・習得・維持には相応のコストが必要となる。一方、回帰テストの量は、テスト対象の数が多くなるにしたがい増大する。 本論では、安価なスクリプト作成・実行ツールを構築・導入することで上記コストを抑えた事例を紹介する。 さらに、テスト経験の差がテスト結果に及ぼす影響についても考察を行った。その結果、本ツールを用いた回帰テストは、経験の差に影響を受けない利便性の高いものであると確認できた。
名古屋大学 組込みシステム研究センターでは研究コンソーシアムを形成し、RTOSに対するテストスイートの開発と実施を行っている。 今年度は、ITRON仕様をベースとしたマルチプロセッサ向け組込みリアルタイムOSのAPIテストを開発し、その過程で、シングルプロセッサでは発生しえなかった問題に直面した。 本論文では、問題を解決するために行った、テストプログラムを生成するテストツールのマルチプロセッサ拡張について述べる。
ソーシャルアプリと呼ばれるSNSプラットフォーム上のWEBアプリケーションが流行し注目を集めています。
開発に関わっていくうちに、従来のWEBアプリケーションと比べてより高品質に短納期で完成させることを求められ、リリース後も非常に手間の掛かることが判ってきました。
ソーシャルアプリの特性に合わせたWEBアプリケーションのテスト方法について実践事例をご紹介します。
世界初(？)、ソフトウェアテストの「設計」コンテストです。ある既定の要求仕様に基づいて、任意の様式、粒度、方式で行った「テスト設計」を応募頂き、当日壇上にて設計意図を簡単にご紹介頂きます。
また、当日はテスト界の有識者をお招きし、発表頂いた作品の注目すべき点など、講評と解説を頂く予定です。是非この機会に、日頃まず目にすることのない、でも興味深々な、
活きた「テスト設計」を会場のみなさんと一緒に味わってみませんか？こうだ！とあなたが考えるテスト設計書の応募をお待ちしております。
※応募の詳細は追って発表させて頂きます。
品質保証と言えば、一般的には、機能要求に対するバグの管理を指す。しかし、米国製の製品には、根強いファンがいて、発売前から予約が殺到するものがある。 しかし、こと、自分が担当するシステム、製品においては、保守的な仕様となりがちである。 しかし、ISO9126に利用時の品質が定義されている。今回は、使い勝手という観点から品質を捉え、その実現において、バグに対する、改善活動が有効であったことを報告する。
ソフトウェアの品質を向上させるには、テストの段階で手を打っても手遅れであり、設計品質を向上させる必要がある。本研究では、テスト技法を用いて設計書の品質を定量化して評価する手法を提案する。 本手法では、「設計書からテストケースを十分に作成することができるか」を3つの観点から評価し、設計書の本質的な品質を数値で表す。 これにより、設計書の問題の特定や傾向の把握、さらには設計品質の向上が実現できる。
「バグはどんな形をしているのでしょうか？」
様々なソフトウェア開発においてBTS（欠陥追跡システム）へ欠陥情報を記録することは一般的に普及しています。しかし採取した欠陥情報の共有を企業をまたがった市場レベルで実現している事例はほとんどありません。
当セッションではIT産業全体に対して欠陥マスターデータベースの必要性と重要性を提言し、その仕組み、分類方法、利点について議論します。
またレビューやテスト担当者の利用に際しての注意点や情報登録／利用のインセンティブ、利用しない場合の問題といった利用側面と文化的背景にも事例を交えながら言及します。
JaSST2011の中で最も地味な欠陥セッションをお楽しみください。
現在のゲーム開発においては、人手によってゲームの面白さの検証と同時にソフトウェアのバグも検出する手法が一般的です。
それは主に以下の理由によります。
この様な昔ながらの方法では、ソフトウェアの大規模化・複雑化に対応しきれなくなってきているのが現状です。
本セッションではこの様な現状を改善するための、ゲーム業界における品質保障への取り組みの実例をご紹介します。
セッションの前半では、CEDEC2009「バグを限りなくゼロにする方法」の講演内容をベースにソフトウェアテスト全般について、どのように実践、広める工夫をしてきたかの実例を伊藤周がお話します。
後半では、粉川貴至が近年注目されている継続的インテグレーション（CI）という考え方の紹介と、ゲーム開発現場への導入事例をCEDEC2010にて講演した「タダで始めるゲーム開発自動化のススメ」をベースに分かり易く紹介します。
ソフトウェアテストが浸透していない現場への改善事例としてお聴き下さい。
本セッションは、CEDEC（CESA Developers Conference：ゲーム開発者向けカンファレンス）にて好評だったセッションを更に選りすぐって発表するコラボ企画となっています。
2010年はISTQB総会の日本開催に合わせて、海外の著名なテストエンジニア/研究者が多数来日しました。また、ほぼ同時期に海外のテストに関わる技術者達のエッセイ、 ノウハウを集めた翻訳本「ビューティフルテスティング」が刊行されるなど、日本でもテスト業界のグローバル化を感じられる年となりました。 そこで2011年最初のJaSSTではそのトレンドを感じていただくセッションを企画しました。本セッションでは、主に海外で活用されているテストツール、技法やプロセスなど、 日本ではまだ馴染みが少ないものを中心にご紹介していきます。また、本セッション参加者とのディスカッションを通じ、 テスト業界のグローバルな盛り上がりを感じてください。。クールなものから、ヘンテコなものまで、各種取り揃えて議論できればと思います。みなさまのご来場をお待ちしております。お楽しみに！
テスト駆動開発(TDD)は、アジャイル開発手法であるXPのプラクティスとして紹介されて以来、アジャイル開発に限らず多くのソフトウェア開発現場で用いられるようになってきました。 TDDは開発の中に「Red⇒Green⇒Refactor」のリズムを作ることで、開発者に安心感を与えるのと同時に、品質や生産性の向上にも貢献することが知られています。
その一方、TDDが多くの現場で用いられるようになるにつれ、TDDの成果物の1つであるテストケースと、従来テスト工程で作られてきたテストケースの間に溝があることが指摘されるようになってきました。
本セッションでは、その2つのテストケース間の溝がどのようなものか明確にしたうえで、その溝を埋めるのみにとどまらず、両者を超える効果を得られるような、新しいTDDの考え方や、 TDDを活用したアプローチを「拡張型TDD」として提案いたします。 概念的な説明にとどまらず、これま での標準的なTDDとの比較を、ライブ形式を交えて実際の進め方などをご紹介いたします。
ディスカッションでは、品質保証やTDDの実践者などのエキスパートにご登壇いただき、それぞれの立場から拡張型TDDへのご意見をお話しいただき、その実用性、実現性、効果などについて考えていきます。
「ソフトウェア品質会計」は、ＮＥＣ独自のソフトウェア品質管理手法です。ソフトウェア品質会計の大きな特徴は、設計・製造工程でのレビューを重視している点と、 テスト終盤における残存課題の分析に注力している点にあります。 ソフトウェア品質会計は、品質向上に大きな成果を上げた実績を持っており、現在では、NECグループ内に広く普及しています。
本チュートリアルでは、特にテストエンジニアを対象として、テスト工程でのソフトウェア品質会計の適用方法、および出荷に向けて残存する品質問題をいかに分析しつぶしていくかを、ケーススタディを交えて解説します。 特に現場で問題となる、出荷間際のテストの終了判断における対応方法について、具体的に取り上げます。 また、品質会計の適用における、現地・現物・現実を重視した活動の重要性についても言及します。
なお、参加者全員に本チュートリアルのベースとなる講演者の著作「ソフトウェア品質会計」を差し上げます。
小惑星探査機「はやぶさ」は往復60億キロの宇宙の旅を終えて6月13日に地球に帰還しました。分離したカプセルは豪州南部の砂漠で無事に回収され、小惑星イトカワの地表の砂を採取していたことも確認されました。
全てのミッションを完遂させる上で「はやぶさ」に搭載された組込ソフトウェアは大きな役割を果たしました。オーソドックスでありながら、とても日本的な擦り合わせが反映されたソフトウェア開発プロセスを振り返ります。
本セッションにみなさまがいらっしゃる頃には、2日間にわたって開催されたJaSST'11 Tokyoもいよいよ大詰め、クロージングパネルを残すのみになっています。
さまざまなセッションがありましたが、みなさま、お楽しみいただけたでしょうか。
毎回、参加者アンケートを集計すると、
「見たかったセッションが重なってしまって選ぶのに困った！」
「後で聞いたら他のセッションも良さそうだった。」
などの声が多く寄せられます。実行委員としては嬉しい反面、申し訳ない気持ちもいっぱいです。
そこで、今回初めて、振り返りセッションを企画してみました。
全て、、、というわけにはまいりませんが、この2日間に行われたセッションの中からいくつかを実行委員が独自にセレクトし、ご紹介します。
実際にそのセッションに参加された方は得られた知識の振り返りに、他のセッションに参加された方は、この振り返りセッションでその時の雰囲気を共有していただければ、と思います。
初めての試みですので、どんな報告になるかは誰にもわかりません。どうぞ、ドキドキ感とともに、本セッションをお楽しみください。
テストを省くとリリースが間に合う状況があったとしたら、そのテストを省いてもよいのだろうか？
正社員テストエンジニアに高い教育投資をし、派遣のテストオペレータに単純作業をさせるのは公正なことだろうか？
前のプロジェクトが作り込んだ母体バグについて、私たちに回帰テストの義務はあるのだろうか――。
つまるところこれらは、「テスト」というものの本質の問題なのだ。
開発を進めるうえで私たちが直面する、正解のない、にもかかわらず決断をせまられる問題である。
これは机上の空論では断じてない。
品質事故、リリース遅延、赤字、要員離脱といった、ソフトウェアの開発やテストを覆う無数の困難の奥には、つねにこのような本質的な問題が潜んでいる。この問題に向き合うことなしには、よい現場をつくり、
品質の高いシステムをリリースすることはできない。
リー・コープランド、細谷泰夫、湯本剛といった現代のエキスパートたちは、これらの問題にどう取り組むのだろう。このパネルを通じて彼らの哲学を吟味することで、見えてくるものがきっとあるはずだ。
このクロージングパネルでは、パネリストだけでなく、テストの現場で様々な体験をしている君たちから意見を聞き、個々の現場でこうした問題に直面したらいかに考え行動するべきか、を会場全体で考えていきたい。
Copyright Association of Software Test Engineering All rights reserved.