本文へジャンプ

ソフトウェア > Lotus > Lotus Developer Domain > 

Iris Today Archives

クオリティーを重視する 、メール、C&S クオリティー・エンジニアリング・チーム


Lotus Software
by Lynda Urgotis
レベル:すべて
対象:すべて
原文の掲載:2000年12月1日

Iris Today Archivesの原文(US)

インデックス
バンジー・ジャンプ用のケーブルでもソフトウェアであっても関係なく、テストを行うというのは、商品の開発で中心となるものです。コンピューター業界では、QA (クオリティー・アシュアランス) や QE (クオリティー・エンジニアリング) といった言葉を多く耳にします。この2つの言葉には何か違いがあるのでしょうか。
このようにプロジェクトに早くから関わるというのが珍しいと思う読者もいるかもしれません。設計段階から開発チームと協力して作業に参加するというのはどのようなものなのかを教えてください。
「初テスト(initial testing)」という話がありましたが、その目的は何なのですか?もし機能が部分的にしか働いていない場合は、どのように何が問題なのかを割り出すのですか?
ここで、基本的な用語の説明が必要だと思います。例えば SPR とは何なのですか?
「バグ」とは何ですか?
QE を昆虫採集者に例えて、ソフトウェアでのバグ (虫) がどのように生まれてどのように消えていくのかを追って説明してください。
分かりました。どのようにテストを行うか計画を立てる際、対象となる機能やタスクの普通の使い方で行うのですか、それとも、ユーザーが誤った選択を1つあるいは連続でして、トラブルが発生したりおかしい場所に飛んでしまった、というようなシナリオを想定して行うのですか?
オートメーションという言葉を聞くと、テレビの Buck Rogers や Futurama のようですが、QEではオートメーションはどのような意味なのですか?
テストで「人」を重視しているのはいいことだと思います。製品の各リリースで、オートメーション化するべきところがたくさんあると思うのですが、それはどのように決めるのですか?
リリース5ではオートメーションはどのように使われたのですか?
スモーク・テストとは何ですか?
メールや C&S では、どのようにテストが計画されるのですか?
例を挙げてもらえますか?
その次に何を行なうのですか?
複数のサブ・システムに関わっている機能エリアはどうなのですか?
機能エリアについて、具体的な例を挙げてください。
機能エリアやサブ・システムの他に、チームが担当していることはありますか?
複雑な機能の場合はどうするのですか?小さなピースに分解して行なうというだけなのでしょうか?
現行の機能の強化版をテストするというのは難しいですか?もし問題が起こったら、新しく加えたコードに不具合があるのか、それとももともとあるコードなのか、あるいは組み合わせが良くないのか、といったことはどのようにして分かるのですか?
あなたのチームは、QME (Quarterly Maintenance Release) の作業にはどのように関わっているのですか?
開発陣と協力するという話がありましたが、それ以外のグループとはどのような関係を持っているのですか?
個人はともかく、企業となると、さまざまなマシンや設定が見られるほか、必要となる機能もさまざまです。どのようにこれらを扱っているのですか?
テストでの複雑なシチュエーションについての話ですが、インターネット・メール・クライアントなど、Web 関係のものをテストする際には、どのような問題点がありますか?
取り組んでいる製品の発展にあわせて、チームも成長しているというのはおもしろいと思います。テストは、以前のリリースと比べて、どのように変化してきましたか?
チームの構成や担当が相当変わったわけですね。
この仕事をしていて、どのようなときに最も充実していると思いますか?

クオリティー・エンジニアリングがなかったとしたら一体どうなるのか想像してみましょう。「さぁ、Buddy のバンジー・ジャンプ・ワールドへようこそ!今日はまったく新しい製造工程と、まったく新しい素材で作られた、バンジー・ジャンプ用ケーブルを紹介します。ぜひ今まで誰も使ったことのないこのケーブルを試してみてください!」という具合でしょうか。Buddy がいくらこのケーブルの詳細や、その製造工程、デザインの美しさについて熱弁したとしても、本当に知りたいのは実際にそのケーブルがテストされたかどうかでしょう。Buddy は戸惑った様子で「問題ないはずです」と言います。

この「問題なく働くはずです」と「問題なく働きます」の間を埋めるのが、クオリティー・エンジニアリング・チームの役割の1つです。今月の スポットライト・インタビューでは、メール、C&S クオリティー・エンジニアリング・チーム (以下 QE チーム) に、メールや C&S (カレンダーとスケジュール機能) でのクオリティー・エンジニアリングについて話を聞きます。

Developer's Spotlight forum(現在リンク切れ) で、メール、C&S QE チームにおけるディスカッションをみることができます。


バンジー・ジャンプ用のケーブルでもソフトウェアであっても関係なく、テストを行うというのは、商品の開発で中心となるものです。コンピューター業界では、QA (クオリティー・アシュアランス) や QE (クオリティー・エンジニアリング) といった言葉を多く耳にします。この2つの言葉には何か違いがあるのでしょうか。

ジャネット・カーン
私の周りでは QA も QE も同じように使われています。QE の方がより正確に私たちがやっていることを表しているし、製品の質を重視しているので、個人的にはこちらのほうが好きです。

QA (クオリティー・アシュアランス) は、順を追って行われるプロセスで、開発者がある機能を実現するためのコードを書き、QA 担当に渡してテストを行います。そして問題点を報告して、それを修正し、再びテストします。

Iris では、テスターが開発チームの中に含まれており、機能の設計段階から初テスト、部分的な運用テスト、そして最後の機能テストに至るまで、協力して行っています。最終の機能テストに至るまでには、大きな問題点は解決されることになり、QE (クオリティー・エンジニアリング) のほうが適切なのです。

アンディ・シャマー
QE は QA よりも一歩進んだ意味合いを持つと思いますね。QE は、ただ問題点を発見して、バグを報告するだけではありません。技術的な知識を活用して製品のデバッグを行い、開発チームと協力してバグの原因を突き止めます。開発チームと密接に協力しながら作業を行うので、より多くのフィードバックや情報を提供したり、どうすれば解決できるか、ということについてのアイデアを提供できるわけです。その意味で私たちはバグ発見作業により深く関わっており、解決策を試してみる、ということも行っています。

QE Team photo

後列、左から:エレン・カルバー、レニー・デッカー、ファラ・グロン、エデル・グリソン、アニタ・パシィ、アンドリュー・シャマー、ジュリィ・アン・スパン、リサ・ノッドウェル
前列、左から:ドリス・ジョーンズ、ジャネット・カーン(後ろ)、リサ・ロウ(前)、メリン・ヤン
 
