Author Archives: KazuCocoa

[Android][Accessibility]accessibility check in Espresso

Androidでは、以下のようにしているといくつかのAccessibilityCheckをEspresso実行時にViewに対してチェックしてくれます。 View要素に対するチェックはこれ https://github.com/google/Accessibility-Test-Framework-for-Android/blob/dafd7ed63daff45dba53c49c893ea9f84af4a942/src/main/java/com/google/android/apps/common/testing/accessibility/framework/AccessibilityCheckPreset.java#L58 accessibilityの付加情報に関してはこれ https://github.com/google/Accessibility-Test-Framework-for-Android/blob/dafd7ed63daff45dba53c49c893ea9f84af4a942/src/main/java/com/google/android/apps/common/testing/accessibility/framework/AccessibilityCheckPreset.java#L101 公式サイト https://google.github.io/android-testing-support-library/docs/accesibility-checking/ accessibility checkのGitHub https://github.com/google/Accessibility-Test-Framework-for-Android これに似た機能をEarlGreyでも実現してほしいというissueが立ってました。 – https://github.com/google/EarlGrey/issues/393 ここら辺をうまく拡張していくと、自分たちの組織におけるViewなどのチェックを拡充していくことができるのでないかなーと期待。More

[React][iOS][Android]Try ReactNative + TypeScript

以下を参考に、ReactNative + TypeScriptでアプリを書いてみる。 ReactNativeでは testID としてiOSはaccessibilityIdentifier、AndroidはView#setTag/getTagが使われている。(ただ、2016/9ごろにAndroidに対してresource idを付与できるようになったとあったので、ReactNativeでもresource idベースでも今後は大丈夫かも) 以下を参考にした。環境構築周り。 https://medium.com/react-weekly/react-native-and-typescript-ad57b7413ead#.el446eisr https://github.com/mrpatiwi/ReactNativeTS https://medium.com/react-weekly/react-native-and-typescript-ad57b7413ead#.3cdqtxsr2 https://github.com/KazuCocoa/MyFirstReactNativeTS ただ、上記のどれもそのままでは動作しなかったので、本格的にはまだ触っていない。More

「消極性デザイン宣言」を読んで、approchiabilityという言葉を知った

「消極性デザイン宣言-消極的な人よ、声を上げよ。……いや、上げなくてよい。」を読みました。 シャイハック。 私自身、ここに書かれていたように消極的な人間で、V字タイプな人。少人数や大人数だとある程度大丈夫だけれど、微妙な人数になると「・・・」となるような。 そんな人たちのコミュニケーションの話から入り、だんだんとモチベーション、インタラクションの話へと内容が移ってきます。個人的に面白かったのは、approchiabilityという考え方と、モチベーションの話。ここのモチベーションはやる気を出していく話ではなく、やる気がわかないことを前提とした(意識の低い)モチベーションの話なので、疲れず良かったです。 人間は基本的には消極的 これが基本的な立ち位置でした。消極的なので、自然にできるようにどうデザインするかとか、そういう話になってきます。 機能があることではなく、”機能する”こと、その機能を使おうとしやすいことなど。 Usability と Approachability Usabilityは使いやすさとしてよく言われます。品質の話になるときや、人間工学の話、デザインの話といったように様々なところで出てきます。一方、Approachabilityという言葉は私が把握している限りでは初耳でした。 Usabilityとの対比としては、Usabilityが製品/サービスそのものの使いやすさを評価の対象とするのに対して、Approachiablityは対象となる製品/サービスがどれだけ”使おうとしやすいか”を評価しようとしている、という感じ。なので、製品/サービスのその周辺から連続した出来事を評価の対象に加えるという感じでしょうか。モバイル端末などの使いやすさとしてはこういった連続性に言及しているものもちらほら見ますが、そこに焦点を当てたものがこの”Approachiablity”という感覚を受けました。 使おうとしやすさ、行為の切り替え・接続、やめやすさ、いかに無理せず自然とできるか。 特別ではなく日常に溶け込む系のサービスとか製品ではこういう考え方って大事なデザインの話になりそうですね。 そういえば、インタラクションデザインにも言及していて、その中であったモチベーションの設計は色々なところで関係しそうな感じがしました。 締め こういう書籍は時折読みますが、Approchiabilityという言葉の定義はなかなか良い発見でした。More

