ksfee blog

やっていき

「知識ゼロから学ぶソフトウェアテスト」を読んだ

ブログ全然書いてないので、これからは本を読んだ感想くらいから頑張って書いていきたい。

最近ソフトウェアテストについてやっていきがあるので、ガツガツと本をあさっています。

まだまだ初心者なので、初心者用にオススメされた「知識ゼロから学ぶソフトウェアテスト」を読んだ感想を少し書きます。

知識ゼロから学ぶソフトウェアテスト 【改訂版】

知識ゼロから学ぶソフトウェアテスト 【改訂版】

ソフトウェアテストの基礎の基礎の部分をうまくまとめているような内容だった。

おおよその内容はすでに知っている内容でだったけど、しっかりと言語化して説明されているものを読んだことがなかったため、改めて認識を確認することができた。

いくつか気になった点や初めて知った内容があったのでまとめてみた。

探索的テスト

Cem Kaner 氏がよって提言されたもので、本の中で定義されていた内容をそのまま記すと

  • ソフトウェアテストの1つのスタイルである
  • 個人に自由意志を持たせるとともに責任をより明確にする
  • 一個人のテスト活動である
  • 継続的にテスト活動を洗練させる
  • 探索的テストには以下の活動を行う
    • テスト関連の学習
    • テスト設計
    • テスト実行
    • テスト結果を報告
  • 成熟したテスト活動
  • 上記の活動をプロジェクト期間中並行して行う

らしい。

長い、要はテストをアジャイル的にやっていくことなのかなと理解した。

探索的テストは本の中で、プロとして成熟した一個人のテスト担当者に責任をもってやらせる！という記述があったが、自分はまだ プロとして成熟した一個人 ではない。

しかし個人的には、テスト初心者がこういった探索的テストのような活動を行っていくことで、ソフトウェア自体への理解 や ソフトウェアテストの学習 を得ることができる効率のいい方法なのではないかと思った。

ただ企業としてそういったことに対してコストを払うことができるかとか、その一個人に対してどのくらい投資をするのかなどを考えられるような場所じゃないと厳しいんだろうなとも思った。

非機能要求

非機能要求とは、品質特性を確保するためのものであり、品質特性とは機能的な側面と非機能的な側面の両方の属性を示したものであるらしい。かなりややこしい。

本の中では、「非機能要求のテスト = 品質特性をテストすること」となっていた。要はソフトウェアの機能面のみの話ではなく、ソフトウェアとして持っているべき特性について言及しているのかなという理解をした。

著者は多様な品質特性の中でも、機密性・信頼性・パフォーマンス の3つが重要と言っている。 重要なのは理解できるがこれらをテストすることは非常に難しいだろ、と思ったがすぐにそういった難しさについても言及されていた。やはり経験がものを言うのだろうか…

テストの自動化

私が読んだのは2013年改定版であるが、そのころのテスト自動化ツールがあまりよくないせいか、著者はテスト自動化についてかなり否定的な内容を述べている。

最近ではGUIソフトウェアに対してのテストを自動化するツールもたくさんあり、更にそれらはOSSとして公開されているものも多い。こういった状況を考えると、 テストの自動化環境においてはかなり改善されてきているのかなという印象をうけた。

自動化に向かないテスト として回帰テストが上げられており、その話の中で著者が経験した、「自動化のコードをただ修正していくのみでテストケースは一切増えない」という話をみて、少し自分も似てような経験があったので厳しい気持ちになった。

まとめ

文字の大きさも大きく、そこまで厚い本でもないためさっくりと読破できる量であった。

冒頭にも書いたが、内容は総じてソフトウェアテストについての概要知識だった。ただ、著者が今まで経験してきた事例を通して実際にどういった点で優劣があるのかということが少し具体的に書かれていたので非常に読みやすかった。

ソフトウェアテストエンジニアというよりは、ソフトウェアテストの担当者 を対象にした本であるため、コードを書く私のような人間からすると少し物足りないかなという印象だった。

ソフトウェアテストについてざっくりとした概念を学ぶ初心者にとっては、良い入門書となる気がした。