上に戻る
 
このようにプロジェクトに早くから関わるというのが珍しいと思う読者もいるかもしれません。設計段階から開発チームと協力して作業に参加するというのはどのようなものなのかを教えてください。

アニタ・パシィ
開発の設計段階から関わるというのは、コードを書くエンジニアにとっても、テストを行う方にとっても非常に有効であることが分かっています。普段はテスト段階になって初めて分かり、変更するのが難しかったり危険だったりするような問題点について、製品の開発に関わるすべての人が知ることができるようになります。

アンディ・シャマー
私たちのチームでは、開発チームと密接な関係を築くようにしています。これは、機能について詳しく知れば知るほど、ソースに関連したデバッグがよりやりやすくなるからです。例えば、メール・クライアントではメール・テンプレートがどのようになっているかを知らなければテストがうまくできない、というように、機能を知ることは重要です。フォームやフォルダー、ビューといった設計要素、この他にもロータス・スクリプト、ノーツ式言語、そして Javaスクリプトといったものを知っておくことが必要なのです。

アニタ・パシィ
ある機能をテストして色々な使い方を試していくうちに、その機能がどのように働いて、それがユーザーにとって使いやすいものなのかどうかが分かってきます。この他にも機能間の一貫性といった側面にも注目し、どのように機能するかも見ます。QEチームは機能を詳しくテストするために、多くの知識を持っているのが普通です。

テスト計画を立てる際には、QEエンジニアは機能のあらゆる側面、そしてそれがどのように機能するのか、といったことを考慮しなければなりません。テストで行うすべてのアクションはある結果となって現れます。ですから、すべてのアクションとその結果がテストでカバーされるようにするのも私の役目です。また、設計段階では今話したようなプロセスで考えを進めていくので、私たちが大きく貢献します。そして「どのようになるのか」という予想を立て、テストで機能をすべてカバーするにはどのようなケース分けをすればいいか、ということを割り出します。私たちが設計段階で関わっている場合は、機能の設計やコードといったものを利用し、その時点までで決められたことを元にしてテスト計画を立てます。

コードを書いていてもテストをしていても、ある機能について詳しい知識を持っているエンジニアほど、特に設計段階でより大きな貢献が期待できます。QE とプログラマーをひとつの開発チームにまとめ、製品開発を通して協力しながら作業を進めることで、作業を向上させるほか、より安定した高品質の製品を作ることができるというわけです。
 
上に戻る
 
「初テスト(initial testing)」という話がありましたが、その目的は何なのですか?もし機能が部分的にしか働いていない場合は、どのように何が問題なのかを割り出すのですか?

ジュリィ・アン・スパン
初テストの目的は、できるだけ早い段階から新機能を部分的にでも試すことによって、大きな変更が許されるうちに、不具合や設計上の問題を洗い出すということです。どの部分をテストして問題報告を行なうかを決めるために、QE と開発チームは密接に協力する必要があります。現在関わっている早期段階のテストでは、開発者が何を行なっているかを毎日報告しに来たり、こちらからも報告したりしています。

アニタ・パシィ
初テストを「ユニット」テスト段階と呼んでおり、テストするコードに、開発サイクルに取り込んで他のコードと統合するだけの安定性があるのかどうかを調べます。また、全体の構成を不安定にさせてしまうような重大な問題がないかどうか、ということも分かります。初期段階のテストにはコードを書く開発者も協力的で、特別なビルドなど、必要なものを洗い出し、作業の中でSPRを書いていきます。

ジャネット・カーン
ユニット・テストが進むにつれて、必要なものも変わってきます。コードが正式に発表される前には、ただ口で問題を報告したり解決したりしますが、コードが発表された後となると、大量の SPR レポートを公式に行ないます。これは、コードが初めて発表されてからすぐに問題が解決されるようにするための1つの手段なのです。
 
上に戻る
 
ここで、基本的な用語の説明が必要だと思います。例えば SPR とは何なのですか?

ジュリィ・アン・スパン
SPRは Software Problem Reportの略です。Irisでは、ノーツSPRデータベースを使って、製品に関して内部から、あるいは外部から報告された問題点を管理しています。これらの問題点は「バグ」、「改良すべきもの」、あるいは「分かりづらいもの」、というように大きく分類されます。

リサ・ロウ
SPRフォームには、そのバグがどの分類に入るかを決めるのに必要な枠がいくつかあります。これによって、その問題点をテストしたり解決するのに適したチームにSPRを渡すことができるわけです。
 
上に戻る
 
「バグ」とは何ですか?

ジュリィ・アン・スパン
バグとは、もともと製品が設計された通りにソフトウェアが動いていないときに存在します。皆がバグだと思っていても実はバグではなく、ただそのように製品が設計されていた、ということはよくあります。こういったケースでは、「改良すべきもの」として扱われ、「バグ」や「分かりづらいもの」ではありません。改良点の要望は、非常に大切です。開発中の製品に関して、ユーザービリティーに影響を与えたりユーザーの期待にそぐわないなど、実現したほうが良い改良点は、製品が出荷される前に必ず実行するようにしています。すでに出回っている製品に関しては、次のリリースで要望があった改良を加えるようにしています。
 
上に戻る
 
QE を昆虫採集者に例えて、ソフトウェアでのバグ (虫) がどのように生まれてどのように消えていくのかを追って説明してください。

ジャネット・カーン
冗談ではなく本当に、開発中にバグは生まれて死ぬ、という「一生」があります。非常に明確化が行なわれているSPR制度では、バグをいくつかの段階に分類しています。まず、「新しいバグ」はまだ発見されていない、あるいはまだ再生されていないバグのことで、「オープン・バグ」とはQEに問題点として確認されているもの、そして次の段階としてQEが修正要求を行って、QEが修正後のコードが正しく機能することを確認すると「修正済み」となります。このプロセスを経る間には様々な問題があり、苦労します。

最初に苦労するのは、バグを発見することです。テストを通じてバグを発見したり報告するのですが、内部で発見したにしろ、ユーザー・サポートに報告されたにしろ、「新しいバグ」の報告を受けて初めてバグ探しが始まります。

ドリス・ジョーンズ
バグを発見すると、「そのバグによって何が起きるのか」「なぜそのようなことが起きるのか」といったことを調べます。

ジャネット・カーン
所定の段階を踏んでも、常に簡単に見つかるというわけではありません。メールがうまく働きません、と書いてあっても、その詳細が分からないということがあります。

