開発部テストチーム所属小林です。5ヶ月目です。

本当にここでブログ書いちゃってもいいのかな？とっても場違いな感じが否めない・・・

まぁ当たって砕けろ精神で行こうと思います。

目標：

毎週水曜日に最低週一でなんか書く

内容：

雑記とか（いいのか？）

ほそぼそと練習中のJavaScriptとか

気になったニュースとか

QGで気がついたこととか思いついたこととか

いつもこの手のことをやると手が震える、些細な緊張やプレッシャーに弱い私ですが、この調子で続けられるのかとても不安・・・

手が震えるといえば我が家のお父さんが煙草の値上がりに合わせて禁煙を開始しました。

でも1年かけて禁煙が成功する割合はわずか１５％程度なんだとか。

調べてみたところ、

喫煙は、他の習慣と結びついていることが多いので、なるべく日常の習慣を変える。タバコを吸いたい衝動は、およそ3分で収まるので、その間を乗り切る。少量でも吸えば、失敗に終わる。
タバコなどに由来するニコチンは平均3日で体から消えるが、精神的な依存は平均30日続く。禁煙後およそ30日が経過したら、一応禁煙達成と考える。

とのことなので、ニコチン切れてイライラしながらニコチンガムを音立てて噛み続ける人に（微妙な）いらつきを覚えながら、手助けしていこうとおもいます。

（本当は酒も煙草もやめるとイライラがひどいので素直に喫煙飲酒して欲しい。もっとも酔っ払うと性質が悪いので禁酒はベターかもしれないが）

失敗のケースとして喫煙本数を1本ずつ減らすやり方は、減らすこと自体がストレスになりやすい。またタバコの無い環境に閉じ込める方法も、依存を強めるだけに終わる。かつては島津藩では喫煙者を死刑にしたが、喫煙を減らす効果は無かった

・・・死ぬより怖い禁煙活動？

開発部テストチーム所属小林です。

残暑もようやく遠退いてやっと涼しくなってきたかと思えば突然猛暑になるというよくわからない天候が続いています。
おかげさまで前3連休は風邪気味で寝っぱなしでした。

そんなざまなので今日の朝ありえるえりあに何書こうか・・・と考え、まぁ仕事終わる頃には何か考え付くだろとか思っていたらあっという間に夕方。
さぁ困った。2回目にしてすでに日記くらいしか書くことがないぞ・・・？

そういうわけにもいかない（？）ので、最近副業で作った探索プログラムについてちょっと書いてみる。

プログラムの目的：
与えられた文書の中から0個以上存在するメールアドレスを抽出する
求められるもの：
遅くてもいいから文書内のメールアドレスを正しく抽出すること

というごく簡単なもの。

紆余曲折あったものの、現在の仕様は
①文書の中からトップレベルドメインを探す
②見つけたら、文書の先頭からトップレベルドメインまでを切り取る
　見つからなかったらこの文書の探索は終了
③トップレベルドメインから1文字ずつ後ろへ下がる
④＠が見つかる前に禁止文字が出てきたら、②で切り取った部分を取り除いた文書に①を適用する
⑤＠が見つかったらメールアドレスに該当するので禁止文字が出るまで遡る
⑥禁止文字が出たらメールアドレスとして保存し、②で切り取った部分を取り除いた文書に①を適用する

というかんじ。
とりあえずメールアドレスの抽出は行えるけど結構遅い。
対象の文書が1000件程度ならいいが、さすがに万単位の処理だと時間がかかる。

そこで、なぜ遅いのか、どうすれば速くなるのか、というのを（主に書く内容がないとき）探求して行こうと思う。

遅そうな原因：
・そもそも現在の仕様が悪い
＞これを考えると少し悲しくなるのでひとまずおいておく
・文書の中からトップレベルドメインを探すのに時間がかかる？
・トップレベルドメインを見つけ出した後にメールアドレスと断定するまでが遅い？

