「The Art Of Software Testing 3rd Edition」を読んだ。

The Art Of Software Testing 3rd Editionを読んだ。

翻訳がされている2版との、大きく差分になっている箇所を主に。その主に増えていたのは、Agileの話とモバイルの話。3版であるこの本は、2011年に出ているので、モバイルが流行りだした前後になるのでしょうか。

Agileは、Agile Manifestoや、XPの話が紙面を割いていたことが印象的でした。モバイルは、Connectivity、Diversity Devices、Device Constraint、Input Devices、Installation and maintainceといった特性から入り、実機などの話や挑戦的なところの話が含まれていた。

いずれも、私個人の経験としてはずれていない話だったのですんなり読むことができた。これは、なるべくは特にテスト界隈に触れる人たちには読んで欲しいものの1つですね。

XPの話がこのソフトウェアテストの話にもでるように、やっぱり技能としてはプログラミング能力の必要性は高いのだろうな。

「ソフトウェア・グローバリゼーション入門」を読んだ

ソフトウェア・グローバリゼーション入門  I18NとL10Nを理解する を読んだ。

2017/07/11現在のものです。まだβ版らしいですね。

I18NやL10Nから入り、G11Nへ続く入門としてとてもまとまっていて良かったです。
断片的に知っていることも、知らないことも含めて学ぶことができました。

ゲーム業界でよく言われるカルチュライゼーションや、翻訳コンテンツの品質の話、質を向上させるために どのような情報・コンテキストの共有が必要か といったこと。
また、ある有名企業における L10N をどのように 開発プロセスに組み込んでいるか と行ったちょっとした例も。

そのほか、よく誤りやすい日付や時刻の話もちゃんと記載されていました。他には文化的なものや、慣習(数字の数え方とか…)。

翻訳の質を評価する方法としてのAccuracy、Fluency、Terminology、Style、Design、Locale convention、Verityや、 エラー評価の体系的な参考の存在 など。

こういう分野は世界を見ると避けては通れないところである上に、膨大な知見が必要になるはずなので、この手の方向性を持つエンジニアは今後重宝されるのではなかろうか…

Continuous Localization系の、モバイルアプリに関するものは現段階で見当たらないので、何か作りたいですね。作れるかな…実際、こうなると最高という形は思い描けていても、それを実現するための技術的な制約が大きすぎる…

[Appium]Get invisible elements

uiautomator2 start supporting findInvisibleElement.
https://github.com/appium/appium-uiautomator2-server/issues/61

After the following method, you can get invisible elements from uiautomator2.

update_settings allowInvisibleElements: true

https://github.com/appium/ruby_lib/blob/cc913edb4bc24c18a58c2c5490dfb7b5a705d303/lib/appium_lib/common/command.rb#L46

「ソフトウェア要求のためのビジュアルモデル」を読んだ

ソフトウェア要求のためのビジュアルモデル を読んだ。

数年前の積読に目を通してみた。

この書籍は、RML(Requirements Modeling Language)(要求モデル)をどのように区分し、どう使えるかをまとめながら、要求をモデリングしていく手段を提供している。システム開発全体の中で、目標、人間、システム、データのそれぞれに焦点を当てながらモデリングする手段を整理している。様々な知見を有していると特別目新しいものは少ないが、それぞれに対して実際に例を提示しながら説明しているところがとても良いと感じた。

  • 目標
    • システムのビジネス価値に対して、要求とフィーチャーに優先順位をつける
      • ビジネス目標モデル
      • 目標チェーン
      • KPIモデル
      • フィーチャーツリー
      • 要求マッピングマトリクス
    • 目標空間の境界を定める
  • 人間
    • システムの利用者を、ビジネスモデルと目標とともに表現する
      • 組織図
      • プロセスフロー
      • ユースケース
      • 役割権限マトリクス
    • 人間空間の境界を定める
  • システム
    • ユーザインタフェースの外観、システムの相互作用やその振る舞いを表現する
      • エコシステムマップ
      • システムフロー
      • ユーザインタフェースフロー
      • 表示アクション応答モデル
      • デシジョンテーブル
      • デシジョンツリー
      • システムインターフェーステーブル
    • システム空間の境界を定める
  • データ
    • データのライフサイクルを表現し、様々なレポートとしてデータを使えるかを示す
      • ビジネスデータダイアグラム
      • データフローダイアグラム
      • データディクショナリ
      • 状態遷移表
      • 状態遷移図
      • レポートテーブル
    • データの空間の境界を定める