その他

ちょくちょく格言というか迷言のようなものが書かれているが個人的には好きだった。（大半は著者の言葉）

次

次はこれを読む

レガシーコード改善ガイド (Object Oriented SELECTION)

レガシーコード改善ガイド (Object Oriented SELECTION)

RealmObjectにLombokを使おうと思ったら死んでしまった話

久しぶりに書きます、またまたAndroidの話です。

さてネイティブアプリ自身にデータベースを持つアプリケーションは様々あると思います。

Androidでは標準でSQLiteがサポートされているのでこちらを使う方がほとんど？だと思います。 そんな中最近Realmというライブラリが注目を集めているようなので実際に使ってみました。

realm.io

※ちなみに今回の記事はRealmの紹介記事ではないので、紹介記事が見たい方は他の記事を参考にしてください。

使ってみて思ったこと

実際に使ってみて思ったこととしては簡単に使えるという印象でした。

コードを書き始めて間もなく、データベースがまったくわからないけどデータベースを使ってみたいと考えている初学者にとってはかなり使いやすく、開発スピードがとても速くなると思います。

逆に悪い点についてですが、それが今回の記事の中身だったりするので感想はこれくらいにして本題に入りたいと思います。

Lombokが使えない！！

きれいなコードを書くため冗長なコードはできるだけ避けることはみなさん意識していると思います。

Androidではそんな人達のためにLombokという素晴らしいライブラリが存在しており、精神衛生上良いコードを書くためにいつも使わせて頂いています。

projectlombok.org

※ちなみに今回はLombokの導入記事でもありません。

そしてやっと今回の本題の問題にぶつかるのですが、RealmObjectを

@Getter
public class User extends RealmObject {
    private int id;
    private String name;
}

という感じで記述するとエラーがでます。

error: Only getters and setters should be defined in model classes

このエラーを見た瞬間に「あ、察し」だったのですが調べてみると

[Feature Request] Project Lombok integration? · Issue #502 · realm/realm-java · GitHub

自分のksな英語力によるとどうやらLombokによる生成とうまく噛みあわせることができていないようです。

そもそもLombokはアノテーションを加えるだけで勝手にコードが生成されてしまうのは謎が多すぎるので少し調べてみました。

結果的にいうとLombokの機能としては

ということのようです。

まあそれだったら他のライブラリと組み合わせるのは難しいですよね...

しかし上記のissueを見てみるとどうやら開発者側もできたらいいねという感じでまだissueもopenしているので

もしかしたら今後対応するかもしれない...！

という淡い希望を抱いていきたいと思います。

参考

pixivインターンに行ってきた

8/31からの10日間、pixivのインターンに行ってきました。

f:id:ksfee:20150917173106j:plain

今回のインターンはスマートフォンアプリの開発がメインで、僕の開発は主にAndroidだったりするのでAndroidエンジニアとしての参加でした。

pixivのみなさんにはこのような始めたばかりのブログに体験談を書いてしまって大変申し訳ない気持ちでいっぱいです...。

pixivの雰囲気

まずはpixivどんなかんじだった？とか言われそうなのでしっかりと伝えたいと思います。

端的にいうと良さ！という感じです。これは決して脅されているから言っているとかそういうのではなくて心から思っていることです。

具体的にどういった良さがあるかというと以下のようなランキングです。

  1. みそしる
  2. 面白くて気さくな社員の方々
  3. 開放的なオフィス

突っ込みどころは満載ですが下から見ていきたいと思います。

開放的なオフィス

ブログ用などに写真を撮ることをまるっきり忘れていて微妙な写真でしか伝えられないのが残念ですが、pixivでは社員全員の顔を見渡せるような開放的なオフィスになっていました。

それがどうしたと思う人は多々いるかと思いますが、個人的に大規模な会社で社屋が分かれていたりすると社員同士が顔を合わせる機会が減ってしまい、少し冷たい印象を受けてしまいます。 pixivでは全体見渡すことができ、団結力というか集団意識が生まれて個人的にはかなりいいつくりだなと思いました(細かい)。

f:id:ksfee:20150917170003j:plain

