Updated: Nov 19, 2019
After my graduation I sort of rolled accidentally into QA. My first employer knew my thirst for learning about a lot of different (preferably interconnected) systems and quenched it by offering a project as a test engineer at the DTV department of one of the major Belgian telco’s.
So I was dropped in the Test & Integration team as a consultant. In this role I learned the basics of testing from my more experienced colleagues. The greatest learning curve however was in learning about all the different systems that come into play in DTV.
The company put great value into quality, which made working there a great experience. Our team got the time and resources needed to make sure the clients got the quality they deserve.
Software testing is often perceived as easy, and to be performed without much specific test knowledge. My perception at that time was no different so I attacked the task with common sense. Soon enough I found out that exhaustive testing was not feasible, and I needed to make smart decisions about which test cases to test and automate. When things got complex, I drew up large tables or timelines and tried to test as efficient as possible. I struggled to bring structure in my tests which seemed to serve different purposes and did need to be executed at different times in the development and test process. The following years, I performed testing in the best possible way.
Then after almost two years I heard about certifications for test professionals. By then, my employer was encouraging me to get started with the more popular and sexier CCNT (Cisco Certified Entry Networking Technician) and CCNA (Cisco Certified Network Associate Routing & Switching), a field I was aiming at because of my interest in the interconnected world. I did not have intentions to apply this knowledge as a network engineer, instead I wanted to learn more about testing and its international ISTQB (International Software Testing Qualifications Board) certifications. It took my employer half a year to provide me with some literature in the form of the ISTQB Foundation level syllabus.
In the meanwhile, I got into contact with TTL.be, a small company specializing in Software Quality Assurance. It’s only then I realized that testing (or QA) was truly a profession with its own specializations, each having their own certifications.
I saw a lot more future in being part of a company focused on the profession I wanted to evolve in. The charming personal touch of a small organization made me take the decision to start at TTL.be. Up until now, this was one of the best decisions I’ve ever made.
I was immediately offered a training program to bring my certifications to par with my experience. It was during the ISTQB Foundation level training, provided by people working at TTL.be, that the pieces of the puzzle that I picked up during my first years as a test engineer started to come together.
I found out that the non-exhaustive nature of testing is one of the seven testing principles. The large tables I was drawing up have a name and are called decision tables. They are a specific test technique. Moreover, I learned about new and other test techniques I could have benefit from if I had known them. The clear explanation of different test levels and test types brought structure in my test cases and in my head. My organically grown test knowledge got structured in an internationally acknowledged framework. I was more excited than ever before, and I started to speak a test language understandable for my fellow test professionals. But structuring my current knowledge was just the beginning. I can honestly say that all new test knowledge I now acquire can be easily fit in the testing framework of the ISTQB Foundation course. These new pieces add to my testing puzzle which is never finished... just like testing itself.
By Peter Lissens
Want to find out more on the ISTQB CTFL training?