アンディ・シャマー
バグがあるときは、何かが正しく働いておらず、どこかに不具合があるということは分かっていますが、その不具合がテストの時に現れるかどうかはまた別問題です。ですから、まずその不具合が自分の専門エリアなのかどうかを判断して分類し、それからどこにその不具合が存在するのかを見極めます。バグのある部分を再生し、解決するのに最も適した人にバグ修正を依頼するために、バグの分類は重要な役割を果たします。

レニー・デッカー
バグではなく、ユーザーの設定やサーバーの設定から引き起こされる問題、という可能性もあります。

ジャネット・カーン
まさにその通りで、私はいつも「メールを使っていて不具合があったからといって、メール機能のコードにバグがあるとは限らない」ということを言っています。ノーツ・ユーザーのほとんどがメールを使っているということを考えると、ノーツ・クライアントのメール機能にバグがあってもおかしくはないでしょう。バグの可能性がある場合は、まずその不具合を別のデータベースで、あるいは別の設定で再現してみます。

そしてSPRを見て、そのバグが再現できないようであれば、私たちの出番です。個人的には、不具合のあるソースを探すというのが最も難しく、同時にやりがいのある作業ですね。チームのメンバーは、SPRを見て、メールやカレンダー、スケジュール機能について持っている知識と照らし合わせます。大抵は、どのような設定でその不具合が生じたのか、ということを特定します。

リサ・ノッドウェル
とても標準的な設定である場合には、あまり考えずにそのまま設定してしまうという場合が多いですね

アンディ・シャマー
情報を加えたり、詳しく記述することで、SPRをさらに良いものにします。開発者などがバグを再現できないようでは困ります。バグ報告をより詳しくして、開発者がコードの中でどの部分がいけないのかを発見できるようにします。

リサ・ロウ
アンディの意見に賛成ですね。これは重要な点で、私たちは問題点の原因を突き止めるために多くの時間をかけています。

レニー・デッカー
クラッシュ・バグと呼ばれるバグは、画面上で確認できるので、比較的簡単に再現できます。多くの場合、コードの中のどの部分でバグが発生したかを発見し、ツールを使って開発者に分かるように問題点をまとめます。

アニタ・パシィ
いろいろなアクションを行った後にバグだと思われる問題点が発生した場合は、まずバグを再現する前に、できるだけ少ない手順を踏んで同じバグにたどり着くようにし、問題点をより明らかにします。会議招集などの招待側と招待される側がいつでも行える送信や返信機能のワークフロー処理などの複雑なものをテストしている場合などはこの手法をとります。できるだけプロセスを分解、単純化して考えることによって、より簡単に開発者がコードのどこに不具合があるのかを見つけやすくなります。とはいっても、すべてのケースでこの手法を使ってデバッグや再現ができるというわけではありませんが。

ジャネット・カーン
そして、バグを再現した後は、開発者が修正することになります。これが終わると、QEには開発者が作った修正版が報告された問題点を解決しているかどうかを見るという役割があります。これを経て、やっとバグは「解決済み」となるわけです。修正版のコードでまたバグが生じるようであれば、再び分析します。

アンディ・シャマー
あと、開発者がバグ修正を行って私たちにまた返した後の作業について少し加えると、修正がうまく行われたかどうかをチェックするときに2通りの結果が出ます。修正版がうまく機能している、という場合と、まだ修正が完全ではなく開発チームに再び渡して修正してもらう、という場合に分かれます。さらに、バグの修正版をテストするだけでなく、関係した部分もチェックするのも私たちの役割です。場合によっては、開発者がユニット・テストを行うときにあらかじめ QE と共同して行うこともあります。
 
上に戻る
 
分かりました。どのようにテストを行うか計画を立てる際、対象となる機能やタスクの普通の使い方で行うのですか、それとも、ユーザーが誤った選択を1つあるいは連続でして、トラブルが発生したりおかしい場所に飛んでしまった、というようなシナリオを想定して行うのですか?

ジャネット・カーン
ユーザーがノーツ、特に中でもメール機能を使う際には、正しい方法は1つしかないというわけではありません。まず、一般的と思われる方法、つまりその製品が目的通りに使われるケースを試します。そして次に「これ以外にユーザーがどのようなことをできるのか」ということを考えますが、この際、デザインや機能の目的を注意深く見て、ユーザーがどのように使う可能性があるか、ということを考慮します。このプロセスで行われるテストは、「ポジティブ・テスト」と呼ばれ、ユーザーが行いそうなことを試してみます。逆に「ネガティブ・テスト」というものもあり、ユーザーが試さないと思われるが、構造的には可能、といった事項を試します。この他にも様々な種類のテストがあり、「リミット・テスト」ではこれ以上やったらどうなるのか、やらなかったらどうなるのかということを見ながら、部分ごとのリミットを見ます。また、逆に一度テストした部分を再テストして、新しい不具合が見られないかどうかのチェック (逆行テスト) も行います。

私たちのチームの主な役割は、すでに開発された部分が正しく機能するかどうかをテストする、というものですが、この他にもユーザービリティー・テスト・グループとも協力して、ユーザーが目的の作業を行うために何通りくらい方法があるのか、ということを考えます。

アンディ・シャマー
ポジティブ・テストではまず一般的な方法を試した後、もう一度戻って他のやりかたも試してみます。コードのたどり方を全通りためすわけにはいかないので、SPRを見ると「こういう使い方をする人がいるとは思わなかった」と驚かされるわけです。そして、こういった SPRを参考にシナリオを想定し、そのシナリオを作業の中に取り込んで、後で使います。

レニー・デッカー
すべてのユーザーが同じやり方をする、と決め込むのはよくありません。何ができて、何通りのやり方があるのか、ということを割り出すようにします。そして、ユーザーがどのようなことをする可能性があるのかを考慮し、その機能のデザインや目的について私たちの持っている知識と照らし合わせて考えます。
 
上に戻る
 
オートメーションという言葉を聞くと、テレビの Buck Rogers や Futurama のようですが、QEではオートメーションはどのような意味なのですか?

リサ・ノッドウェル
QE では様々なオートメーションがあり、各 QE グループによってその意味合いが変わってきます。メールC&S チームでは、機能性とユーザー・インターフェース (UI) の2つの側面に焦点を置いていますが、オートメーションは主に機能的な側面で使用しています。というのは、ユーザー・インターフェースに関しては、よいかどうかを判断するには実際に人が見るほうが良いからです。この側面に関してはオートメーションを導入してもよい効果は得られないのです。

