TestonoBlog

Softwaretest,QA

DeNA QA night 招待講演のメモ

こんにちは、とのの(@tonono2587)です。
2018/11/27に参加した勉強会メモをいまさら(ほんとうにいまさらですが)振り返ってまとめておこうと思いました。

今回のテーマ:DeNA QA night に参加しました

参加したイベントはこちらです。
dena-qa-night.connpass.com

セッション概要にある、

品質の対象の変化とその手段であるテストにどんな変化が生じ,どこへ向かっているのかについて

キャリアについて考えていたこともあり、興味がある内容だったためお話を聴きに行きました!
|´・_・`)。oO(以下、必死にとったメモベースなのでお話そのままではないことご了承ください。)

招待講演「テストの広さと深さ,どっちが大事?」松尾谷 徹さん(デバック工学研究所)

概要

  • 市場の変化、技術の変化がある
  • それにともないQA Peopleは分岐
    →QA難民
    →Contoributer(コントリビューター):○こうなりたい
    どうしたらContoributerとして繁栄できるのか?

  • 誰に対する品質?

  • どんな品質特性?
    相手側が「社会」になってきて、
    社会に対する品質を考えなければならなくなってきた
    現在のサービスはそのくらい大きく影響している

  • それをどうやって測る?

  • どうやったらどんな変化をする?
  • 大きな流れを読む

Analysis:虫の目、細かい
Synthesis:鳥の目、ひろく←これからはこちらが広がっていく

  • どんな心意気で何を学ぶのか
    古いものは残念ながら捨てないといけない

市場の変化からみる

■これまでの流れ

□IT大昔(バブル期まで)

  • ハードウェアを売ろうとしたけど、ソフトが難しいのでなかなか売れない
  • そこで多くの企業は組織/企業活動の合理化をすすめた
  • ハードウェアの検査部門の人たちが中心となって、ソフトウェアの品質をみていた
  • たとえば I○Mとかは、品質管理部は「品質が悪いから」ではなく、社内を監視するために存在していた意味が強い
  • このころ本格的なアプリケーションのテストはあまりなかった

IT大昔の市場構造は、汎用機メーカーが主なプレーヤーだった

□ITちょっと昔(サブプライムまで)

  • カーナビやケータイなどの組み込み系ビジネスが増えてきた
  • そこからだんだんWeb系へ:ホームページみたいな小さなものから、Amazonみたいな大きなものへ
  • 汎用機ビジネスが終わり、水平分散してく
  • Web系の新ビジネス
    急激な成長、裾野の拡大

  • このころの品質管理は、
    負け犬の遠吠え
    品質工学で成功したところはひとつもない
    「正しい」ってなんだろう?
    それをどう評価するか???
    大事なことなどはあとからいろいろ言われているが、うまくいってなかった

□現代

  • 提供側と消費側(お客さん)
  • 消費側が「このサービスを使う人」くらいの狭さから、スマホをつかうひと、のように広く大きく、「社会」になっていっている
  • プロダクトとしてのソフトウェアは終末状態
    単独のソフトウェアをつくってもビジネスにはならない
  • OSSの拡大
    企業の開発戦略が背後にあり、開発していく
    マネタイズの戦略変化
    →知識をどのようにしてお金に変換していくか?になっている
    単独のソフトウェアでは、要求に応えられない
    オープンソースをつかおうとおもったら、自分もオープンソースにならないといけない
  • サービス型ビジネスの繁栄が桁違い
    GAFAによる世界制覇

  • ソフトウェアマネタイズが変化したので、
    品質のパトロンはだれ??
    G○○gleってなに業なの???
    どんどん自転車操業しないともたない時代

技術の変化からみる

■「良否の判断」をなんらかの形で判断しないといけない

  • いままでは、正解は仕様書だった
  • もうサービスには仕様はない。考えていかないといけない
  • 過去、テストの実態は仕様記述だった!
    禁則
    ただし、大多数は「無則」。ここがどんどん増えてきた
    いまはそれが「無害」であることも考えないといけない

■良否の判断における多様な課題

  • 社会や文化に対する品質
    なにが有則、禁則、無則 か?
  • OSSに対する品質
    バグがあっても、使う側の禁則で回避する
  • システムの稼働品質

QA難民にならないためには??

Contoribution がキーワード

  • 評価自身もオープンにして、どのくらいContributeしているか
  • みんなで公平に働こう、という時代ではなくなってきた
  • 日本人は持続的に何かをすることに長けている
    なんでこんなに貢献できたか?
  • 映画の配給とかと一緒で、多くは「べき分布」になっている
    売上はものすごいけど、殆どが上位5つ、とか

お話のまとめ

  • headに対するContributionとしてのQA活動をしてく
    head⇔tail
  • 一夜にしてサービスを崩壊させるリスク対策
  • 過去の価値観は捨てる
    捨てる代表は規範やプロセス定義
  • たくさんの対象がべき分布
  • メンタリティとしての推進力はFlow!
    ポジティブ心理学
    ワーク・エンゲイジメント
  • (ISOとか、品質特性について)いままでにある枠組みでは、いまある規範、定義では測れない
    なので捨てる
    現実のものからはかったほうがいい
  • 全体をみる鳥の目が要る
  • 当たるものをサポートする問題、ハズレを抑える問題に
  • プロダクトの品質は、「品質」の概念が変わってきた
  • 情報やサービスの品質は、
    お客さんへの品質保証
    安定供給:インフラとしてのクオリティ
    社会や文化に対する品質

感想

個人的には、「品質の対象が変化している」ことがわかりやすかったです。
その変化を前提として、「合わないものは捨てる」という話はスッキリ入ってきました。
今回のお話とは逸れるかもしれませんが、
業界全体を広く見られる世界地図みたいなものがほしいな〜と思ったり、
一方で「この雑誌読んどけば大丈夫!」みたいな情報が一箇所に集まったものってないのかな、と思ったりしました。(Software Test Pressはもうないしな〜)
JaSSTがそういう役割なんでしょうか。(ネットだと検索ありきだし散らばってるのでイメージとちがう)
「QA難民」にはなりたくないです!(>_<)取り残されないためにも鳥の目が要ることを実感したうえで、
虫の目と上手く切り替えできていくひとになっていきたいなと思いました。

このテスト本が好き!2018

こんにちは、とのの(@tonono2587)です。
こちらはソフトウェアテストの小ネタ Advent Calendar 2018 14日目の記事です。

ソフトウェアテストの小ネタ Advent Calendar 2018 - Qiita

前日はオムそばさんのこちらの記事でした。

teamomusoba.hatenablog.com

今日は、いままでわたしが出会ったなかでもお気に入りのソフトウェアテストを 紹介したいと思います。

今回のテーマ:とののお気に入りのテスト本

  1. お気に入りテスト本との出会い
  2. お気に入り本!!
  3. まとめ

※ランキングとかじゃなく、ただただ好きな本です。
早速いってみましょー(^o^)ノ

お気に入りテスト本との出会い

はじめに、わたしのテスト本読書歴を振り返ってみます。
どんな本を読んだか整理したかったので、ブクログでを本棚つくってみました。

booklog.jp

ここで本を並び替えながら振り返ると、以下のような感じで読んできたことを思い出しました。

時期 探し方
テストをはじめて数ヶ月 とりあえず会社にあったもの
テストをはじめて1年くらい 図書館の検索で「ソフトウェアテスト」に引っかける
アウトプット覚えてきたころ -(同じ本をじっくり)
設計モヤモヤ期 モヤモヤに関係する単語でも検索
知り合いのおすすめ
最近 モヤモヤ期と似た感じで、おすすめや気になる単語で検索

あまりたくさん読んでいるわけではないですが、いろいろ試すうちに少しずつ自分なりの本の選び方ができてきている感じがします。

お気に入り本!

そんななかで、お気に入りなのはこちらの本です!


ソフトウェアテストの教科書』

おすすめポイント

  1. わかりやすい
  2. 練習問題がついている
  3. 手に入りやすい

1. わかりやすい

この本の帯にもありますが、「世界一わかりやすい」くらいやさしい文で書かれていると思います。
個人的には、翻訳じゃないところが大きいのではないかな、と思いました。
ソフトウェアテストに関する本は翻訳のものも多くて、はじめは頭に入りづらかった思い出があります。。
この本は純日本語(?)で書かれているので安心して読めました。

2. 練習問題がついている

なんと、テスト技法の最後に練習問題がついています!
初心者の頃って経験があまりないので、技法の説明を読んでも実感しづらく、つかうイメージが持てない気がします。
読むからには自分のものにする感覚がほしい!業務につかいたい!でもつかいかたわからん!!
この本だと技法ごとに練習問題がついているのですぐ試せるし、「つかった」気持ちになれるところが好きです!笑

3. 手に入りやすい

テスト本はいい本がたくさんあるので、古くてもう本屋さんに置いていなかったり、
置いていても高かったり。。という本もあります。
これはお値段もそんなに高くなく、本屋さんにも置いてあることが多いし、近くの図書館にもあったので
他の本に比べて手元に来るまでがスムーズだったなーと思っています。
あとあと、分厚すぎず大きすぎないところもいいなと思います。
分厚すぎて圧に負ける、初心者あるある…(あるよね?)

まとめ

読んできたなかでのお気に入りの本の話でした。
お気に入りポイントを3つあげましたが、社内で技法の勉強会をしたときに何回も読んだので、思い入れがあったのかもしれません。
ブクログ積読も管理できたので、あのときさっぱりだった本とかにも再チャレンジしたいなと思いました!!
教科書、まだ読んでいないかたはぜひ!




明日は@yoshitakeさんの記事です! 15日目へつづく… qiita.com

『間違いだらけの設計レビュー』からの学び

お久しぶりです、とのの(@tonono2587)です。
本を読みましたので学びをおいておきたいと思います。

今回の記事はソフトウェアテスト Advent Calendar 2018 2日目の記事です!

ソフトウェアテスト Advent Calendar 2018 - Qiita

記念すべき初日の記事はぱいんさんの

テストエンジニアに求める3つの姿勢 (2018/12) - 飴ブロ(仮

でした。ではさっそくいってみましょう!

きっかけ

以前レビューに関してもやもやしたことがありました。

もやもやについて

  • とののがつくったテストケースのレビュー
  • テスト対象は機能追加されたアプリ
  • ドキュメント1:機能の要件チケット
  • ドキュメント2:画面仕様書(いつもの他プロジェクトより粒度粗め)
  • 開発からテストまで1週間強

わたしの思いは、

  • 「要件が実現されているか」のテストになるよう、そこにいちばん気をつけてケースにした(つもり)
  • 細かい挙動確認は実装を見ながらやるしかないかなー
  • テストケースは納品しないし、自分しかテストしないし、整理と記録のためにつくろう
  • とはいえ自分にしかわからないのはまずいな
  • いつものテストケースフォーマットに沿って整えよう

こうしてレビューしてもらったところ、思っていた以上にえらい数の指摘が返ってきてしまいました。
サクッと終える軽い気持ちだったので、たくさんの指摘にしょんぼりしてしまいました。(´・ω・`)

  • たくさんコメントついちゃった。。
  • 内容は理解できるけど、なんか納得できないなぁ…
  • これ全部なおさないといけないのかな
  • 細かいとこなおすよりテストはじめたい。。

