QAからCSへレンタル移籍をしてきた話

はじめに

プロフィールでは「スニーカー好きのQAエンジニア」と書いていましたが、若干訂正があり…。
実は2019/06/10 ~ 2019/10/31のおよそ5か月の間、社内のカスタマーサクセス(CS)チームへレンタル移籍に行っていました。
なのでここ5か月弱くらいはほとんどカスタマーサクセスサポートがメイン業務でしたので訂正しておきます。
とはいえ振り返ってみると、QAエンジニアとしてはとても良い経験だったのでここに書いておきたいと思います。
(また、11月からはQAエンジニアとして再始動です。)

レンタル移籍の経緯

件のチームメンバーの退職&産休が重なり、局所的にメンバーが不足するということで、ヘルプのメンバーの招集がかかり、開発チームから自分とバックエンドエンジニアの二人でヘルプに行くことになった。
他の職種にチャレンジする際の注意事項として、伝えたいことは一言だけです。

望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。

今回はチャレンジに前向きなメンバーでヘルプに行ったため、二人とも非常に実りがある時間を過ごすことができました。
一方でもしそうでない場合は、トラブルになりかねない出来事だと思うので要注意。
ホントに注意。

CS(Customer Success)チームの仕事内容

Salesforce上のアプリケーションなのでユーザーのシステム管理者からComunity Cloud上であげられるサポートケースの調査・回答がメインの業務として行いました。
開発チームでの詳しい領域(勤怠管理)のケースを中心に割り振られて回答していました。
その他アカウント管理や、データ修正もあわせて実施。

この辺りはQAエンジニア前の前に運用プロジェクトのエンジニアとして働いていたこと、サポートチームが手厚い研修をしてくれたため、比較的すんなりと働くことができました。
また、偶然二人で行く形になったのですが、同じ境遇の同期(厳密には違うけど)がいるのはかなり良かった。
分からないながらも助け合うことができたり、互いにレビュー等ができたので、それもまた良い方向に作用したかなと思っています。

よかった事・悪かった事

〇:ドメイン知識がついた

サポートケースに回答する以上、質問を正確に理解して正しい回答をする必要がある。
製品に関する知識、Salesforceに関する知識、勤怠管理にまつわる業務知識、が質問者と同等の理解にないとケースには回答できない。
そのため、検証環境を用意して、実際に問い合わせ内容が再現できるか・案内した手順が実施できるか検証を行う。
この仕事は開発でのバグの再現確認等とかなり近しい仕事に感じられた。

違いとしては、QAの時はある程度で調査を切り上げてfixを担当するメンバーに任せることができたが、原因を突き止める(回答として伝えられる)まで調べる必要があるのが大きい。
結果としては粘り強くやることや、限られた時間の中で戦略的に進める力が養われ、自信の知識を整理やさらに深めるために有意義な時間となった。

〇:ユーザーの声が聴ける

人事や総務が片手間で対応する場合や、システム開発部の担当などシステム管理者といっても様々な属性があることが分かった。 そして、作る側にとって難しい仕様は大抵ユーザー側も理解するのが難しい機能になるということが認識できた。

また、ユーザーにとって、問題が製品部分なのか自身のブラウザやネットワークなのかは関係なく、「機能が使えない」という一つの状態になってしまう。 そして、往々にして状況を切り分けるための情報が足りていないことが多い。
そのため、サポートで切り分けやある程度は相手の気持ちになって状況の推理する必要がある仕事だということが分かった。
(ちなみに変に勘ぐってしまい検討違いの回答をする可能性もあるので、思い切ってきちんと状況を整理する等のコミュニケーション力も必要)

〇:様々な背景のメンバーと話せる&仲良くなる

前職で人事の営業だったり、歴戦の導入メンバーだったり、普段開発チームにはいないようなメンバーと話す・一緒に仕事をすることができた。
日々の会話の中で新しいインプットが入ってきたりすることで、また別の刺激になった。
サポートケース対応がないときは、仲良くなった営業メンバーが使う資料のデモ画面の準備を手伝ったり、開発メンバーの時とは違った種類の差し込みタスクは新鮮。