GUI (グラフィック・ユーザー・インターフェース) テスト・ツールや、カスタマイズしたロータス・スクリプト、そしてノーツ式言語を組み合わせてオートメーションのテストをする場合が多いです。これによって、ユーザー・インターフェースを使いながら機能面をテストできます。ノーツに組み込まれている機能が設計されたように働き、エンド・ユーザーがそのように使える、ということを目指しています。

まずは機能面のみをテストして、個々の小さな部分がそれぞれ設計どおりに機能することを確認します。次にこの小さな部分同士を結びつけ、より実際の状態に近くします。機能によっては、極端なシチュエーションでも正しく機能するかどうかのテストを行うこともあります。例えば、「名前が J で始まる人」という検索をかけたときに何千人もの結果を返すようなデータベースに検索テストを行ったりします。また、オートメーション・テストではエラーがどのような状態で出るのかもチェックします。検索をかけたときのエラーを探していると、検索結果が1つも無いとき、あるいは検索基準が誤って入力されたときにエラーが起こっている、といったことが分かってきます。

オートメーション・テストは、エンド・ユーザー・テストを強化したり、改良するために使われ、一晩放っておいて自動的に一定のプロジェクト・サイクルに沿って行なったりできます。その意味で、オートメーション・テストは Buck Rogers や Futurama (いずれもアメリカのアニメ) に似ていると言えますね。私たちは、オートメーションを、より科学的にテストを計画したり、行なったりするために使っています。とはいえ、オートメーションでは不可能な、人がやらなければならないテストもあります。私たちのチームで人が行なうテストを担当するメンバーは、製品がどのような見た目や感触を持つか、ということについてすばらしい判断力を持っています。
 
上に戻る
 
テストで「人」を重視しているのはいいことだと思います。製品の各リリースで、オートメーション化するべきところがたくさんあると思うのですが、それはどのように決めるのですか?

リサ・ノッドウェル
どの機能にオートメーション・テストを行なうかを決める際には、いろいろな要素があります。オートメーションは、以前にリリースされたような、安定している機能、そして何度もテストを行う必要がある機能に適しています。また、修正した機能がうまく働いているかどうかを再びテストする場合にも使います。これはまた、QMR (Quarterly Maintenance Release) の開発時にも適しています。この他にも、現行の機能で次期リリースに向けて改良されているようなものにも適していると言えるでしょう。
 
上に戻る
 
リリース5ではオートメーションはどのように使われたのですか?

リサ・ノッドウェル
メールと C&S 機能でのオートメーションは、R5 では早くから行なわれ、次期メジャー・リリースに向けて現在も行なわれています。長期的な目標としては、ほとんどの機能のテストをオートメーション化して、QE チームがより複雑なテストや、ユーザーに報告された問題点に集中できるようにしたいと考えています。メール C&S チームは、メール・データベースのユーザー・インターフェースでオートメーション・テストを集中的に行い、正常な状態でも、エラーが発生しても正しく働きつづけるようにしています。

R5 では、繰り返し予約機能でもオートメーションを取り入れ、すべての繰り返し方法を組み合わせて、設計通りに、正しい日付になることかどうかをチェックしました。これは以前からあって R5 で強化された機能なので、テストをオートメーション化することによって、新機能が追加されてもバグが生じていないかどうかを確認しました。

R5 で他にオートメーション化されたものとして、メール・ファイルを見ているときに [アクション] - [ツール] - [プリファレンス] と選択して開くメール・データベースのプリファレンスがあります。この機能をオートメーション化することで、機能の状態を常に確認しながら R5 を開発することができました。

LDAP 検索機能にも、データベースのチェックや検索が多く含まれるため、部分的にオートメーション化しました。このようなテストを手動で行なうと、何週間もかかってしまい、ノーツの次のリリースの出荷が遅れてしまうことになるでしょう。検索テストは同じ作業の繰り返しなので、オートメーション化に適しているわけです。

さらに、QE の仕事をうまく分配するのにもオートメーションが役立ちます。大きな機能をテストする場合、その一部分、特に次期メジャー・リリースに向けて強化されている部分のみをオートメーション化するのが良いと言えます。また、改良する予定のない機能をオートメーション化して、QE チームが現存する機能ではなく新しい機能に労力を注げるようにしています。

R5 以降で予定された、あるいは開発されたオートメーションには、社外アクセス、タイム・ゾーンのテスト、C&S グループ・スケジュール、メール・ルール、アラーム・テスト、ユーザー名の別名機能のテストなどがあります。

また、開発ビルドでベーシックな機能が働くことを確認するために、スモーク・テストも行なっています。
 
上に戻る
 
スモーク・テストとは何ですか?

リサ・ノッドウェル
スモーク・テストとは、手動、オートメーションあるいはその両方が混じったテストで、コードが変更された際に、テスト・ビルドにもともとあったベーシックな機能が壊れていないかどうかをチェックするものです。私たちのチームでは、新規メモの作成や送信、返信、会議招集の作成、スケジュール確認の作成、アラームのセットといった機能が正しく働くことをチェックするときなどにスモーク・テストを使っています。メモ作成や招集機能について、より複雑なテストを行う前に、ベーシックな機能が正しく働いている、ということをまず確認したいというわけです。もし問題点があれば、すぐに開発陣に報告して、解決してもらうことができます。
 
上に戻る
 
メールや C&S では、どのようにテストが計画されるのですか?

アニタ・パシィ
ノーツとドミノは、サブ・システムに分類され、さらにこのサブ・システムは機能エリアに分けられます。メールC&S 機能の場合は、メインとなる部分がテンプレート内で動くように設計されましたが、サブ・システムの中にはノーツ・クライアントとドミノ、あるいはそのどちらかで作動するものもあります。
 
上に戻る
 
例を挙げてもらえますか?

アニタ・パシィ
メーラーがそうですね。メーラーはメールというサブ・システムの中に分類されていますが、ノーツ・クライアント内にあり、ノーツ・アプリケーションから何かが送られたときに起動します。C&S の中には、いくつかのサブ・システムがあり、この中にはドミノ サーバーで実行されるものもあります。例えば、カレンダーが自動的に特定の種類の会議招集やカレンダー・エントリーを処理するように、ユーザーがカレンダーのプリファレンスを設定した場合などがそうです。

また、会議室とリソース(会議室予約)は会議室予約テンプレートを使い、データベースを介して手動で行なえますが、会議招集を使ってドミノ サーバーが自動的に処理して予約する、という方法もあります。ユーザーが特定の日にちや時間に忙しいかどうかを知らせる空き時間システムについても同様です。この機能では、スケジュール・マネジャー・タスクが各ユーザーの空き時間を busytime.nsf というデータベースに保存する、というように大部分がドミノ サーバー上で行なわれ、ユーザーが誰かを会議に招集したい、というときなどには、ノーツ・クライアントがユーザー・インターフェースでこの情報を表示します。また、ほとんどのメール、C&S 関係のビューやフォームといった機能のように、直接メール・テンプレートの一部分であるものもあります。