もやもや。。。

本との出会い

このもやもやがかなりあって、それについて(話題は「プロセス改善」でした)オンライン飲み会で話を聞いてもらいました。
そのなかで、「レビューアの机の上にこの本置いてみたら?」とアドバイスをもらいました。
タイトルと「机上にそっと置く」から察するところはありましたが、実行するにもまだ読んだことがなかったのでとりあえず読んでみることにしました。

読んだタイトル『間違いだらけの設計レビュー』


本の内容

簡単にいうと、
間違ったレビューをしていませんか?しかも間違ったやり方をそのままにしていませんか?
どうしたらレビューを改善できるのでしょうか、という内容だと理解しています。

1章では現場で起こりがちな「間違い」の例を、
2章ではその対策として効果的なレビューの手順を 準備から問題検出 まで、
3章ではその続きの 問題指摘から修正 まで
4章でレビュー自体の改善、見直し方法

が書いてありました。

読んでみて

もう1章からめちゃくちゃ刺さりました。
ここであげられている間違いレビューの例が、わたしのもやもやと似ている気がしたのです。
例えば、典型的な間違いレビュー「思いつき」「数字合わせ」「つるし上げ」について。

【思いつき】
レビューアーごとに観点がバラバラ。誤字脱字のような軽微な問題が多くなる
重要な問題の指摘が少なくなる

