はてなブックマーク

「Top 15 Best Test Management Tools of 2017 – Our Reviews」という記事を見つけたので読んでみました。とてもわかりやすく、うまくざっくりとレビューされていてとてもステキ。有名どころは調べたつもりですがたくさんありますねぇ。 Our day-to-day activities include: テストにまつわる活動は以下が含まれます。 プロジェクトサイクルや成果物情報（プロダクト）の開発やメンテナンス リリースサイクル内でのテスト成果物の開発やメンテナンス トレーサビリティやカバレッジといったテスト資産の確立 テストスイーツ、実行ステータスや実行結果のキャプチャといったテスト実行サポート 分析のためのメトリクスやレポーティング バグ管理 こういったテスト管理プロセスをサポートするためにツールが役に立つということです。 ここはとても重要ですね

ドメイン知識ってなんだろう。最近、ドメイン知識があるだのないだのという話を聞いて、ふとそんなことを思いました。何を「ドメイン知識」と呼んでいるのだろう？ ドメイン知識とは何か 調べてみると@shin_semiyaが情報を発信してくれています。 ゴールデンカムイに学ぶドメイン知識 ドメイン知識を計画作りにどう使うか 例えがいいですね。でも、まずは例えずに考えたい気分（ごめーんね）。みつけたのが「ドメイン分析，ドメインモデル，ドメイン知識」という記事。 用語，問題のとらえ方，システムの構造，システムの作り方などは，システム開発を効率化するためのドメイン知識(domain knowledge)です. ―― 「ドメイン分析，ドメインモデル，ドメイン知識」より ふむふむ。 まず、「用語」。金融には独特の言い回しがあったりしますね。システムによって商品が何をさしているか異なっていたりするので、言葉をそ

By: Kate Ter Haar 最近、品質に関するお仕事をすることが多く、特にアジャイルな開発でどうやって品質を作りこんでいくのか？ いろいろ妄想しているところです。そんな中、ふと思ったのが「QAなんて人は存在しないんだなぁ」ということ。 QAとは何か QAとは「品質保証（Quality assurance）」を意味しています。ちゃんとWikipediaにも書いてますね。 品質保証（ひんしつほしょう、英: Quality assurance, QA）は、効率と品質が求められるあらゆる活動において、それらに保証を与えるのに必要な証拠を提供する活動一般を指す。 Wikipediaより引用 僕の経験でしかないですが、これまでやってきた仕事を思い出すと 実装が終わったからQAにお願いしてテストしてもらおう これはQAで見つけたかったバグだった QAは品質を守るのが仕事なのだ とかとか、文脈によ

テスト管理ツールを使ってみようシリーズ第３弾は、スーパー高機能な「QASymphony」です。この会社は、テスト管理、テスト分析、探索テスト実行などなど、テスト系ツールをビジネスとして売り出しているので、これまで紹介したツールより高機能なのが特徴的です。 qTest Manager qTest Managerはテスト管理ツールです。１４日のフリートライアルを申し込んでみると、サンプルデータ付きのデモプロジェクトが利用できます。 テスト計画（Test Plan） リリースに対するテスト計画を作成できます。 RESOURCESセクションでは、リリーススコープを選択できます。リリーススコープの選択では、この次に紹介する「要件（Requirement）」から、対象を選ぶ形になります。 要件（Requirement） このツールもTestLodgeと同じく、テストケースと要件をセットで管理できます。

By: John Lester Webサービス開発（最近だとWebにかぎらずスマホアプリもあるな）で品質の話になったときに、課題として見えてくるものが似ている気がするので、ざーっとまとめ。もう５〜６回、同じような話をしている気がする。 品質の定義 品質とは誰かにとっての価値である。 ―― ジェラルド・ワインバーグ だとすると、開発に関わる誰かごとに品質があるはず。よくある誰かはこんな感じ。 ユーザ： 見た目や使い勝手の品質。ユーザは品質全般に関われるすごい人。 プロデューサ＆プロダクトマネージャ： サービスとビジネスの品質 エンジニア： ソフトウェア（プログラム、システム）の品質 主に、エンジニアの関わる品質をチェックするために、QAってのが存在することが経験上多い。ということは、ユーザーやサービス視点の品質チェックがおろそかになってしまいがち。 逆に、ユーザ視点で操作性を確認できて、サー