テスト内容や、QE がどのようにテストを行なうかといったことに関係してくるため、機能エリアを定義しようとしたときには、サブ・システムに含まれるすべての部分を考慮に入れる必要があります
 
上に戻る
 
その次に何を行なうのですか?

アニタ・パシィ
サブ・システム内の機能エリアを見つけ、定義づけを行なったら、それらをチームの QE エンジニアに割り当てます。多くの場合、QE テスターは、特定のサブ・システムの中の機能エリアについてのテストを主に行いますが、これはそのサブ・システム全体に関する知識をつけることができるためです。この他に、メールと C&S 両方の機能エリアを担当するエンジニアもいます。ノーツのバージョン間で機能エリアが異なっており、追加予定の機能にあわせて、既存の機能エリアに追加、削除、あるいは修正を行なう必要があるかもしれません。
 
上に戻る
 
複数のサブ・システムに関わっている機能エリアはどうなのですか?

アニタ・パシィ
どちらのサブ・システムに属しているかがはっきりしている機能エリアもありますが、両方のサブ・システムにまたがっているものもあります。例えば、宛先やユーザーの別名機能などがそうです。これらは複雑な上に、メールと C&S では、微妙に異なった方法で使われており、両方でテストを行う必要があります。このような場合には、各サブ・システムの中に別々の機能エリアを作って、同一の QE エンジニアがテストをする、ということが多いです。
 
上に戻る
 
機能エリアについて、具体的な例を挙げてください。

アニタ・パシィ
リリース 5.0.5 で行なったものとして、カレンダーとスケジュールのサブ・システムを例にとってみましょう。この中にはグループ・スケジュール、繰り返しグループ・スケジュール、といった機能エリアがあり、これらは会議招集の送信、受信、そして編集を行なう際に使われるワークフローです。繰り返しオプションを複数に設定した 繰り返しカレンダー・エントリーや、作成されるインスタンス、この他にも空き時間の検索、空き時間ユーザー・インターフェース、カレンダビュー、そしてグループ・カレンダーなども機能エリアです。これらの機能は、メール・テンプレートの中に組み込まれる際にテストします。カレンダービューやグループ・カレンダーといった設計要素は、どのノーツ・アプリケーション内でも実行でき、各部分やプロパティーなどを全体的にテストする必要があるため、メール・テンプレートに組み込まれる前に QE がテストを行います。そのため、私たちがテストするときには、メール・テンプレートにどのように組み込まれるか、ということを考慮した上で行なっているというわけです。
 
上に戻る
 
機能エリアやサブ・システムの他に、チームが担当していることはありますか?

ファラ・グロン
製品の中ですべてのユーザーが接することになる、メールやカレンダー、タスク機能やビューといった、フロントエンドの部分をテストしています。私たちのチームの他にも、ドミノ・デザイナーやノーツ・クライアントの編集機能をテストする QE チームもあります。また、これらの機能に関係のあるフォームのテストも行なっています。ユーザビリティーのセッションに参加して、ユーザーにとって何が使いやすくて何が使いにくいのか、といったことの理解を深めるようにしています。また、デザインのセッションに参加したり、SPR を書いたりして、そこで得た知識をデザイン、開発段階でも生かしています。ユーザーから報告があったバグも、問題点をしぼる際に有効です。正しく機能しているはずなのに、うまく働かないという SPR を受ければ、ユーザー・インターフェースを修正、あるいは変更してユーザーにとってもっと使いやすいものにするよう、SPR を書きます。

また、ロータス オーガナイザー・チームにいたことがあるメンバーもおり、ユーザー・インターフェース・デザインや、製品の使いやすさに関する知識を、ノーツ・カレンダーやスケジュール機能を生かしてくれます。
 
上に戻る
 
複雑な機能の場合はどうするのですか?小さなピースに分解して行なうというだけなのでしょうか?

アニタ・パシィ
テストを行っている部分の機能を損なうことなく、できるだけ小さなピースに分けるようにしています。繰り返しカレンダー・エントリーが複雑な機能としていい例でしょう。私たちは、まず繰り返しオプションのダイアログ・ボックスでの設定に応じてカレンダー・エントリーがユーザーのカレンダーで繰り返す、というのと、繰り返し会議の招集を送る際のワークフローで起こることを検証し、分解していきました。これにより、必要に応じてチーム・メンバーにテストを割り振るのが簡単にできます。このケースでは、1人の QE エンジニアがすべての 繰り返しオプションをテストし、繰り返しインスタンスが正しく作成され、作成されたインスタンスが編集、削除されることを確認します。そして、もう1人のエンジニアが、受諾、拒否、スケジュール変更、確認といった、招集する側とされる側の両方が使うワークフロー内のすべてのアクションをテストします。繰り返しグループ・スケジュールをテストしているエンジニアはインスタンスがどのように作成されるかということは気にする必要がなく、逆に繰り返しカレンダー・エントリーの 繰り返しオプションをテストしているエンジニアは会議招集のワークフローの仕組みについては気にする必要がない、というわけです。

ファラ・グロン
私は繰り返しグループ・スケジュール機能のテストを担当しています。すべてのインスタンスが1つのアクションに影響を受けるような設定を作って、繰り返し会議招集をかけるテストを行っています。この段階では、繰り返しの内容を分解して、会議の内容を一部変える、という作業から始めます。この他にもエリアに関わらず行なわれるテストとしては、クライアントと Web の逆互換性のテスト、そして Web 上でのテストがあります。まずは最新版のクライアントを用いてのクライアント・テストを行い、Web 上でのテスト、そして最後にクライアントと Web の両方を使っての互換性テストを行います。さらにこの他にもプラットフォーム・テストというものもあります。
 
上に戻る
 
現行の機能の強化版をテストするというのは難しいですか?もし問題が起こったら、新しく加えたコードに不具合があるのか、それとももともとあるコードなのか、あるいは組み合わせが良くないのか、といったことはどのようにして分かるのですか? ファラ・グロン 現行の機能の強化版というのはすでに確立された機能で、出来上がった基盤があるのでシンプルです。まずは強化した部分をテストして、新しく加えられた変更点が全体に悪影響を及ぼしていないかどうかをチェックします。例えば、招集する側が場所や会議室、リソース・フィールドを変更した場合に起きるスケジュール変更の通知を送信する機能に加えられた変更点がありますが、以前は、招集する側が会議の日付や時間を変更した場合のみこのようなスケジュール変更の通知が送られていました。
 