×:引継ぎは計画的に

突発的に移動してしまったので、残されたQAメンバーに負荷を与える結果になってしまい、本当に申し訳ないことをしてしまった。
本当に申し訳ない気持ちでいっぱいです。
結果的にお詫びの肉をおごることで難を逃れたが、きちんと仕事の引継ぎはするべきだと思いました。
あれ、でも…自分も肉おごられても良いのでは…。

まとめ

QAエンジニアに必要なスキルとしてはテストの技術といった「テクニカルスキル」のほかに「ドメインスキル」が重要だと思っている。
そういう意味でいうと製品のドメインや顧客の属性など様々な情報をインプットすることができたので非常に有意義な時間を過ごすことができた。

一方で、有意義な時間を送れたからといって全員が同じ経験をすべきかというとそうでないと思っている。
CSチームでのやりがいはお客様の成功(カスタマーサクセス)を通して感じれるかどうかがポイントになりそうだと思った。

自分の場合は、困っているシステム管理者がケースを通して課題を解決していく姿に立ち会うことで開発とは違ったやりがいや仕事の意義を見出すことができた。

一方で、開発チームとしてのやりがいというのは難しい機能・案件をリリースしたりチームに貢献したりすることで感じる部分だと思っている。 なので、互いにやりがい・難しいポイントが違うからこそ、合わない人が同じ経験をしたところでなんの実りにならない時間を過ごすことになってしまうので…要注意。

QAエンジニアの自分としてはとても良い経験だったので、ちょっと伸び悩んでて興味がある人はあえて新しい環境に身を置くことで新しい発見があるかもしれないと書いておく。
ただ、望んだメンバーだけ行くべきで、絶対に他人に強制してはならない。という一言に尽きるかなと思う。

【おまけ】QAエンジニアとしての活動+その他

CSチームに所属しながら…

勉強会を開いた&登壇したり…

【増枠】QuALiTy~QAエンジニアによるLT大会~ - connpass

speakerdeck.com

認定スクラムマスター研修受けたり…

会社のオフィスの引っ越しをしたり…

www.teamspirit.com

JSTQBテストマネージャ試験受けたり…

JaSST北海道で登壇したり…

speakerdeck.com

してました!
(意外といろいろやってた)

おわり

JSTQBテストアナリストの勉強方法を書いてみる。

はじめに

2月に受験したJSTQB Adavanced Level テストアナリスト試験の結果発表があり、見事に合格することができました。
今回の記事は合格までの道筋・勉強方法を書いていければと思っています。

 

JTQB Adavanced Level TA(テストアナリスト)試験とは

世界で最も普及しているソフトウェアテストの認定機関であるISTQB資格を日本で受けられるというもの。
現在日本で受けられる資格としては、Foundation試験(FL)・テストマネージャ試験(TM)・テストアナリスト試験(TA)がある。

Advanced Levelの試験については応募資格のレギュレーションがある

  1. JSTQB認定テスト技術者資格 Foundation Level資格の合格者、JSTQB(日本)以外のFoundation Level資格の合格者
  2. 業務経験3年以上(業務経歴申請書の提出あり)

f:id:riririusei99:20190407120328p:plain
ISTQBが定める技術体系

Certifying Software Testers Worldwide - ISTQB® International Software Testing Qualifications Board

JSTQB認定テスト技術者資格

Advanced Level試験/資格試験-JSTQB認定テスト技術者資格/日科技連|ソフトウェア品質|SQiP研究会

STEP0. 前回の受験

実は2018年もTA試験を受験して落ちています。

  • 動機:マネージャが受けるからとりあえず受けてみた(自腹だから落ちてもいいよねマインド)
  • 勉強:忙しさにかまけて、さらっとシラバスを読んだだけ
  • 試験当日: さーっと進めたら30分くらい余ったので先に帰った