[ReactNative][Appium]testIDの振られ方

ReactNativeだと、 testID としてiOSだとaccessibilityID、Androidだとview tagを使ってIDを埋め込むのですね。なので、ReactNativeのアプリに対してidで要素を検索したい場合はAndroidだと特に従来のAppiumやEspressoとは少し異なる。 Appiumだと、以下でview tagの取得をサポートするらしい。 https://github.com/appium/appium/issues/6025 これつくと、resource idが同じ要素も細かくidを振って操作することもできるようになるので、安定性向上に寄与しそうですね。 Does EarlGrey support finding react-native elements? https://github.com/google/EarlGrey/blob/master/docs/faq.md react native https://facebook.github.io/react-native/docs/accessibility.htmlMore

2016年振り返りと2017年へ

2015年振り返りと2016年へ ~20代も最後~からもう1年たったのですね。30歳ですかー。 今年の活動を簡単に振り返る。2017年のことも、最後に。来年振り返る時にちゃんと達成できているとよいな。 全体 今年は私の中ではOSS周辺の活動が大きく動いた気がします。あとは機械学習系とかも今後テストでは標準的なスキルになるはずなのでそこらへんを学んだり… 振り返り 仕事(Works) 引き続き社内ではテストエンジニアというロール名で活動中 引き続きモバイルアプリのテスト周辺や他チームの(主に)テストに関する色々な支援 開発プロセス改善、Choreography的な関わりの中でのチームビルディング、retrospectiveなどの継続したサイクルを深化させること 社内アプリ開発とか 海外チームの支援 会社Blogで社内で使ってたモバイルアプリ開発で用いているテストサイズなどの話を書いた http://techlife.cookpad.com/entry/2016/03/02/083000 http://techlife.cookpad.com/entry/2016/08/13/test-size-for-mobile Elixirの話も書きましたよ http://techlife.cookpad.com/entry/2016/08/19/170726 活動(Activity) 発表系 2015年はJaSSTなんかに積極的に募集したのですが、今年は少し異なる方面の活動をしていました。人のキャリアプランに影響を及ぼしているという話も耳にし始めました。 デブサミ2016での発表を経験した JaSST’16 Tokyoでのパネルディスカッション toteka04 Cookpad Tech Kitchen, English Test Engineer Meetup#1 toRuby Closed meetup at Money Forward (Regarding with Elixir) OSS系 一番大きかったのはAppiumのRuby bindingのメンテナになったことでしょうか。他には言語ではElixir、Ruby、Swift(Objective-C)、Java周りで既存OSSにPR投げたりOSS公開したりしました。今の会社に入って、会社がOSSを推奨するのでOSSに対する活動を広げてきましたが、ここにきて世界的に使われているツールのライブラリメンテナになるとは思ってもなかった… AppiumのRuby bindingnのメンテナになった https://github.com/appium/ruby_lib , https://github.com/appium/ruby_console Slackにも参加しているので、時折Slack上でサポートしたりもします 公開したもの DroidTestHelper Androidのflakyなテストを支援するライブラリ。これを出したあとにLinkedInからtest-butlerとか公開されたが、いくつかは類似機能をもつ https://github.com/KazuCocoa/DroidTestHelper anticuado 対象となるプロジェクトのoutdatedなライブラリをHash形式で整形されたものを取得可能なライブラリ…More

[Elm]getting start Elm language

