2017年 ~> 2018年に向けて

ちょうどクリスマスが終わったくらいだけれど。 2016年振り返りと2017年へ からはや1年。アラサーといっても、四捨五入が必要な歳になった。 2017年 昨年のやりたいことに書いていたSwift/Kotlin、海外との関わり付近は仕事の兼ね合いもあって前進中。そこに加えて、OSS関連は良い方向に向かっているようで良い年でした。私の専門性の源泉はテスト/品質よりなので、そこは今後も大きく離れないようにしたいなーという感じを持っています。 完全なプライベートはここでは書きませんが、全体としては楽しく/幸せな感じで進んでいるのでよかった。 会社関係 海外事業部にうつり、日本国外を対象としたサービスの開発にどっぷりになった UKのBristolに国外アプリの開発拠点があり、開発メンバの大半はそこか日本オフィスにいるリモートな環境 役回りはテスト/品質系エンジニアを継続して行っており、海外チームの中でもその手の役割を創っていく側になりました 類似の専門性を持った人がいない + 完全英語環境 もあって、やっぱり今までの経験を色々と手順を追って噛み砕きながら進める必要があり、挑戦的 英語を主とした開発にうつり、主言語として英語、もしくは第二外国語として英語、という形のコミュニケーションが増えた 異動当初は色々ともたついていましたが、最近はだいぶ全般的に改善できたと思う… 私の役回りとして必要とされる英語スキルにはまだまだ達していないので、特に表現周りや落ち着いて話して伝えるところを継続して訓練していこう OSS周り 昨年にAppiumのコアメンバに入り、そこからRubyだけではなくPythonクライアントをみたり、Appium自体へのコミットも増えた JavaScriptはそこまでがっつり触ったことはなかったので、NodeJS環境におけるJSを学びながら…という状態 Appium初期から開発されていたこともあり歴史的な複雑さも持ったruby_libをコアパートであるruby_lib_coreに分離して、最小限の機能を持ったところと分離させた。これのおかげでか、W3C対応とかも見通しが良い感じでクライアントの実装を修正できている。 こういったElectronアプリをちょっと創ったりして、面倒なところを減らせるようにもした https://github.com/KazuCocoa/appium-source-viewer OSS周りでは、知らない人からこういうOSSつくったんだよね、とか、Appium関連からちょっと先進的な取り組みのお誘いをもらったりするようになった ほか、細かなものはちょくちょく創ったりしていたかも そういえば、profileを作成するサービスあったのでやってみた https://github-profile-summary.com/user/KazuCocoa そのほかの活動 try!Swift 2017で話した この頃から、英語の発表の機会がちょっとできた ICSTへの参加や、ICSTの非公式meetupを開いてGooglerのかたとも直接色々お話できた link Selenium Committer Dayで話した 海外のテスト/品質系カンファレンスにCfPだした 今2つ出して、1つダメだった… そのほか 海外からもユーザ企業から直接的なオファーが届くようになった + 複数回の技術的なやりとり含んだ英語の面接もパスしたし良い経験がもてた LinkedInだったら今までももらっていたけれど、そうではない経路も出てきたのはびっくり Web記事を少し書いた link これからも少し書く予定 2018年 やりきること CookpadTechConf2018でちゃんと話きる 仕事で私と同様以上の専門性を持つ人を招き入れる(英語圏が主な対象ですが、ゴロゴロいそうなので) やりたいこと (願わくば)数個のテスト/品質系の海外カンファレンスで話す ちょっと考えているやつを形にしていきたいなー 私生活はもちろん大切にしたい そういえば、ElixirにProperty-based…More

[Appium][Android]Scrolling to an element

Just for my memo When we scroll views using Appium, then we have two ways to achieve it. 1: Use UiScrollable The below method is implemented in Ruby client. 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…More

“Designing Autonomous Teams and Services”を読んだ