【数字合わせ】
問題の指摘件数ばかりに注意がいく、指摘件数でのみ管理する
重要な問題の検出が疎かになる

【つるし上げ】
指摘するうちに作成者への人格攻撃へエスカレートする
つらい

ここで言われていたのはどれも、レビューの目的を見失っているということでした。

もやもやへの光(振り返り)

レビューアの名誉のためにも断っておきたいのですが、
内容にわかりみが深いというだけで、実際に(このようなつらい思いを)経験したわけではありません。
この本を読んで響いたのは、レビューの目的を見失ってはいけないな、ということです。
もやもやを振り返ってみると、

  • たくさんコメントついちゃった。。
      →大きなヌケモレがないか、「ざっくり」みてほしいとのの vs 「きちんとしたドキュメントであるべき」レビューア
  • 内容は理解できるけど、なんか納得できないなぁ…
      →レビュー目的の認識がお互いに合っていない。とののからきちんと共有できていなかった。
  • これ全部なおさないといけないのかな
      →認識がズレたまま無理やりレビューの流れだけ進んでいっている。。
  • 細かいとこなおすよりテストはじめたい。。
      →時間が短いからサクッと終わらせたいことも共有してない。大事なことはなんだっけ??

他プロジェクトで「レビュー→なおす 」のある程度決まった流れがあったからこそ、なにも考えずその流れに乗せてしまっていました。