By: Silverisdead 前に友人と飲んだときに、「うちのエンジニアが芸人化している」という話を聞きました。その内容がとても興味深かったので、自分なりに考えをまとめてみると、なんだかさらに深い話になってきました。 芸人化するエンジニア 勉強会ブームの影響で、おもしろい話をしてくれるエンジニアがたくさん登場しました。エンジニアならではのネタが盛り沢山で面白く、情報がいろんなところで発信されるとても良い時代になりました。 そんな中、時代のトレンドを紹介する人が現れました。彼は勉強会を開催する中心メンバーであり、コミュニティでも有名人です。その人は技術や業界トレンドを紹介し、ちょっと先の未来を語ります。やがて、その人の話に感化される人が現れます。極端な例だと、その人の紹介するトレンド以外を否定する人まで現れてしまいました（すべてはアジャイルになるべきだとか）。 はじめはそれでよかったんで

プログラミングの義務教育化の検討がはじまり、何かと注目のプログラミングですが、ちょうど「週末に家で子供向け講座開きたいなー」と思っていたので、まずはどんな子供向けプログラミング言語があるのか実際に触って調べてみました。 スクラッチ（Scratch） 8歳から16歳向けにデザインされている、MITメディアラボ開発のプログラミング言語。 開発環境：Webブラウザ。 オフラインでも構築できる。 作品の公開： ScratchEdというコミュニティで、他のユーザと交流したり、自分の作品を公開したりできる。誰かの作品のスクリプトを見たり、コピーしていじることも可能。 学習用コンテンツ： ヘルプが充実。 step-by-step guide（エディタ右）。Getting Started Guide（PDF)。Scratch Card。チュートリアル動画。 教育者向け情報： 先生用アカウントが今後登場する

WordPressのAMPプラグインを入れたら「必須の構造化データ要素のエラー」で怒られたので、直し方をメモ。 WordPressのAMP対応 WordPressのAMPプラグインを入れてしばらくしてから、GoogleのSearch Consoleを見るとエラーが2つ。構造化データテストツールで調べてみると・・・ 「logo」には有効な URL を指定する必要があります。 「image」フィールドの値は必須です。 と怒られてます。publisherのlogoが指定されていない問題に関しては、調べてみるとIssueとしてあがってますね。 Issue > Missing and required – publisher logo + name missing ただ、WordPress Amp Article logo missing while Testing in Google Struct

NECの友人に誘われてRedmineの運用に関する勉強会に参加しました。ツールにとどまらず、タスク管理についていろいろ議論できて面白かったです。いただいた質問に対する回答はこんな感じ。 使った資料 チケットの種類や粒度について 分ければ分けるほど複雑になります。だから、できるだけわけないのがポイントだと思います。分ける場合は、そのコストにみあった意味づけが必要です。それがないと、利用者からみれば不便なルールになってしまいます。 ワークフロー ワークフローは使ったことないです。JIRAを試しに使うときに設定を考えましたが、これも使えば複雑になりますし、「リーダーがチェックする」みたいなフローになると、リーダーの負担が増えて流れが遅くなるので、使わない運用（例えば、口頭やメッセでリアルタイムに依頼するとか）にしました。 おすすめは、「かんばん」を使ったチケットの状態管理です。『リーン開発の現場

By: Eoin Gardiner 以前、数百人のエンジニアを抱えるマネージャーと話す機会があった。その人は全体的にスクラムを導入したけど、なぜかうまくいっている気がしていないという。その理由を聞いてみると、こんな話をしてくれた。 彼の組織は、スクラムマスターやプロダクトオーナーの役割を明確に決め、職能横断的なチームを作ろうと組織的にアジャイルを導入していた。もともと、トップがアジャイル開発に知見があったため、トップダウンでの導入はスムーズに進んだそうだ。 扱う開発規模が大きくなるにつれて、エンジニアもどんどん増えていった。足りないリソースはオフショアまで活用するようになった。すべてがうまくいっているように見えた。しかし、何かが変だと感じていたそうだ。 「教科書のような事例ですが、何か変な感じがすると？」 「そう、なぜかうまくいっている気がしないんだ。特に生産性。たしかにみんな楽しそうに働

By: butupa 別に誰かを責めるわけではないとはじめに断っておこう。前にこんなことがあったんだ。そのときの僕は、仲のいい従姉妹の結婚式後に、両親と中華街で食事をする段取りを考えていた。 事の顛末 親になった僕は両親のことをよく考えるようになった。だからそのときも、大阪で暮らす両親のことを考えながら、「久しぶりに関東に来るんだったら、うまいもんでも食べさせてやりたいなぁ」とか「孫とゆっくりすごしたいだろうから、ゆっくりできるところがいいなぁ」とかあれこれ段取りを思い描いていた。 大阪からは従姉妹の両親と、まだ小さい子供を連れて弟夫婦もやってくる予定だった。だから、「みなさんはどうしますか？ もしご一緒できるんだったら段取りしまっせ」と伝えており、返事を待っていた。 そこにこんな電話がかかってきた。 うちの母親は三人姉弟。姉がいて（伯母さん。この人の娘が結婚するのだ！）、母がいて、弟（叔

