Week 2 – APIs With Context

This week was spent gaining context on APIs. Questions such as:

  • Who are the consumers of the APIs
  • What is the minimum viable check we want in place for a single API
  • What checks are currently being created by developers
  • What aspects of the API Checklist are of value to a specific group
  • What ways can we black box test an API
  • What ways do we want to white box check the API

We created a diagram of the parts of the white box API framework
+ which layers are being checked via JUnit
+ who are the authors of each layer of checks

This gave me a better understanding of the direction of functionally verifying our API. So the majority of my week was experimentation. My goal was to make it easier for developers to author JUnit checks. My petri dishes are being reviewed, and the results are in the mail 🙂

There are still a lot of unexplored territory, especially around API consumability. Next week we’re going to mindmap what we think we know, and what we think we need to know. That should help give focus to our efforts.

I suspect that communicating our gathered information might be a key next step.


Week 1 – Changing Gears: Manual & Automatic

My first week in, and I am being exposed to my team mates’ interests.

My cube mate has done some great things to make front-end automation tools available to all developers on the floor. Coming from the dev group myself, I know that this has been a coveted possibility for many years. Now it is just a matter of letting everyone know it exists, hand holding a bit on creating their own first scripts, and then watching as opportunities and future possibilities unfold 🙂

Another member of the testing team is investigating API testing. We’re collaborating to define a strategy. We’ve read this checklist for inspiration, and we’re being vigilant for aspects that could be checked with automation. An API seem like a natural fit for Functional checks, seeing as the longterm actor for it is another inhuman system. Lots of items from that checklist require human interaction and interpretation (especially in the Consumable category). I am unsure of how to test something like ease of use of an API that has hundred of end points and variations on each of those. Then again, I suppose the answer is in the question: if it is so large it has become daunting it might inherently not be easy to use…

Lots of thinking going on, and lots of passionate people. I look forward to the surprises next week may entail.

Week 0 – Learning and Assimilating

I may be new to the testing team at work, but I am no stranger to the culture exposed on the internet. I have long been a reader of many online blogs regarding testing. To name a few of my regular reads:

On top of that, if you watch twitter, it is a hotbed of conversations and battles on the definition of “Testing”  and the visionary future of the field.

I wish I knew where the similar meta-level conversations happen around other aspects of software craftmanship. Most conversations I have spotted are to highlight the latest cool tool or technology. The focus on the long-term sustainability and improvements might not be happening in the recorded public spaces.

Speaking of culture, I am a partial stranger to the culture of testers at my work. Luckily I often talk to members of the team, but that is different from being fully submerged in the plights and passions of the individuals. Now I shall strive for a deeper empathy.

I am listening to conversations and asking questions. I hope to be able to contribute meaningfully to my new family.

I need to give thought to my direction, as there are many roads that can be traveled.

Adventures in Test Automation Land

[Note: The term “Automated Test” is slowly being pushed to a simplified rename as “Check”. This is being put forward by the software testing community to disambiguate between the less intelligent verification done by a machine vs. the intuitive and engaged verification that is only achievable via organic minds.]

Starting this month, I shall be adopting a new role as a test automation tools developer. What this means is that I will be exploring and analyzing areas for automation. I will research tools and|or build frameworks to facilitate software verification.

I am hoping to log my learning and growth on this voyage, and welcome feedback from the community at large. “Fail early – Fail often” is a great mantra to self-development, and only by exposing my ignorance can such opportunities occur 🙂

Sharing – the key to learning