どうしたらよかったんだろう?(反省)

まずは、目的の共有をすべきだったと思います。

  • 背景や状況(期間短い、サクッとやりたい)
  • いつもと違う(形式はゆるくていい)
  • ここを見てほしい!(ヌケモレがないかチェックしてほしい)

目的の認識合わせをしたうえでそれでもズレてしまうなら、こういう意図だったんですが、という説明もできたなぁと思います。
(今回はズレていることもわからずもやもやという形で残ってしまいました。)

まとめ

これを読んで、わたしなりの学びは以下のようになりました。

  • レビューの目的を見失うと、つらいレビューになる
  • 悲しいけど目的喪失はよく起こる
  • 見失っていないか常に気をつけよう!!

この本には他にも 目的を見失ってしまった失敗例や、
失敗を起こさないための効果的な手順 がのっていたりします。
「問題検出」と「問題指摘」は別、とか
ネガティブなマインドを持たないことは「心がけ」ではなく、レビューアに必要な「スキル」です。とかとか
納得できる内容盛りだくさんでした。

  • レビューでつらい思いをしたことがある方
  • レビューがうまくいっていない自覚があるレビューアさん
  • レビューにネガティブな感情を連想してしまう方

ぜひ読んでみてはいかがでしょうか。


さいごに

本は机へ置かずに済みました、ありがとうございました。
アドベントカレンダー3日目へつづく…
ぷったーさんお願いします〜(^o^)ノ http://yoshikiito.net/blog/

qiita.com

iPhoneで通信環境をわざと悪くしたいときのこと

発掘記事です。
わざと接続環境を悪くしたいとき、iPhoneの「デベロッパ」の機能をつかうとその環境をつくりだせます。
わざわざ電波の悪い場所を探さなくてもOK!
Developer>NETWORKING_Network Link Conditioner>EnableをONにする


2016/11/07

iPhoneの通信速度を変更する iPhoneで通信速度をあえて遅くしたいとき!

方法

この記事がわかりやすいです https://www.lancork.net/2014/04/ios-dev-how-to-change-network-condition/

デベロッパ」が設定にないときは?

最新のXcodeにつないでもらう
https://www.htmlhifive.com/conts/web/view/study-room/devtool-network-ios-web-inspector#HiOS7AEF672B306E300C8A2D5B9A300D306E980576EE306B300C30C730D930ED30C330D1300D30928868793A3059308B

まとめ

設定 →デベロッパ →NETWORK LINK CONDITIONER  →Status  →EnableをON(緑)  →速さを選ぶ

注意

検証し終わったら必ずもとに戻すこと!!!

テストマスターへの道 第3回 狩野モデル

過去記事の再投稿です。


2016/10/06
テストマスターへの道 第3回 狩野モデル
テストマスターになりたいとののが勉強した記録です。
9/15のチーム会で発表した内容になります。

今回のテーマ:狩野モデル

ソフトウェアテストの教科書』のPART1 ソフトウェアテストの基礎 のところを読んでいて、
前回の第2回 ビューティフルなテストに通じる考え方だなと思いチーム会で発表共有しました。

狩野モデル

  • テストに限らず、商品企画などものの品質を考えるときに使われる考え方
  • 狩野さんが考えた
  • ユーザーの要求に応じて品質を分類するという考え方:大きく3つ→当たり前品質、一元的品質魅力的品質

■例えば:携帯電話

  • 当たり前品質→電話ができる(できて当たり前)
  • 一元的品質→バッテリーの持ち(長ければうれしい、短いと不満)
  • 魅力的品質→音声がめっちゃきれい(あるとうれしい)

このように分類して考えてみることで、検証の力の入れどころや、検証の質としてもどうだったのかを捉えられて
→ビューティフルなテストになる!とわたしは解釈しました。

