sashima

「エンジニア100人に聞きました」〜新人エンジニアにお勧めする一冊編〜

こんにちは。開発企画室の佐島です。

今回のブログはe100qプロジェクト第三弾、テーマは「新人エンジニアにお勧めする一冊」です。

e100qプロジェクト #e100q

e100qプロジェクトとは、各社で同じアンケートを実施し、結果を各社のエンジニアブログ等の場で、同日同時刻にいっせいに公開するというプロジェクトです。

詳しい話は以下をご参照ください。

「エンジニア100人に聞きました」始めます。

ということで、改めまして「エンジニア100人に聞きました」〜新人エンジニアにお勧めする一冊〜

グリーのエンジニアに対して行った結果と併せてご覧ください。

  • アンケート期間:2014年03月25日〜04月01日
  • 回答数:14

Q1:新人エンジニアにお勧めする一冊を教えてください。

Q2:(Q1で挙げた一冊を)お勧めする動機を教えてください(1つ選択)。

にこいちの質問なので結果はあわせて紹介させて頂きます。

お勧めの一冊 動機
エリック・エヴァンスのドメイン駆動設計(2名から推薦) a. 自分が新人のとき、実際に読んでみてためになったから。
c. 今にして思えば、自分が新人のときにこれを読んでおけば良かったと考えているから。
人月の神話(2名から推薦) a. 自分が新人のとき、実際に読んでみてためになったから。
たしなみだから
Code Complete これを読んでいればこんなひどいコード書かないだろうというコードにたくさん出会ってきたから
Binary Hacks とりあえず。
実践vim 頻繁に行う作業の効率化につながったと思うため
Perlデータマンジング―データ加工のテクニック集 a. 自分が新人のとき、実際に読んでみてためになったから。
『体系的に学ぶ 安全なWebアプリケーションの作り方』 a. 自分が新人のとき、実際に読んでみてためになったから。
情熱プログラマー ソフトウェア開発者の幸せな生き方 a. 自分が新人のとき、実際に読んでみてためになったから。
小さなチーム、大きな仕事〔完全版〕: 37シグナルズ成功の法則 転職したときに、チームメイトから贈られた一冊。新人のみならず、チーム全員が読んでおくべき本だと思っています。
ライト、ついてますか a. 自分が新人のとき、実際に読んでみてためになったから。
[脳の右側で描けベティ エドワーズ (著) c. 今にして思えば、自分が新人のときにこれを読んでおけば良かったと考えているから。
会社は2年で辞めていい 若いうちに転職慣れしておいた方がいいと思うので。

(自由回答なので)ある程度結果は予想出来ていたとは言え見事にばらけました。知らない本も多かったので調べてみたのですが面白そうなものばかりで、新人向けかどうかは別として良書が集まっているなぁと思いました。

しかしお勧めする理由の中に「b. 自分が新人のとき、先輩から勧められたから。」が一つもないというのが何とも香ばしい結果というか、今回は勧める側なので自分は良いと思って勧めているわけで、けど勧められた方は何年後かにその本を勧めてくれな (ry

Q3:(Q1で挙げた一冊)それ以外に、お勧めの本があれば教えてください。

どーんと列挙します。

  • 3名推薦
    • 『CODE COMPLETE 第2版 上』
    • 『CODE COMPLETE 第2版 下』
  • 2名推薦
    • 結城 浩 (著) 増補改訂版Java言語で学ぶデザインパターン入門
    • すごいHaskellたのしく学ぼう
    • 人を動かす
  • 1名推薦
    • 7つの言語 7つの世界
    • 7つの習慣
    • [24時間365日] サーバ/インフラを支える技術 ‾スケーラビリティ、ハイパフォーマンス、省力運用 (WEB+DB PRESS plusシリーズ)
    • [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ)
    • 『エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド』
    • アジャイルサムライ
    • 欺術(ぎじゅつ)―史上最強のハッカーが明かす禁断の技法
    • コンピュータの構成と設計
    • アルゴリズムイントロダクション
    • 論理回路入門
    • 集合知プログラミング
    • アイスマン(ケビン・ポールセン)
    • 誰のためのデザイン?―認知科学者のデザイン原論
    • 数学ガール 乱択アルゴリズム (数学ガールシリーズ 4)
    • 呪いの時代
    • 予想どおりに不合理―行動経済学が明かす「あなたがそれを選ぶわけ」
    • アーキテクチャの生態系――情報環境はいかに設計されてきたか
    • なんでコンテンツにカネを払うのさ? デジタル時代のぼくらの著作権入門
    • アイデアのつくり方
    • 富の未来
    • 究極の会議
    • 財務3表一体分析法 「経営」がわかる決算書の読み方
    • ビジョナリー・カンパニー 2 – 飛躍の法則
    • ハッカーと画家
    • 働き方革命―あなたが今日から日本を変える方法
    • 3年で辞めた若者はどこへ行ったのか―アウトサイダーの時代
    • 労働法についての本(何でも良い)
    • 入門UNIXシェルプログラミング(bashコマンドに関してはこれさえ読めば十分というかほとんど必須の本)
    • *nixを知りたいならW. Richard Stevens先生の本を読みましょう
    • 「俳句への道」高浜 虚子(「脳の右側で描け」と同じく客観的にものを見ることの大切さを教えてくれます。客観的にみたものを絵で表現するか言葉で表現するかという違いはあるものの、両者とも同じことをいっているように思います。)
    • Joel On Softwareとハッカーと画家とFINE SOFTWARE WRITINGSを読んで、いかに現実的に、気楽にやるか、ということを身につけておくといいと思います。

一人一冊ではないのでよりカオス感がUPしました。

しかも後半の方は本のタイトルの紹介に留まらず、若干レビューっぽいコメントまでついていて、とにかく読んで欲しい感がひしひしと伝わってきます。

Q4:先輩エンジニアとして、新人エンジニアに贈る言葉をお願いします。

新人エンジニアにお勧めする一冊というテーマですが、この質問がメインじゃないかという思うのは私だけでしょうか?

(当社に限らず)新人エンジニアのみなさん、アツすぎるメッセージをどうぞお受け取り下さい!


  • 誠実さを忘れずに
  • いい師匠を見つけるのがエンジニアとして成長する最短経路
  • Done is better than perfect. – Mark Elliot Zuckerburg
  • 常識的には無理だと考えられている問題も、狂気なまでにやり込んでしまえば、力押しで突破できる
  • 「勝つために戦え」
  • 20代のころに勉強した差が30代になって圧倒的に出るので、若いうちにがんばりましょう
  • 「学会発表の緊張感を忘れるな」
  • 取り返しがつかないミスはない。他者の失敗を責めるよりも、フォロー、リカバリー、問題解決する技術などを磨くのが優れたエンジニアへの道のひとつ。

どれもいい言葉ですね。染み入ります。標語にしてスマホのホーム画面にでもしてみてはいかがでしょうか?


  • セキュリティについては大学の教育などでは意識されない点なので、顧客の個人情報を守るためにも、そもそもどこが脆弱性になりうるのかなど最低限の部分は学んでおくとよさそう。
  • プログラミングの本を読むのもいいですが、あえて全く別のジャンルの本を読むことをおすすめします。3〜5年もたてばプログムが出来るのは当たり前になり、プログラムの他に何が出来るのかの方が重要になります。若いうちから専門分野以外のいろいろな物事に目を向ける練習をしておくと良いとおもいます。「脳の右側で描け」は絵の描き方を解説した本なのですが、絵の描き方を通して客観的にものを見ることの大切さを教えてくれます。客観的にものを見ることはどんな場面でも役に立ちます。

標語にするには長すぎますが的確なアドバイスですね。覚えておいた方が良いと思います!


そして、、、ここからはサバイバルなメッセージが。

新人エンジニアに言う必要ある?と思いつつも、飲み会の席とかではこういう話を聞かされることになると思うので、知っといて損はないのかなぁと思います。

しかし贈られた方もどうリアクションしていいものやらw(ともあれ社会は戦場なのです)

  • 「守れない納期と満たせない要件を引き受けない勇気」
  • 「プログラミング道グリー流に入門するわけでもなければ、大エンジニアになるための功徳を積むために会社に来ているのでもない」
  • 会社内でのキャリアパスとか評価制度とかは一切気にしないことをおすすめします。「上司から褒められたら負け」くらいに考えて、若いうちは一切自己犠牲を払わずに自己利益だけを追求した方がいいと思います。(ただしなるべく波風を立てずに「いつの間にかおいしいとこだけを持っていく」ようなやり方でいきましょう)
  • 君らの方が圧倒的に優秀だけど、年寄りの心配も知ってほしい!
  • 転職市場におけるエンジニアの需要は40代になると一気に減っていきます。そうなった時に重要なのはやっぱり「人脈」なので、色んな交流会や勉強会に積極的に参加することをおすすめします。(特に将来「キーマン」になりそうな優秀な人とは良い関係を築いておきましょう)
  • 「雇われエンジニア」からの「出口戦略」を常に考えておくことをおすすめします。50代になっても人に使われていたいなら話は別ですが。
  • 早いうちに「フリーランス経験」を積んでおくことをお勧めします。「フリーでもやっていけるんだな」ということが分かると、「今所属している会社は単なる取引先の一つに過ぎない。自分にメリットがなくなったらいつでも切る」というような考え方が出来るようになります。(会社側もそう考えてるわけなんでこれで対等になれます)
  • 会社とは「利用するもの」であって「利用されるもの」ではないので、会社からいかに「搾取」するかを考えて働くことをおすすめします。間違っても「搾取」されないようにしてください。


ということでいかがだったでしょうか?

それでなくても研修やらなんやらで新しく覚えること多いと思いますが、せっかくの機会なのでどれか一冊読んでみるのもいいかもしれません。

他社さんの結果も気になります。

今後もe100qプロジェクトが開催される際には乗っかって行きたいと思います!

chobi_e

hhvmのExtension書いてみた

みなさんこんにちは。hackしてますか?

今日はhhvmのC++拡張(Extension)について書いてみます。

前振り

hhvmはfacebookが開発・公開しているPHPの処理系のうちの一つでC++で書かれており、linux上でのJITがサポートされており場合によってはとても高速にPHPアプリケーションを実行する事ができます。

勿論Native拡張を書くこともでき、既存のライブラリ資産の有効活用やどうしても速度が出ない部分の改善などが簡単に行えるので手段として知っていると便利です。

この記事をきっかけにhhvm Extensionのとっかかりになれば嬉しいです。

続きを読む
KuokaYusuke

Mavenで結合テストを自動化する方法

こんにちは、九岡です。

Javaエンジニアのみなさん、結合テストの自動化してますか?!

この記事では、

  • 結合テストとは何か
  • 筆者は何のために行っているのか
  • それをMavenで自動化する方法

をご紹介します。

用途が知られていたりいなかったり、単体テストに比べると情報が少なかったり、より多くのMavenプラグインを使うことになりがちで手間がかかる「結合テストの自動化」。

「まだやってない」という方は、この記事をとっかかりにしていただけるとうれしいです!

続きを読む
gong023

レガシーなプロダクトにテストで向き合う話

はじめまして。荻原といいます。グリーのプラットフォーム部門で、サーバーサイドのエンジニアをしています。

昨年末ぐらいまで業務の空き時間にテスト周りでごにょごにょと動いていたので、今日はそのことについて書かせて頂きます。

こんな人は読むと役に立つかもしれません。

  • レガシーなプロダクトになんとかして突破口を開きたい
  • PHPUnit の書き方で参考になりそうなものを探している
  • Ruby でスマートフォンのブラウザ操作を自動化したい

経緯

こちらでも言及されている通り、サービスを運営している以上、時には技術的負債に向き合わなければなりません。GREEも歴史が長いプロダクトなので、日々コードをリリースしていく中でそういった問題に頭を抱える場面もありました。

技術的負債による副作用はたくさんありますが、どういう点に不安を感じていたのか、実際に開発の現場に立って感じたことをいくつか書いてみたいと思います。

コードが読めない・・・

私がチームにアサインされた当初、担当範囲のコードを読み解くのに非常に苦労しました。もちろんこれは私のリーディング力が低かったからというのもあると思いますが、それを差し引いてもコード以外に理解しなければならない業務知識も多く、チームにジョインしていきなり仕事をするのはほとんど不可能なように思われました。

しかし、そんな状況でもタスクは存在します。業務に慣れないうちは、中途半端な理解でだましだましコードを書くしかありませんでした。お恥ずかしい話ですが、しばらくはそんな状態で仕事をしていて、先輩に「あーそれとそれの順番かえちゃダメだから。」という類の指摘を受けたこともありました。この時言われてなければ大障害を起こしていたと思うと今でもぞっとします。

それから時間が経ち、ある程度業務知識も増え、コードの全体像も理解できるようになったころ、かつて作った部分をもう一度メンテする機会がありました。以前やった箇所だから簡単だろうと思ってファイルを開くと、コードには無邪気に if や for が積み上げられていて愕然としました。今だったら業務背景も理解しているしコードの全体像もわかる。このディレクトリのこんなクラスにこんなコード書く必要ないのにと思いつつ、あんなに苦労させられたコードの加害者の一員に、知らぬ間に加わっていたのだということに気づいてショックを受けました。

プロダクトがこういう状態になってしまうと

  1. コードが読めない
  2. よくわからないから適当に注ぎ足す(故意・過失に関わらず)
  3. さらにコード読めなくする

というサイクルに入ってしまい、もはや割れ窓理論状態です。

リリース前テストが終わらない・・・

私のチームでは、コードが完成し、レビューも完了となると、次はステージング環境での受け入れテストというフローになっていました。

一つ補足しておくと、私が今回言及する「受け入れテスト」とは「ユーザーから見て、対象のソフトウェアが受け入れられるものかどうかテストする」という意味です。もっと根も葉もない言い方をすると、ポチポチ端末をいじってテストすることです(少なくとも今回の記事ではそういう意味で使っています)。近い意味としてよく用いられる言葉は、ブラックボックステスト、統合テストなどでしょうか。

受け入れテストは、デベロッパー目線ではなくユーザー目線であることに注意して下さい。私のチームではこれを徹底するため、受け入れテストは専門のチームに依頼していました。開発者自身がテストする場合、修正箇所だけを確かめがちになりますが、そうではなく、第三者にユーザー目線で広くテストしてもらうことは品質担保という意味で非常に妥当だと言えます。

しかしそれゆえに、時間もかかります。開発者からすれば修正箇所以外のテストも行われるので無駄なような気がしてしまうのですが、実際に予期していない箇所から不具合が検出されることもありました。思わぬところで影響が出てしまうというのは技術的負債を背負ってしまったプロダクトならではという感じですが、だからこそしっかり確認していかなければなりません。

また、時間がかかる要因として、非常に多くのテストケースをカバーしなければならなかったことも挙げられます。基本的に歴史の長いプロダクトであるほど満たさなければならない仕様が多く、色々な条件を掛けあわせていくと場合分けがどんどん発散していきます。さらにそれを様々な端末・OSでテストするので、テストケースは膨大になってしまいます。テストケースが膨大になると、今度はテストを依頼するチームとのコミュニケーションコストも無視できない問題になってきます。

しかしいくら時間がかかるとはいえ、これは決してスキップすべきフローではないように思いました。ミッションクリティカルな部分を触ることも多いチームだったので、些細なものでも不具合を看過すべきではありませんでした。

そんなこんなで、私はコードレビューが完了してから全ての修正を出すまでに二ヶ月あいたということも経験したことがあります(非常に極端な例でしたが)。確かにテストはスキップすべきではありませんが、同じような端末操作が行われていることも多かったので、自動化できればリリースを効率化できるのではと考えていました。

どうしよう

勢いで色々と書きましたが、一旦感じていたことをまとめてみようと思います。

  • コードの汚染度が高く、必要とされる業務ドメインをコードから読み解くのに苦労するし、その状況がまた汚染を加速させる
  • 端末を操作してテストする作業がリリースのボトルネックになっており、自動化したい

大胆にリファクタリングを行っていくという選択肢もあるのかもしれませんが、多くの方々に利用して頂いているプロダクトに大幅な修正をしていくのは大変です。また、リファクタリングを加えるにせよ、それの前と後で挙動に差がでていないか確認する手段が必要です。そういった経緯で、テスト周りの強化に目が向きました。考えていたのは以下の二点です。

  • 単体テストを強化し、ドキュメントとする
  • 端末操作を自動化し、業務を効率化する

単体テストを強化するモチベーションは様々ですが、私の場合は特にドキュメントとしての効果を期待しました。テストを強化する前からドキュメントはあったのですが、どうしても wiki のような形式だとリリースするそばから古くなっていってしまいます。日々書き換わるコードに対して正しさを保証するためには、単体テストをドキュメントとして作っていくのが良いと思いました。イメージとしてはコードの翻訳という形に近いかもしれません。

受け入れテストに関しては、同じような端末操作を自動化することで直接的な効果を期待出来ました。ただし、専門のチームとコミュニケーションを取るためにも、非エンジニアの方でもどのようなテストをしているのかわかりやすいようにすることと、より広い範囲をカバーできるよう多端末でテストできるような仕組みにすることを念頭に置きました。

ドキュメントとしての単体テスト

単体テストにはドキュメントとしての効果を期待していましたので、可読性には特に気を払っていました。ここでは実際にサンプルを挙げて、どのような書き方をしていたかを紹介したいと思います。なお、テスティングフレームワークは PHPUnit を想定しています。

今回は以下のようなコードをテストターゲットととして考えてみます。

よく見かけるのは以下のようなテストコードです。

残念ですがこれは、可読性うんぬん以前に異常系をカバーできていません。意外に書かれていない場合が多いです。とりあえず異常系を書き足してみましょう。

というわけで書き足しましたが、同じ関数の中に複数のテストケースが混在しているのは頂けません。テストコードでは、関数を振る舞いごとに分けましょう。余談ですがこういうことを繰り返して、たまにテストコードなのに100行や200行もあるモンスター級の function になっているのを見かけたりします。こうなってしまうと何をテストしたいのかわからなくなってしまいます。もっと酷い場合 if や foreach などのロジックがふんだんに入ってテストが間違っているのか元のコードが間違っているのかの区別もつけられない時もあります。

異常系、正常系を分けました。私の場合、正常系・異常系ごとにテストケースを @group アノテーションで振り分ける場合が多いです。こうすることでテストの意図を明確にできます。

良くなってきましたが、もう少し読みやすく書けます。振る舞いで関数を分けたのなら、関数名もそれに合わせてしまいましょう。ついでに @test アノテーションをつけて、関数の頭の test という prefix を削ってしまったほうが読みやすいでしょう。

いかがでしょうか。全て同じコードに対するテストですが、書き方の工夫次第でかなり可読性が違うと思います。サンプルは isOverTen という prefix ではじめていますが、実際はテスト対象の関数ごとにテストクラスを一つ作っていたので、この部分は省略していました。テスト対象のクラスがかなりファットになってしまっている場合、テストクラスの方を細かくしないと対応していけません。

fixture の扱いも気をつけたいところです。何も考えずに一つの array で管理していたりすると、どのテストデータがどういう意図で設けられているのか全く読めないです(というか既存のテストがそうなっていて苦労しました)。今は PHP にも fixture をうまく管理するライブラリが作られているので、積極的に導入していって良いと思います。そもそもDBアクセスさせないという方針もアリで、DBデータは極力 mock を使うようにしていました。私はテストが失敗した時にDBの状態とロジック両方を疑わなければならない状態はあまり好きではないです。

また、弊社はフレームワークに Ethna を使っていますが、標準のテストクラスが SimpleTest の利用を前提としていたため、こちらでヘルパーを作りました。ついでにヘルパーにはスーパグローバル変数を操作して iPhone や Android の UserAgent をエミュレーションする機能を乗っけたりしました。

Ruby 周辺のツールで受け入れテストを自動化する

冒頭で述べたように、受け入れテストも効率よく行っていかないとリリースのボトルネックになってしまいます。今回は RSpec + turnip + selenium-webdriver + Appium という構成で自動化を実現しています。これに関しては実際にコードをみて確かめてもらったほうが早いので、今回は「ブラウザを立ち上げgoogleにアクセス > 検索ボックスにワードを入れて submit > 検索結果をスクリーンショットで保存」というブラウザ操作を自動化したサンプルを用意しました。是非一度動かしてみてください。

サンプルの動作方法は以下です。なお、サンプルは Ruby2.0 以降で動くので、事前にインストールしておいて下さい。

いかがでしょうか。うまくいっていれば Firefox が立ち上がりブラウザ操作が走ったかと思います。またインストールしたディレクトリの pic 以下に、検索結果のスクリーンショットが保存されているので確認してみてください。

せっかくなので、iOS でも動かしてみましょう。実機でも動かすことはできますが、サンプルではお手軽に iPhone Simulator で動くようになっています。Ruby に加え、事前に以下の環境を整えておいて下さい。

  • node.js v0.10以降
    • Xcode 4.6.3以降
    • command line tools
  • Appium 0.14.2以降
    • 手元では、npm から取れる CLI ではなくこちらの GUI 版を使っています

環境が整ったら、Appium を launch して、以下のコマンドを実行してみてください。うまくいけば iPhone Simulator が立ち上がって先ほどと同じ操作が行われると思います。スクリーンショットが pic 以下に保存されるのも Firefox の時と同様です。

さて、iOS で動かせたら、次は Android です。Android は実機で動かすハードルが低いので、サンプルでも実機をターゲットにしてあります。環境面では、Appium を利用していないので node.js や Xcode は不要です。代わりに、以下のものをセットアップしておいて下さい。

  • Android SDK
    • adb
  • android-webserver
  • adb install android-server-2.21.0.apk で対象の端末に apk をインストールしておいて下さい。

セットアップが終わったら、以下のコマンドで試せます。

以上のサンプルをベースとして、チームではよくテストするブラウザ操作を jenkins の「ビルド実行」をクリックすれば行えるようにしてあります。リグレッションテストで役立つのはもちろんですが、定期的に動かして監視ツールとしても使えます。(ただ、現実は端末が wifi をつかめずテスト失敗したりするので、監視ツールとしての運用は難しい部分も多いですが・・・。)

さて、ここまで試して頂けたらコードもあることですし説明することは実はあまりないのですが、最後にいくつかこの構成を選択した理由を挙げておきます。

1.feature ファイルが魅力的

以下はサンプルの spec/acceptance/firefox/google_search.feature の抜粋です。

どんなテストをしているのかひと目でわかると思います。そのため「このテストをこうして欲しい」といったコミュニケーションも簡単にとることができます。Gherkin をしっかりサポートできていそうなのは Ruby,Java,JavaScript,.NET でしたが、個人的な好みもあって RSpec + turnip を使っています。

ついでなので selenium-webdriver を使っている理由も簡単に説明しておきます。最初は driver に capybara を使っていたのですが、capybara が単に selenium-webdriver をラップしていたので、直接触ってしまって良いだろうということで selenium-webdriver を採用しました。特に capybara に不満があったというわけでもないのですが、こういうスクレイピングのような作業は繊細なので、うまく動かなかった場合に疑う対象は一つでも少ないほうが良いと考えました。

2.iOS, Android のブラウザをターゲットにできる

昨今はメインターゲットがスマートフォンだという場合が多いと思います。GREEもその例に漏れずスマートフォンからの利用が多いプロダクトなので、iOS 及び Android のブラウザからテストが行えるという点はかなり重要視していました。そういった意味では calabash でも良かったのですが、native アプリのサポートしかなく、iOS Safari ではテストできなさそうだということで使用をやめました。代わりに Appium を採用し、iOS でのテスト環境は当初想定したとおりに作ることができました。そのまま Appium で Android の環境も構築しようと考えましたが、chromedriver がデバイスの root を取らないと使えないということで見送り、代わりに端末に android-webserver を立てる形で対応しました。

雑感

少し脱線してしまいますが、色々やらせて頂いて学ぶことも多かったので雑感を書き連ねてみようと思います。

効果ある?

パピルスから紙に変えた効果を定量的に説明するのは難しいです。そして、テストを充実させるというのはそういう類の話だと思います。

また、開発に銀の弾丸はないとはよく言われますが、それ以前の問題としてテストは充実させるのは必要条件だと思います。

テスト書くと工数倍になる?

確かに書かなければならない行数は増えますが、TDD,BDD で開発する場合仕様やバグの確認を行いながら開発できるので、手戻りがなくかえって開発を早く行えるケースも珍しくないと思います。また、自身の書きたいコードを明文化しながら開発できるという点も大きなメリットで、これも開発効率を向上させる追い風になります。

逆に後追いでテストを書いていく場合、開発時の不安を思い出せないので大変です。

受け入れテストって難しい?

受け入れテストに使えるツールは本当に色々開発されているので、選ぶのが大変でした。またツールに一癖ある場合が多く、少し慣れが必要です。例えば対象ページのHTMLがうまく取得できず悩んだが、実際はページのレンダリングが終わらない内に要素を取得しにいっていたので、再試行する必要があった、などといった話です。こういう場合特にエラーを発したりしないのでこちらで原因にあたりをつけなければなりません。

方法論に関していえば、いわゆる普通のソフトウェアエンジニアの中でメジャーになっているものはあまりない印象ですが、かなり研究されており興味深かったです。一応調べた中ではハードウェアメーカーのテスト技法が面白かったです。HAYST法、CFD法、状態遷移図などを使えばより効率的にテストケースを洗い出せたかもしれません。またISTQB,JSTQB といったものもあるので、学んでみると面白そうです。

まとめ

抱えていた問題と対処策

  1. コードが読めない
    • 単体テストをドキュメントにする

      • (テスト対象関数名)_ Return(返り値) _When(条件) にした
  2. 受け入れテストに時間がかかる
    • 端末操作を自動化する

      • RSpec + turnip + selenium-webdriver + Appium を使った

なんだかまとまりのない記事になってしまいましたが、ひとつの事例として皆様の参考になれば幸いです。