上に戻る
 
あなたのチームは、QME (Quarterly Maintenance Release) の作業にはどのように関わっているのですか?

アンディ・シャマー
QME チームとは、私たちの分野でのトレーニングを行なうなど、密接な関係を持っています。

ジャネット・カーン
QMR の QE チームは、ノーツ・メールや C&S のクオリティーを各リリースで保つ、という点で重要な役割を果たしており、QMR の QE チーム、そしてインターナショナル QE チームとは協力しあって開発を行なっています。特に、インタナショナル QE チームの Edel Gleeson や QMR QE チームの Elinor Calver は私たちのチームの一員も同然で、メールや C&S の開発に協力してもらっています。

ファラ・グロン
大抵の場合は、メインとなる QE チームがメジャー・リリースのテストを行い、私たちのチームは最初と2つ目の QMR リリースで大きな役割を果たします。そして、後の2つのリリースは QMR チームが引き継ぎます。メインとなるチームは、最初のリリース前にずっとテストを行っており、担当エリアの細かい点にいたるまで詳しい知識を持っています。また、5.0.5 での Web メールでは、オフライン機能といった大きな変更点が始めて導入されたこともあり、QE チームのメンバーがメイン・チームで大きな役割を果たしました。

アニタ・パシィ
機能のテストを行ない、新しいリリースのテストをするというのが私たちの主な役割です。しかし、機能が改善されたり、大きな修正があった場合など、QMR に大きなリスクを伴う変更点がある際には、私たちも QMR 関係の仕事に協力します。この場合、修正したエリアに必要な逆行テストを行なう、という形で参加し、QMR QE チームがバグの修正点をテストして修正後正常に働くことを確認します。この他にも、QMR サイクル内で、製品のほとんどの部分で逆行テストを行うのも QMR QE チームの役目です。しかし、全体で行なう逆行テストの際には見落としてしまうようなはっきりしない問題点を発見するのに、私たちのような、機能をテストするテスターが大きな貢献をしています。

新しいリリースのテストと QMR テストの行なっているわけですが、うまくテスト分野を決めることによって両方のテストをさばいています。メールC&S チームでは、すべての種類のテストを行なえるような分け方で、相互認証を持つ2つのテスト用ドメインを作りました。さらに、各ドメインでうまくプラットフォームを混ぜて、どのサーバーがどのプラットフォーム、どのバージョンのドミノを稼動しているか、ということが常に分かるようにしておきます。そして、プラットフォームそれぞれにユーザーとメール・ファイルを登録しておきます。ノーツやブラウザー、そして Outlook といった複数のクライアントからメール・C&S 機能をテストするのですから、メール (R5.0)、拡張メール (R5.0)、というように、それぞれに適当なテンプレートの必要なバージョンを使う必要があります。
 
上に戻る
 
開発陣と協力するという話がありましたが、それ以外のグループとはどのような関係を持っているのですか?

アニタ・パシィ
ドキュメンテーション・チームとサポート・チームとも密接なつながりを持っています。新しいリリースの開発サイクルでは、これらのチームと一緒になって学ぶことが多く、持っている知識を共有することが非常に大切です。ドキュメンテーション・チームがドキュメントの原稿を作ると、QE と開発チームがそれを見て必要に応じて情報を追加します。そして、このプロセスを繰り返して、やっと最終原稿の完成となります。新しいバージョンや、メンテナンス・バージョンにリリース・ノートもこのようなプロセスを経て作成されます。

サポート・チームは、開発陣とユーザーをつなぐ連絡係のような役割を果たしており、特に QMR で修正して欲しいという要望がある SPR などについては、協力して取り組みました。また、サポート・チームは、普段私たちがテストできないようなさまざまな設定やカスタマイズを施したユーザーとのつながりがあり、テストのプロセスに貢献しています。

この他にも、プロダクト・マネジメント・チームとも密接なつながりを持っています。各エリアのプロダクト・マネジャーは多くのユーザーにとって大切なエリアや、改良する必要があるエリアを特定する作業に関わっています。私たちのチームも彼らと協力して、ユーザーが満足して、製品価値をあげるにはどのような機能が必要なのかを考えています。
 
上に戻る
 
個人はともかく、企業となると、さまざまなマシンや設定が見られるほか、必要となる機能もさまざまです。どのようにこれらを扱っているのですか?

ドリス・ジョーンズ
まさにその通りで、非常に多くの設定が見られます。テストを行う際には、ほとんどのユーザーが行なうであろう設定にし、さまざまなテスト分野をすべてのプラットフォームで行なっています。

ジャネット・カーン
ドリスは Web メールのテストに長く関わってきたこともあり、さまざまな設定に触れる機会が一番あると思います。さまざまなプラットフォームにも多くのサービス・パックがあり、それらにサポートされているブラウザーにもまた色々なバージョンがあります。さらに設定も1通りというわけではないので、適当な機能を決めて、ある設定のもとでテストを行なうというのは容易なことではありません。

ドリス・ジョーンズ
しかも、ほとんどの機能エリアでは、サード・パーティーのサーバーでもテストを行なう必要があります。

ファラ・グロン
その分野でのすべての設定をカバーするために、相互のドメイン間をまたがってのテストも行ないます。

メリン・ヤン
サード・パーティーのクライアントでインターネットのメールを使い、ノーツ・クライアントでの場合と比較します。

ジャネット・カーン
すべてをカバーするには、結局すべてやってみるしかないのです。ですから、多くのマシンとテスト・ユーザー、さまざまな設定を用いて柔軟に作業を行なっています。設定に関しては、必要に応じて頻繁に、そして簡単に変更できるようにしています。

ノーツのドメインやサード・パーティーといったテストのセットアップに関しては、クリエイティブに行ない、テストを楽しくやるようにしています。チーム・メンバーがそれぞれユニークなユーモアを持ち寄って、皆でする仕事に生かしています。

アンディ・シャマー
例をあげると、アドレスをテストするための名前の一覧のデータベースがあったりします。長いもの、短いもの、そして面白い名前を付けていて、最近までマシンやテスト・ユーザーにスタートレックのキャラクターの名前を付けるというのがはやっていました。今は人気のテレビ番組シリーズ「Survivor」から取った Tagi や Pagong という名前をサーバーに付けています。何かいい名前があったら投稿してもらえないでしょうかね。
 
上に戻る
 
テストでの複雑なシチュエーションについての話ですが、インターネット・メール・クライアントなど、Web 関係のものをテストする際には、どのような問題点がありますか?