チーム会より

  • テストにも当てはまる:大事なところがわかるので、「木を見て森を見ず」のようなことが防げる
  • 経済の勉強とかでも出てくる
  • ラーメンつけ麺狩野さんはイケメン?(親しみやすさ)

出典

あまりうまく伝えられなかったのですが、個人的には「狩野モデル」しっくりきています。
テストマスターへの道のりはつづく。。。

テストマスターへの道 第2回 「ビューティフルなテスト」

過去記事の再投稿です。


テストマスターへの道 第2回 「ビューティフルなテスト」
テストマスターになりたいとののが勉強した記録です。
2016年7月5日

今回のテーマ:ビューティフルなテスト

図書館でタイトルに惹かれ『ビューティフルテスティング ーソフトウェアテストの美しい実践』という本を読みました。

  • 本の概要
  • 2章「ビューティフルテスティングは、ステークホルダーを満足させる」
  • まとめ
  • 出典

本の概要

この本は、テストのプロフェッショナルたちが編み出したテストの極意、「美しいテスト」について語るものです。

豊富な経験やユニークな見解をもつ人物に焦点を当てた「テスター」、試行錯誤の末に到達した「プロセス」、すばやく効率的に行うための「ツール」という3部構成で、書き手自らが確率したテストの極意を実例を上げてわかりやすく解説します。


と裏表紙に書いてありました。
眺めるとわかるのですが、2部と3部は特にエンジニア向けという感じで、私は正直ほぼ意味がわかりませんでした。(諦めた)
その中でも意味が理解できて、なるほど〜と思った、
第1部2章「ビューティフルテスティングは、ステークホルダーを満足させる」
についてまとめます。

2章「ビューティフルテスティングは、ステークホルダーを満足させる」

この章では、「ビューティフル」を「満足」だとして、それはどのようなテストであればよいか、的なことが書いてありました。

「誰が」満足するかを明らかにする。誰=テストステークホルダー

ビューティフルなテストをするためにまずは、誰に対するテストなのかを明らかにしましょう。
筆者は満足させる人々を、テストステークホルダーと呼んでいます。
テストステークホルダーとは、テスティングと、その最終的な成果物の質に対して、利害、関心、影響力などを持つすべての人々のこと。
例えば、テスター本人、開発メンバー、プロジェクトマネージャー、ユーザ、スポンサー、など。

「何が」満足させるのかを知る

それぞれのステークホルダーは、テスティングをする目的と、期待するものを持っています。
誰が満足するかがわかったら、その人のテストの目的と期待を明確化しましょう。
これが不明確だと、ビューティフルなテストになるかは運任せになり、ごくわずかなステークホルダーしか満足させることができません。
ステークホルダーと合意形成ができていれば、「有効で、効率がよく、エレガントなテストとは何か」がわかり、美しいテストが実施できるのです。
有効に:各ステークホルダーの目的と期待を満足させること。
効率よく:投資したリソースから最大限の価値を生み出す方法を通じて、目的と期待を達成すること。
エレガントに:有効さと効率を、手際よく実行すること。

外面的な美しさ

誰が何に満足するかを明確にしたら、具体的にどのくらいやれば満足なのか、を考えます。

 - 存在しているバグのうち、実際に検出したバグの割合は? - バグ全体における重要なバグの割合は? - バグ1件あたりの検出・修正に要するコストは本番環境で障害が1件発生する場合と比べてどの程度か?


例えば上記のような質問に答えるために、指標をつくります。
(((計算式が書かれていましたが、よくわかりませんでした)))
また、コストを測定する方法として、CoQ(Cost of Quality:品質コスト)があります。
これにより、テストや品質に関する以下の3つの主要コストを明らかにできます。

  • 検出コスト  - バグの検出がゼロだとしても発生するテスト費用。
  • 内的障害コスト  - バグ検出のみに起因して発生する、テストおよび開発コスト。バグ報告の作成、バグ修正、修正の確認テストなど
  • 外的障害コスト  - 提供した製品にバグが存在することに起因するコスト。テクニカルサポート、保守、維持のための費用


こうした指標によって、ステークホルダーの満足を達成する方法と、達成度を測定する方法をしめすことができます。

内面的な美しさ

ビューティフルテスティングについてもうひとつ検討するべき要素が、内面的な美しさです。
例えば、テスト工数のかなりの割合を手動での回帰テストに費やすと決めたとします。

 ○自動化した回帰テストの割合は?  ○回帰関連の品質リストのうち、網羅できた割合は?  ○自動化によって、手動よりどの程度早く回帰テストを実行できるのか?