read “Beyond Software Architecture”

ビヨンド ソフトウェア アーキテクチャをずいぶん前に積読にしていたので読んだ。

読む前はシステムアーキテクチャの話だと思っていたのだけれど、フタを開けるとソフトウェア開発に関する全般を扱っていた。単にシステム開発に限った話ではなく、ソフトウェア開発する対象や、マーケット、人といった様々な要素に対するアーキテクト、つまり様々な構造にまでその話の範囲を広げていた。

ソフトウェア開発と人の関わりから始まり、ソフトウェア開発とマネジメントの話(ここには、プロダクト開発におけるコンセプト提案などの重要なところも書かれていた)に入りながら、だんだんとシステムによっていく。作るシステムのマーケティングの話やテクニカルな話。もう少し進むと、ログやセキィリティ、リリース、変更管理なども取り扱う。

このように、ソフトウェア開発においてシステム自身の狭義のアーキテクチャではなく、全般を扱っている内容となっていた。

そういえば、私は大学なんかでプロジェクトマネジメントを少し学んだり、話を多く聞かせてもらったのだけれど、こういう全般的な話を受けたなーと思いながら読んでいた。社会人になって、経験も多少積んで、その上で読むと頭の中を整理したり、そういえばこれも必要だったなと思い出すことができた。

最後に。この本で印象的だったことは、品質保証という役割が度々出て来たことと、その活動の範囲の広さをちゃんと説明しているところだった。

Read “Functional Programming: A PragPub Anthology”

Functional Programming: A PragPub Anthology を読んだ。まだβだったけれど、内容はだいぶまとまっててあとは微調整して発売という感じを受けた。

The Functional Paradigmから入り、Scala、Clojure、Elixir、Haskell、Swiftと関数型というテーマに絡めたそれぞれの言語の特性に触れながら話は進む。それらがひととおおり終わり、考え方を経験した後、Going Deeperということでそれらを再び題材に、より言語毎の特性、テスト(コード)の話、タイプシステム、The DCI architecture、そしてLuaと理解を深めていく。

この書籍をまるっと読むと、いくつかの言語から関数型言語、関数型な考え方に触れ、それらを学ぶことができる。さらには軽くそれらに触れることで、いわゆる写経もやりながら理解を深めることができるので、とっかかりとしても有用な内容だった。特に前半は、その言語に触れたことがある人からすると読み物的な内容に見えるので、考え方を整理するという形で触れることができると思う。

個人的にはElixirやSwift、Testing周りが関係が強いので、そこら辺は特に楽しむことができた。

例えば、ElixirやSwiftのProtocolの話。SwiftではProtocolはGlobalスコープに対して定義される一方で、Elixirでは特定の型に対して定義することができる。そのため、影響範囲を限定することができるのでより安全に利用することができるという話も。

テストの話としては、Elixir、Haskellが題材になっていてよかった。Elixirの話では、TrueStoryを題材にして、可読性の高い(テストしたいシナリオ・ストーリーを理解しやすい)テストコードの書き方に対しても言及している。その中で、パイプ演算子を使った関数型としての書き方に触れながら話を進めている。

Haskellでは、型システムのほか、C言語で書かれたコードをHaskellでラップしてテストコードを書いていく方法を載せている。ほかの言語をテストするためにHaskellを使う形は興味深かった。