アニタ・パシィ
メールや C&S で用いられているインターネット・スタンダードをテストする際に最も大変なのは、インターネット・メールを送ったり受信したりするノーツ/ドミノ以外のクライアントやサーバーも考慮に入れなければならないということです。インターネットを介したノーツ同士でのメールや会議招集の送受信が機能するかどうかだけでなく、ノーツから、インターネット・スタンダードをサポートしているノーツ、ドミノ以外のクライアントやサーバーでも送受信をテストする必要があります。

このようなテストを計画する際には、すべてのサーバーやクライアント、そして設定を網羅する組み合わせを考えます。例えば、ノーツ/ドミノ・ユーザーから Outlook/ドミノ ユーザー、あるいは Outlook/Exchange ユーザー、オーガナイザー・グループ・スケジュール/ドミノ・ユーザー、Netscape ユーザー、というようにです。

ドリス・ジョーンズ
サード・パーティーのクライアントやサーバーも使いながら、シームレスに作業を進めていかなければなりませんが、ブラウザーでのメールや C&S へのアクセスを可能にするドミノ Web メールも忘れてはいけません。というわけで、クライアントやサーバー、設定は無数にあり、組み合わせは非常に複雑なものになることがわかると思います。

ジャネット・カーン
R5 では、ご存知のように、インターネット用のメール・クライアントを完全に統合し、MIME 形式のメッセージを SMTP を介して読んだり、書いたり、送受信することを可能にしています。カレンダーやスケジュール機能でもこのように拡張していく予定です。
 
上に戻る
 
取り組んでいる製品の発展にあわせて、チームも成長しているというのはおもしろいと思います。テストは、以前のリリースと比べて、どのように変化してきましたか?

ジャネット・カーン
リリース 4.0 を公開したときには、チームには4人しかメンバーがいませんでした。1人がノーツ・メール・クライアント、メール・テンプレート、アドレス、そしてメーラーのすべてのテストを受け持って、もう1人がノーツ・メール・サーバーのメール・ルーティングをテストし、3人目がノーツ管理クライアントや代替メール、そして MAPI を担当していました。マネジャーだった私は、すべての分野でのテストに参加しました。

リリース 4.5 では、新しい C&S 機能も受け持つことになり、リリース 4.6 では、メールや C&S へのブラウザーからのアクセス (Webmail) や、ノーツ・クライアントとの互換性に関するテストも担当しました。リリース 5.0 では、ノーツ・メール・サーバー、ノーツ管理クライアントの機能が向上したのに伴って、複雑さが増し、チーム全体が集中して取り組む必要がありました。インターネット・クライアント (POP、IMAP、LDAP、SMTP) のテストだけでなく、ノーツ・メールや C&S クライアントが機能面で複雑になったので、非常に多くの作業を伴い、チームは常に忙しい状態でした。現在は10人のメンバーがおり、ノーツ・メール・クライアント、C&S (クライアントとサーバーともに)、そしてノーツ・メールへの代替クライアント・アクセス (Webmail や iノーツ アクセス for MS Outlook による MAPI インターフェースを介したアクセス) のテストを担当しています。
 
上に戻る
 
チームの構成や担当が相当変わったわけですね。

ジャネット・カーン
より複雑になってきましたね。ノーツ用のメール・クライアントから始まって、カレンダーとスケジュールが加わり、現在は Webmail があるわけですからね。

アンディ・シャマー
さらに、ユーザーの数も増えたので、それに伴ってユーザーが何をするか、ということも多様化してきました。

ファラ・グロン
サード・パーティーの製品もテストします。例えば、ノーツ・クライアントとドミノ サーバーという環境でドミノ サーバーを使う際には、Outlook クライアントをサポートしています。
 
上に戻る
 
この仕事をしていて、どのようなときに最も充実していると思いますか?

メリン・ヤン
私が担当している製品が売れていて、ロータス ノーツのように多くのユーザーに使われているときにはよかったなと思います。製品といっても、ユーザーに好かれて使われなければ、製品とは呼べないのです。また、私が担当している機能が、日々の生活の中で役立っていると思うと充実していると感じます。飛行機に乗っていて、向かいに座っている人がノーツを使っていたりすると、ついつい話し掛けて自分が関わっているということを話したくなりますね。バグの報告といったユーザーからのフィードバックを受けると、がっかりする場合もありますが、これは同時にユーザーが私たちが担当している機能を真剣に捉えている、ということの証拠でもあります。ユーザーの満足度を維持する、というのは私にとってやりがいがあることです。

ファラ・グロン
デザイン段階や、開発段階から製品に関われるというのはやりがいがあると思います。開発陣と密接に関わりあいながら作業をするのは非常に面白いですね。大きな機能のコードを書いている時には、私と同じ部分を担当している開発者と毎日コンタクトし、その日のビルドではどのようなことをするのか、前夜にチェックしたコードがどのような影響を及ぼすのか、といったことを話します。私はプログラミングの経験があるので、機能やその実現についての話をするときにはその経験が役立っています。ですから、チームワークがうまくできていると言えますね。私は「こうなっていたほうがユーザーにとってはいいだろう」という、ユーザビリティーに関する意見を出し、ユーザーの「声」として、機能をより直感的に使えるようにしています。また、不具合の原因を突き止める、というまるで探偵のような仕事もおもしろいですね。

ジュリィ・アン・スパン
私にとっては、開発の早い段階で新しい機能をより良くするような提案をするのが、QE の仕事をしていてやりがいがあると思いますね。製品に長く関われば関わるほど、ユーザーがその製品にどのようなことを望むかが分かってきます。製品のライフ・サイクルの中で、早いうちに顧客の代表として意見を言うというのは非常にやりがいがあることなんです。

アニタ・パシィ
バージョンごとに製品がどんどん大きくなっていくのを見て、市場に送り出す前に多くの問題点を発見して大きな貢献をできたと思うとやりがいがあると感じますね。

アンディ・シャマー
QE としては、再生が難しいバグを担当したときに、再生しやすいようにして開発者が問題の原因を突き止めやすくするのがおもしろいですね。あと、バグを発見して再生し、修正したものが正常に動くかどうか効率よく確認するというのも、質の高い製品を生み出すのに貢献し、役に立てたと感じて楽しいです。よい QE になるには、常に質に気を使う必要があるのです。