この時点で受かる気がなさそうですが、当日の試験はテスト技法をあてこんだり、状況に応じて対応を判断するような実例問題が中心だったので「いつもの仕事の延長だ」とか「いろんなシステムを想定して問題が面白かった」とか「ワンチャン受かるのでは…」と試験を甘く見てましたが見事に落ちました。(マネージャは見事に合格しました)

という恥ずかしい失敗経験をかき消したいというモチベーションを元に今回の資格試験に臨んでます。

STEP1. 申し込み

まずはHPをよく読み、受付している期間に申し込みを行います。(仕事が忙しくなると、試験日は大体いつか覚えてられるが申し込みの締め切り日は忘れそうになるので注意。) 申し込み時にはFL認定証の写しやFLでの認定番号が必要になるので、あらかじめ準備しておく。(職場で申し込もうとすると大抵、手元にない) 初回受験時は業務経歴申請書を提出する必要がある(メールで案内が来る)ので、募集要項からダウンロードして作成します。

www.juse.or.jp

STEP2. テスト当日までの勉強パート

試験問題の結果は回収されてしまうのでどの問題が間違っててどの問題があってるのか分かりませんが、試験を受けてみての自分が正解・不正解してそうな部分が分かっていたので今回は自分の弱点になっていそうな部分(自信をもって正解といえる領域以外)について重点的に勉強することにしました。

カテゴリ分け・方針決定

ざっくりいうと、テストを受けた問題の傾向をカテゴリ分けし、それぞれの理解度を3段階でつけました。(下記参照) 普段の仕事ではストーリーチケットのテスト設計(限られた時間の中で網羅的な・かつステークホルダーの要求する品質を満たせるようなテストを設計)をしています。なので、テスト技法を当て込んでテストケースを作成する問題は得意ですが、業務で取り扱っていない知識体系の引き出しが少ないこと、テストマネージャとテストアナリストとしてスクラム開発では分けて考えていないため一緒に考えてしまって、それぞれが一般的なプロジェクト開発における棲み分け・役割分担といったところが曖昧になっていることという弱点が見えてきました。 試験に向けて、理解度が低いものから優先順位を高く定め、それぞれ学習時間の重みを変えて学習します。

正解してそうな領域(自信をもって正解といえる問題)

  • 普段使っているテスト技法を当て込む問題

たぶんあってると思う領域(多分これが正解!って答えた問題)

  • 普段あまり使わない技法、業務ではツールに任せてしまうテスト技法の問題
  • テストアナリストとしての振る舞いをこたえる問題

おそらく間違っている領域(わからない・回答の一部がわからなかった問題)

  • 知識問題
  • 業務の知識とシラバスの知識とで差異・言い換えながら解釈した問題

シラバスを読み込む

勉強といっても問題集等々が無いので基本はシラバスを読みこむことを行いました(読み込むといっても2周ですが)。シラバスで分からない単語・略称などについてはGoogle検索して、関係する発表やブログなどを読んで、自分の言葉で理解できるまで資料を読み、理解した内容をテキストに書き起こし、あとで読み返せるようにして学習していきます。そのため、シラバスを読み込むと言っても寄り道がほとんどなのでかなり時間がかかります。
とはいえ、時間がかかっても日々の業務改善などに使えそうな知識・考え方が入ってくるので有意義な時間なのでおススメです。

テスト技法の勉強

過去問セミナーTA

テスト技法についてですが、「問題文を読んで実際に使えるレベル」が求められている気がします。 そのため、テスト技法については読み込みに加えて、別に時間を取りました。
対象のシステムに対して複数のテスト技法を組み合わせて考えられる必要があると、当日の試験で自信をもって回答ができると思います。

おススメはJSTQBの過去問セミナーの資料を熟読することです。実際に出た問題を解説していること、資料の少ないクラシフィケーションツリーについて書いてあります。

過去問セミナーTA
http://jstqb.jp/dl/AL_Exam_Seminar_TA.pdf

技法を手になじませる

