Tuloncz » Ondrej Tulach
I've spent 14 years as Software Tester / QA / / SDET (i.e. combining testing with automation and coding utilities and data generators).
Besides that, I worked full-time as programmer and Ops support for a year, sysadmin contractor for two or three.
And since 2024, I'm officially working as Software Safety / System Safety engineer and Functional Safety Manager (please don't mistake Safety with Security), reviewing every SDLC step artifacts from requirements through architecture and DD to test specs and test reports, and above all, moderating and executing Safety Analyses (FTA, SFMECA, HAZOP etc.)
So I'm your IT generalist jack-of-all-trades. Waterfall, Agile, V-model. Coding in procedural (PL/1, some C) and OOP (C#.NET) languages. Test automation scripting. Infrastructure and IaaS in GCP.
Yet throughout the years, I found that my biggest passion and talents are in 1) decomposing problems and 2) inductively and deductively analyzing possible system faults and risks to propose technical countermeasures.
That means that I can look at any system on a functional/requirements/architectural elements level and quickly identify
And work with SMEs like architects or developers to mitigate, sanitize or rearchitecture the product to mitigate these risks before they are deployed or even coded.
Thus after 15 years in IT, I evolved into a System/Software Safety Engineer. And since this job never goes alone, also Functional Safety Manager.
These skills I've acquired and honed hands-on:
Since late 1990s, I toyed with HTML and JavaScript. Then I got some formal education in proper programming languages (Pascal, C++, Java, C#.NET - the latter become my life-long love), followed by a gig as a System Administrator.
During my second semester on University, I quit studies in favor of a work on the IBM z/OS Mainframes. That lead me from PL/I procedural programmer and Tech Support to QA, and from Banking to Enterprise Software Development.
I started my QA career in manually-testing teams, and off course spearheaded test automation. It was then that I've learned my 1st hard lesson: Test Automation is not a replacement for quality test design. If the Test Coverage is low, it doesn't matter how well is it automated - it will not catch the defects, period.
I got trained and certified as ISTQB-certified Tester (foundation level) and embarked on a journey to improve the test coverage and finally stop missing defects.
When I run out of ISTQB and The Testing House techniques such as Boundary Values Analysis etc. but couldn't get my hands on the ISTQB Technical Test Analyst course, I started piecing technical test analysis together from every source I could get - IEEE test-related docs, Preventive Quality Assurance, BS-7925...
My first major improvement was the Test Classes Cheatsheet. Originally a formality in bureocratic Test Plans, I turned them to checklist/cheatsheet ever-improved on Lessons Learned from the testing campaigns and defects, thus unknowingly following the Aerospace FHA "generic lists" approach.
When I run out of topics in QA-related IEEE standards, I turned to Aerospace as the cradle and state-of-the-art of quality. There I discovered and understood RCA (Root Cause Analysis), FMECA (Failure Mode Effect Criticality Analysis) and FTA (Fault Tree Analysis). Following years were filled with attempts to "lean-ize" these and "cut the fat" to allow use in informal, Agile/Lean SWDEV enterprise.
Breakthrough was when I was acquainted with the Fault Hazard Analysis process via the DOE-178 and more importantly, ARP4761. That gave system to the workflow I've so far only intuitively followed based on mentions and fragmented hints from open-source presentations - and it provided the last piece to the puzzle in Function Lists. These mapped perfectly to FMECA and finally enabled it.
Finally, I had to start with Systems Engineering practices per INCOSE SE Handbook. There I understood that the "function lists" I've reinvented on my own are actually an estabilished field of "Functional Analysis" (functional decomposition of requirements).
The result was a lean and fast, yet highly integrated and systematic workflow to assure Risk-management and Quality across the SDLC.
And since I rolled-out de-facto Software Safety techniques into software testing, I was later hired by Porsche Engineering Services to work Software Safety full time on their control systems. I got introduced to the ISO 26262 (automotive-specific derivative of the generic IEC 61508), and I'm working on my knowledge in the SW requirements, SW architecture and SW Detailed Design topics. INCOSE SE practices help there a lot, too. But more and more, I'm getting to the actual System Safety real via the Technical Safety Concept and Functional Safety Concept - you need to get these right to have the downstream artifacts right.