はじめに 6/21に開催されたJaSST'24 Kansai。 すでに1ヶ月近くも経とうという時にようやく書き始めるという相変わらずの遅さなのですが、思い出しながらつづっていこうと思います。 ぼくは今回、スポンサー枠でもなく、業務としてでもなく、自費で休みをとって参加しました。 内容的に、今の業務に直結するわけではないと思ったのと、テスト会社として持ち帰れるものがそれほどないのではないかという推測からでした。 あと、なんとなく業務として参加すると何らかの有益な情報を持ち帰らないといけないな、と個人的に思ってしまうというもあって、気楽に、自分自身のために参加しました。 とはいえ参加する限りには自分自身で何をテーマに参加するのかは決めていて、今回で言うと「事業会社におけるQAはどういったことを考えられているのか、それはテスト会社の思考とどんなところが違っているのか」が見えればいいなと思い参加しました。 続きをみる

はじめに１ 今回、本当に転職するつもりで、転職活動中に、これまでの現職での思い出がよみがえってくることがあったので転職活動の合間に書き溜めていました。 しかし、最終的には現職に残ることを決意しました。 ただ、せっかく書き溜めたというのと、転職か現職かで揺れている人に”退職しなかった人の意見”として少しでも参考になればと思い公開するに至りました。 ぼく自身、本当にゆれにゆれました。 今回の決断が良いものになるかどうかはこの先にならないとわかりませんが、良いものになるかどうかは自分次第ということもあると思います。 あと、近いうちに実は転職している可能性もあるかもしれません笑 続きをみる

お断り 今回は軽い内容になっています。 いつも軽いといえば軽いのですが、、、 息抜き程度に読んでもらえるとうれしいです 続きをみる

どんな内容？ コンサルティングやプロジェクトマネジメントを中心に活動していた方が昔から夢であったプログラミングをやりたくて外資系の企業に入って、実際に海外の人たちと接する中で得た思考の違いの気づきをまとめた本です。 続きをみる

先日、にしさんがお亡くなりになられました。 にしさんのお世話になったので自分自身のために思い出を書き留めておこうと思います。 とはいっても、にしさんはX（旧：Twitter）でぼくのフォローはしていないし、ぼくのことを覚えているかもわからない。 なんて書くとにしさんに嫌われそう。なんかそういう人を嫌いそうなので。 実際はどうだかわからないけど。 続きをみる

はじめに 管理って何？良い管理と悪い管理の違いって何？って聞かれたときに回答したことをメモ代わりに。 何か改めて文献を探りながら書いていないのでその点はご容赦ください。 続きをみる

はじめに ここ最近、ちょこちょこと「『品質保証』と『品質管理』の違い」について話題に上がることがあったのですが、あまり自分自身の言葉で明確に説明できないなと感じたので自分なりの定義を作ろうと思いそれを記事にしてみました。 ネットで調べてみると「品質保証は買い手視点、品質管理は作り手視点」のように書かれていることもありましたが、この定義が自分の中の定義といまいち合わなかったという背景もあります。 ただ、ここでの定義はあくまでぼく自身が理解しやすいように、かつ説明しやすいように定義づけしているのでその正当性は保証していませんのでご注意ください。 続きをみる

2:6:2の法則とは Wikipediaで調べると「働きアリの法則」として書かれています。 Wikipediaによるとパレートの法則（80:20の法則）の亜種らしく、「2:6:2の法則」とも呼ばれているものらしいです。 続きをみる

はじめに テストプロジェクトの運営において、プロダクトの品質状況やテストの品質状況を測りたい場合があります。むしろ常に測りたい。 その場合にメトリクスを使いたいのですが、その場合に、測定した結果がプロダクトの品質やテストの品質が良いかどうかを判断するための目安となるもの（これ以降はこれを便宜上「値」という表現をします）を次のいずれで表現するのかいいかを調査したのでそのメモを記載します。 多分にぼくの解釈が入っていますし、自身が一番しっくりきた形で記載しており、必ず正しいとは限らないのでその点についてはご容赦ください。 続きをみる