基本的なテスト技法(境界値分析・ディシジョンテーブルや状態遷移図)については試験で多くの問題が出てくるのですが、今回はシラバスを読んで自分の知識と差異がないか確認する程度にしました。
今回は優先度を下げましたが仮に勉強をするとして、テスト技法は誰か分かっている人に教えてもらう・自分のやり方を見てもらって指導を受けるのが身につく近道だと思っています。
自分の経験では以前に有料の研修に行きましたが、そこでテスト技法の使い方を学んだ経験が日々の仕事でも活きている気がしています。
最近ではテストコミュティのワークショップもたくさんあるので、そういったところに足を運んで手を動かすのもいいかもしれません。

よさげだと思うセミナーを列挙
日本全国対応のソフトウェア品質教育支援 | VALTES

JSTQB認定 ソフトウェアテスト技術者 ― Foundation Levelトレーニングコース | セミナーサイト | 日本科学技術連盟

WACATE : 若手テストエンジニア向け勉強会・ワークショップ

STEP.3 テスト当日

TA試験は180分60問の長丁場です。しっかり準備して臨んで分かりましたが、時間が足りません。計算だったり・確認に時間がかかる問題だったり、結構大変です。
ペース配分を考えながら受験するのがおすすめです。自分の場合は今回も問題を解いたタイミングで回答の自信度をカテゴリ分けしながら進めて、最後に怪しいところ・間違えてそうなところを見直すようにしました。 朝はしっかり食べないと後半考えられなくなるので、早起きしてきちんと朝食をとるのは大事だと思います。

おわりに

第4回の受験者は前回から220人増えて500人程になったということでテスト系の資格・QAという仕事も一般的になって来たのかなぁという印象です。
今回は考えられる準備をちゃんとして臨んだので落ちたときは、「分からない場所が分かっていない=何も分かってない」なので1から勉強し直しの必要があるという不安な日もありましたが無事に合格できてよかったです。
取得していない認定資格はテストマネージャもあるので、ゆくゆくは取得できたらなぁと思ってます。ほかにもスクラムで開発しているので、英語を勉強してアジャイルテスターの資格を取りたいなぁとか思っています。

状態遷移図・表の書き方&考え方

はじめに

状態遷移図の話を書こうと思いながら前回のブログから1ヶ月経ってしまっているので徒然と書くことにする。

状態遷移図とは

本を読んだ内で一番分かりやすかったのはテスト会社がやっていた有償のセミナーでエッセンスを聞いたのが非常に分かりやすかったんだが色々問題が歩きがするので、今回もwikipedia先生に解説していただく。

状態遷移図 - Wikipedia

Wikipediaを読んで分かったが自分が知っている状態遷移図というのはUML図におけるステートマシン図(state machine diagram、状態機械図)というものがルーツにあってそれを簡略化しているということが分かった。
今回はふんわり分かれば良いので簡略した書き事を書く。

書き方のルール

正しいお作法についてはwiki参照(UML)
今回はふんわり分かれば良いので下記のルールで書いた。(差分は赤文字)

  • 塗りつぶされた円が START(開始)を意味する。必須ではない。
  • 中抜きの円は STOP(停止)を意味する。必須ではない。
  • で状態を表す。
  • 矢印が操作・振る舞いを表す。

実際に書いてみる

テーマ

腕時計のストップウォッチ機能

f:id:riririusei99:20180921005935p:plain
※便宜的に上のボタンをA、下のボタンをBとする。

振る舞い(仕様)

  • 初期状態は針が0を指している状態
  • 初期状態でAボタンを押すと針が動き出し、計測開始する
  • 計測開始状態でAボタンを押すと針が止まり、一時停止する
  • 一時停止状態でAボタンを押すと針が再度動き出し、計測開始する
  • 一時停止状態でBボタンを押すと針が0を指し、初期状態へリセットされる

状態遷移図

振る舞いに書かれた情報を元に、状態遷移図を書くと下記のような図になるはず。
この時計にはAボタンには3つの機能があることがわかる。(計測開始、一時停止、計測再開)

f:id:riririusei99:20180921014221p:plain

状態遷移表とは