『ワーク・ルールズ』で紹介されていた、面接の質問例である「PBI」を、ちょびっと翻訳してみました。ストーリー性が求められる質問なので、いろいろ応用して使えそうです。 PBIとは PBI（Performance Based Interviewing）の略で、直訳すると、過去のパフォーマンスに焦点をあてた質問手法でしょうか。『ワーク・ルールズ』では、アメリカ復員軍人援護局のサンプルが紹介されています。質問は以下のようにレベル分けされています。 Level 1 – 部下を持たない最前線で働くスタッフ向け Level 2 – 仕事をリードするチームの管理者、チームリーダー、ワークユニットリーダー（一時的に役割を果たしている場合も含む） Level 3 – 部やサービスラインマネージャーとして、Level 2のスタッフを管理するミドルレベルのマネージャー。組織内の主要な機能の役割を果たす人向け。 L

エンジニア採用面接の方法について、最近、どしどし面接するようになったという後輩どもと話したことを、自分の経験をふまえてまとめてみます。僕も先輩や上司から教えてもらい、悩みながら考えをまとめてきました。 原則 面接は優劣をつけるものではない。マッチングです。 勘違いしないように。 ほしい人材像や技術レベルを満たす、または超える人を選びます。 そのためには、面接の前にこちらの期待値を確認、定義しておく必要があります。また、何かがこちらの期待に満たない場合、将来的にクリアできそうかを考えるようにしています。例えば、習得に時間がかかる言語スキルや、比較的情報が少ない新技術知識などは、「今」足りてなくても「将来」達成できる可能性がありますから。 一緒に働きたい人を選びます。 面接官が自分の判断に責任をもつため、「あの部署なら行けそうだ」の場合、通過させるのではなく、次の面接官にパスしてその人に見ても

たまたまメルカリのQAさんとお話する機会がありました。さすが今一番ホットとも言えるサービスだけあって、触発されていろいろ妄想がふくらみました。次世代QA組織とかテストエンジニアの役割とか、議論した内容をメモ。 はじめに 僕の興味は「速さ」です。「速さはすべてを超越する！」「速さと品質は両立できる！」と信じて、アジャイル開発とかリーン開発、業務改善を仕事で活用しようとしています。また、サービス開発会社で働いているので、作ることが仕事ではありません。作ったらサービスが死んじゃうまで開発運用が続くので、漸進的な開発が求められます。 この記事も前に書いたQAネタと同じく、素人ながら、経験したことをベースに、自分の置かれた環境に対して、あるべき姿を主観的に考えています。 これまでのQA 僕はSIerにいたので、そのときのQAのイメージが強いのですが、日本はSIerが多いので、QAのイメージの基盤にあ

『今すぐ実践! カンバンによるアジャイルプロジェクトマネジメント』をいただいたので読ませていただきました。「実践」というだけあって、あるあるネタ満載のいい本に感じました。以下、書評です。 「スクラムできないわ」と思ったのは2013年ごろのことだ。これはスクラムがダメというわけではなくて、ある一定の期間（スプリント）の作業を固定し、チームへの障害を最小限におさえて開発を進める形を作れないということ。当時の開発現場は、 急な横槍作業がある スプリントを超える長く続く作業がある まだ小さいサービスでとりまく変化が多い と、当時大ブームだったスクラムを試す機会に恵まれなかった。そこで試したのがこのカンバンだ。ちょうど平行して『リーン開発の現場』を翻訳する機会があり、実際のプロジェクトでもカンバンを試すことができた。まずは小さなカンバンから。やがてWIPを設定したり、ステップごとの完了を定義したり、

テストケースの管理は、テスト自動化云々の前になんとかしておきたいところ。テストケースはExcel管理することが経験上多いですが、世の中にはもっと便利なものがあるだろうと思い、ブラウザベースでテスト管理できる「TestRail」を試してみました。さてさて、Excelを超えるのでしょうか？ 超えてみろ！ なぜテスト管理が重要なのか テストケースの管理について、以下のような課題を多く経験しました。 テストケースの追加や更新、その後の整理が難しい。行のコピペミスやマージ漏れ、同時更新でおかしくなったりファイルが壊れたり。マスタとなるテストケースをバージョン管理しながら育てていきたい。 トラッキング情報を書き込みにくい。Excelのセルには表示限界がある。「5/31 藤原 XXXXX追加」とか書くのがとても面倒くさい。 過去のケースを検索しにくい。ファイル・フォルダに行って、過去の日付のケースを開い