面白くて気さくな社員の方々

pixivの社員さんは面白い人ばかりです！！

社会人の方々とあまり面識がないせいもあるのかもしれないですが、自分の中にある社会人というイメージよりもかなり柔らかいという印象でした。

pixivというサービスのコアユーザが10,20代ということもかなり関係していると思いますがとにかく発想が若い！www。

そんな社員の方とインターン中に様々なことについてお話することができ、ただ面白かっただけではなく、今後の糧となるようなことばかりでした。人の話を聞くのはやっぱり大事ですねー。

みそしる

一人暮らしでかなり不足がちな大豆成分...。

そんな一人暮らしへ送る1杯のみそしる、すばらしいですね。

要はオフィスでみそしるが飲めたって話です、飲み過ぎて塩分かなり摂り過ぎたと思います。ちゃんと運動して汗流したいです。

なぜ参加したのか

じゃあなんで参加したのという

元々大学をでたら院進せずに速攻で就職してやろうと考えており、「いまのうちからインターン行くと面白いんじゃね？」というてきとうな考えのもとインターンを探し始めました。

そんな中とある某ようじょ先輩からpixivのインターンが非常に良いというお話をいただき詳しく調べてみることにしました。調べてみたところ以下のメリットがあることがわかりました。

  • 10日間という限られた中で1つのプロダクトをつくることができる
  • 自分はアニオタである

まず1点目に関してですが、他社のインターンを見てみるとかなりの割合で自社のサービスを実際に開発してもらうという形式が多いという印象がありました(個人の感想です)。そんな中、今回のpixivのようなインターンは珍しく、目を引くきっかけとなりました。

2点目に関しては正直もう言うことはないと思います。pixivは一種の聖地なんじゃとか考えてます。

なにしたの

今回のインターンは1日x回は起動したくなるアプリと創作活動を盛り上げるという課題でのアプリ開発でした。

アイデアの考え方から企画のブレスト、仕様定義、実装、ドッグフーディング、そしてプロトタイプを用いての発表会というようなアプリ開発の一連の流れをしっかりとさせていただきました！

なにか期間内でプロダクトをつくるようなインターンであると10日間よりももっと少ない期間でこの流れをかなりふっ飛ばしてのものならあると思いますが、ここまで流れをしっかりと舐めることができるのはpixivの特徴かと思います。

チームで開発したアプリは惜しくも優勝を逃してしまいましたが、他のチームと比べてクオリティは1番良かったんじゃないかと自負しています。普通プロトタイプでまでチュートリアルを用意するアホはいません。

とにかく激しい開発であったことは間違いないです。

しょうじき苦労したところ

それでもなんとかアプリの題材も決めることもでき、仕様定義を決めている時に事件は起こりました。 限られた期間内で実装できる量は有限です、そういった中でこれは本当にコアな部分なのかという話で意見が強く衝突しました。普段からチームの開発メンバーと言い合い(争いではない)をしている自分にとっては慣れていることで特に紀にしていなかったのですが、かなり自分の自己主張が強く、他のチームメンバーの意見をかなり潰してしまいました。

普段から自分から意見をがつがつぶつけていかないと生きていけない環境(決してそんなことはない)にいたので自分から相手の意見を吸い出すようなことはまったく意識していなかったので、非常に驚き、またいい経験になりました。

仕様定義で十分にぶつかったおかげか実装段階ではあまり困ったことになることはなく、至って順調な開発となりました。ただ、タスクの量ははんぱなかったと思います。

実際の開発はどうだったの

アプリの概要としては全画面で通信処理が発生するようなものだったので、いかに非同期処理を淡々と書いていくかを考えながらつくっていました。

今回のアプリでは無難にRetrofitとRxJavaを使っていきました。また各モジュールで作業を分けて開発はしましたが、チームメンバーがあまり通信周りを書いたことがないとのことだったので通信処理は全て請け負い、とにかく開発のスピードを上げることを重視しました。

あとやっぱりカメラアプリは闇ですね...。

ちらっとですが今回つくったアプリ載せときます。

f:id:ksfee:20150917235401p:plain