状態遷移図をもとに今度は操作の一覧を表に落とし込むのが状態遷移表である。 もしかしてこれもwikiありそう…と思ったらやっぱりあった。

状態遷移表 - Wikipedia

すご~くざっくり書くと

書き方のルール

  • 縦軸に現在の状態
  • 横軸に操作
  • 交わる場所に操作後の状態を書く

実際に書いてみる

STEP1:図から表に落とし込む

書き方のルールに基づいて図を表に落とし込むと下記の様になる。

状態/操作 Aボタン Bボタン
初期状態 計測開始
計測開始 一時停止
一時停止 計測開始 初期状態

交わったセルが状態遷移テストにおける一つのテストケースになる。
表では空白が2つできているため、想定結果がわからない状態(もしくは仕様が決まっていない状態)なのできちんと仕様を確認することが重要。
ここらへんの考慮漏れとかを早い段階で指摘するのがテスト設計での腕の見せどころかもしれない。

STEP2:足りない部分を落とし込む

足りない部分を追記したバージョン

状態/操作 Aボタン Bボタン
初期状態 計測開始 初期状態※1
計測開始 一時停止 計測開始※2
一時停止 計測開始 初期状態

※1: ボタンは押せるが、状態遷移しない
※2: ボタンがロックされるため、状態遷移しない

この状態で初めてすべての表が埋まりテス実施できるようになった。
今回は物理的な時計の話なのでどの状態でも常に2つのボタンを押すことができたが、そもそも操作ができない場合などは「N/A(not available)」と書いたりする。

まとめ

状態遷移図・表の書き方を書いてみた。
実際の業務では操作が複数の状態を起因にして違ったり、操作の数が多いとかあるので図や表が複雑になりがち。
本当はNスイッチの話もしたかったんだけどまた次の機会かなぁ。

おわり

c0,c1,c2カバレッジってなんだっけな話

はじめに

c0,c1カバレッジと状態遷移図のnスイッチの話が自分の中でごっちゃになってたので調べて自分の中で整理する話です。
※状態遷移図テストとnスイッチの話もしようと思ったが、長くなりそうなので今回はc0,c1カバレッジ

教えてwiki先生!!

Wikipediaがいろいろ書いててとてもわかり易かった。

ソフトウェアテスト - Wikipedia

なるほど、c0とかのカバレッジはホワイトボックスの手法なんだなと分かった。

  • 命令網羅 (statement coverage) (C0)
  • 分岐網羅 (branch coverage) (C1)
  • 条件網羅 (condition coverage) (C2)

自分の中で理解する

というわけでサンプルプログラムを書いてみた。

雑に書いたサンプルプログラム (Javascriptで引数は数値なイメージです。)

追記】 二個目の分岐の中でx,yを使用していたため、後述するテストケースでは網羅できなくなるため修正しました。

function outputTriangle(x, y, z){
  // 最初の分岐
  if(x>0 && y>0){
    var area = x * y / 2;
    console.log("底面積は" + area);
  }else{
    console.log("おやおやなにかおかしいぞ");
  }
  // 二個目の分岐
  if(z>0){
    console.log("体積は高さ" + z + "を掛けて3で割る!");
  }
}

命令網羅 (statement coverage) (C0)

「命令網羅基準を用いてテストを行う場合は、すべての命令を実行すればよい。」とのこと。(by wiki)
テストケースは下記になりそう。

  • x=2,y=3,z=4(面積、体積の表示)
  • x=0,y=0,z=0(例外)

分岐網羅 (branch coverage) (C1)

「分岐網羅基準を用いてテストを行う場合は、すべての分岐において、すべての分岐の方向を実行すればよい。」とのこと。
なるほどわからんな状態なので改めて整理する

最初の分岐 2個めの分岐 テストデータ例
true true x=2,y=3,z=4
true false x=2,y=3,z=0
false true x=2,y=0,z=4
false false x=2,y=0,z=0

こんな感じか。分岐を意識するんだな!

条件網羅 (condition coverage) (C2)

