テスコン要求分析チュートリアル前半
記事内容
完全に自分のツイートをまとめただけ。
参考資料
テスト要求分析チュートリアル資料
http://aster.or.jp/business/contest/doc/2019_TRA_1-3_V1.0.0.pdf
ザクっとした感想
テスト要求分析って、なんとなくやったつもりになってるし、なんとなくできちゃう。
これってどういうことかというと、説明はできないんだけど、長年の勘と経験でやれちゃってます、ってパターンがすごく多いってことだと思う。
そのまま同じような差分開発の評価を続けていると、うまくいったように見えていても、どこかに大きな落とし穴があったりして、でも要求分析してないし、そのあとの設計もふんわりするから、落とし穴に気づけないままはまって「なぜ…こんなことになったのか…わかりません…」みたいなことになるんだと思う。
それじゃあかんでえ、と、今回のイベントでは言ってた。
自身の所属する組織や、求められる品質や、開発規模、その他もろもろの要因によって求められる要求が違うので、そこら辺を加味しつつ、
- どういった目的でテストするか
- どこまで、どんなテストをするか
といったあたりを、きちんと根拠をもって、かつ言語化して、ステークホルダーと合意をとりつつ、トレーサビリティをもって要求分析をしましょうね、という風に理解した。
Twitterまとめ
自分のつぶやき。基本的には右矢印(→)から先がその時ふわっと思ったこと。 その手前は資料のメモだったり、講師の人が話してたこと。
— つみき (@mktk0808) 2019年3月5日
テスト要求分析
— つみき (@mktk0808) 2019年3月5日
・集める(準備含む)
・分ける(分解、分類)
・整理する(構造化)
→ 今回はここまで。
あーーーーなるほど…確かに観点出す前にそういうことやってるかも。
要求分析、なんとなくやれてることもある。
— つみき (@mktk0808) 2019年3月5日
→ つい最近までそんな感じだったな(今できてるとは言ってない)
プロセス上それなりの要求分析は行うようになってる
→ 意識的にやることが大事かー。そうだよなあ…。
テスト要求分析の説明は受け手によって深さがまちまち
— つみき (@mktk0808) 2019年3月5日
→ まちまちなのでどうしたらいいかはこれからかな。
どういった目的でテストするか
— つみき (@mktk0808) 2019年3月5日
どこまで、どんなテストをするか
→これ考えるのほんとに要求分析?パッと見観点出しと構造化しかしてないよ?観点出す段階でそこまで考えて構造化しましょうってことなのかなあ...あー私が機能の観点に寄ってしまってるからか。
どこまでどんなテストをするか、
— つみき (@mktk0808) 2019年3月5日
・なんでテスト範囲がそこでいいのか、なんで?をつきつめて考える。
機能分けるだけでいいの?
→業務フローごとに考える、っていうのは一つありな観点かな?
なぜそう考えたか?を説明できて、ステークホルダーと合意できる内容であること。
— つみき (@mktk0808) 2019年3月5日
→ 大事だ~~~~~~~~~~~~~。やっぱり明日開発のリーダーさんに週次隔週でMTGさせてもらお。
他の成果物と整合するべき
— つみき (@mktk0808) 2019年3月5日
→ これ難しいんだよな…。観点図しか出してないからか…。
集め先のところはまあいいや。大丈夫。わかる。でも一応メモ。
— つみき (@mktk0808) 2019年3月5日
• 実際の物
• 開発時に作成された文書
• 設計書
• ユーザーズマニュアル
• 想定された使われ方(≒仕様)
• 問題が起きやすいところ、考えられるリスク
テスト対象以外から得られるテスト要求を忘れる…
— つみき (@mktk0808) 2019年3月5日
→ってどういうこと?対象以外って何?規格とか?
使用者の要求
— つみき (@mktk0808) 2019年3月5日
→ これが難しいんだよな…。うーーん。聞けそうなら聞いてみたい。Summer Days に行って色々聞けるようになろう。
集めた情報を分けて俯瞰する。ロジックツリーを作って整理する。
— つみき (@mktk0808) 2019年3月5日
→ これ苦手な奴~~~。マインドマップで頑張ってる。
深堀の方向
→ なぜなぜだなー。なんで?なんで?を常に念頭に置かねば。
状況変化の情報を集め忘れないように。
→ なぜ開発メンバーが休みがちに、ってなに、、どういうこと
開発メンバーが休みがちに
— つみき (@mktk0808) 2019年3月5日
・仕様変更が多発してるとか、何かハードなことが起きている可能性がある
→ …。去年の夏を思い出す顔
集められない時:想像する
— つみき (@mktk0808) 2019年3月5日
想像できても、できれば事実を集めたほうがいい
・想像に頼りすぎると説明しにくくなる
→ 想像しすぎないようにしないとなあ…。想像だけで作ると途中で矛盾が発生したりするしなあ。
はわわ…分析手法?の話になったら急についていけなくなった…😢
— つみき (@mktk0808) 2019年3月5日
わからないことをそのままにせず、帰ったら調べます。
品質を区分して考える
— つみき (@mktk0808) 2019年3月5日
既存の区分けは便利だが、やりたいこととの相性の確認や内容の取捨選択は検討すべき
→ これにとらわれて要求を見逃さないようにしないとなー。
「常識」「一般的」
— つみき (@mktk0808) 2019年3月5日
「法律などのルール」
→ RFC は法律…?ちょっと違うか。
仕様質問して、RFCに書いてあるでしょ、って言われたんだけどそれは常識なのかな…
NG:チュートリアルで聞いたから必要かわからないがやる
— つみき (@mktk0808) 2019年3月5日
重要なのは理由や問題を理解して行うこと。やろうと思ったらいくらでもできるから、ちゃんと考えないとだめ。
分解⇔分類
— つみき (@mktk0808) 2019年3月5日
要求の種類
・テストを厚くする、しないの要求
・バグを出すのか、動作を保証するのか
・エンジニアリング要求、マネジメント的要求
→ バグを出すのか、動作を保証するのか、、動作を保証することを考えているはずなんだけど、バグも出したい…
今、まさに仕様の内容を分解する、ってやってるわ。
— つみき (@mktk0808) 2019年3月5日
行間を埋める、はやってない。印刷してやってみるかなあ...
空気読むのと同じくらい行間埋めるの苦手なんだけど。
アウトプットをイメージし、どんな切り口の情報が必要か考えながら行う
— つみき (@mktk0808) 2019年3月5日
• テスト設計などのインプットとして欲しい情報は何か?
難しいなあ…
整理はマインドマップ使ってる。
— つみき (@mktk0808) 2019年3月5日
のかな?マインドマップからのオリジナルフォーマットで整理をしているはず。
てか整理はもうアーキテクチャ設計に入るのかと思ったなあ。
集める→分ける→整理する、は、行ったり来たりする
— つみき (@mktk0808) 2019年3月5日
→ 大事なんだけど行きつ戻りつしたときに抜け落ちないようにするの難しい。
Selenium & Edge & Python
Selenium で Edge を動かそうとして詰まりを解消したメモ
自社研修で Selenium で Edge を動かすための環境構築にちょっと苦労したのでメモを残す。
Edge のバージョンが 17 までと、18 以降で手順が違うぞ?!問題
- Microsoft の以下のページから、自身の Edge のバージョンとあった webdriver.exe を落とすように言われた…
developer.microsoft.com
('ω')
18はないでござる...
当然古いバージョンではエラーになってしまう...
調べてみたら、
WebDriverの改善 WebDriver を利用した Microsoft Edge での自動テストがより簡単になりました。
これまで WebDriver を使用して自動テストを行う場合、ダウンロード用の Web サイトに赴き、テストする Edge のバージョンに合わせて個別のパッケージを別途入手する必要がありましたが今回のアップデートにより Windows Feature on Demand(FOD)、つまり Windows 10 の [設定] - [アプリと機能] の中にある [オプション機能の管理]からインストールして使うことができるようになりました。しかも Windows Update により WebDriver のバイナリも自動的に更新されます。
Windows 10 October 2018 Update に搭載されたMicrosoft Edge(EdgeHTML 18)の新機能 – monoe's blog
とあったので、その通りに Microsoft Webdriver をインストールしてみました。
引っかかりポイント 2つ目
もともとは、以下のように webdriver.exe と同じディレクトリに python のファイルを置いて実行していたのですが、当然ファイルは無いのでエラーになります。古いファイルを実行しても、もちろんエラーになります。
#Edgeを操作 driver = webdriver.Edge(executable_path=".\\MicrosoftWebDriver.exe")
困ったなあ…と思ってたら、ぴんときました。
さっき落とした webdriver がこのPCのどこかにいるんじゃない?と。
調べてみたら、c:\windows\system32 の下にいました。 そこで、今度は
driver = webdriver.Edge(executable_path="C:\Windows\System32\MicrosoftWebDriver.exe")
こうしてみたら動くようになったのですが、先輩に確認したところ、そもそも環境変数が通っているところなら、executable_path はいらん!ということで、
driver = webdriver.Edge()
これで動くことが確認できました。ちゃんちゃん。
DNS 勉強会資料 2日目:レジストリ・レジストラ?(memo)(教育)
DNS をはじめよう 2日目
全体の流れ
以下の流れで話が出来たらいいな・・・
レジストリ・レジストラとは?
1 つのTLD ( DNS 勉強会資料 1日目:ドメイン名って何?(memo)(教育) - 備忘録~小さなことから大きなことまで~ 参照) には 1つのレジストリ、が原則です。
ただし、1つのレジストリに対して、レジストラは複数であることが多いです。
お名前.com やサクラインターネットなどのほかにも様々なレジストラがいます。
レジストラの役割
レジストラは、ドメイン名を登録したい人(もしくはその取次ぎを受けた人(リセラ))からの申請情報を受け取り、レジストリが管理するデータベースへの登録依頼を行います。
レジストリの役割 ( 抜粋 )
ドメイン名って何?のなかでも説明しましたが、インターネット上のIPアドレスを特定するための仕組みが DNS です。 例えば example.jp が複数存在してしまうと、いったい私がアクセスしたい example.jp はどれなの?となり、違う宛先にアクセスしてしまうことも考えられます。
そうならないために、「レジストリデータベース」でドメインを一元管理するわけです。
.jp ならば、JPRS がドメインを一括で管理するので、example.jp というドメインを取得したとしたら、example.jp = xxx.xxx.xxx.xxx というIPアドレスを紐づけることによって、インターネットを通して、example.jp にアクセスできるようになるわけです。
おまけ情報
前述のとおり、ドメインの重複は許されません。が、テストなどで適当なドメインを使用してしまうことがありませんか?
それがテストの範囲内で収まってて、インターネット上にでないのであれば問題ないのですが、もしでている場合、きちんと制約をかけないとそれは誰もがアクセスできるものになってしまいます。
ルール上、「example.jp, example.com」といった、「example」というドメインはドメイン登録できない(しない?)ことになっていますので、テストで使う場合は「example」を使ってみてください。
よくテストで使われる「hogehoge」は実際に使用者がいるのでなるべく避けたほうが無難です。
- whois 実行結果
Domain Name: HOGEHOGE.COM Registry Domain ID: 1979393_DOMAIN_COM-VRSN Registrar WHOIS Server: whois.jprs.jp Registrar URL: http://jprs.jp/registrar/ Updated Date: 2018-01-26T17:30:19Z Creation Date: 1996-03-09T05:00:00Z Registry Expiry Date: 2019-03-10T04:00:00Z Registrar: Japan Registry Services Co., Ltd. Registrar IANA ID: 1485 Registrar Abuse Contact Email: gtld-abuse@jprs.jp Registrar Abuse Contact Phone: +81.352158457 Domain Status: ok https://icann.org/epp#ok Name Server: NS1.DNS.NE.JP Name Server: NS2.DNS.NE.JP DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of whois database: 2019-01-09T03:51:33Z <<<
今日はここまで。
DNS 勉強会資料 1日目:ドメイン名って何?(memo)(教育)
DNS をはじめよう 1日目
全体の流れ
以下の流れで話が出来たらいいな・・・
ドメイン名とは何か?
郵便で手紙を送る時に住所が必要であるのと同様に、 インターネットでは、電子メールを送ったりウェブサイトを見たりするために、 相手がインターネット上のどこにいるのかを特定する必要があります。 ドメイン名は、言ってみれば「インターネット上の住所」にあたるものです。(https://www.nic.ad.jp/ja/dom/system.html より抜粋)
ドメイン名を使ってインターネット上でやりとりを行うためには、 これをコンピュータ同士が通信するために必要なIPアドレスに変換させなければなりません。このドメイン名とIPアドレスを対応づけるしくみがドメインネームシステム(DNS)であり、「インターネットの住所録」にあたります。(https://www.nic.ad.jp/ja/dom/system.html より抜粋)
ニュアンスですが panmania.hatenadiary.com を例にとると、以下の感じ。
- panmania 新宿区西新宿1-1-1
- hatenadiary 東京都
- com 日本
com だから日本、とか、そういうことではなくて、ニュアンスですニュアンス。考えずに感じてください。要するに、住所が特定できる=ページを特定してアクセスができるということです。
ドメインの構成
ドメインの構成は、以下のページを参照してください。私が頑張って説明するより丁寧且つ詳細です。
先ほどの panmania.hatenadiary.com を例にとると、以下のとおり。
* panmania 新宿区西新宿1-1-1 第3レベルドメイン(3LD)
* hatenadiary 東京都 第2レベルドメイン(2LD...言うかな)
* com トップレベルドメイン(TLD)
ドメインの一番最後、.com や .jp などを基点に、それより左を2,3 とカウントアップします。 panmania などの部分を「ラベル」ともいうが、TLD の L はレベルなので間違えないように。
- 混乱のもと
ドメインの種類ってどんなものがあるの?
- gTLD (参考 : https://www.nic.ad.jp/ja/dom/types.html#kinds-gtld)
- 世界の誰もが登録できる「.com」「.net」//「.org」
- 登録にあたって一定の要件が必要とされる「.edu」「.gov」「.mil」「.int」
- 新gTLD「.biz」「.info」「.tokyo」「.name」「.pro」「.museum」「.aero」「.coop」「.jobs」「.travel」「.mobi」「.cat」「.tel」「.asia」「.post」「.xxx」
「.com」「.net」//「.org」の間の // はわざとです。次回書きますが、この二種は(多分現在も)レジストリが異なります。
レジストリが異なることによる問題も後半でてくるので、あえてこのような記載にしています。
今日はここまで。
DNS 勉強会資料 0日目:準備(memo)(教育)
DNS をはじめよう
経緯
ソフトウェアテストエンジニアとして、DNS サービスの検証を行っています。 というより、今年から前任から引き継いで検証することになりました。
元々少人数体制だったところからの引継ぎのため、まずは本格的に評価に入る前に自身も含めメンバーの知識底上げをする必要があり、その取り組みの一環として毎週1回 DNSトークをすることになりました。
その資料まとめを、ノウハウをまとめる意図もあってブログにまとめることにしました。
1 回 5-10分程度のトークになるので、ブログもその単位で作成していこうかと思います。
一般的な DNS の知識の説明
参考URL集
Japan Network Information Center - JPNIC
- 全てまとまっているので究極他のページは見なくてもいいくらい
RFC1034 ドメイン名−概念と機能
RFC1035 ドメイン名−実装と仕様書
- 1035 のほうが見る機会は多いかもしれない。いずれにしても基本となるページ。 英語が読める人は原文を読みましょう。
JaSST Review'18 S2 (memo)
目次
このページの概要
一気に書き上げようと思ったら書ききれなかったので、S0,S1 と S2,S3 を分けることにしました。 今回は S2。
S2) レビュー再定義
- レビューの目的
- 品質担保、バグをみつける
- コードの均一化
- スキルの低いメンバーの教育
- スキルトランスファー?をするため
- 分類
- 検査:品質担保
- 学習:ナレッジ共有
- 強化:リファクタリング、もっとよく、もっときれいに
- 目的達成できてる?
- レビューの目的と実際にレビューをしている人のコメントの間で相違があることがある
- 実際のコメントにしかないもの:コードの理解、コミュニケーション
- レビューの目的と実際にレビューをしている人のコメントの間で相違があることがある
- レビューは楽しいですか?
- やらなくてはいけないこと
- やるべきこと
- やりたいこと
- やらなくてはいけないことに話が集中しすぎてつらくなる
- 実際にはやらなくてはいけないことですら難しい...
- モブプロを通してもっとわくわくするレビュー!
- モブプロを初めてレビューが不要になった
- でもレビューはやっぱり必要
- モブプログラミングを通してもっとわくわくするレビューについてのアイデアが出てきた
- 働き方モブプロ
- 9:00-11:00 個人時間
- 以降全部モブ
- 分担作業
- 分担作業の前後に同期をとる作業が必要になる
- 前:キックオフ 後:レビュー
- これ忘れがち
- ミスコミュニケーションにより手戻りが発生する可能性もある
- 働き方モブプロ
- 分担作業とモブワークの違い
- 向き不向きがある。同期コストがかからないのであれば、分担でもいい
- 分担する=生産性が高いという思い込み
仕事や状況に合わせて使い分けている - モブワークをすると、工程としてのレビューは不要になった
- レビューによる忖度がストレス源
- チームの最善を目指す
- 分担:誰がやっても難しい作業も、アサインされたら誰かが頑張らなきゃいけない=つらい
- モブ:誰がやっても難しくてもチーム全員で割り切って判断して対応することができる
- モブプログラミングはチーム全体の活動
- チーム全体で立ち向かってダメなら仕方ない
- 判断をチームですることができる
- 絶対なる安心感とそこから学ぶ姿勢
- モブプログラミング学習
- 結果だけじゃなくて過程を学ぶことができる
- 分担:同期(ナレッジ残す的な)しなければ、個人の学びに過ぎない
- 経験値が低い人をドライバーにすると、わからなければ手を止める権利があるのでわからないところが見えやすい
- ノウハウの Just in Time!
- 我々に必要なレビュー
- Pull-Request
- モブ振り返り
- 今日の仕事は最高だった?
- どう改善するか
- それは今やること?
- 次はどういうことを学ぶべき?
- Re-View (再び、見る)
- モブじゃないレビューは本当に Re-Viewだった?
- 実際にはファーストビューである
- 初めて見る場合は理解するコストが必要
- モブじゃないレビューは本当に Re-Viewだった?
- リアルタイムとレビューの強み、弱み
- 強みと弱みが補完関係にある
- レビューの再定義
- 自分たちのレビューを見直そう
- そのプロセスでの解決に固執しなくてもいい
- 目的を達成するために、そのプロセス自体をやめるという選択肢も常に頭に入れておく
- 実際にやらなくてはいけない、からの解放
- 無限にわいてくる やらなくてはいけないことに対して、有限のリソースで向かっている きりがないし、目指したって無理、つらいしギスギスする
- ROI を考えて自分たちにできることをする
- ダメなら仕方ないという割り切り
- 最善を尽くしても失敗したときはそこから学ぶ
- 変化に適用する
- 他人にうまくいったことが、自分たちにそのまま当てはまるとは限らない
- チームの練度や状況によって最適解は変化する
- 一度定義しても時がたったら見直す
- 情緒を大事にする
- 小手先のテクニックでどうにかできると思わない
- 人間であることを楽しむ
- 完璧ではないけれど成長できる
- 楽しいと楽しくないのインパクト
- 楽しくないとやめるのでは
* 楽しいレビューを考えよう!!!!
S2) 私見
モブプロ推し、というわけじゃなく、モブプロを通して学んだこと、その結果必要なレビューについての話でした。
私が大事そうだと思ったところは赤字にしておきました。 自分の中の結論としては、現在のチームでモブテスティングは難しい。テストの専門会社として、お客様先に入ってテストをしているので、モブテスティングを「やってみる」というのがまず超難関。 ただ、基本的に全部仕事をするうえで大事なことだなと思いました。特に時間とお金とリソースが許せばいくらでもやりたいことがわいてくる中でレビューにどこまで時間をかけるのか。
あとは、チームリーダーとして作業を見積もる際に忘れがちな「作業の同期」にかかわるコストの存在を改めて「コスト」として認識できました。
他、モブテスティングを研修で使えるんじゃないかということ。
レビューという軸からはちょっとずれてしまいますが、今いるメンバーのスキルが上がれば、畢竟レビューの質も上がるはず、という強引理論。
モブテスティングを通して、要求分析~テスト実装(あるいは実行、報告まで)をチームで行い、テスト初心者の教育、新ドメインに入るメンバーの育成などが行えるのではないか、と考えました。
実施するとしたら恐らく1日がかりになるでしょうし、すぐには難しいことと思うのですが、私が参加したいですw
なお、やり方次第ですが、WACATE 2018夏で同じようなことをしていたチームがあったと記憶しています(うちの班は分担を選びました)。
次に WACATE に参加する機会があれば、モブテスティングを提案してみたいです。