Better Software Testing

ソフトウェアテストをもっと良くしたい

はてなブログの記事を無作為に選択、ツイートするbotを作った

まぁ大した記事なんて書いてないわけだけど、それでも、せっかく書いたものを腐らせておくのは勿体無いなぁと思った次第。
だらだら書いて丸一日かけてしまったけど、やってることは特に難しくない。


実行フロー：

  1. はてなブログAPIを使って、最新記事10件の情報（タイトル、URL、その他）を取得する（はてなブログAtomPub - Hatena Developer Center）
  2. 最新記事10件の中から1件を無作為に選択する
  3. 選択した記事のURLをtwitterに投稿する（Twitter API | Products | Twitter Developer Platform）

これをAWS lambdaにセットし、毎朝9:00に実行するというもの。
せっかくなのでソースコードを公開しておきます。
python50行弱で書けたので、興味のある人はやってみるとよいと思う（記事最下部参照）。
いやー、年末年始休暇の工作としてはちょうどいい感じだったな。
ちょっとした達成感が得られてよかった。

f:id:katsu-ichiro:20211231100105p:plain
実行例
import requests
import xml.etree.ElementTree as ET
import random
import tweepy
import datetime

def tweet_random_post_title_and_link(tweet_message):
    # 認証に必要なキーとトークン
    API_KEY = 'XXXXXXXXXXXXXX'
    API_SECRET = 'XXXXXXXXXXXXXX'
    ACCESS_TOKEN = 'XXXXXXXXXXXXXX'
    ACCESS_TOKEN_SECRET = 'XXXXXXXXXXXXXX'

    auth = tweepy.OAuthHandler(API_KEY, API_SECRET)
    auth.set_access_token(ACCESS_TOKEN, ACCESS_TOKEN_SECRET)
    api = tweepy.API(auth)
    api.update_status(tweet_message)

def get_random_post_title_and_link():
    url = "https://blog.hatena.ne.jp/katsu-ichiro/better-software-testing.hatenablog.com/atom/entry"

    payload={}
    headers = {
    'Authorization': 'Basic XXXXXXXXXXXXXX',
    'Cookie': 'b=XXXXXXXXXXXXXX; sk=XXXXXXXXXXXXXX'
    }

    response = requests.request("GET", url, headers=headers, data=payload)
    root = ET.fromstring(response.text)
    index = random.randint(0,9)
    entry = root.findall("{http://www.w3.org/2005/Atom}entry")[index]
    link = entry.findall("{http://www.w3.org/2005/Atom}link")[1].attrib['href']
    title = entry.find("{http://www.w3.org/2005/Atom}title").text
    post_info_dict = {
        "title": title,
        "link": link
    }
    return post_info_dict

post_info_dict = get_random_post_title_and_link()
print(post_info_dict["title"] + " : " + post_info_dict["link"])
today = datetime.date.today()
tweet_random_post_title_and_link(today.strftime('%Y年%m月%d日') + "のおすすめ" + post_info_dict["link"])

不具合データの可視化と分析　を読んだ

engineering.mercari.com

プロジェクトの振り返りとして、定性的な感想や意見だけでは足りない部分をQAチームから定量的な指標をフィードバックすることで、より有意義で建設的な振り返りを実施できるように取り組んでいます。

これ、いいな。FACTFULNESSにも書いてあったが、印象と実際の状況って結構乖離があったりするから、事実ベースで議論できる土壌を作るのは大事だと思う。

Dashboardを通じて不具合チケットが特定な種別に偏っているのか分かるので、Adhoc 的なテストを実行する場合、操作面をもっとみるか、ユーザービリティ面をさらに見直すかなどの判断のもとになると考えます。

発生している不具合の状況から、重視するテストを切り替えるのは上手いやり方だと思う。これは参考になるなぁ。

テスト実行に一番大きく影響した問題にはなにかしらの突発的なことがあったと考えられます。そのため、案件進行中に発生したことを文章化して、今後類似案件を対応する際に参考になる素材になります。突発的なことから学べる経験を共有したり、今後同じ問題が再発しないように議論してトライを決めたりします。

あぁ、これもよさそう。振り返りのいい材料になると思う。ちゃんと文書化されていないと、重要な出来事でもうっかり忘れられたりするのよね、、で、繰り返してしまうという。

リスク管理の観点でいいやり方だと思った。

 