アジャイルテストの話のときに、QAの人とちょっと話す機会がありました。その人は「QAもプログラミングスキルがいるかもなぁ」と話してくれて、僕も「これだけ簡単にテストをプログラミングできちゃう時代だと、書けないQAの市場価値は下がるかもしれませんねぇ」と思いました。QA本来の価値は変わらないと思いますが、求められる責任範囲が増えてる気がします。 QAの責任範囲 前に書いた「アジャイルテストの話」では、誰がどこをやるかまでは書きませんでした。 https://daipresents.wordpress.com/2016/agile-testing/ きっとそれは組織やチームレベルで違うので、必要な部分を誰かが担当すればいいだけだとおもいます。僕がよく聞く話だと、QAの役割は以下のパターンに分かれています。 テスターの管理だけする人。いずれ、直接テスターとやり取りしたほうがはやくなりがち。問屋と

この記事は、ソフトウェアテストの専門家でもなんでもない僕が考えたアジャイルテストのお話です。実際に遭遇した課題や問題に対して考えたりアクションしたことをまとめています。結果的にうまくいったこともあれば、うまくいかなかったこともあり、いまだに悩むことは多くありますが、「何が正しいかなんてわかららない」とラルクアンシエルも言っているので、誤解を恐れず、断定的に書いています。なお、上のむちむち写真はなんとなく選んだものです。 なぜ今アジャイルテストなのか？ ことの発端は「テストの自動化」が周囲で話題になってきたからです。これはこれで「ええこっちゃ」なんですが、徐々に過熱化して「なんでもかんでも自動化！」「自動化サイコー！」みたいな相談を受けるようになり、大失敗事例も目の当たりにして、テストについて改めて考えなおす機会が生まれました。 また、自分自身が体験したテスト問題もあります。昔、とあるサービ

ソース静的解析ツール「SonarQube」は「Quality Gates」という、コードレベルの品質基準を設定できます。ただ、どういった値を設定すればいいか？ 悩ましいところなのでいろいろ調べて自分なりの基準を考えてみました。 Quality Gatesの魅力 Quality Gatesの魅力。それはずばり、基準値ができることだと思います。SonarQubeによってソースコードレベルで解析が行われ、コードカバレッジ、ソースの重複度、複雑さといったデータがわかるようになれば、次はそのデータをどう扱うかがポイントになるはずです。 周囲でSonarが流行っていたときに感じたのですが、解析結果がグラフィカルに確認できるようになったのに、「で、どうしようか？」と困っている雰囲気がありました。確かに、「Complexity 8.2」って言われても、それがいいのかわるいのかよくわからない。 だから、得た

ソース解析を使って技術的負債を管理するツール「SonarQube」を使って、有名所のJavaフレームワーク（Spring、Spring Boot、Play Framework）を解析してみました。それぞれの解析結果の平均値を調べて、「Quality Gates」の値を調整できないかなと考えたからです。 SonnarQubeのインストールと解析まで Requirementsにあるように、「Oracle JRE 7 onwards or OpenJDK 7 onwards」がインストールされていれば簡単に動かせます。今回はWindows環境で試しています。 Get Started in Two Minutesを見ながら起動と解析を行います。 https://gist.github.com/daipresents/75060fcc156eeb80d424167ce77809d5.js?file=

たしか、採用面接の方針を話していて、それぞれの採用に関する価値観を聞いたときのこと。ある後輩が「GitHub採用つらい」という話をしてくれました。聞いてみると、たしかにすんなり納得できない部分もある気がします。 GitHub採用とは 最近のエンジニア採用では、応募者のGitHubアカウント情報が流れてくるようになりました。同様に、LinkedInアカウントも流れてきますね。書いてきたコードや経験がオープンになってきたということなのでしょう。 情報がオープンになり、人材の流動性が高まるのは、個人的にはうれしいことです。なぜなら、いろんなことをいろんな場所で経験できることに魅力を感じるからです。一つの会社でいろいろできるのも魅力的ですが、土台となる文化が同じだと、体験に差が生まれそうですし。また、景気に影響を受けるとはいえ、クビになっても仕事を見つけやすくなるかもしれない。 一方で、マネージャ