テストエンジニアに必要なスキル

テストエンジニアに必要なスキルには、
1.情報収集能力
2.プログラミング能力
3.コミュニケーション能力
4.忍耐力
5.分析力
などがある。

その中でも特に、プログラミング能力を見に付ける必要があると感じる。

プログラミング能力を身に付ければ、テストケース設計やテストツールの作成のときに非常に約に立つことが多い。
バグを狙ったテスト設計をするためにもどのようなアーキテクチャで、実装はどのようになっているかを知ることで見つける確度はあがってくると思う。

では、どのような言語を選択するであるが、個人的にはC++やJavaが良いと思う。
書籍が多く出ていること・転職や会社が倒産したときにもこれらの言語は多くの会社で使用しているからだ。
テストエンジニアからキャリアアップしようとしたときに、ある程度プログラミング能力があればプロジェクトマネージャになることも可能である。

良い（美しい）ソースコードの書き方

良い（美しい）ソースコードとは、ぱっと見たときに意図が明確だったり、メソッド名が分かりやすかったりするなど色々ある。
この辺は、絵を描くこととや小説を書くことと同様に何が正しくて何が間違っているというのはない。感覚的なものが含まれるから難しい。

一度作成したらメンテナンスをする必要のないソフトウェアというのは存在しない。
だから、誰が見ても分かりやすいコードを書きメンテナンスを簡単にできるようにする必要がある。

ではどのようにしたら良いソースコードを書くことができるのだろうか？
たぶん、色々なソースコードを読むこと、自分のソースコードを批判することではないかと思う。
すぐにはできないので、時間はかかると思うが、良い（美しい）ソースコードを書いていかなければならないと思う。
そのように思わなくなったら技術者をやめるときになると思う。

多変量解析法がテストに使えないかな

多変量解析法とは、ある結果に対して複数（2つ以上）の原因が考えられる場合に、これらを分析することで、複数の原因の相互関係を解き明かす方法です。

その中には色々とあり
1.重回帰分析、2.数量化1類、3.判別分析、4.数量化2類
5.主成分分析、6.数量化3類、7.クラスター分析がある。


ソフトウェアテストにおいてもある結果（仕様）に対して複数の原因（因子）がある場合に、それらを分析して、因子の相互関係を解き明かせば爆発的に増える組み合わせを減らすことができるのはないかと考えてみた。

これが実現できれば少ないテストケースで多くのバグを見つけることができるのはないかと思う。
多変量解析法を調べ始めたところなので、どうやったら良いかは分からないが、なんかしらヒントがあると思う。
直交表やTOCではないが、やはり生産管理の部分から学ぶべきことは多いと思う。

問題はいつも突然やってくる

ソフトウェア開発に限ったことではないが、ビジネスの世界において問題はいつも突然やってくることが多い。
例えば、バグはそんなに出ないだろうと予想したソフトウェアにおいてテスト中盤から終盤にかけて収束しないやシステムテストの段階に入って顧客からの突然の要求の追加や仕様変更などである。

突然やってくるときは、大体、思わぬ伏兵が現れたときである。

そんなときは、大抵工期終盤になって現れるので、かなり厳しい現実になる。
時には、現実逃避したくなるときもある。そういったときはきまって、マンパワーで頑張るしかないのだ。人の力には限界があるので、単純なミスをしたり・体調をくずしたりする。

突然の伏兵の出現を予想するのは無理である。

ただ、ある程度、思わぬ伏兵が出現しないようにするために、見える化や顧客に早い段階での確認を行うなどの仕掛けは必要であると思う。

コンパイラ作成：続編

結果から言うとコンパイラは作成できなかった。

理由としては、「スモールコンパイラの製作から学ぶプログラムの仕組み」の本を読んだが、概念的なことはこの本で学ぶことができる。
しかし、「OS自作入門」のように、作成途中にソースコードが細かく記述されていない。
字句解析などのプログラムを動かすにも、仮想マシンの実装が字句解析よりも後であること・詳細なソースコードが途中には出てこないので、動かすことができない。
良かった点は、コンパイラの仕組みが理解できたこと、変数や関数のスタック状態を知ることができたことだ。
Amazonのレビューにもあったが、りんご農園の例えがあると読みづらいこと・余計分かりづらくなったのは同じ意見だ。
ちなみに、作成する言語はJavaだった。

巻末の付録のソースコードを見ながら、実装することで、コンパイラの作成はできる。
今年の目標にも立てたように、Javaを学ぶのにはいいサンプルかもしれない。

物理学から見たピッチング

物理学からピッチングを見るとかなり切れのいい球を投げられることが分かってきた。
まず、足の使い方から、以下の2点がある。
1.軸足をプレートを蹴りながら移動すること。
2.軸足を上げて投げること。