まなびあること

今回のインターン中でのまなびとして簡単にいうと技術面のまなびはあまりありませんでした。それは当然のことのように思えるので技術的なまなびを求める人は実際の業務に入るタイプのインターンへ参加するのをおすすめします。

じゃあ何をまなんだんだという話なんですが、今回のまなびとしてはプロジェクトの立ち上げとはというものすごく意識高い分野についてが1番大きかったなと思います。

自分がいままで関わってきたプロジェクトのことを考えた際に、自分が立ち上げの段階で1から関わっているものは0でした。かなり早期の段階で入ったものはありますが大元の案はすでにあり、それを発展させていくというものばかりでした。

そういった経緯から今回のインターンでの経験は非常にためになりました。非エンジニア職である総合職とデザイナーとのやりとり、課題の内容にも沿いつつ会社としてのプロダクトである以上収益も考えなければいけないなど、もろもろの内容を全て加味しつつ、企画を1からできたというのはこれからエンジニアとして生きていくうえでかなり重要な経験であったと思います。

まとめ

かなりだらだらと書いてしまいましたが、最終的にまとめると最高の10日間だったということです！

とてつもなく文才が無いのでひどい文章になっていますが、「ここはどうだったんだよ？」的なお話はがんがん聞いて欲しいのでリアルな知り合いの方は頑張ってコンタクトを取ってください。

最後に10日間自分の業務があるにも関わらず面倒を見てくださったメンターのみなさん、またメンターとしてではなくてもアドバイスや楽しいお話をしてくださったpixiv社員のみなさんには大変感謝しています。

このような貴重な体験をさせていただきありがとうございました！！

PercentSupportLibrary使ってみた

ブログを作ってからずっと書いていませんでしたがこれからはちゃんと書いて行きます。

PercentSupportLibraryとは

よくCSSとかでwidth: 100%的なことをする気がしますが、Androidのlayoutでもそれを可能にしたSupport Libraryです（てきとう。

Androidで割合を上のような割合でlayoutを表現する場合LinearLayoutのweightを使うかと思いますが、今回はFrameLayoutとRelativeLayoutでそれがpercentつかえるようになったよ！的な内容です。他にも良い所があると思うのですが、よくわかってないので誰か指摘していただきたいです。

にわか程度に使ってみたので軽く紹介したいと思います。

開発環境はAndroidStudio(v1.3.2)を使用しています。

使い方

build.gradleに以下を追加してください。

dependencies {
    compile 'com.android.support:percent:23.0.0'
}

Percent LayoutではPercentFrameLayoutとPercentRelativeLayoutがあります。

今回はPercentRelativeLayoutだけ紹介したいと思います。

使い方は簡単で以下の様な感じです。

<?xml version="1.0" encoding="utf-8"?>
<android.support.percent.PercentRelativeLayout
    xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:gravity="center_vertical">

    <TextView
        android:id="@+id/text"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_alignParentTop="true"
        android:layout_centerHorizontal="true"
        android:text="Title"/>

    <ImageView
        android:id="@+id/image"
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:layout_below="@id/text"
        android:layout_centerHorizontal="true"
        android:src="@mipmap/ic_launcher"
        app:layout_widthPercent="80%"
        app:layout_heightPercent="50%"/>

    <Button
        android:id="@+id/button"
        android:layout_width="0dp"
        android:layout_height="wrap_content"
        android:layout_below="@id/image"
        android:layout_centerHorizontal="true"
        android:text="Submit"
        app:layout_widthPercent="70%"/>


</android.support.percent.PercentRelativeLayout>

↑の例は例とは言えない気がしますが、割合を100%に抑えれば端末によってlayoutがksになるなんてことはなくなるという感じです。

実際に動かすとこんな感じになります。

f:id:ksfee:20150915185726p:plain

まとめ

RelativeLayoutで割合が使えるとかなりlayoutのバリエーションが広がる気がするのでこれからがっつり使っていけたらと思います。

この間のインターンに言った時に初めて使ったんですがかなり良いです。

あ、インターンの記事は後で書きます。

参考URL