ProgateのWeb開発パス（Ruby on Rails）でHTMLについて勉強する！
4月上旬から新型肺炎の影響を受けて在宅勤務になりました。
それまで残業が常態化しており、なかなか自己研鑽に励むことができず...
在宅勤務になってからは通勤時間もなくなり、また残業もほぼ0時間になり
これはチャンスだと思い、以前からseleniumを触るに当たって興味のあった
HTMLを勉強することにしました。
勉強前のマーガリンの
HTML・CSS・Ruby on Railsの理解度
HTML
・今まで勉強したことはない
・なんとなく「あ、こんな風になっているのね」と分かっている風
→ Seleniumでイジっているうちにそうなった感じですCSS
・なにそれ状態Ruby on Rails
・Rubyは聞いたことあるけど、"on Rails"ってなんやねん状態
なぜ勉強することにしたのか
単純かも知れませんが、Seleniumを使っていく上でHTMLの知識は必須だと考えたからです。
- テスト自動化といったら、Seleniumが有名だし、使いこなしたい（普段はUFT*1使っています）
- Selenium を使いこなすためには、プログラミング知識は当たり前に必要
- だけども、HTMLの知識がなかったので「タグ？」「xpath？」って状態になった
- pythonとかプログラミング言語よりも先にHTMLだな！
のような流れでHTMLを勉強することにしました。
Progateを選んだ理由
以前から使っていて、初学者と思ったからです（単純）
Progate | プログラミングの入門なら基礎から学べるProgate[プロゲート]
勉強記録
2020/4/20に学習をはじめました。
基本は業務後の夜間。
勉強時間は決めず、集中力が切れるまで取り組みました。
初級編
2020/4/24 初級編 修了
1日平均40分実施しました。
HTML & CSSは初学者だったのですが、
分かりやすく
楽しみながら
学習することができました
「HTML & CSS 学習コース 初級編」コースを修了しました！ https://t.co/uLfhZ806j3 #Progate
— マーガリン (@Y_MAGARI000) 2020年4月24日
中級編
2020/4/25 中級編 修了
初級編に続きとても分かりやすく、楽しみながら学習することができました。
これまでHTMLについてほぼ分からない状態でしたが、
今はYahoo!のホームページの開発者モードで見て、
「なるほどね、こう作ってるのか」なんて思うことができるようになりました。←なに様やねん
「HTML & CSS 学習コース 中級編」コースを修了しました！ https://t.co/lA9m5ZBBuO #Progate
— マーガリン (@Y_MAGARI000) 2020年4月25日
Ruby on Railsについて
私が取り組んでいるのは、タイトルにもある通り
Web開発パス（Ruby on Rails）というコースになります。
正直HTMLが学習できればなんでも良かったので、これを選びましたが
少し興味が出てきたので、こちらも学習しようかと思いました。
また、学習したら記事にしようかと思います。
おわりに
この記事は私自身のメモと記載しておりますので、とても読みにくいものとなっているかと思います。
なので簡単にまとめを書いて終ろうかと思います。
メリット
■ Progateでの勉強は初学者にとてもオススメ
■他の教材を用意しなくても、十分勉強できる
■環境構築不要でWeb上だけで完結している
■スマホでも勉強できるので、心理的ハードルは低め
デメリット
■説明のスライドがDLできない
■セッションのまとめページがなく、振り返るのが大変
■実際に手元で開発する場合の環境構築に触れられていない
個人的に初心者が挫折するポイントの一つに環境構築があるかと思います。
その点がフォローされていれば、より良い学習コンテンツかと思います。
以上ですー
プロジェクトマネジメントについてのメモ
2019年の9月くらいから、チーム内の小さいながらもプロジェクトを任せられるようになり（2〜4人）、 2020年からはある程度大きな（って言ってもステークホルダーが全部で10人くらい）のプロジェクトのマネジメントに携わることになった。
まだ立ち上げ時期なのだが、ここまでのプロジェクトマネジメント（面倒なので以降「PM」とする）についてメモとして、 色々とここに書き連ねてみようかと思う。
(20/1/22：1回目の更新)
プロジェクトマネジメントの目的
QCDを達成して、プロジェクトを完了すること
Q：Quality（品質）
C：Cost（コスト）
D：Delivery（納期）
プロジェクトマネジメントで有名なPMBOK（ピンブック）1でも、このQCDについて触れられています。
-
プロジェクトマネジメントを体系的にまとめたやつ。詳しくはWiki参照(ja.wikipedia.org)↩
Agile QA Night #2 参加レポート
このブログ内で「〜やります！」とか「いつかまとめます」とか書いていますが、なかなか進んでないマーガリンです。
今年も半分が過ぎてしまったので、そろそろ本格的に取り組んでいこうと思う次第であります。
さて、久しぶりに社外イベントに参加してきました。
今回参加したイベントは下記になります！
Agile QA Night!! 2
はじまりました！#D3QA
— マーガリン (@Y_MAGARI000) June 20, 2019
ちなみにtwitterでのまとめ（toggeter）は下記になります。
私（@Y_MAGARI000）も呟いておりますよー
＊ブロッコリー🥦さんには大変感謝です。
さて、今回はAgileにおけるQAのあり方について、今回は３名のゲストが登壇してくれました。
えっちゅーさん、コヤマンさん、まつさん
前回の第一回は満員だったため出ることが出来なかったので大変楽しみでした。
えっちゅーさんの発表はこちら
今回の発表は私も参加した、「wacate2018冬」で発表されたものを一部修正したものでした。
某複合機メーカ、X社で組み込みマニュアルテスターのえっちゅーさんがWeb系の自動テストエンジニアになったお話でした。
- 組み込み系の第三者評価をしていた。開発体制はウォーターフォール開発
- スクリプトテストのマニュアルテストしかしていない
- プロジェクトの期間も長く、テスト工程が２〜３ヶ月あることも。
- 「自動化をやりたい！」でWeb系企業に転職。開発体制はアジャイル開発。
実は私も前職でえっちゅーさんと同じ現場で仕事をしていたの、この組み込み系の話はとてもよくわかりました。（辛いこととか苦しいこととか。。。）
そして私も転職後は同じ自動化エンジニア。（エンプラ系ですけどね）
転職後に思ったことが、とても似ていたこともあり、非常に面白い発表でした。
前職と現職の違い
ざっくり表にまとめて見ました。
| 前職 | 現職 | |
| 開発体制 | ウォーターフォール | アジャイル・TDD(BDD)で開発 |
| サイクル | リリースまで１年くらい *テストは2ヶ月くらい |
基本的には、週１回 |
| 対象 | 組み込み系 | Web系 |
| テスト手法 | マニュアルテスト | 自動テスト＋マニュアルテスト |
| テスト内容 | チェッキング | リグレッション系は自動テスト 探索的テストはマニュアル |
| 仕様書 | 機能別に仕様書がある... | ドキュメントは少なく、 自動テストの記述内容が仕様書 |
転職して気づいたこと
前職と現職では、対象システム・開発手法の違い・仕様書の有無・テスト手法の違いなどが大きいという発表でした。
大きく環境が変化しても、JSTQBに書かれているようなテストの基本となる考え方は変わることなく、環境は変わってもテストへの関わり方は変わらないということには強く共感しました。
私自身も同じようなキャリアを経ていますが、今までテストについて勉強してきたことは、アプローチは違えど、基本的に適用することが出来ていますし、なんとかやってきています。
全然色の違うプロジェクトであろうと、以前経験してきたことが思いも寄らないところで活用できたりと、むしろ別の分野を経験したことが＋になることが多いとも思っています。
この発表は同じようなキャリアの人には「だよね〜」ってなるし、
一社しか経験していないとか、一つのプロジェクトにずっと関わっている人には、とても有意義な発表だったのではないかと思います（なぜ上から目線なんだ...⬅︎）
コヤマンさんの発表はこちら
コヤマンさんは先日のJaSST東北で基調講演をされていた大物（体も大物...！）です。
私も短い期間でしたが、陸上自衛官をしておりましたので、なぜか勝手に親近感が湧きました。
さらにさらに、某複合機メーカX社で一時期働いていたこともあったとか。。。
えっちゅーさん、コヤマンさんとはなんだか似ているキャリアだなぁと発表中に思っていたマーガリンです。
さて、今回の発表は、えっちゅーさんとも共通することがありましたが、次のようなものになっていました。
ウォーターフォール型とAgile型の違い
| WF | Agile | |
| プロセスと役割 | 会社標準で決まっていた →計画重視 |
できること全部 →価値・スピード重視 |
| 周囲の意識 | 計画重視 | ユーザーの価値を重視 |
| 時間の使い方 | 調査 | 議論・会話・探索 |
これは本当にそう思いました。
以前は社内でそれぞれ、誰が何を担当することが明確に決まっていました。
テスト設計はテスト設計者が。テスターはテストを。開発は開発だけを。
全員の共通目的は納期までに社内標準で決まった項目をパスしてリリースすること。
認定スクラムマスターを取得するのにあたり、受講した研修では、
何に重きを置くのかを考えさせられる時間があり、目から鱗が落ちる気分でした。
そのプロジェクト・機能をリリースしてどうしたいか。
上から言われたからなのか、それとも利用してくれるエンドユーザーのためなのか。
話を聞いている最中は、こちらも同意しかありませんでした。
WFとAgileで変わったこと、変わらなかったこと
- テストをすること！
- 製品の目的・存在意義が大事であること
- テストは状況次第
- 「開発チームの認識の外側をフォローする」こと
特に最後の１行は大切だと思います。
とある機能に対して、開発は「正しく動くこと」に意識が向くかと思います。
これに対して、QAは同じく「正しく動くこと」を見ているだけではいけない。
そうコヤマンさんはお話されていました。
意識が向いていない分野。例えば、その機能で〇〇はどうなるんだろう？とか
どのような影響を与えるのかを発言することで、喜ばれるし、そのような関係になるべきと。大大大大賛成です。
コヤマンさんのお話で、改めてQAとは？と考えるキッカケになりました。
まつさんの発表はこちら
テスターちゃんの生みの親である、まつさんは唯一同じ現場（某X社）を経験していない方だったので、とても新鮮な内容でした。
まつさんが経験してきたAgile
【 餅つき型 】
— マーガリン (@Y_MAGARI000) June 20, 2019
機能できました！
⇅
テストします！
の繰り返し
（これは疲弊するなぁ）
| # | 名称 | 概要 | その他 |
| 1 | 餅つき型 | 開発⇄テスト 機能ができらたテストをする。その繰り返し。 切れ間なくテストが続く |
繰り返しやるので、トラブルが出るとお互いに疲弊する |
| 2 | 管理メイン型 | スプリント前半：開発 スプリント後半：テスト 工程が分かれているので、管理が容易 |
スプリント内で小さなWFが回っている。 なんちゃってAgile |
リリースサイクルが早いのが問題。どうテストをするのか・・・
まつさんの改善策
最初はJSTQBに記載されているテストプロセスを適用。
だが、これではやる作業が多く、早く回っているスプリントでは時間が足らず、
辛くなってくる。（辛いことは続かないのよ〜）
そこで！下記のような一連の流れで進めた！
- 仕様書をみんなで読む
- みんなでテスト観点を出す（出なかったら赤いテスト会s...(自重)
- テストケース作成
- 探索的テスト（１回目）
- スクリプトテスト
- 探索的テスト（２回目）
- リグレッションテスト（自動化）
- リリース後テスト
詳しくはツイッターを見てもらえるとわかりやすいかも（体力切れ）
まとめ
久しぶりイベント出たけど、外に出て話聞くと"気付き"が得られて良いですね。
— マーガリン (@Y_MAGARI000) June 20, 2019
モチベが上がる。
うまく言語化できないけど、外に出て、いろんな事例や発表を聞くことで、
いつか「これ進◯ゼミでやっったこと（聞いたこと）あるやつやー！」って思えることがあるかもしれない。
また、自分の今の立ち位置（レベルとか）も計測できるし、やること・やるべきこと・やってみたいことが見つかるのかも。
何がいいたんだろう。。。まとめになっていない。。。
ニポンゴムツカシイ。。
発表者のそれぞれの発表は準備など考えると大変な作業だったかと思います。
時間をかけて作ってくれた資料に込められた熱意の全部は難しいかもだけど、
一部分でもいいので、自分のものに落とし込めればなと思いました。
今度は自分が発信して、世のためになりたい！ と密かに思っていますので、
その時がきましたら、何卒よろしくお願いします。
macbookへのjavaインストールとsikuliXの導入
経緯
研修用にJavaで動作する「sikuliX」を使う必要があったため環境構築を行った。 ここでは、環境構築した際に参考にしたページをメモとして記載します。 ＊詳細はいずれ書きます（フラグ）
Javaのインストール
参考ページ eng-entrance.com
sikuliXのインストール
参考ページ
Pythonでスクレイピングするための環境構築（VSCode + Selenium + Python）
自分メモ用に投稿します。
VSCodeでPythonとSeleniumが動く環境を構築する
はじめに
タイトルにスクレイピングとありますが、せっかくなのでSeleniumも入れて普段の学習にも使えるように環境構築をしようと思います。
＊自分用のメモなので、拙い部分についてはご了承願います。
注意事項
スクレイピング*1をする場合、サーバー側に負荷をかける行為です。
またスクレイピングをするデータには著作権など権利問題が絡むことがあります。
過去には訴訟にも至ったこともありますので、法律や利用規約、マナーを守って行いましょう。
下記の記事内に注意事項が記載されていますので、読んでみましょうー
環境
今回環境構築に使う環境やツールは以下の４つを使います。
それぞれDL用サイトのリンクを貼り付けていますので、DLをしてください。
なお、ここでは詳しいインストール方法については記述しません。
ぜひググって調べてみてください。
私が書くよりも何倍も分かりやすいページがあるはずです。
Visual Studio Code
Visual Studio Code（以降「VSCode」と呼びます）
基本的に最新版を取得すれば大丈夫
Python
最新版を取得すれば大丈夫。
ただし、PythonにはVer.2.X系とVer.3.X系があるので、Ver.3.X版を入れてください。
Selenium
Seleniumは何かexeとかをDLするのではなく、Pythonのパッケージ管理システム(pip)を利用して取得します。
このpipはPythonをインストールすることで自動的に取得出来るので、特別何かをする必要はありません。
Selenium WebDriver
Seleniumを使う場合、各ブラウザごとにドライバーを用意する必要があります。
ChromeならChrome用、Firefoxならfirefox用など。*2
インストールした後の設定
1. VScodeを日本語化にする*3
- 起動直後、左側に見える四角いアイコンをクリックする。■←こんな感じの
- MARKETPLACEが表示されるので「Japanese Language Pack」を検索。
- 「install」（緑色の小さいやつ）をクリックする。
これで再起動すると日本語になっているはずです。
2. VScodeの【 拡張設定 】にPythonを追加する
- 起動直後に、左側に見える四角いアイコンをクリックする。■←こんな感じの
- MARKETPLACEが表示されるので「Python」を検索。
- 「install」（緑色の小さいやつ）をクリックする。
3. コードを書いてスクレイピングしてみる。
スクレイピングするサイトは以下の場所を拝借。
なおくれぐれもスクレイピング には、冒頭でも書いたよう注意事項を理解してから行ってください。
scraping-for-beginner.herokuapp.com
ブラウザを起動する→上のリンクのサイトにアクセスする→表示されている値を取得する。
#Chromeを開く。もし動かなかったら、()の中にWebDriverがあるパスを記述する
#（）の中に記述したURLの場所にアクセス
#ターミナルにWebページのタイトルを出力する
print(driver.title)
# ブラウザを閉じる。じゃないとブラウザが起動しっぱなしになってリソースを食うので。
driver.quit
そのほかの操作については、以下の記事を参考にすると分かりやすいです。
以上
Pythonでスクレイピングするのに使うもの
Pythonでスクレイピングするのに使うものと、ちょっとした使い方をメモとして記述する。
＊スクレイピングする際は、操作するWebページの利用規約などを確認してからやりましょう。くれぐれも迷惑をかけてはいけません。
Pythonでスクレイピング
スクレイピングとは
簡単に言うと、Webページに表示されているデータを取得する技術のこと。
APIがなくてもデータ取得できるし、必要なデータに絞って取得できるのが強み。
スクレイピングを実現する技術一覧
ブラウザを操作する
puppeteer
html.parser
lxml
html5lib
BeautifulSoup4
pyquery
今度使ってみての感想を記事にしようかと思います。
テスト自動化の8原則について
業務でテスト自動化を行なっているのですが、基本となる「テスト自動化の8原則」について、
たまに忘れしてしまうので、改めて書きまとめてみようかと思います。
ここに書くのはあくまでも私自身の解釈であり、所属する組織などとは一切関係ございません。
*むしろ違っていたりしたら教えてほしいです。
詳しくは、テスト自動化研究会の記載されているページでご確認ください。
テスト自動化の8原則
1. 手動テストはなくならない
自動化が優れていても、人間でしか出来ないテストはもちろんある。
例えば、ユーザビリティテスト。
自動テストで不具合が見つからなくても、使い勝手とかは人間でないと判断できない。
2. 手動でおこなって効果のないテストを自動化しても無駄である
これは書いてある通りではないでしょうか。
意味のない手動テストを自動化しても、自動化するのにお金と時間がかかるだけで、
なんの効果もないでしょうし。
3. 自動テストは書いたことしかテストしない
書いてある通りで自動テストは人間とは違い、書いてある通りの動きしかしない。
これが人間であれば、「ログイン画面でIDとPASSを入れてログインできること」とあれば、5人いれば5通りのことをするかもしれない。
だけど、自動テストでid:User PASS:Passwordと書けば、この通りにしか動かない。
（まぁ人間だと、たまにとんでもないことをやらかすこともあるけどねぇ。。）
4. テスト自動化の効用はコスト削減だけではない
何度も同じテストを実行する場合、コスト削減はもちろんできる。
例えば、既存システムに新機能を導入したいと言った場合、既存のテストは自動化。
新たに実装した箇所は手動+新しい自動化テスト。
こうすれば新たにバグが発生したときに、実装済みの自動テストを流せば、
同じ結果を返してくれるのでバグの修正にかかる日数や工数などが削減できる...はず
5. 自動テストシステムの開発は継続的におこなうものである
テストを自動化したから終わり！手動はやらないから人間は全員解雇！
なんてことには絶対にならない。
自動化することで、新しい仕事が生まれる。
機能の追加・削除、新しいテストケースの追加、実行結果の確認などなど
せっかく自動にしても、メンテしてないとかだと意味ない気がします。
「殺虫剤のパラドックス」と同じで、自動でやるところの質は上がるかもしれませんが、それ以外がおざなりになってしまいますし。
なにより、そのうちせっかく作った自動テストを使わなくなる未来が見えます。
6. 自動化検討はプロジェクト初期から
これは本当にそう思います。。
すでに手動でずっとやっているプロジェクトだと、既存のものに対して自動化するのって大変なんですよ。。
最初から自動化を前提として設計していればもっと楽になるのに。
7. 自動テストで新種のバグが見つかることは稀である
これは「3. 自動テストは書いたことしかテストしない」にも関わっていると思います。
既存の今まで動いていたシステムに対して、自動テストを流すことで、その機能がコピペミスで動かないとかは結構早く見つけ出すことは可能だと思います。
でも、多くの現場だと手動テストを自動化すると思うので、そうなると新種のバグが見つかる可能性は低くなるかと思います。
8. テスト結果分析という新たなタスクが生まれる
5のところでも書きましたが、自動テストを使うと、新しくテスト結果分析という仕事が生まれます。
自動テストを流した結果を人間が確認し、Passしているかを確認する。
Failedだとなぜ失敗したのかを調べます。
それが単純にシステムが落ちていたのか、バグなのか、それとも自動テスト自身に問題があるのか。これらの結果を分析しする必要が生まれます。
これが数件程度ならいいんですけどね....
*結果はFailedだけど「それはFailedになることが正しいから、FailedだけどPassだよ！」 っていうものもあったり。。。
ソフトウェアテストの7原則と同じで、テストに関わる人なら知っていないとダメな原則だと個人的に思っています。