1.はプレートを蹴りながら体を前に進めると、横方向に運動エネルギーが働いて、加速がつく。
2.は体が上に移動するために、位置エネルギーが高いところから移動するために、加速がつく。
上の2つのイメージとしては、スキーのジャンプ台からボールを落としたときのイメージ。

ただ2点目のものを行うと、コントロールが悪くなるので、かなりの練習と筋トレが必要。

腕の使い方は、物理学とはあまり関係ないが、よく腕を力いっぱい使う人がいるが、間違いである。
腕は、腰の回転力で振れば良いので力は特に必要としない。

これらを行えば、切れのあるボールとコントロールがつくことがわかった。

新型スカイラインはいい

新型スカイラインをCMやネットで見ていて良いなと思っていて、実際に展示場にいって見てきた。
実際に見たら、やはりいい。どうしてもほしくなった。

試乗車とあったのは、2.5リッターのPというタイプだった。

外から見ると、フロント周りがかなり大きく見えるが、実際に中に座ってみたら、それほど大きさは感じなかった。
トランクも、給油タンクを前に持ってきたようで、広くて通常の車の1.5倍から2倍くらいの広さがあった。
足回りもアルミでできているので、軽量化は図られているのではないかと思う。

子供と2人で見に行ったので、試乗することはできなかったので、エンジンなどはわからない。
ただ、値引きなどはあまりしないので、価格が非常に高いのが難点である。

テストエンジニアにもモデリング技法は必要だ

最近、テストエンジニアにもモデリング技法は必要であると考える。

テスト設計を行うときには、製品全体の構成や機能の関連性などを考えながら行う。
その際に、モデルとして可視化していればある程度テスト設計を行うのに非常に役に立つのではないかと思う。
又、クラス図やユースケースなどを基にテスト設計を行ったり、内部を見てアーキテクチャがどのようになっているかを考えながらテスト設計を行えば、確率論であるが、バグを狙ったテスト設計を行うことができるのではないかと思う。

そのためにもテストエンジニアにもモデリング技法は必要であると考える。

どうも色々と調べていたら、モデリング技法を身につけるには、システムシンキングを勉強することがいいらしい。

信頼度成長曲線による収束の基準

信頼度成長曲線における、縦軸に起票件数、横軸に経過日数をとることに常々疑問を感じていた。

横軸に経過日数を取った場合に常にテストの開始から終了まで同じ人数で、同じ時間テスト実施ができれば特に問題ない。
しかし、必ずしもそういった場合が多いとは限らないからだ。又、一般的にテスト実施期間が1ヶ月半ないと、曲線自体の信頼性がないということが言われてるかだ。

そこで、先日、ソフトウェアテストPRESS Vol.1を読んでいるときに、横軸にテスト項目数をとれば良いのではないかと載っていた。
これは読んでいるときに非常にいいと感じた。これは期間が短いテストでも適用できること、収束度を算出して、数値として明確にされていることがあるからだ。
この著者によると、経験から収束度が0.5以下であれば問題ないのではないかとあった。
企業によってこの値は異なってくるので、企業や製品ごとに値は変化してくることもあるとなっていた。（当たり前である）

その中で、疑問が湧いた。通常テストは2サイクルは実施されるので、1サイクルで計測するのか、2サイクルまとめるかという疑問がある。
たぶん、自分なりに解釈した手順としては、以下の通りであると思う。
1.1サイクルで判断して、一度収束度を算出してから、2サイクル目を行うかどうかを判断し、2サイクル目を実施するかを判断する。
2.2サイクル実施した場合には、2サイクルが終了した時点で、再度収束度を算出する。

やってみないとわからないので、今後試してみようと思う。

テストとは情報収集の作業

テストをしていて感じることとして、ドキュメントに必ずしも書かれていない事柄が多いこと、2サイクルでテストを実施したときに、2サイクル目に新たなバグを見つけることができることがある。

これは、必要な情報を引き出せていないこと、テスト担当者が仕様の理解が浅いことなどが原因であると考える。

必要な情報が引き出せていないことは、ドキュメントに必要な情報がない、コミュニケーション不足により、情報が引き出せていないために、テストケースから漏れていると考える。

そこで、プログラマからいかに情報を引き出して、テストケースとして作成するか、又、プログラマにバグの匂いを気がつかせることが重要であると最近感じる。

具体的には、テスト担当者が、要求を決める段階からの参加、朝会などで定期的にコミュニケーションをとることである。
そこから、ドキュメントとしては現れてこない不安な箇所（バグの多そうな箇所）を引き出すことで、バグの発見率はかなり違うことが分かってきた。

それ以外にも方法はあるかもしれないが、すぐにできることとしては、上記の方法がベターである。