メールや C&S に関しては、この分野を担当するのが好きな理由がいくつかあります。1つ目は、全然退屈しない、ということです。さまざまなクライアント、プロトコル、オペレーティング・システム、そしてロータス スクリプトや Java スクリプトなどの手段、この他にも色々な機能があり、1つのことをやっていて飽きる、ということがありません。もう1つの理由としては、このチームでそうですが、すばらしいチームワークがあるということです。メールや C&S のすべての側面をテストするには、チーム・プレイやグループ同士のコミュニケーション、そして知識の共有といったことが必要になってきます。最後にもうひとつ思いつくのは、このチームで働いていて接することができるテクノロジーですね。アプリケーション・レベルから始まって、フォームやビューといった設計要素、式言語や Java スクリプトに関われるほか、メール・テンプレートを構成するライブラリーにも触れることができ、やりがいのある、すばらしいテクノロジーを学ぶ機会を与えてくれます。
 
上に戻る
 

レニー・デッカーについて
レニー・デッカーは、昨年クライアント・メール QE チームのプロジェクト・リーダーをつとめました。以前は数年間、大手の通信系の会社でドミノ管理者として、ドミノ・メール、アプリケーションそして SMTP サーバーの運用を担当していました。また、レニーは Iris に移籍する前は、開発者、また有資格トレーナーもつとめました。

ファラ・グロンについて
ファラ・グロンは、Iris で3年間クオリティー・エンジニアのリーダーをつとめてきました。Iris に移籍する前には、ロータス オーガナイザーにも2年間関わりました。ファラは Brandeis 大学でコンピューター・サイエンスの学位を取得しています。趣味は、夫と2人の娘と時間を過ごすことと、ホメオパシー(同種療法)、ガーデニング、そして1年生と4年生の宿題を手伝うことだそうです。

ドリス・ジョーンズについて
ドリス・ジョーンズはボストン大学でコンピューター・エンジニアリングの学位を取った後、チームに加わりました。現在は3年チームに関わるベテランとして、主にアドレスと Webmail に関わっています。ニックネームは Deejay で、フット・ボールとバスケット・ボールの大ファンで、空想でスポーツをするのが好きだとか。テニス、バスケット・ボール、ソフト・ボール、そしてプレイステーションを楽しんでいるそうです。

ジャネット・カーンについて
ジャネット・カーンはメール、C&S QE チームで 1995 年以来、マネジャーをつとめてきました。以前は、ロータス Improv で QE エンジニアを5年半つとめ、ロータスに入る前は Gold Hill コンピューターとゼロックスでプログラマー、カスタマー・サポート、そして LISP ベースの製品を担当していました。ジャネットは Vassar カレッジで認知科学の学士を取りました。プライベートは、教会に行ったり、家族 (夫のフランクと10歳のエリック、6歳のアンナ) とすごしたり、200 年前に立てられたという家を直すことが多いそうです。

リサ・ノッドウェルについて
リサ・ノッドウェルは、Iris Associates でオートメーション・クオリティー・エンジニアのリーダーをつとめています。リサは 1998 年の2月に Iris に移籍し、オートメーション化したテストを担当しています。Iris に来る前は、ロータスで、8年以上にわたってさまざまなソフトウェア・オートメーションに関わるツールを担当してきました。リサは University of Lowell で電気工学の学士を取得した他、Tufts 大学で国際関係学とフランス語の学位も取っています。

アニタ・パシィについて
アニタ・パシィは、ノーツ C&S QE のプロジェクト・リーダーをつとめており、1996 年からロータスでノーツ・メール、C&S チームに所属した後、Iris に移籍しました。以前は、何年間もベネズエラに住んでおり、ロータスのビジネス・パートナーである積算機会社の Grupo Beke Santos でテクニカル・サポート・マネジャーをつとめていました。さらにその前は保険会社の Grupo Asegurador La Venezolana の関連会社である La Venezolana de Datos y Servicios でアプリケーション開発者をつとめていました。アニタは旅行、ハイキング、新しい言葉を学ぶのが趣味で、好きなスペイン語を生かせるといって Iris Today の翻訳もしたこともあります。

リサ・ロウについて
リサ・ロウは、ここ2年間 Iris Associates でクライアント・メール、C&S QE チームに所属しています。以前はロータスに4年間いて、eSuite チームで Sun Java ステーション の QE などを担当していました。趣味は料理、ホッケー、スキー、そして3人の娘とショッピングを楽しむことだそうです。

アンディ・シャマーについて
アンディ・シャマー(ニックネーム Drew) は、メール・クライアント・グループでシニア QE をつとめており、現在は同グループで開発者としての役割も果たしています。コンピューター・電気工学の学士を持っており、Raytheon で2年間、Banyan Systems で約8年間働いた後、2年半前に Iris に移籍しました。人生で大切なのはやはり家族だそうで、2歳になる娘と4歳の息子、7歳の娘、そして妻の Dawn (年齢は秘密) をこよなく愛しています。また、サッカーやホッケー (ストリート・ホッケーもアイス・ホッケーも) をするのが好きで、子供たちのサッカー・チームを 10 年以上もコーチしているそうです。

ジュリィ・アン・スパンについて
ジュリィ・アン・スパンは、2月にメール、C&S チームに加わり、グループ・スケジュールのワークフローを担当してきました。Iris に移籍する前は、数年間ドミノ・チームに、ロータス Fax の QE エンジニアのリーダーとして貢献したほか、10年間 Marcam Corporation でサポート、トレーニング、マネージメント、QE と、様々な役割を担当しました。製品のテストをしていないときには、娘のシャノンと遊んでいるか、ガーデニングを楽しんでいるそうです。

メリン・ヤンについて
メリン・ヤンは3年前に Iris に移籍しました。以前は Digital Corporation で10年間、Wang Labs で1年働いた経験があります。Digital Corporation では2年間ネットワーク開発者として働いたあと、QE エンジニアに転身しました。メリンは Taiwan Normal 大学で教育学の学位を取得したあと、University of Lowell でコンピューター・サイエンスのマスターを取得しました。趣味はガーデニングだそうです。

リンダ・アプゴティスについて
リンダ・アプゴティスは、文書作成を専門としており、旧石器時代に石器についての記事を書いて以来ずっと文書作成をしているのではないかと思うくらいです。Data Resource、PSDI、そして Software House で文書作成の仕事をしてきました。ロータスでは Lotus Improv、SmartSuite、eSuite、そして現在はノーツを担当しており、そろそろ 30 回目の誕生日を迎えようとしています。Que ブックの Quick Reference for Improv、そして Improv キューブックの中のいくつかのチャプターを手がけました。ガーデニングが趣味で、娘のメーガン、夫のミッシェルと時間を過ごすのが好きだということです。
 
上に戻る