速く出来そうな方法：
・ボイヤー・ムーア法
＞トップレベルドメインを探し出す時間を短縮できそう
＞トップレベルドメインから1文字ずつ下がる方法だとこれは適用できなさそう

とりあえずボイヤー・ムーア法を乗っけてみてどうなるか検証してみようそうしよう。

開発部所属小林です。

最近ようやく秋らしくなり、気温も25度を越えることがなくなってきました。
外は肌寒いけど室内はちょっぴり暑い・・・

ORACLEのインストールに思った以上に苦戦しています。
手順書にしたがって作業すればうまくいくと妄信してはいけないという教訓を得ました。

さてはてゴールはAquaのインストールなんですが、手順書で言えばまだ1番最初。
いつになったらAquaインストールまでいけることやら・・・

とりあえず作業を行う上でちゃんと念頭においておいたほうがよさそうなことをピックアップ。
・ORACLEとは何か？（ORACLEのXEとか何か？）
これを知らなかったおかげでどうやら無駄足を踏んでいた模様。
ORACLEの製品版とXEを両方インストールする必要なんてなかった。

・SQLって何をしているのか？
・ORACLEにSQLを流すってどういうことなのか？
・インスタンスとSID（これ少し重要なんじゃないかなぁ、と思うんだけどどうなんだろう）

この業界についてわからないことだらけなんだということを改めて思い知りました・・・
心のどこかで手順書あれば簡単に行くだろうという考えがあったことも。

とりあえずさわりの部分をご教授いただいたので、それを念頭にもっと慎重に作業しよう。

開発部品質チーム所属小林です。

すっかり肌寒い季節になってきましたが、朝の気持ちよさがぐっと増してきました。
やはりきれいに晴れた日は気持ちがいいものです。

今回は大学の授業でちらと考えたことについてちょっと書いてみます。
超小規模グループウェアについてです。

前々から小規模なグループウェアがあってもいいんじゃないかなー、と考えていたので、これを機にちょっと調べてみました。
調べてみると当然幾つかあるわけですが、小規模グループウェアというものはどうにも導入を敬遠されがちのようです。

・導入コストや管理コスト
小規模なグループなので利用者数が少なく、グループウェアを導入する利点の
「情報の収集・蓄積」「利用者のスケジュール管理」
などの恩恵が少なく、費用対効果が悪いのでは、という考えが念頭に出ている？感じです。

・管理者の問題
自社サーバーで管理できればコストを抑えられるけど管理が大変だしなぁ・・・という問題。

他にもあるようですが、小規模グループウェアの導入を検討している人の不安はこんなところの様子。

小規模グループウェアにもいろいろな種類の製品があって、それぞれにいろいろな問題があるわけですが、今回考えてるのは超小規模グループウェアです。
最小単位のグループにあたる家庭向けの製品があってもいいんじゃないか？！と思ったわけです。

で、当然素人考えなので既に家庭向けグループウェアってのは存在するわけなんです。
そこで、今は実現できないが近未来において出来そうな家庭向けグループウェアを提案してみます。

配慮する点：
管理者の問題（導入が簡単で線につないでちんとんしゃんで動かせること）
コストの問題

前提となる未来技術：
ユビキタスネットワーク
（ちょっと前ですごく盛り上がってたけど最近沈静化したような・・・？気のせい？）

販売する形態：
セットアップが完了したサーバーを兼ねるデスクトップPC
またはネットワークからのインストール
PCを買い換えることで導入できる狙い

出来ること：
従来のグループウェア機能（スケジュールとか）
家庭内家電のコントロール
例）ネットスーパーでの買い物との連携した冷蔵庫の内容物の管理

・・・思いつきで書くもんじゃないなぁ・・・
でもユビキタスネットワークが完成すれば物理的なリソースを扱えるようになるので、いけるんじゃないかなぁ、と思った次第でした。
（しかしこんな稚拙内容を、グループウェアのプロの会社のブログで書くのはどうなんでしょうOrz）

オチ：
課題をやろうと思ったら既にその授業の単位が取れてたりする。なんてこったい。

