How to Pass the ISTQB Certification Exam


ISTQB is the International Software Testing Qualifications Board and the syllabi is globally recognized as the de facto industry reference for the software testing profession.  It is one of the most sought after certifications in the software testing industry.  Personally, I was looking to grow my skills and enhance my competency in the field and certification is one of many ways to do this.

I set the goal to study for and pass the the Certified Tester Foundation Level exam within a month.  There are accredited training providers all over the country and typically the courses are a week long and cost between $2000-$3000 plus travel and lodging.  My goal was to self study and sit the exam at a local community college. These are the steps I took and it worked for me so my hope is that it may help anyone else looking to take the exam.

Step 1: Register for the exam in advance

I didn’t want to let my training and preparation drag on for months (it easily could), so I scheduled the exam one month out at a local community college.  The exam cost $250 and there was a fee to reschedule it so this was all the motivation I needed to remain focused!  In the USA, you register through this site:

Step 2: Read the syllabus twice

The syllabus forms the basis for the the exam and breaks down the material into the following learning objectives:

  • K1: Remember
  • K2: Understand
  • K3: Apply
  • K4: Analyze

It is not intended to be thorough and can be quite vague in some areas.  The course content is thoroughly covered in the book Foundation of Software Testing: ISTQB Certification by Rex Black and Dorothy Graham.  I did not purchase nor read this book but I did spend the time looking up topics from the syllabus where I felt I needed more information.  The exam questions are distributed as follows:

Source:  ISTQB exam structure –

Based on this, I focused my efforts on Chapters 1, 4, and 5.  To pass the exam, you have to score 65% or higher.  No one ever asks what you scored on the exam.  It really only matters that you pass and become certified.

Step 3: Watch this Udemy course twice

I found this course on Udemy to be invaluable in attaining the knowledge necessary to pass the exam:

The instructor has a bit of an accent but it wasn’t really an issue for me and I felt he covered the material really thoroughly and provided all the instruction necessary to take and pass the exam.  Some of the concepts were new for me and the instructor recommends that everyone watch the course from beginning to end twice.  I felt that was good advice and I did much better on the practice tests after the second run through.

Step 4: Use a cheatsheet for review

There are a number of CTFL cheatsheets available on the web.  I found this one to be the most helpful:

Software Testing Foundation – Topic Cheat Sheet – ISTQB-ISEB

I learned this content well enough that I could be quizzed on it and felt it helped me through a number of questions in the exam.

Step 5: Take Practice Exams

I cannot stress strongly enough how important taking the practice exams are.  There are a number of practice exams on the istqb website:

I took all of these.  In addition, I took each of the exams in this Udemy course:

Taking these exams really solidified my understanding of the course content and if I missed any questions, I took the time to review those areas in the syllabus and the udemy course.  If you want to pass the exam, do not skip this step.  It is probably the most important.

Take the exam

On exam day, I arrived early and had to provide numerous forms of identification and put all my belongings in a locker including my watch.  I was shown to a computer in a glass room with security and cameras.  The exam was 40 multiple choice questions and had to be completed within 60 minutes.  I was able to go back and review/change any questions as needed.  On submitting the exam, I received the results immediately and was delighted to have passed!  I received my certificate and welcome letter a few weeks later and my name is listed on the ISTQB Successful Candidate Register.

All in all, I was very happy with the knowledge I gained preparing for the certification and was able to apply numerous principles and techniques in my every day work.  I’m planning to follow a similar set of steps for the Agile Tester certification exam shortly.  If this post helps you in any way, please leave a comment and let me know.  Good luck!

QA Process Based On Gitflow