元々はこれ => http://www.oreilly.com/programming/free/designing-autonomous-teams-and-services.csp ちょくちょくと、オライリーさんからこういった無料で購読できる、ちゃんとした内容のものが増えているように見えますね。こういうところで経験をまとめ、今後のビジネスにしていくという著者のスタイルとか一般化しているのでしょうか… この書籍を表現すると、複雑な課題に自律的に取り組める組織/サービスを作る、ということだろうか。（タイトルのまんま…） 実際に、この書籍は単に組織の話だけではなく、例えばBDDやユースケースをモデリングして管理する為のサンプルの提示なんかもしている。Microservice関係の書籍、Spotifyのエンジニアリング組織といったあたりの有名どころの情報に触れていない人にとっては、よくまとまった書籍という感じがします。 気になったところをかいつまんで以下に残しておく。あまり文章としてまとめる気持ちにならなかったので、今後の自分のポインタとして… どこに境界を引くかというところ To maximize autonomy and enable business agility, it is essential to align organizational and technical boundaries. 誰/何に自律的なところを期待するか これらを持っているチームの場合、より高い嬪度で良い連携を組むことができる。 Aligned autonomy—that is, a shared understanding of the company’s strategic context and key objectives Autonomy to make business and product decisions Autonomy to develop a rich understanding of user…More

[Appium]See the screenshots and source on offline after tests failing

Almost software engineers take a bunch of time to investigate the cause when automated tests fail. And they try to make sure whether the error is test code itself or product code. In the case, helpful error messages and additional information help us so much and save time for the investigation. In this article, I…More

Appiumのテスト失敗時の修正をちょっとわかりやすくする

こんばんは。Selenium/Appium Advent Calendar 2017の15日目の記事です。 多くのエンジニアの方々は、テスト失敗時の問題修正に時間を使っていることかと思います。それはテストコードの問題なのか、製品コードの問題なのか、はたまた別な問題なのか。 そのため、例えばテスト失敗時のエラー情報から、再度テストを実行することなく、どのように修正すれば治るのか、どうなおせば良いのかを教えてくれるとその時間を減らすことができますね。（これに似た話は色々と目にしますね） 今回は、Appiumを使った時の、そんな修正を便利にするちょっとしたアプリを共有します。 リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer テスト失敗時に取得する情報は何を取得する？ 多くの場合、Appiumのようなツールを使う人はテスト失敗時にテスト対象のスクリーンショットを取得するかと思います。また、人によっては動画を取得する場合もあるでしょう。Appiumに限らず、GUIが関係する場合は特に、そのような情報を失敗時の情報として取得するでしょう。 では、テストを修正する人はその情報を見ただけでどのように修正すればテストがOKになるか判断することができますか？ 表示されている文字だけを見ているのであれば修正できる可能性はあるでしょう。ただ、例えばAndroidだと resource-id 、iOSだと accessibility identifier を使うことが普通になっている場合は、スクリーンショットを取得したとしても該当しそうな箇所をその表示のみから追うのはキツいのではないでしょうか。ソースコードを確認し、再度繰り返し実行し、調整していくことも多いのではないでしょうか。 とても時間が勿体無いですね。 どこが失敗 し、 どう修正すべきか を教えてくれるテスト結果であれば、この時間は短縮でき、楽に問題を修正することができるでしょう。 Sourceも取得する どこが失敗 し、 どう修正すべきか を知る手段として、テスト失敗時の情報として page_source の情報は1つの役立ち情報でしょう。例えば以下な感じのXMLです。 GoogleのEspressoやEarlGreyはテスト失敗時にそのように画面のヒエラルキー情報を出力してくれますね。そのおかげで、修正者は要素がそもそもないのか、ある場合はどのような情報を付与するとそれを特定できるのか、はたまた別な要素である必要があるのかを判断することができます。(XCUITest自体は残念ながら取得できないです(できなかったですよね…?)) スクリーンショット x source sourceだけの場合、そのXML情報を想像できなければ結局は表示内容を確認することになるでしょう。 そこで役立つのがスクリーンショット。ただ、sourceとスクリーンショットを自分の目で照らし合わせることはそれはそれで慣れが必要です。 そんな時、例えばAppium-Desktopのようなツールを利用できたらどうでしょう？ 視覚的にスクリーンショットから該当するsourceの要素を確認できる ようになり、だいぶ問題を見つけることが楽になるのではないでしょうか。 オフライン x スクシーンショット x source 便利だろうということで作って見ました。Appium Desktopを参考に、オフラインで使える形にしてみました。 sourceのXMLを読み込み、任意の要素をクリックすると、該当する要素がハイライトされます。逆に、スクショの任意の要素をクリックすると、該当するsourceのXML要素がハイライトされます。 再度、リポジトリはこちら => https://github.com/KazuCocoa/appium-source-viewer これを用いると、 例えばAndroidだと resource-id 、iOSだと…More