開発部品質チーム所属小林です。

最近カスタムアプリケーションと呼ばれるジャンルのテストを行いました。
標準的な機能にはないさまざまな機能が連携していて複雑であるため、テストも大変でした。

これらのカスタムアプリケーションの中で（今回担当した分だけかも知れませんが）一番大変だと感じたのが金銭計算のアプリケーションです。
普通のアプリケーションのテストよりもお金が絡む分重圧がかかります。

自分は現在入ったばかりの下っ端なんですが、以前働いていた場所で考えていたことがあります。
というのは、下っ端のミスというとなんだか些細なことのように聞こえる（現に前にいた職場では末端の人たちは悪い意味で失敗を恐れませんでした）のですが、実際に与える影響はかなり大きいなぁということです。
でも実際のところ末端で働いている場合は大きなことに目が向かないもので、まぁいいか。という風にミスを流してしまいがちです。
だいたい末端の人間が緩んでいる場合は印象がよくないです。コンビニとか飲食店とか。

まぁいいか、で済むならばよいのですが、アプリケーションの品質、特に社益に関するようなものでは絶対に許されないはずです。
自分のテストが他の人の仕事に大きな影響を与えているんだと。

でもあんまり思いつめても時間には限りがあるし、バグをなくすのは不可能に近いしで、どこかで妥協点を見つけないといけない。
つまり仕事を上手くこなすということは、よい妥協点を見つけることであると。

良い妥協点を見つけるのは強化学習のアルゴリズムにもあったけれど、とにかくいろんなことにチャレンジするしかない。
失敗もするだろうけど、めげずに続けることが仕事の向上なんだろうなぁ・・・

なんて思った次第なんですが、やっぱりお金が絡むと怖いです。

開発部品質チーム所属小林です。

急に寒くなって薄手一枚羽織るだけでは寒さに震える季節になりました。

最近隣から聞こえてくるいびきがかなりうるさくなってしんどい日々が続いてるのですが耳栓は効果があるんだろうか・・・

耳栓が気になって逆に眠れなくなりそう。

最近のテスト：
AquaDesignerで独自アプリを作る。
目的は詳細検索フィルタを組み込むことだけだったのに、つい作るのが楽しくなってしまったり。
AquaDesignerの悪いところをあげるとするならば、作れる楽しさが強すぎてついついやりすぎてしまうことだ。

SQLが絡むテストを行う。
未知の領域なので手探りで進めては見るけれど・・・
テストごとに出来ることが増えてはいるのでよしかな？

暇つぶしに作っていたプログラムがついにバグる。
仕様とか設計とか一切考えずに書きなぐるように作っていたので当然といえば当然か。
とはいえ、「ハッカーと画家」によるとこうすることでより良い物が生まれてくるらしい。

確かに作ってる間にあれもこれもと欲張って追加した結果がバグって止まるという状態なのだけれども・・・
とりあえず一旦整理して全部書き直そうと思う。

鉛筆の下書きにインクを当てて消しゴムをかけてる感じがする。

QG小林です。

最近QGの中ではテストのあり方についてよくミーティングが開かれています。

流動的に更新されていくテスト対象だと、以下の関係があるらしい。

・テスト内容の具体性

抽象的に書く：

利点）流動的に変化する対象においては抽象的に書くことでテスト内容のメンテナンス性を向上できる

欠点）抽象的に書くとテスト実行者によって解釈や精度が大きく異なる場合がある

具体的に書く：

利点）具体的に書くと実行者によるテストのムラが減少する（が、テスト量は増加する）

欠点）変化の乏しいテスト対象ならば問題はないが、変化が多いとメンテナンスが大変（絶望的）

・メンテナンス性

メンテナンス性を向上する：

利点）変化に対応してテスト内容をすぐに更新できる

欠点）重視しすぎるとテスト実行者の読みづらいテストになる？

とりあえず議題にあがったのはこのあたり。

