To summarize the series, I first read and wrote notes for the ISTQB foundation-level syllabus, and then worked through a multiple-choice practice exam. Writing everything down to post in this journal took some extra time compared to just reading/thinking, but I suspect it was worthwhile.

This article will cover my attempt to work through the a practice version of the ISTQB Foundation-level exam. It's a multiple choice format, so I will list each question, the answer options, and my reasoning for each option.

These are my study notes for Chapter 6 of the ISTQB Foundation-level syllabus. This chapter has the theme "Tools for Supporting Testing."

These are my study notes for Chapter 5 of the ISTQB Foundation-level syllabus. This chapter has the theme "Test Management."

These are my study notes for Chapter 4 of the ISTQB Foundation-level syllabus. This chapter has the theme "Test Design Techniques."

These are my study notes for Chapter 3 of the ISTQB Foundation-level syllabus. This chapter has the theme "Static Techniques," meaning tecniques to test software without executing that software.

These are my study notes for Chapter 2 of the ISTQB Foundation-level syllabus. This chapter has the theme "Testing Throughout the Software Life Cycle"

These are my study notes for Chapter 1 of the ISTQB Foundation-level syllabus. This chapter has the theme "Fundamentals of Testing," and covers what testing is, why it's important, key principles, and so on.

It's time for the last and most important step of this project: figuring out how to improve for next time. Ideas have been building up in my mind over the past few days, so I'll launch straight into their analysis.

This quest is nearly over, let's recap what has been done so far. Given the task "test the Omni Converter Challenge service," I first read its documentation and performed exploratory testing to build an understanding of the system (store and retrieve files containing Directed Acyclic Graphs via a RESTful API). Based on that understanding, I created a regression testplan. Then I built a SoapUI test suite which automates that test plan. Now it's time to execute the test suite and review the results.

With a testplan in hand, it's time for execution. These are regression tests, so I should spend the time now to automate them, to save manual execution time on subsequent runs.  But how should I perform this automation?

The idea behind regression testing is to find bugs in the new version of a system, when those bugs were not present in older versions of the same system. Since the requirements of the new version are usually very similar to the old version, regression testing is done with a single set of tests reused across many versions. Since the tests can be reused, it's worth investing some extra effort up-front to make those tests the best they can be. An extra hour spent automating a test today might save 30 minutes in every subsequent run, quickly paying back that initial cost.

So, if my goal is to regression test the Omni Converter service, then I should be thinking about automation.  I know from exploratory testing that I need to send HTTP requests, and that those requests have predictable text responses. A simple way to automate those tests would be to shell script a series of HTTP requests using cURL, print their responses to a file, and run some sort of analysis on that file to verify correct results. Let's try it.

My testing environment is ready (re-hosted the Omni Converter service locally, cURL and POSTman to execute test requests, Eclipse to view source code, a simple directory for bug reports), so it's time to launch back into exploratory testing. 

It now occurs to me  that I never planned out my testing environment.  While I could continue testing through Palantir's web frontend, that frontend will become unavailable after 5 days when Palantir ceases hosting my OCC server instance... meaning I'll need to download the source code and host it myself. So, what does my environment need?

Now that I have a rough idea of what OCC is supposed to do (translate uploaded Directed-Acyclic-Graphs from one file format to another), I'll dive into an instance of the system and see what there is to see.

As with any testing project, this one starts with determining expected behaviour.  Bugs are defined by their difference from expectations, so to find bugs we must first have expectations.

Reading through the Omni Converter documentation, I would describe it as a REST API service with the purpose of storing Directed Acyclic Graphs (DAGs) in various file formats. DAGs can be created, stored, replaced, retrieved and deleted.  There are also some informational commands for API version, supported file formats, etc.

So, if OC is a REST service, then its expected behaviour lies in how it responds to HTTP requests, sent to specific endpoints...

This journal will follow the development of my portfolio, and successes and/or failures in job-searching. I intend to keep this site up-to-date throughout my career as well, but we'll see what happens. 

The site is currently under construction using SquareSpace as a toolkit, all the pieces should be finished in the next few days as time/interest allows.