「条件網羅基準を用いてテストを行う場合は、各々の個別条件について、全ての可能な結果を少なくとも1回はとるように実行すればよい。」
ということで表に落としてみる。

No x>0 y>0 z>0 テストデータ
1 true true true x=2,y=3,z=4
2 true true false x=2,y=3,z=0
3 true false true x=2,y=0,z=4
4 true false false x=2,y=0,z=-1
5 false true true x=0,y=3,z=4
6 false true false x=-1,y=3,z=-4
7 false false true x=-2,y=-3,z=4
8 false false false x=-3,y=-2,z=-4

補足

なお、判定結果に影響を与えない真理値に関しては省略しても良い。と書いてあったのでこちらを考慮するとこんな感じでしょうか。

短絡評価
No x>0 y>0 z>0 テストデータ 結果1 結果2
1 true true true x=2,y=3,z=4 面積表示 高さを表示
2 true true false x=2,y=3,z=0 面積表示 表示されない
3 true false true x=2,y=0,z=4 メッセージ 高さを表示
4 true false false x=2,y=0,z=-1 メッセージ 表示されない
5 false true true x=0,y=3,z=4 メッセージ 高さを表示
6 false true false x=-1,y=3,z=-4 メッセージ 表示されない
7 false false true x=-2,y=-3,z=4 メッセージ 高さを表示
8 false false false x=-3,y=-2,z=-4 メッセージ 表示されない

x>0が満たされない時点でyの値は判定結果に影響を与えないので省略できる。 なので5,7と6,8は同じテストケースと判断する事ができそうなので省略する。

短絡評価後
No x>0 y>0 z>0 テストデータ 結果1 結果2
1 true true true x=2,y=3,z=4 面積表示 高さを表示
2 true true false x=2,y=3,z=0 面積表示 表示されない
3 true false true x=2,y=0,z=4 メッセージ 高さを表示
4 true false false x=2,y=0,z=-1 メッセージ 表示されない
5 false (true) true x=0,y=3,z=4 メッセージ 高さを表示
8 false (false) false x=-3,y=-2,z=-4 メッセージ 表示されない

5,6でもいいはずなんだけど個人的にこっちの方がいい気がするので5,8とした。
もっと言うと、3,4と5,8は結果が同じなので更に削ることが可能だよね!(今回はここまで)

こんな感じか。分岐の条件を意識するんだな!

その他のカバレッジ

その他にはこんなのものある様子。

  • 判定条件/条件網羅 (decision/condition coverage)
  • 複合条件網羅 (multiple condition coverage)
  • 経路網羅 (path coverage)

また静的解析でのカバレッジについては若干ニュアンスが違うので注意されたし。

コード網羅率 - Wikipedia

感想

プログラム的には体積の表示は最初のエラーが出た時点で計算ができないから表示させたくなかったのだけれど、意図的に変な書き方になっています。
テストデータに文字列とかを入れると結果がエラー内容が変わって来ちゃったりするのですがいろいろややこしくなるので今回は簡素にこんな形にしました。 理解はしていたつもりだったけど実際に書いて確かめるって大事だと改めて思いました。

Javascriptの単体テストを書く(power-assert)

はじめに

単体テストについてはE2Eを組む前段で用意してたことはあるのだけれど、真面目に書くことがなかったのでpower-assertを使ってテストコードを書くことに挑戦してみる。

参考

みんなのPowerAssert github.com

インストール

$ npm install mocha espower-loader intelli-espower-loader power-assert --save-dev

ディレクトリ構成

.
├── node_modules
├── package.json
├── src
│   └── Calculator.js
└── test
    └── test.js

対象&テストコード

Calculator.js

module.exports = class Calculator {
  constructor(name){
    this.name = name;
  }
  plus(x, y){
    return x + y;
  }

  minus(x, y){
    return x - y;
  }

  divide(x, y){
    return x / y;
  }
};

test.js

const Calculator = require('../src/Calculator');
const calculator = new Calculator('riririusei99');
const assert = require('power-assert');


