In this interview, we speak with Tetiana Hrybok, Head of Quality Assurance at Atola Technology. With over a decade at the company, Tetiana has played a key role in the development of all current Atola products. She shares her journey in the QA field, the challenges of testing complex hardware and software systems, and the strategic decisions that have shaped Atola’s quality assurance practices, all aimed at ensuring the exceptional performance and reliability of Atola imagers in the forensic industry.
Tell us more about your career path and how you became the Head of Quality Assurance.
Since I was a kid, I had a knack for breaking things, literally. I loved disassembling and reassembling devices to figure out why they weren’t working. Sometimes, I helped my father repair various electronics. When it came time to choose a profession, I decided to study programming because it seemed promising. But as I progressed, I realized it just wasn’t the right fit for me.
It wasn’t until I started studying software testing at university that I discovered how well it matched my skills and natural talents. My journey in QA began in 2012, when I worked on a browser-based game. In 2014, I left that company due to a mismatch in values and a lack of challenge and growth opportunities.
Soon after, I joined Atola as a QA Engineer in May 2014. Over the first three years, I had the chance to contribute ideas, take leadership in tough situations, improve cross-department collaboration, and truly feel connected to the company’s growth.
In March 2017, I was offered the role of QA Team Lead. The transition wasn’t easy. I had to quickly build up my technical and soft skills, support my team’s development, and juggle testing, automation, environment setup, and cross-functional work. But things gradually fell into place, and now, almost 11 years later, I’m still with Atola.
You’ve contributed to all Atola products over the past decade. Which one was the most challenging to design, and why?
The most challenging period was 2017–2018, during the development of Atola TaskForce. It brought huge changes: new technologies, new workflows, new challenges. We were training new teammates, designing processes from scratch, and learning how to work on multiple products in parallel.
Atola TaskForce introduced a new forensic imaging concept: parallel operations across numerous ports at full speed. This required us to rethink how to manage simultaneous tasks involving many devices, protocols, and interfaces. All while delivering a simple UX and ensuring 100% data integrity. In forensics, a single bug can be incredibly costly.
Testing was especially complex. We had to:
- Anticipate how users would interact with the device
- Prioritize tasks carefully
- Manage a large number of variables affecting results
- Invest heavily in both automation and manual testing
What challenges does your team face when testing features like RAID functionality or damaged drive support?
One word: variability. RAID and damaged drive testing is wildly unpredictable. It takes forever to prepare test data and environments, and the behavior of individual disks is unpredictable. We constantly evaluate risks and trade-offs because development time is limited.
For example, it takes up to 2 days to generate a 16TB RAID set with realistic user data. We always back up and store these test sets for reuse, which requires careful management of large datasets.
Damaged drives are another story. One day, a drive may have one damaged head; the next, it has three or won’t spin up at all. You can’t reliably “create” damage: even intentionally damaging drives doesn’t guarantee the results you want. That’s why we’re always sourcing damaged drives from eBay, second-hand marketplaces, our users in data recovery, or even friends.
Right now, Atola imagers are tested on around 200 damaged drives in our so-called drive library, each with unique failure types.
What’s unique about hardware testing at Atola? What types of testing do you use?
Hardware testing starts with prototyping and hypothesis testing. We often work with disassembled devices and need to factor in physical influences.
Our imagers consist of a motherboard, processor, memory, custom boards, cables, and power supplies. We also use extensions for connecting different types of drives. We test components individually (component testing) and together (integration testing).
Each new imager goes through functional testing, alongside simultaneous checks of documentation and refinement of hardware/software requirements. Once core functions are verified, we move to non-functional testing, including:
- Usability testing
- Load and performance testing
- Stability, endurance, and stress testing (depending on the device’s components or software)
- Maintainability testing (we can assemble/disassemble imagers ourselves, which helps reduce workload on the hardware department)
Our core goal is to deliver excellent UX and performance. And that’s what sets Atola apart.
How do you ensure quality during device assembly?
We’ve developed self-diagnostic software that runs on each device to verify its health and functionality after assembly.
We also created internal hardware tools called Octopus and Centipede to test ports more efficiently. Thanks to close collaboration with our hardware team, we get rapid feedback and can iterate quickly when changes are implemented.
Tell us how the drive library came to life.
The drive library was my idea long before I became Head of QA. Originally, our drives were kept in boxes, unlabeled and unorganized. We wasted time searching for the drives we needed, emailing colleagues, or even dismantling computers to find the right one. Sometimes, things went sideways; we once knocked over a stack of drives, and they all crashed to the floor.
As our team and drive collection grew, it became clear we needed a system. I suggested numbering the drives and assigning tokens to team members. When you take a drive, you leave your token in its place. With help from our hardware team and a contractor, we installed metal cabinets with drive slots in just two weeks.
We also created a searchable database with 30+ parameters per drive: model, serial number, size, head count, damage type, password removal support, speed, behavior quirks, and more.
All drives are now stored in anti-static bags, which helps protect these rare and fragile devices.
How many drives are in the library today, and how often are they used?
We now have over 800 unique drives and flash memory cards. And yes, most of them are actively used.
Some have very specific damage (slow drive initialization, freezing, flaky read/write behavior). Others have odd firmware bugs or very old interfaces. We even have an IDE drive from 1989 that still works but is as loud as a server. We also keep drives with varied capacity and technology including enterprise NVMes with incredible speed for performance testing.
While around 20% of testing can be done with emulators, most tasks require real hardware. Testing usually starts after morning coffee: we check the daily plan in JIRA, pick the needed drives and peripherals, and use special baskets to carry them to our workstations to run the planned tests.
What are the most interesting bugs you’ve faced?
QA is the last line of defense before a product reaches users. It’s our job to uncover and understand bugs. That takes motivation, focus, and sometimes a detective mindset.
Here are some bugs I’ll never forget:
The 42nd Run: When I joined Atola, we were optimizing hash calculation and found a bug that only appeared on the 42nd run of software. It was caused by task parallelization and was caught thanks to our automated tests.
Variable Overflow: Atola Insight, released in 2008 when drives were 1TB tops, still had some original code from years back. When 16TB drives appeared, a variable overflow caused incorrect capacity display. Because we monitor the market and update our library, we caught and fixed it quickly.
A Bug of One Character: In one release, two files didn’t appear in an SMB-shared directory located in the root partition of NTFS. After a week of investigation, the cause was a single character in thousands of lines of code. Fixing it took minutes. Testing the change took two more weeks. That character cost us three weeks of work.
The $2 Drive with 200,000 Bad Sectors: We once bought a $2 drive at a flea market. It had over 200,000 bad sectors, which caused our error visualization to crash, for it wasn’t designed to handle more than 65,000 “bads”. Even junk hardware can reveal critical bugs!
These bugs remind us that the goal isn’t just fixing issues, it’s learning from them to prevent repeats. And never underestimate your users. When they tell you, “No one would ever do that,” they probably lack imagination.
What role does automation play in your QA process?
Automation is essential. Each Atola product has its own automated test suite. Every day, hundreds of tests run on our Continuous Integration and Delivery servers to verify core functionality from one commit to the next. Without this, it would take 1–2 months to complete all manual checks.
All critical and time-consuming tests are automated, including:
- RAID Autodetection across 250+ test configurations
- Performance benchmarks on real devices and test benches that closely mimic production hardware
Since drives wear out over time, we regularly replace them to ensure valid performance testing. We also use scripts to set up environments, generate test data, and handle routine tasks.
How do you support team development and implement new approaches?
At Atola, we believe engineers should be versatile — no one is an expert in everything, but everyone should have a strong foundation.
That’s why we created a list of key skills for QA engineers, which helps guide onboarding, identify growth areas, and track development.
We’ve also defined our team values:
- Ownership: Taking initiative and responsibility for outcomes
- Excellence: Maintaining high standards and striving to improve
- Autonomy: Finding solutions independently and respecting others
These values shape how we work, grow, and support one another.
Atola recently launched MultiDrive. Can you tell us about it?
MultiDrive is our new free drive management tool. It lets users:
- Back up and clone drives
- Transfer data to new machines
- Restore files from backups
- Securely wipe drives
- Run multiple drive operations simultaneously
- Use a full-featured CLI (for advanced users)
You can download it here: https://multidrive.io
How was testing different for MultiDrive compared to Atola imagers?
MultiDrive is entirely software-based, unlike our traditional imager products that combine hardware and software. That made development much simpler and faster: no hardware dependencies, no complex build cycles.
Still, time-consuming parts like OS support and working with different drives remained.
One of the key focuses was automation, which helped us catch issues early and accelerate the workflow. MultiDrive is where our experience and automated testing infrastructure really paid off.
What inspires you at work?
I’ve been with Atola for more than a third of my life, and it’s never felt like “just a job.”
As a kid, I admired investigators and police officers, the people who catch the bad guys and make the world safer. Knowing that our imagers help law enforcement and digital forensics teams deliver justice is deeply motivating.
It’s rare in tech to work somewhere that encourages direct communication between tech specialists and customers, participation in trainings and conferences, and deep product ownership. Atola offers all that and more.
But above all, my team inspires me. Every person is unique, talented, and unafraid of challenges. Their dedication motivates me every day.
Thank you, Atola team!
Looking ahead, what are the biggest challenges in forensic hardware QA?
The biggest challenge is keeping up with rapid storage innovation while maintaining Atola’s quality standards. Drives are getting faster and larger, and users expect more efficiency and reliability.
That’s why we approach forensic imaging differently. My focus is on accelerating workflows:
- Imaging dozens of drives in parallel
- Reducing time spent on damaged drives (low-level access, 100+ Linux kernel patches)
- Automating RAID reassembly with unknown configurations
- Minimizing manual work via automation
- Integrating with 3rd-party DFIR tools to cut errors and delays
Ultimately, our job as QA engineers isn’t just to verify quality, it’s to make sure our systems help customers move forward and make real progress.