データの可視化、蓄積って基本的な部分ではあるけど、バタバタしているとおざなりになったり、サボったりしがちな印象。でも、やるとちゃんと効果出てくるんだよな。基礎をしっかりやっているという感じがして好印象だった。

メルペイQAチームにおける自動化のイマ　を読んだ

 

engineering.mercari.com

QAチームがE2EもAPIテストも担当しているのすごいと思った。

学習コストとテストコードのメンテナンスコスト、それなりに高い気がするんだけど費用対効果はどうなのかしら。それとも、ガンガン投資していくぜみたいな感じだろうか。まぁ、「ずっとQAし続ける」という前提で考えると自動化必須なので、効果出てるんだろうな。

 

QA 組織の開発組織との関わり方　を読んだ

www.m3tech.blog

JSTQB シラバス、そういえば自分も読んだのであった。

よく見返してみると、独立性のメリットの

  • 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い

これについては、独立性関係ないように思えた。

また、

  • ベンダーの独立したテスト担当者は、契約元の会社にある（政治的な）圧力なしに、テスト中のシステムについて正直に客観的な態度で報告できる。

これについては、独立性云々というよりは会社の文化づくりの話なので、独立したから客観的な態度を取れますよ、というものでもないように感じる。

一方で、独立性のデメリットの

  • 開発担当者の品質に対する責任感が薄れることがある。

これについては、品質に対する責任感の有無は独立性と直接関係がなかろうと感じる（QA組織が独立性に関係なく、品質に責任感を持つ/持たない開発者は一定数いるのでは）。

また、

  • 独立したテスト担当者は、ボトルネックとして見られることがある。
  • 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。

これはプロジェクトマネジメントというかコミュニケーションの話であるので、独立性とは直接関係なさそう、と感じた。

 

 

 

QA 組織の開発組織との関わり方　を読んだ

www.m3tech.blog

JSTQB シラバス、そういえば自分も読んだのであった。

よく見返してみると、独立性のメリットの

  • 独立したテスト担当者は、開発担当者とは異なる背景、技術的視点、バイアスを持つため、開発担当者とは異なる種類の故障を検出する可能性が高い

これについては、独立性関係ないように思えた。

また、

  • ベンダーの独立したテスト担当者は、契約元の会社にある（政治的な）圧力なしに、テスト中のシステムについて正直に客観的な態度で報告できる。

これについては、独立性云々というよりは会社の文化づくりの話なので、独立したから客観的な態度を取れますよ、というものでもないように感じる。

一方で、独立性のデメリットの

  • 開発担当者の品質に対する責任感が薄れることがある。

これについては、品質に対する責任感の有無は独立性と直接関係がなかろうと感じる（QA組織が独立性に関係なく、品質に責任感を持つ/持たない開発者は一定数いるのでは）。

また、

  • 独立したテスト担当者は、ボトルネックとして見られることがある。
  • 独立したテスト担当者にテスト対象の情報などの重要な情報が伝わらないことがある。

これはプロジェクトマネジメントというかコミュニケーションの話であるので、独立性とは直接関係なさそう、と感じた。

 

 

 

開発経験のないQAエンジニアのAPIテスト実装までのキャッチアップ　を読んだ

blog.kyash.co

素晴らしい取り組み、自分がやりたかったことだ。

QAエンジニアの方々は、もともとコードが書ける人たちだったのだろうか？そうでないとしたら、そこまで教育できたのほんとすごいと思う。

自分の経験上、コード書いたことがない人にコード書いてもらうのはとても大変なので、、（コードを書くという行為に対する精神的ハードルが非常に高い様子）。

可能であれば、なぜAPIテストを実施することにしたのか、その背景も読めると嬉しかった。

スクラムガイド　を読んだ

https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

以前読んだが、内容を忘れたのでもう一回読んだ。

頭の整理にはなったが、なんというか精神論というか心を強く持つことが大事なのかな、という印象を受けた（スクラムで大事なのは、きっとスクラムイベントではなくて５つの価値基準であると思われるため）。

価値基準の中でも特に勇気を出すのが大変な気もするが、頑張らずに勇気を出せる方法ってないだろうか。そのきっかけになるのが心理的安全性なのかもしれない。

しかし、自分は心理的安全性が担保された組織で働いたことがない。そんなことできるのだろうか。心理的安全性が担保できるようなチーム作りができる人なら、心理的安全性が担保されていないチームでも勇気を出せてしまうのでは、と思った。

現場の人間関係は選べないので、結局頑張って勇気を出すんだろうなぁという結論になりそう。