(((これを指標にする計算はやっぱり意味わかりませんでした)))


ここでは、テスティングの目的と期待を内部の観点から設定することで、仕事をよりよく、速く安く賢く行うためにテスティングを測る方法を示します。

まとめ

ステークホルダーが満足するビューティフルなテストをするにはどうすればよいか!

  1. ステークホルダーを知ります。
  2. ステークホルダーにとっての、テスティングの目的と期待を知ります。
  3. ステークホルダーの目的と期待を達成するための、メトリクスと目標を設定します。(外面的な美しさ)
  4. テスティングの目的と期待を達成するための、メトリクスと目標を設定します。(内面的な美しさ)

いままで考えたことはありませんでしたが、
この検証は成功だった!と言えるとすれば、たしかにこんなふうに誰にとってどのくらい達成した、と言えれば確実に成功なのかなと思いました。

出典(読んだ本)

『ビューティフルテスティング ーソフトウェアテストの美しい実践』
Tim Riley,Adam Goucher
大西健児(監訳),児島修(訳者)
オライリー・ジャパン,オーム社
2010年10月25日

テストマスターへの道 第1回:テスターの適性

社内Qiitaに投稿したりした記事をあつめてきています。
ちょっと直しながら再投稿しています。


2016/05/13
テストマスターへの道 第1回:テスターの適性
テストマスターになりたいとののが勉強した記録です。

今回のテーマ:テスターの適性について

  • まずは
  • くわしく
  • まとめ
  • 出典、参考

まずは

診断チャートをつくってみたので、やってみてください!

くわしく

ソフトウェアテスト実践ガイド』によると、

テスターの素質については、

その1:体力に自信があること

テストは長丁場になることが多く、時間がかかり、単純な作業も多いため。

その2:忍耐強いこと

同じ理由で、メンタルの体力(忍耐)も必要

その3:素直だが、ひねくれてもいること

事実は事実として客観的に素直に受け入れた上で、その事実が真実なのかどうかをきっちり見極める目をもつこと。
不具合がみつかったとき、その背景を含めどういった現象なのかを観察し、特性を把握しなければならない。
その上でそれが表出している現象だけなのか、ほかに影響がないかなど、いろんな角度から検証できるかどうか。「鼻が利くかどうか」これには経験が必要。

その4:好奇心旺盛なこと

不具合の臭いに敏感な鼻をもつために、経験を積むためにも必要。
「どうなっているの?」「こうすれば、どうなるのだろう?」「分からないといらいらする。くやしい!」ただしほどほどに。熱中し過ぎると効率がよくない。


だそうです。

次に適性については、

  • 細かいところまで目配りができる
  • ダメなものはダメとはっきり言える
  • 時として大胆
  • 複数の角度で物事をとらえられる
  • 横同士のコミュニケーションが上手

といったことが挙げられるようです。
テストエンジニアの国内の男女構成比は男性が多く、IT産業全体とかわらず、ほぼ3:1。
国外の、テストエンジニアという職種が確率している米国ではほぼイーブン、もしくは女性が多いそうですよ!

『基本から学ぶソフトウェアテスト』による優秀なテスト要員のもつ素質や能力

  • 誠実さ、そして品質に対する責任感
  • 理論よりも経験をもとに根拠を見つける能力
  • 教育(高いほどよいそうです)
  • プログラミングの経験
  • コンピュータやソフトウェアの豊富な利用経験
  • 組合せ論についての知識
  • 優れたコミュニケーション能力や高い文章能力

『基本から学ぶテストプロセス管理』による良いテスト技術者の条件

  • プロフェッショナルな悲観主義
  • バランスの取れた好奇心
  • 熱中型の人はダメ
  • 見当違いの野心を持っている人はダメ
  • 怠け者はダメ:ある程度怠け者でないと効率のよいテスト実装、実行をしようとしないのでほどほどに
  • 臆病者はダメ:ある程度臆病でないと入念なテスト設計や実行にはつながらない

まとめ

テスターの適性を知ることで、テスターとして必要なことがわかってきました。 わたしは熱中しすぎてしまうことがあるので、ほどほどに、客観的に、というところも身につけていきたいなと思います。 知識もあればあるほどよいようなので、まずはこの本を読破するところからはじめていきます!

出典・参考

『ステップアップのためのソフトウェアテスト実践ガイド』 p.135〜 第3章 テストマスターになろう 大西健児/日経BP