Tips for UI/Scenario Tests: Recording screens and getting view hierarchy

When we run UI related tests, debugging failing test is one of the most difficult and need a bunch of time task. To make it easier, we usually take screenshot, capture videos and make error report helpful. Taking screenshot is very famous, and I skip it. Recording Android Android provide screenrecord command to record a…More

try reportportal

I tried reportportal to research awesome extensible reporting system. The framework provided by Docker and it’s very easy to try demo app via docker-composer… I know of Allure2 and it also awesome. The following is a capture image.More

「Building Evolutionary Architectures」を読んだ

Building Evolutionary Architectures: Support Constant Changeを読みました。 “Evolutionary”というものをどう表現しているのか、そのケーススタディを知ってみたいと思ったからです。 Evolutionaryとは、小さく変更をくわえながら、フィードバックループを回し、どのようにシステムを開発していくかを学ぶというところをいっているようです。その要素としてCI/CDの環境を作っていたり、例えばMicroservicesなどの話が出たり、チーム構成の話にも及んでいるところがあり、なかなか面白いものでした。チームの話だと、そういえば”Culture”という言葉も度々出てきたので、そういう環境づくり含めた全体の、文字通り”システム”（複雑系）を対象として設計するというものという印象を持ちました。 Fitness Functionと表現している、拡張していくような機能を対象に、その機能を壊さずに変化させていくか、というところでどのようなプラクティスがあるかとか書かれていました。そのように変化させていくことを”incremental change”というような表現を使ってたりします。Microservicesの文脈で度々目にするConsumer-Drivern Contractsの話も出ていました。この書籍を読んでいると、様々な小さなチームの責任範囲が重なる(もしくは重ならない)、システムの境目となるところを横断的な、例えば横断組織としてのテストチームがケアする、などにも言及していて、Consumer-Drivern Contractsが単なるツールの話ではなく、むしろそういう境目に対する話に絞っていたのはよかったです。（Pactガーというような言葉だけで終わらなかった） もちろん、そういうテスト/品質をみる人は各々の責任領域ベースでのチームにいたりしてるけれど、横断的な人の役割などを別途明言しているところがよかったですね。 Re-engineering Legacy Softwareなど読んでいると、色々なところで話が重なっているところが見えたりするかと思います。また、Servive Oriented ArchitecturesやEvent Driven Architectures、Service Based Architectures、Serverless Architecturesなどのツール側の設計の話もありました。これらの説明、システム間の関係、要素技術などを整理してたりします。ある程度知ってる人には良い要点整理になるかと思います。 Amazonの有名な2枚のビザの話もコラムにありました。 Each team is cross-functional, and they also embrace the philosophy of “you build it, you run it,” meaning each team has complete ownership of their service, including operationalizing it. ということをいっていて、それを最適化するような活動までを責任持つことを意味すると書いているところが個人的には好きだった。…More

[book]Read Chaos Engineering again

I read the Chaos Engineering again. This book also. And I chatted a little bit with one of my friends on the Twitter. So, I also put the conversations here. またChaos Engineering 読んでるけど、fault injection testing との違いも書いてたのね。イメージとしては、探索的テストに近い仕組みっぽい。 — KazuCocoa (@Kazu_cocoa) November 1, 2017 ICST 2016のIndustry TrackのNetflixの方の発表で"Chaos Engineering"が初耳でした。昔からFault injectionという用語はあったけど、彼らがFailure injection testingと呼ぶのは何かこだわりがあるのかな? — Keizo Tatsumi (@KeizoTatsumi) November 1,…More