I have been avidly researching the QA process of other scrum teams and I found there to be a general lack of information regarding specific process steps.  This is likely because scrum teams vary widely in the tools they use and the processes they employ to deliver their commitments.  I have been tasked with establishing solid QA process and procedure for our scrum team.  Our team operates on a 2 week sprint cycle and we also release working software every 2 weeks.  I am a strong believer that the responsibility for quality lies on the whole team, not just on the person designated in the testing role.  Having said that, there are definitely predictable patterns and practices that QA can engage in to serve the team and the organization well.  Some of the tools we use are Jira, Git, Bamboo, Jenkins, RobotFramework and TestRail.  Here’s an outline of the QA process we utilize with these tools, based on the Gitflow branching and merging strategy:


  1. Developer creates a Feature branch from the Develop branch
    1. Jira status: Dev in Progress
    2. Jira ticket number used as the branch name
    3. Coding begins
  2. Developer completes story and requests a code review
    1. Developer merges Develop branch into Feature branch (in case of changes on Develop branch)
    2. Developer creates pull request to merge Feature branch into Develop branch
    3. Jira status: Code Review
    4. Peer reviews code using Github review tools
    5. Changes are made if necessary, step 2 starts over
    6. When all changes are complete, code review is approved
    7. Jira Status: Ready for QA
  3. QA deploys Feature branch to QA Environment
    1. Jira Status: QA in Progress
    2. Test plan is document in TestRail and test cases are linked to Jira ticket
    3. Automated test cases are written (this can begin earlier in the process based on the acceptance criteria)
    4. Tests are executed – functional, manual, automated
    5. Automated results are pushed from RobotFramework to TestRail and to Jira via API’s
    6. If issues are uncovered, a Jira ticket is created per issue.
    7. Issues are addressed on the feature branch and step 2 and 3 begins again.
  4. QA merges Feature branch into Develop Branch
    1. When all issues are addressed and QA approves changes, feature branch is merged into develop branch (Use –no-ff flag to create a new commit object and group together commits by feature)
    2. If there are merge conflicts, QA works with Dev to resolve
    3. Jira status: QA Complete
  5. Repeat all of the above until EOD second Wednesday of Sprint
    1. Full automation suite is executed numerous times during this process
  6. QA creates a release branch on all repos to be released
    1. Naming convention: release-##.##
    2. Develop branch is merged into release branch
  7. QA Deploys Release branch to Staging for all applications in the release
    1. Merges into Develop end (feature freeze)
    2. Regression/automation and thorough testing as a whole occurs
    3. Jira status: On Staging
  8. Product owner reviews sprint items on Staging and approves release
    1. Product team marks stories “Product Approved” in Jira for those that are approved
    2. Items not approved need to be removed from the develop branch and carried over to the next sprint
    3. Product team communicates release to internal team members
  9. Release branch is merged into Master on all repos
    1. QA opens pull requests to merge release branch into master
    2. QA works with Dev on any merge conflicts
  10. Master is built and deployed to QA
    1. Smoke tests run against QA
    2. QA verifies that everything is set for release
  11. Release Candidate is built
    1. Repos are tagged with release version
    2. Release Candidate is deployed to QA, and Staging
  12. IT deploys Release Candidate to Production according to agreed upon schedule
    1. Jira status: Done
    2. Release complete
  13. QA and/or Dev merge Master into Develop
    1. Master and Develop should be even
    2. Changes to Automation framework that need to wait until after the Production release are pushed to master


  1. Developer creates hot fix branch from Master
    1. Jira status: Dev in Progress
    2. Naming convention: hotfix-*
  2. QA deploys the hotfix branch to QA env
    1. Jira status: QA in progress
    2. Fix tested and approved
  3. QA merges hotfix branch to Master and Develop
    1. Jira status: QA complete
    2. Release is tagged on Master
    3. Naming convention: release-##.##
  4. QA deploys Master to Staging
    1. Automation executed
    2. Change request created for deployment to Production
  5. IT deploy fix to Production
    1. Hotfix release complete



Bug Report Example

Reporting bugs found during the software development lifecycle in a clear and concise way is critical to fast, in-cycle resolution.  The scrum team I work on uses the Jira bug tracking tool which integrates very well with our test case software, TestRail.  It is extremely helpful to developers when QA Engineers provide consistent and relevant information to assist the developer in locating and addressing the specific issue.  Here are some sample details we require QA to provide in every bug report:

Bug Name: 500 Server Error When Adding a Comment > 2000 Characters
Bug #: (Automatically added by Jira or other Bug tracking tool)
Type: Bug
Status: To Do
Priority:  High/Medium/Low
Affects Version/s: Version Number
Component/s: Software components
Environment: QA
Sprint: Sprint ##.##
Assigned to: Developer Name
Reported By: Your Name
Reported On: Date
Reason: Defect
Status: New/Open/Active (Depends on the Tool you are using)
Environment: Dev/QA/Staging/Production

Application crash on clicking the Add Comment button when a comment has more than 2000 characters.

Steps To Reproduce:

  • Log in to Application
  • Navigate to Attendance Page
  • Enter attendance
  • Select Date
  • Enter text > 2000 characters
  • Click Save Comment

Expected Result:
Should receive error stating cannot exceed 2000 characters

Actual Result:
Receive a 500 Internal Server error

Stack Trace:
If you have access to database logs or similar, include as much of the exception details as possible.  This may involve filtering through a lot of records to locate the exact stack trace for the exception.  This can save developers a significant amount of time which is win win for the whole team.


New Role As Quality Engineer












In March, 2016 as my family was moving from Dallas, TX to Kalamazoo, MI, I discovered that Fellowship One was being acquired by a company called Ministry Brands. Here’s the press release. This meant a lot of changes at work! My role within Active Network was API Software Engineer and it was a hybrid of developing REST-API’s, testing the existing API’s prior to every release cycle and supporting the Developer Community. My favorite part of the job was actually the testing function. To do this efficiently, I created an exhaustive REST-API testing framework which iteratively called upon every endpoint we exposed and checked HTTP response codes, response messages, and response data. I used PHPUnit to accomplish this and we opened up the code to be used as an example of API consumption, found here.

Shortly after the acquisition, a position opened up on our development team for a Software Quality Engineer and I eagerly applied. I was given the role without hesitation and now lead the software Quality efforts for Fellowship One Premier. I work with an amazing team of developers and every day we work to make our product better.  I am passionate about testing whether it be on the API level or the user interface level and love the challenge of finding bugs!

Family holiday in England

Scrum Team Git Workflow

Update my local master
git pull origin master

Create a branch for the story and check it out
git checkout -b storyName

(work, work, commit, commit)

Switch to the master branch
git checkout master

Pull again to fetch and merge any changes
git pull origin master

Merge master into my branch
git checkout storyName
git merge master

Check everything one last time and fix any conflicts

Merge branch into master
git checkout master
git merge storyName

Push the changes upstream
git push origin master

Delete the branch from remote
git push origin --delete storyName

Delete the branch locally using -D instead of -d because it forces a delete
git branch -D storyName

Single Sign On Demo and Code

Http Dev Client Demo

Installing PHP Extension Mcrypt on Mac OS 10.7

Today I needed to install the Mcrypt PHP Extension on my Mac running OS 10.7 and PHP 5.4.10.  I had to piece together directions from a number of sites and so I’m outlining them here in case anyone else finds this useful:

1. Make a new directory called “mcrypt”

2. Download mcrypt from here

3. Download the php binary file for the php version you are running

4. Move both of these unzipped downloads to the “mcrypt” folder you created

5. Open Terminal, type:

 cd libmcrypt-2.5.8 
  sudo make install 

6.  Libmcrypt is now configured but now it’s necessary to make the mcrypt extension

7. In Terminal:

 cd ../php-5.4.10/ext/mcrypt  

8. You should see:

Configuring for:

PHP Api Version: 20100412
Zend Module Api No: 20100525
Zend Extension Api No: 220100525 

9. Type:

 sudo make install  

10. You should see:

Installing shared extensions:     /usr/lib/php/extensions/no-debug-non-zts-20100525/ 

11. Open you php.ini file and add the following line: 

That’s it!


Webhooks, Formstack & Fellowship One

Page 1 of 3123»