JSTQBで定義されている「事後条件」について、私自身の解釈が違っていたのでメモを。 これまでの自分自身がテストをしてきた経験で、テスト実行したときには不具合が出ていなかったのに、テスト実行したその後の状態で不具合が発生することがままありました。 例えば、複合的なテストにおいて、ある機能（A）とある機能（B）をぶつけるテストをしたときに、ぶつけたときはちゃんと優先順位が考慮されていて問題なかったんだけど、その後、ぶつけられたAの機能を動作させようとするとうまく動作しなかった、ということがありました。 続きをみる

因子・水準とは 因子・水準という言葉がテスト設計界隈で使われ始めたのはHAYST法からだと認識しています。HAYST法では実験計画法が使われていて、つまりは直交表を使うために因子・水準が使われていると認識しています（間違っていたらごめんなさい）。 この因子・水準は実験計画法における何らかの要因となり得るものが「因子」でそれを測るための基準をもつものが「水準」であるといった意味で使われています。つまりは、因子に設定するものは何らかの要因になっている必要があって、水準はその要因を測る上での基準となっていなければならない、ということになります。 続きをみる

テストタイプとテスト設計技法って同じように見えてしまうことがあるのでその違いについて明確にしてみました。私が自分で理解しやすい表現をしているので必ずしも正しいとは言えないかもしれませんが、その点はご了承ください。 結論 続きをみる

「これって接続性テスト？それとも互換性テスト？」と聞かれてちゃんとした違いについて即答できなかったのでこの機会に調べてみました。調べていくうちに「相互運用性」という用語も出てきたので合わせて調べています。 ※調べたのは「ｘｘテスト」ではなく「ｘｘ性」になります 結論 続きをみる

私の所属している会社では方針を掲げる資料（年間計画）に先期の成果と反省を書くことが多いようです。ただ、方針を掲げる資料に成果と反省を書くことにすごく違和感を覚えます。というのも自分自身が資料を作るときには成果と反省を書かないからです。で、何で違和感を感じるのかってのを考えてみました。 1.一年単位で評価をしている 続きをみる

テストマトリクス（どのマトリクスでもいいのですが、ここではわかりやすいように機能xテストタイプ（テスト観点）とします）は、私は個人的に使わないんですよね。 ソフトウェアテストをやり始めた頃はマトリクスで作ると変な安心感があって使っていたのですが、やればやるほど使いづらくなってきました。なのでVSTepでいうNGTなどを好んで使うようになってきました。 使いづらいと思うのは以下の点です。 ・交差する箇所を”並列で”1つずつ考えていくことになりしんどい ・あらかじめ決められたこと以外の発想が出にくい ・テストタイプによっては機能を跨ぐ必要が出てきたりして、その場合にマトリクスで表現しづらい 続きをみる

仕事をやっていると少なからずトラブルが発生します。そんな時、風潮として「振り返り」をやることが多いです。振り返りといいつつも実態は反省会のようなもので、一応、なぜなぜ分析のような手法を使ってやっているようですが、その中身は全然、本質に迫れていないものが多いです。 そもそもこのような形で何かしらの失敗に対して原因分析して今後のアクションにつなげていくようなことは効果があるのでしょうか。 効果がないとは言えませんが、成功した事例から学ぶよりも効果が薄いように感じます。 続きをみる

部門の教育担当の役割も担っている私が何らかの研修を企画するたびに「研修を受けても役に立たない」という発言があります。 これ、そのいいっぷりから私は「研修には意味がない」と受け取っていたのですが、この発言の意図についてよくよく話を深掘りしていくとどうも「研修だけをやっても役に立たない」という意味だということがわかってきました。 もちろん研修を受けた”だけ”では何の役にも立たなくて、研修で得た知識を実際に試してみて、そこで大抵はうまくいかないのでもう一度、知識を自分なりに理解し直して、また試して、と繰り返し使っていくうちに身につけていくものです。そういった意味で発言した内容はその通りではあります。 （そして、一部分の人は研修を受ければその知識を得たと思っている人がいるっぽいです。だからこその発言だったようでもあります） 続きをみる

