こちらは「実践ソフトウェアエンジニアリング第9版 Advent Calendar 2021」、(だいぶ遅れましたが)13日目の記事です。書籍へのリンクはこちら(オーム社)。 私は本書の13章と21章の英語から日本語への粗訳を担当しました。これらは主にWebや移動体通信が関わる範囲の話でした。私の過去の経験が多分に重なる分野であり、照らし合わせながら訳を進めることができました。翻訳プロジェクトが本格化した時期と私の渡米が重なり、限られた時間しか翻訳に従事できませんでしたが、粗訳を他のメンバーが磨き上げてくれてとても立派な文章になったかと思います。 既に一読された方々は感じたかもしれませんが、特に移動体通信まわり(21章)は原文自体もまだ粗けづりな感じが他に比べて強いかと思います。これは原文自体も同様です。私の同分野における経験を照らし合わせても、今現在も変化している内容も多分に含まれるためこの荒削り感は否めないと感じたところでした。 一方、例えばWebで扱われた、議論された内容の多くが移動体通信の話で引用されたりと、これまで培われてきた内容が転用できる箇所も多いと感じるかもしれません。新しい表現や言葉も登場します。これらの中には英語に対する対訳としての適切な日本語が難しいところも多く、翻訳の難しさを感じたところも多くありました。教科書として利用されることも想定される書籍のため、十分に適切な日本語の対訳ではない場合、以降の世代にも影響を出してしまうというプレッシャーもありました。 現在、私は仕事として21章で言及されているような実際のユーザに近しい環境(国、地域、ネットワーク環境など含む)をいかに現実的な環境として提供し、テスト・計測・観測できるようにするか、性能計測やその結果分析を評価するサービスを開発します。その環境もあり、21章は挑戦内容含めて共感する場面が多くありました。いずれ、例えば21章で言及されているような現在の課題なども月日の経過とともに発展し、その先にある課題に取り組むことができる状況になっていくと良いと考えています。 それでは、また。More
Tag Archives: softwaretest
Read “Agile Testing Condensed”
I’ve read agile testing condensed. The book was in my reading list for a while, but picked it up recently to remember Agile Testing stuff. It was well summarized about agile testing that had been discussed. Whole team approach, automation strategy, guiding teams etc. They should be in our nature. I’d love to recommend this…More
A note about “Software Testing”
I read “Software Testing” by Ron Patton. The title is very generic, so I thought what the book’s main topic. The book is 2nd edition. The 1st was published in 2001. When I searched “Grey box” before, I met this book. I wanted to know what was the root about the word/concept of “Grey box”…More
Read [改訂新版]マインドマップから始めるソフトウェアテスト
I read [改訂新版]マインドマップから始めるソフトウェアテスト which is renewed software testing book. Ordinary, the was published in 2007. We never get new the book via Amazon etc recently even if it is very helpful for Test/QA engineers. Mindmap tools are very useful toolset to break our thought down and arrange them. I like it very much. I often…More
Read “Are Your Lights On?”
Are Your Lights On? by Gerald M Weinberg and Donald C Gause. I reread the book since he has gone. The book remembers us we must consider many things and perspectives whenever we face defects, etc. Through the book, below sentences probably stay in your brain. They will remain there. They help you when you…More
Taste mabl which provides ML-driven test automation service
Lately, ML related technologies step into industry section and many engineers challenge to integrate them into their services. The movement also comes into test/quality industry. I also have some ideas to use them though. A few weeks ago, I found a service which named mabl which provides ML-driven test automation service. The service run tests…More
[ML]Backtesting and Cross-validation
This article is a memo to me reading https://eng.uber.com/omphalos/ This article is a backtesting tool which used in Uber to validate ML related thing. I’m not sure some words and I’d like to memorise them in my brain. Thus, I’ve published this article. Back testing: https://en.wikipedia.org/wiki/Backtesting Backtesting is a term used in oceanography, meteorology and…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
[Erlang][Software Test]Property-based testing/QuickCheck Testing
I often see Property-based testing recently, and the following article is useful to understand what property-based testing and quick check testing is I’ve read for a few years. PropEr Testing http://propertesting.com/ I use QuickCheck testing in my work, and it works fine against functions especially stateless ones.More
Classification Treeの歴史
知らなかったので、メモMore