やー。思いの外、Elixirに関する話が多かったのとHaskellを使った説明も多く、個人的にはそれだけで満足度が高かった。Haskellはがっつり触れたことはなく、考え方を学ぶために触れている側面が強いけれど、触れる機会が増えてきたらまたこの書籍でさっとHaskellは頭の中を整理したい気分。

Classification Treeの歴史

知らなかったので、メモ

[iOS]What’s new Testingを見た

What’s new Testingを見た。

https://developer.apple.com/videos/play/wwdc2017/409/

見ている途中でいくつかメモしたので、その記録として…


  • multiple appのテスト、URLを引数で与えることできるのね

20170612035154_img20170612-17-2kk0z7_480

  • Accessibility Dataのところで説明しているsnapshot、WebDriverAgentが使っているやつぽいな
  • おー。いちいちsnapshot取得する必要がなくなるのか。実行時間改善しそう

20170612035308_img20170612-16-1ng7xs0_720

20170612035501_img20170612-14-zvr8i3_720

  • 要素の検索で全捜査でなくて最初にマッチしたものだけさっと返すようにした、という話だけれど、ようやくという感じ。

20170612035637_img20170612-14-nebl01_480

  • ここら辺は元からそうなのでそうよねという感じだ。
  • ここはどこまで厳密に書くかはどれだけ内部実装と結合を強くするかの問題ですね。Espressoでも同じ問題をもつ。

20170612040244_img20170612-19-18xc35w_720

  • 地味に嬉しい

  • Activity styleの書き方、Cucmberとかイメージすると良さそう。stepsにいろんな処理を入れて、シナリオはstepsを並べて記述するような感じが使い方として近そうだ。

  • 非同期の奴も良さそう。XCTestなので、XCUITestでも使えるし。
  • snapshotのところはほんといろんな3rd partyも恩恵受けるだろうし、良いことづくしな気がする。けれど、これはXcode8でないと使えないOSテストするときは恩恵受けられないので、完全に恩恵を教授できるのは数年後かな…

Xcode9のいくつかの機能、Xcode9以前でも使えると恩恵大きくて良いな…

[ReactNative][Test]Detox instead of Appium

2017/06/08現在

過去、ReactNativeに対するUITestに関して書いていたのですが、今の段階ではAppiumよりはDetoxを使うほうが、JSを経由したテストツールとしては良さそう

EarlGreyも参考にしている所とかあり、より安定したUIテストを実施するには現実的な気がします。
Androidのサポートも計画されているので、必要に応じてコミットしたいですね。

参考: [ReactNative][Appium]testIDの振られ方

read “ZERO BUGS シリコンバレープログラマの教え”

ZERO BUGS シリコンバレープログラマの教えを読んだ。
タイトルと、その副題の高品質なコードを書くための物語というところですね。

エッセイ形式なので、全体を通して、物語を楽しむように読んでいきました。
わかる、あるある、なるほどなーというようなところが色々あり面白かったです。

「すべてのエラーは、あなたが最後にプログラムを変更した場所から3行以内にある」 by Joe Armstrong の引用。

ドナルド・クヌースの、ソースコードがドキュメントになるような文芸的プログラミング(literate programming)に対する考え方。

トランザクション処理のACID(Atomic, Consistency, Isolation, Durability)への言及。

人月の神話と、小さなチームならどんな方法論も上手くいくという話。これは、プログラマが習熟すれば、自分自身を実質的に管理できるようになるから。

Linuxカーネルのコードスタイルにある、それぞれの関数のすることは1つのことだけという姿勢。それとそのコードたちがPolymorphism、オブジェクト、関数型プログラミング、メッセージパッシングの全てをCで実現していること。

OpenBSD開発における、1箇所の修正に対して全体を見直すという、局所と全体の繰り返しのループ。

Erlangのモジュール同士のメッセージパッシングの形が、アラン・ケイがオブジェクト指向で表現したかったアイディアの理想形の1つであるという話。

などなど。

私の専門は品質/テストにあたる分野ですが、そのような立場の人も様々な領域を学ぶ必要があるのと同様、こういう話も知ってもらいたいですね。