著者 著者はあの「知識ゼロから学ぶソフトウェアテスト」でお馴染みの高橋寿一さんです。ソフトウェアテストに携わっているほとんどの人は知っている方なのではないかと思います。この方はMicrosoft、SAP、ソニーというそれぞれPC、エンタープライズ、組み込み製品のドメインの中の大企業に勤められていました。そういった意味でも書いてある内容に説得力があると思います。単に私が権威に弱いだけなのかもしれませんがw 続きをみる

著書名 「洞察力」宮本慎也著 続きをみる

ソフトウェアテストを行う上で、計画段階できちんと見積もりをして予実管理していくのはとても大切です。 ただ、その見積りの正確性を問われても土台無理な話で。。。 見積りの話題のときにある大学の先生から言われた言葉が今でもすごく印象に残っています。 曰く、「見積りってのはいつも正しいんだよ。だって見積もった内容に合わせて行動していくんでしょ、結局。だから見積もりってのは意思表示なんだよ。このプロジェクトではこのように行動していきます、っていう意思表示」 続きをみる

経緯 私は以前にマウスのサイドボタンでPage UpとPage Downを利用していて これが大変便利だったのでまた利用したくなってBUFFALO社製のBSMBU510Mシリーズの「BSMBU510MBK」を購入しました。 で、サイドボタンにキーを登録するために必要な 「NEOFIT」というアプリケーションをインストールして サイドボタンに「Page Up」「Page Down」を登録すると ・・・動かない。 続きをみる

日頃から言葉は大切に使いたいな、とは思っていて、 その一つにタイトルに書いた言葉の使い分けも意識しています。 で、この「導出」と「抽出」はこんな風に使い分けています。 導出：あるインプットから分析なり考察なりを入れた形で取り出す場合 抽出：あるインプットからそのまま必要なものだけを取り出す場合 続きをみる

TPIをベースとしたプロセス診断をやることが多いのですが、そこから改善活動していくとプロセスの枠組みを作ることやプロセス通りに実行することが目的になりがちなんですよね。で、改善していく過程でプロセスの診断結果は良くなっていくのですが、じゃあどこまで改善していけばいいのか（プロセス診断と改善のゴール）がわからなくなってくる。最近、支援している現場でも同様のことが発生しています。 そんな中で、社内のプロジェクト発表会である大学の先生の一言が琴線に触れました。いわく、「実際のプロジェクトの結果をプロセス診断の結果と結びつけるといい」でした。それはそうですよね。でもこのことを忘れがちというかプロセスを、実際のプロジェクトの結果（課題）と結びつけるのってやってこなかった気がする。例えば、市場不具合が2件発生した（プロジェクトの結果）。それがプロセス診断の結果として「欠陥管理において欠陥分析ができていなかった」のであれば、欠陥分析ができていなかったことにより市場不具合を発生させてしまった」という結びつきができる、ってな具合です。実際の現場ではそんな単純な結びつきにはならないと思いますが、プロジェクトの結果とプロセスの結果を結びつけるってのは非常に目から鱗なのでありました。 続きをみる

テストタイプとテスト技法の定義を自分なりにしてみました。で、その違いを野球で例えるとしっくりきたのでその例を添えて。 定義 続きをみる

経緯 JSTQBのシラバスにおける「regression testing」の翻訳についてFL2011(Foundation Level 2011年発行版)では「回帰テスト」と訳されていたのに対してFL2018では「リグレッションテスト」と改められたようです。 しかし、ネット上やJSTQBの用語集においては「regression testing」は「回帰テスト」と訳されていることが多いように思います。 では、なぜ回帰テストではなくリグレッションテストと訳されるようになったか自分なりに違いを定義してみました。 続きをみる