Elm is a functional language that compiles to JavaScript GitHub : https://github.com/elm-lang 知ってはいたのですが触っていなかったElm。少しきっかけがあったので触ってみました。 ※Elmについて、といった内容はここでは触れません。 この理由としては、チームメンバの1人がSwiftでとある機能を実装している時にこのElm Architectureから構成をインスパイアされたといっていたためです。といっても、Elm Architecture付近をチュートリアルを元に学んでみたというくらい。なので記法を学ぶというよりは、どんな問題を解決しようとどういう設計を行ったか、です。(そういえば、このElm->JSのコンパイラはHaskell製) 試したElmは0.18.0 tutorial(guide): https://guide.elm-lang.org/ tutorialをいくつか実際に動かしたGitHub repository: https://github.com/KazuCocoa/my_first_elm Elm、実行環境も elm-repl コマンドでターミナル上から簡単に動作みることできるし、 elm-reactor コマンド実行するとローカルホストにブラウザでアクセスするとすぐに動作みることができるので触ってみる障壁がとても低くて感動しました。ドキュメンテーションとか、コミュニティパッケージ群も揃っていました。テストツールとかも、パッケージとしていくつも既に存在しているみたいです。 http://package.elm-lang.org/help/documentation-format http://package.elm-lang.org/ Elixirをもともと触っていると感じたのですが、なかなかElixirと似通ったものがありました。類似言語に影響を受けているっぽいので文法的なところもなのですが、 One crucial detail here is that commands and subscriptions are data と書いていたり、 Elm treats errors as data とあるように、データの流れを基軸として表現しようとしているところです。 では、かいつまんで。 Architecture https://guide.elm-lang.org/architecture/ Elmの実装設計パターンは画面の操作を以下のように3つに分割してデータを記述するところ、データを更新するところ、それをViewに反映するところ、で分けるところです。これにより、基本的なボタンをタップするとか、そういうことに対してデータを受け取り、更新し、Viewに反映するという一定の操作を決まった定型文によって区切りながら実装することができるようになっています。 Model —…More

[Elixir]What’s new in Ecto2.0

Elixirの開発元であるPlatformatecからEcto2.0に関するフリーペーパーが正式に公開された。 Click to access whats-new-in-ecto-2-0-1.pdf いくつかEctoの特性(Ecto is not your ORMといったこととか)が書かれていて、解決したい問題とその対策として2.0や2.1で入ったことを書いている。 1つ、気になったところをメモとして残しておく。 Ecto2.1からdynamicを使って簡易に動的にwhere句を制御することができるようになった。コードは以下。 https://github.com/elixir-ecto/ecto/blob/v2.1.1/lib/ecto/query.ex#L381 例えば、以下の場合は dynamic で指定した箇所をその引数の状態によって動的に切り替えることができる。 (http://blog.plataformatec.com.br/wp-content/uploads/2016/12/whats-new-in-ecto-2-0-1.pdf より) This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode…More

2016年に新たに読んだ書籍群を振り返って

昨年の 2015年に新たに読んだ書籍群を振り返って に続き、読んでBlogに書いたものをピックアップ。 昨年と比較すると、読んだ書籍の本数は減った。これは翻訳だったり発表、OSSメンテといったことに手を出していることもあり、時間の傾け方が変わった感じ。あと、有名どころは読み終えて大体は新しい書籍中心になったからというのもありそう。ただ、Webの記事やプログラミング言語でも書籍を元にしないものをトライする量も増えてきたので、入力の量は案外どっこいどっこいなのかもしれない。 よかったものは★をつける。 programming language Erlang [Erlang]Dive into Designing for Scalability with Erlang/OTP★ Development 「レガシーソフトウェアー改善ガイド」を読んだ★ 『アジャイルの魂2015 アジャイル開発者18人の物語』を読んだ Keep Agility with Rapid Deployment★ 『チームが機能するとはどういうことか』を読んだ read “オブジェクト指向入門 第2版 原則・コンセプト”★ Software Test / Organization 『ソフトウェアの欠陥予防 テストより確実な品質改善法』を読んだ★ 『Mobile Testing Interview Questions & Answers』を読んだけれど、これは入り口向け 『ヒューマンエラー 完訳版』を読んだ ~ これが否応のない人生の現実である ~★ Reading “Mobile Application Penetration Testing” and dive into it…More

「レガシーソフトウェアー改善ガイド」を読んだ