describe('Test plus', function(){
  it('shoud return 3 when value is number', function(){
    assert(calculator.plus(1,2) === 3);
  });
  it('【ERROR SAMPLE】shoud return "12"', function(){
    assert(calculator.plus("1","2") === 12);
  });
});

describe('Test minus', function(){
  it('shoud return 3 when value is number', function(){
    assert(calculator.minus(5,2) === 3);
  });
  it('shoud return -2 when value is number', function(){
    assert(calculator.minus(3,5) === -2);
  });

});

describe('Test devide', function(){
  it('shuoud return 1 when value is number', function(){
    assert(calculator.divide(5,5) === 1);
  });
  it('shuoud return error when 0 divide', function(){
    assert(calculator.divide(5,0) === Infinity);
  });
});

テスト実行

power-assertのREADMEを参考に実行する

$ node_modules/mocha/bin/mocha --require intelli-espower-loader test/test.js

こんな感じで出力される f:id:riririusei99:20180608202737p:plain

おわりに

環境の準備は割とさっくりできた。
テストの書き方とかが大事なんだろうなぁというかんじなので、次回はもう少し複雑なコードに対してテストを書いてみるみたいなのをやってみたい。
CTFで作ったお遊びスクリプトとかがちょうど良さそう。

今回できたもの

github.com

Jenkins pipelineを触ってみた

はじめに

最近の仕事でJenkinsのデプロイジョブとE2Eのジョブの2つを作ったので、ここらへんでpipelineを使って2つのジョブをつなげて一目で確認できるようにとpipelineについていろいろ調査して挑戦しました。

ざっくりと書いたもの

実際はブランチの他にも組織名とかいろいろパラメータがあるのだけれど簡素に書くとこんな感じ。
ここまで実装するためにいろいろ調べて時間がかかった…もう見つけられないかもしれないと思うと怖くなったので、自分のブログに残しておく。

PipelineScrip

node {
     //  ステージを設定する
    stage ('build') {
        build job: 'build',  parameters: [
            //  ジョブに渡すパラメータを設定する
            [$class: 'StringParameterValue', name: 'BRANCH', value: 'ブランチ名']
        ]
    }
        
    stage ('test-setting') {
        build job: 'E2E-A'
    }
}

おわりに

Jenkins側のジョブを分けつつ、自動テストの粒度も小さくすることで「前のバージョンでデータを作って、最新バージョンにデプロイし直してテストする」みたいなこともできると思うといろいろ便利だと思いました。
バージョンアップテストとかってどうするのかって思っていたけれども自動化のアプローチとしてpipelineを活用するってのもありかもしれないと思いました。

参考

下記参考にしたもの

jenkinsのpipeline入門(jenkinsfile) - SIerだけど技術やりたいブログ

Jenkins2のPipline参考リンク集

【Jenkins】パイプラインからジョブを呼び出す際、パラメータを指定する - 自分の速さで

ParameterValue (Jenkins core 2.125 API)

readコマンドを使ってスクリプトを書いてみる

はじめに

普段使ってるシェルスクリプトはユーザー&パスワードはほぼほぼ固定なんだけど、たまに任意の入力を受け付けて実行したい時がある時の話。
調べたところreadコマンドを使うのがよさそうというのと…

shellを書く時にはたいてい記憶が空になっているので、自分のための備忘録。

read コマンドを使ってスクリプトを書いてみる

readInput.sh

#!/bin/sh

echo "ユーザー名を入力してね"
read inputUser
echo "PASSWORDを入力してね"
# -sでpass入力
read -s  inputPass

echo "$inputUser にデプロイするよ? y/n"
read input

if [ $input == "yes" ] ||[ $input == "y" ]
then
    echo "$inputUser で処理するよ"
    # 処理を書く
else
    echo "終了するよ"
    exit
fi

おわりに

作り終わったタイミングで、実務ではJenkinsのパラメータ付きビルドで同じ事を出来ることに気づいてしまった…。
何事も経験ですよね!ということでお茶を濁すことにします。。。。

おわり