Author Archives: KazuCocoa

[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

“Humans vs Computers” has educational case studies

I had read Humans vs Computers. This book has a bunch of stories against bugs, how bugs affect humans, humans how embedded bugs in computers. Various case studies help you understand what happens if developers embedded bugs into the real-world computers. Thus, you can learn them in one book. So, I describe this book as…More