レガシーソフトウェア改善ガイドを読みました。英語では “Re-Enginnering Legacy Software” なので、”改善ガイド”とするには少し内容とタイトルに乖離があるかもしれないですね。 この書籍は、最近のアーキテクチャ(モノリシック/SOA/Microservices)や言語特性の変化、CI/CD環境など含め最近の流れを踏襲した上でレガシーソフトウェアを継続してより改善できる形にするためのtipsが書かれています。そのため、開発環境/スタイル/設計などを含んだ全体的な改善の話が書かれていました。レガシーコード改善ガイドをベースとすると、テストできない、継続して機能を壊さず改善することが困難なソフトウェアがレガシーなものになります。 ソフトウェア開発においてしばしば言われるように、コードがレガシーとなる原因の多くは人に関係します。それは例えばサービス開発におけるサービスの成長フェーズに対するビジネスの要求に応えるためのものだったりとします。そのため、レガシーに見えるものも実はサービス開発を試行錯誤しながら行い、成長した結果と言える面もあるかと思います。(ここは組織の力に依存しそうですが) この書籍の中で、コード品質の指標として欠陥密度に対する言及があります。それがCoverityによる2012年のLinuxカーネルの静的解析において、コード1000行あたりの欠陥密度(defect density)が0.66/klocであるというところでした。これは純粋に興味深い内容でした。OSSとして多くの意見が入る可能性の高い成果物が、高品質なコードであると示される珍しいものではないでしょうか。そしてそれを支える為に重視しているものがコードレビュー。これにより、低品質なコードの混入を防ぐ、知識の共有とそれらのサポートといった保守も含めた知見を共有しているとあります。 開発の中では心理的な障壁は最善の仕事を効率よく行うことを妨げます。この中に”恐れ”があります。この恐れは未知なものに対峙するときに顕著になため、未知な領域(コード)に足を踏み入れながら、未知を克服していくことが必要となってきます。このような未知を克服しながら進むことを”調査的リファクタリング”(exploratory refactoring)と呼んでいました。 Exploratory Testingが探索的テストと呼ばれる一方、こちらは調査的と表現しているのですが英語をベースとするとどちらも似たようなことをしながら”中身を理解し明らかにしていく”ことを達成しようとしているのですね。 ちなみに、これらを補助するためのツールなども書かれています。 理想のシステムは、コードの品質を開発者の努力なしに自動的に監視し、その情報をチームメンバ全員が利用できるようにするもの。意識しない、努力しないというのは大事で、それが系として組み込まれている状態を指します。やはり意識によって改善するには人は確率的に誤りをおかしすぎてしまいますからね。 そういえばミカドメソッドの話が出てました。これは修正したい対象の周辺をグラフに落としていって、見通しをよくした上で優先順位を定めて取り組むというものです。言及されるとは思いませんでした。 あとはmutableなものをimmutableにしていくところも言及されていました。これは最近の関数型言語に対する風潮もありますね。これは複雑奇怪なビジネスロジックをテスト可能にし、確認可能な状態で単純化することに貢献する説明の箇所で出てきています。 当然、テストの自動化にも言及していました。単体テストを自動化することに対しては誰もが納得することだろうという前提のもと。私もここ数年でモバイルアプリの領域でやってきたことなのですが、 とくに自動化を必要とするのがUIテストの領域 と書かれています。ここがちゃんとできているところはおそらくできていないところに比べて多くの利益を享受しています。不具合の見つからないごく一部の自動化されたUIテストではなく、不具合をちゃんと見つけてくれる多数の自動化されたUIテスト。個人的に、それは特にGUIが差別的な要素になる可能性の大きな特にモバイルアプリの領域では差が出てくるところだと考えています。(ここら辺は今度機会があるのでそこで話すかもしれません) 英語ではこれらのように書かれています。 – Unit tests are not a silver bullet. – One area that cries out for automation is UI testing. (4.3.2. Regression testing without unit tests) 他に面白かったところは、Webアプリのアーキテクチャの話でモノリス/SOA/Microservicesなどを比較しているところでした。特に、組織面での利点まで言及していたところが個人的には好印象でした。アーキテクチャはやはり組織に影響を及ぼしあうので。その中で、やはり情報伝達はモノリスがオーバーヘッドが小さく、個々の独立性が高まると従来の情報伝達はオーバーヘッドが大きくなるところが印象的。(いっていること自体は至極真っ当) まとめ 主な対象はWebサーバアプリでしたが、これはモバイルアプリにも多く転用できるものでした。実際、私がモバイルの領域でやっていたものはこの書籍における改善案の方針として言及されているものが多かったです。 refactoring/rewriteしながら継続して価値を出しているサービスをより継続して開発し続けることができるように取り組んでいきたいですね。More