Tuloncz » QA and SW Safety/Reliability
Integrated process of everything I've learned over 12 years of building QA knowledge and hands-on experience. It may look complex, but it's actually very fast and fully compatible with Agile Scrum. And it's not some "ivory-tower" theoretical dreaming - it's hands-on-experience proved and recognized even by seasoned, initially skeptical, senior Developers. This is how I do business (when I'm allowed to.)
Brief but concise summary of the advances I learned and put to practice troughout the 13+ years of my QA career. Explains limitations of Basic Positive Testing and Unit Tests; need to include env and interop influences in system testing; how to start using Test Classes Cheatsheets which improved Test Coverage by 400%; difference between QC and preventive QA; the basics of Software Safety (SPoF vs. Fail-Safe) and why everyone needs FMECA not to miss most issues; and how to use Function Lists to reduce refactoring and defects in Agile way.
When I was sitting as one of the experts on Broadcom MSD's New QA Metrics workgroup, I've thought and realized a lot about metrics. From shared destructive patterns trough Systems-Thinking analysis of how metrics actually work to how to fix the caveats in 3 rational steps, this critically acclaimed presentation outlines my findings.
My full-day course to teach full spectrum of advanced Test Analyst and Safety Analyst skills or at least knowledge: Equivalence Partitions Dependency Islands, State Transition Testing, Fault Tree Analysis and Failure Mode Effect Analysis, Integrity levels, Test Classes and even All-Pairs Ortogonal Arrays testing.
Čtyřdílný cyklus přednášek pro studenty ČVUT na SiliconHill Akademii. Cílová skupina jsou studenti vývoje softwaru. Proto kurz nebyl laděn pro testery/QA, ale spíše aby si vývojáři uvědomili, co všechno a jak se jim může v kódu pokazit, jak závažné následky to může mít, a proti čemu všemu musí naprogramovat sanitizaci.
Refined and improved version of popular Share&Learn session I first delivered in 2021. Mostly "kicking holy cows" of what supposedly is "QA", but actually is not. Also, debunking automation myths and popping every kool-aid bubble. Frankly, I was quite surprised with the overwhelmingly positive reaction of the audience.
Summary of all the innovations I've brought to the company by "cherry-picking" and "lean-izing" Aerospace QA tools and techniques. FHA, FMECA, FTA, Function Lists, Generic Lists aka Test Classes, QA coverage levels, and how it all maps together.
Lessons learned about everything that I've ever encountered to go bad in QA, test automation and test metrics. Debunking the Code/Path/Test Coverage myths, adressing the Testing workflow and Test Design deficiency, showcasing Goodheart's law regarding testing Metrics, important practical lessons regarding TestAuto.
Co je software QA - a co není? Jak by určité techniky test analýzy mohly zabránit smrtícím nehodám způsobeným SW bugy? A jak začít dělat QA? Na to odpovídala přednáška pro studenty ČVUT.
Colorized poster graphically depicting the 4 QA levels with their characteristics.
Best printed on the A3 format.
Single A4 page print reminding QAs what Test Classes to cover.
My take at the „devise test cases for electric kettle” mental excercise: 50 High-Level Test Cases.
Condensed FTA cheat-sheet on 2 A4 pages. Issued for the final excercise on my Advanced QA course.
Excercise „core of FMEA” form to be used for teaching „lightweight” FMEA within „Agile”-based, documentation-hating software development teams.
In IT, I was almost everything. I was sysadmin, ops support, programmer in procedural (PL/1) and OOP (C#.NET), I dealt with automation scripting, infrastructure and IaaS.
I was a tester, QC, QA, Lean Software Reliability.
I participated in SW requirements and architecture, teached IT courses, presented SWE topics on IT conferences, webinars and talks.
Yet throughout the years, I found that my biggest passion and talent is to deductively analyze system design and find risks and design shortcomings.
That means that I can look at any system on a functional/requirements/block scheme 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 finally found my place as a System/Software Safety Engineer.
I love sharing the knowledge I have. Being a seasoned QA professional, I teach QA courses and deliver QA-related speeches on various events. And it works both ways - research and preparation for technical presentations and courses have caused the biggest leaps in my understanding of the tools and techniques.
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 Software Development Enterprise.
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 Foundation Tester 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., I started reading IEEE test-related doc.
It was there that I've discovered Test Classes. Originally a formality in bureocratic Test Plans, I put them to good use as Cheat Cheet and Checklist, 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.
Finally, 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.
The result was a lean and fast, yet highly integrated and systematic workflow to assure Risk-management and Quality across the SDLC.