開発者とバージョン管理の話をすると、ワークフローツールとしてのGitやコードと履歴書を保存する場所としてのGithubの話になるかもしれない。しかし、例えば、テスターやビジネスアナリストのような開発者と比べれば技術的ではない職種の場合、Gitは成果物とバグを生み出す魔法の呪文のように思えるかもしれない。しかし、テスターがGithubを使って個人的、または、仕事上でのプロジェクトに参画したり、既存のプロジェクトに貢献するのは有益なことだ。
Excelon Development氏でマネージングディレクターを務めるMatt Heusser氏とLaurel & Wolfでテストエンジニアを務めるChris Kenst氏は Spring Online Testing Conference 2017でGitHubに貢献することについて語った。
Heuser氏とKenst氏は、GitHubのアカウントを作り、貢献を始める方法を聴衆に示すことから講演を始めた。講演の動画は再生可能なので、一度動画を見て"要点を掴み"、2度目に見るときは、示された方法をなぞりながら、2人が実行したコマンドを手元で実行することができる。
InfoQは両氏にインタビューして、GitHubをコード以外で活用する方法、テスターがGitHubを使うことで得られる利益、テスターによるGithubやその他のオープンソースツールの活用を促進する方法について話を聞いた。
InfoQ: Githubはコード以外でも便利だと話していましたね。例を挙げてください。
Matt Heusser: テストの成果物、テスト計画、セッションノート、テスト方法などはバージョン管理の下に置けます。仕様書(例えば、HTMLやMS Word形式の)もGitHubに置けます。
Chris Kenst:Exploratory Chartersやチートシート、データ、あるいは、redditのような Ask Me Anything (AMA)を置くこともできます。GitHub Pagesを使ってウェブサイトを作成、ホストしたり(テスターはオンラインの世界でもある程度の存在感を出すべきです)、本を書いて公開することもできます。制限は創造性だけです。
創造性は事例によって刺激されます。少し紹介しましょう。下に紹介するのは、私が作ったり、見つけたりした、公開されているテスト関連の資材です。1つ目はElisabeth Hendricksonが広めたフォーマットを使ってExploratory Charterを書く方法とその説明です。3つ目は文字列が入力されるフィールドに入力されると問題を起こしそうな文字列の一覧です。これは面白いですよ。
テスト関連の資材の例
- How-to on Writing Exploratory Charters
- Putting Exploratory Charters in Github
- A giant list of strings to test with
GitHub Pageで公開されている事例はたくさんあります。1つ目はGitHubのプロダクトマネージャであるBen Balter氏の個人のウェブサイトです。2つ目はとてもシンプルなページでソーシャルメディアへのリンクがあるランディングページのようなものです。GitHubのウェブサイトのすごいのは、気に入ったらフォークして、少し手直しして、自分のサイトとして公開できるという点です。3つ目はオープンソースで、ソフトウェアテストのカンファレンスやワークショップの情報が載っている、コミュニティが運営しているサイトです。GtiHubへの貢献を始めたいなら、テストのカンファレンスに貢献するというのは良い選択肢かもしれません。
ウェブサイトの例
InfoQ: GitHubでコード以外のものを扱う場合、GitHubのすべての機能が使えるのでしょうか。
Kenst: すべてのプロジェクトはほぼ同様に扱われます。リポジトリを作れば、バージョン管理、Issues、Wikiなどの主要な機能を使うことができます。コードではなくても、プルリクエストを作り、少しづつ手を加えることができます。
Heusser: バイナリファイルのマージとdiff以外はシームレスです。ふたつのブランチのうちの最新のバージョンの一行を選ぶ、というgitの魔術はMS Wordのドキュメントには使えません。
InfoQ: テスターがGitHubを使うことにどのような利点がありますか。
Heusser: まず、開発者のワークフローを理解でき、開発者の言葉で話すことができます。これによって、テスターと開発者の間で軋轢が生まれにくくなります。次に、ビルドの成果物とコードそのものに対して、一歩近づけます。コードを少し読めば、ソースコードレベルでピンポイントでエラーを指摘できるかもしれません。よりしっかりとコードを読めるようになり、コードレビューにも貢献できるかもしれません。Chrisも指摘すると思いますが、Github自体をワークフローツールとして使うこともできます。プッシュされたものを承認したり、バグを整理したりできます。さらに、Githubのアカウントがあり貢献をしているということは公開されたポートフォリオです。雇用されやすくなりますし、顧客のリスクを少なくなります。
Kenst: その通りです。営利組織でも非営利の組織(例えば、Selenium Project)でもGitHubを使ってコードを管理しています。
これは、ますます多くのソフトウェア開発者がGithubのワークフローを仕事をするようになっているということです。このワークフローではコードの変更はプルリクエストを通じて提案され、テスターや開発者はコードの差分を視覚的に確認でき、マージする前に独立して変更をテストできます。自動テストもプルリクエストに対してさまざまなレベルで実行できます。これは、チームのテストとプロセスに巨大な利点を与えます。Mattが言うように、テスターがコードレビューに参加し、GitHub Issuesを使ってバグを指摘できます。
そして、ますます多くの組織やリクルーターがGithubのアカウントを候補者の評価に使うようになります。公開されているポートフォリオがあるのになぜわざわざ履歴書を見る必要があるのでしょうか。ポートフォリオにサイドプロジェクトや日常業務に関係のないものがあったとしても、履歴書だけよりはより価値のある材料になります。
InfoQ: Online Testing Conferenceでは、まず最初にGitHubへのサインアップ方法、プロジェクトの始め方、そしてどのように使うかを説明しましたね。なぜ、このようにしたのですか。
Kenst: 私たちのプレゼンの目的は聴衆がGitHubのリポジトリを作り、貢献ができるようにすることでした。時間の制約があることを加味すると、まずデモをして、それから付随する背景情報や事例を紹介するという方法になりました。
Heusser: 開始するとデモが長く、追加の資料はもっと長かったです。時間切れになるのではと心配しました。うまく切り詰められたと思います。また、ほとんどChrisがやったのですが(笑)。
InfoQ: テスターがGithubのようなオープンソースのツールを使うことを促進したいと考えている人にアドバイスをお願いします。
Heusser: 良い質問です。正直に言って、"まずやってみろ"と言ってみたり、"なんでテスターは新しいツールを使わないんだ"と言ったりするリーダーやコーチをたくさん知っています。テスターとペアになって新しいツールを使えるようになるのを支援するのがいいでしょう。GithubでもSeleniumでも構いません。思っていたより難しく馴致する時間が必要でサポートするのが正しいと感じるかもしれません。あるいは、簡単でペアになって支援することで抵抗を克服できるとわかるかもしれません。いずれにしろ、成功です。
いくつか、アドバイスがあります。まず、プロジェクトを始めましょう。型からコーディングを学びます。ループ文についてのGoogleで検索して情報を探すことと、実際に書いてみることの違いは巨大です。型となるコードを何度か実行してみることで経験が得られます。私の型のリポジトリをフォークして、katagenerator.rbを実行してみてください。ローマ数字を十進数に変換する簡単なコードです。コミットしてプルリクエストを追加してください。これで実際にプロジェクトへのコミットの仕方がわかりました。
次にソフトウェアが必要になり、予算獲得のための長く辛い道のりを歩み始めるなら、代わりにオープンソースを探しましょう。SeleniumはUFTの代わりになります。プロジェクトを探し、貢献できるかどうか探ります。バグの報告でもいいでしょう。単なるバグ報告でも、gitのフローの別の側面を学習できます。
Kenst: テストツールについて言えば、この10年の最大の進歩はオープンソースコミュニティによって成し遂げられました。Seleniumはウェブアプリケーションテストの標準(今はW3C標準になろうとしていますstandard)です。モバイルアプリ自動化ではAppiumが同じ位置を占めようとしています。また、私たちが感謝したいブラウザやブラウザツールもオープンソースコミュニティ(例えばChrome)から生まれています。Gitもそのひとつであり、オープンソースです。
関係を持ち続けるためには、テスターはこれらのプロジェクトを追いかける必要があります。これらのプロジェクトはどこで見つかるでしょうか。もちろん、GitHubです。
Rate this Article
- Editor Review
- Chief Editor Action