現在のテスト内容はどちらかといえば具体的な内容に置かれていてメンテナンス性が低いので、ここをなんとかしようとしている模様。いくつかの改善案もある様子。

テスト精度とメンテナンス性がトレードオフの関係になっている？ようで、ミーティングではたびたび意見交換を交えながらどの程度のバランスでテスト内容を作成するかが議論の的なのだが、かなり難しい。

いったいどうすれば常に変化していく環境に対して、精度（実行者によらないもの）とメンテナンス性の両方を満たすことができるのだろうか？

・グループの意見をまとめて決定する民主政治がいいのか、一人の意向で決定する哲学政治がよいのか

・精度とメンテナンスはどちらが重要なのか（または両方を満たすにはどうすればいいのか）

・どのような規格でもってテスト内容を構築するのか

・どの程度のテスト精度であれば、人と時間を割いたときに過不足ないのか

自分が思いつくだけでもたくさん課題がある・・・こりゃむずかしそうだ。

思った以上にテスト内容の奥は深い。

話がまとまったら年末大掃除のような感じで一気呵成に作業したほうがよさそうな感じがするが、流動的な環境だとそういうのは難しそうだ。

よいテストの実行のためによいテスト環境を作ることは一筋縄ではいかない。

前回に続いてオフサイトミーティングに向けて。

課題はQGをよりよくするためには。

とりあえずちょっとしたメモ。

・個人的な前提
目的：品質を向上すること
手段：バグを見つける、要望を出す、テストの精度を上げる

品質向上などに関して
・回帰テストは自動化できる
・自動化＝工数削減　というわけではない
・自動化するのにも工数がかかる
・自動化の価値はテスト対象やリリース期間、回帰テスト実施回数に左右される
＞テストケースの見直しや書き直し、その他保守性などについての検討はコストに対する効果が得られるのか？
　仮に行うとして何を主導として行うのか？（個人による主導なのか、グループとしての主導なのか）
　前者は即効であり、後者は遅効である　前者はうまくいけば問題なく、後者は前者より失敗しにくい

優先度、コスト、重要度に関して
・テストの優先度やコストに対してテスターは認知したほうがよいか？
・テストの重要度をテスターは認知したほうがよいか
・一テスターとしてこの内容に関与するとチーム全体に効果があるか？
＞チーム全体の目標として上げられる
　遅れている重要なテストがわかれば個々でカバーにいける（個々で判断してよいのか？）
　テスト作業の方向性に関してグループで決定する必要があるのか？

テストエンジニアの育成に関して
・知識共有に対する個々の意見を聞くべき（どういう知識を共有するべきなのか、公表するべきなのか）
・チームとしての向上（抽象的過ぎるので検討するべきではない？）
・プロジェクトに配置されている人材は適切なのか？
・突然プロジェクトのテストを依頼される場合、どうすれば効率よくテストを行えるのか
・テストケースの設計について学習するべき？
＞Verify精度の向上も狙える？
　個々で学習するよりもグループでの学習のほうがテストケースの規格が統一できてよい？

将来的に求められることに関して
・品質の保持には自動化が有効？
・品質の向上には何をすればいいのか（or何をやめるべきか）
＞案のひとつとしてテストケースの修繕があがっている
・製品の売りをより伸ばすためにはどうすればいいのか？（一番難しそう）

とりえあえずQGとしてやる必要がなさそうなのが優先度、コスト、重要度の決定。

これはグループで関与すると面倒なことになるだけなきがする。

で、

求められること：
それなりに即効性があり、継続して効果が保たれるもの。

テストケースの設計について学習した場合次の効果が得られるのでは、と思った
・Verify作業時、スモークテスト時、リグレッションテスト時に担当テストの妥当性が図れる？
・追加したテストケースによるテストの効果があがる？
・今は行われていないけどテストレビューをやるときの効果があがる？
・メンターを行うときのアドバイスにより具体性が増す？

他の人たちにはどんな考えがあるんだろうか。素人ながらQGに貢献できれば・・・とは思うけれど、難しそうだ。