A Quality Journey and the Missing Quality Attribute: Culture

While writing one of my blog posts about CCT (Continuous Comprehensive Testing), I realized I had never shared my journey. I went from a developer to a consultant and, eventually, a software executive. It all started many years ago in Puerto Rico. My first job was with a startup company called Abaco (eventually Abaco Mobile). I did not know much about software development except what I learned at the university, mainly how to write code.

Early Lessons about Functional Testing

The only thing I learned about testing at college came from my microprocessor class. The professor insisted we write test cases as part of our projects. The demo was always to show the test cases and how they passed. For the final demo, the professor will give us the test cases at demo time, and we will have to execute them in front of him. One test case did not pass. 

I did learn to write simple and specific test cases, each with one objective. At the time, I did not know how important that would be for my career. Still, I do not miss writing code in assembly, even if that became handy in my first job.

Interacting with Users & Performance is Hard!

In my first job, I wrote Windows desktop applications and embedded software for barcode readers and handheld units. Client interactions exposed me to testing and other quality attributes. While working with Merck, I learned how to document a test case properly. For some reason, I had to execute each test case three times before we could mark it as passed. At a GE manufacturing plant, I had to support color-blind users. The experience introduced me to the importance of accessibility.

My first career shock came when writing the code for the shipping area at the GE plant. I hit a wall. I needed to learn how to write a fast enough solution to meet their needs. There was no wifi in those days, so the handheld units had to handle much processing with few resources. The users sent the data to a central database by connecting the handheld unit to its base station. We had to display the results using a desktop app. The whole thing was slow as hell.

Meanwhile, the desktop application's user experience (this was before anyone used that term) was generally good. It had a beautiful UI and was easy to use. But the response time was terrible. I failed to provide a quality solution because I needed to learn how to write high-performing code. Someone else had to finish that project and fix my code.

My next job was in a stuffy IT department. I hated having to wear a tie every day. It was a large insurance company – the second largest corporation in Puerto Rico. Most of the code I wrote was what I called throw-away code. These were mostly migration tools to move data from systems X to Y. However, I had the chance to learn the internals of an ERP system. I learned a lot about databases. I also became the guy who built tools to expand the capabilities of the ERP system. I started learning about architecture and how complex some of the systems used by corporations are. The complexity of the business rules required special attention during testing. Finally, I learned ways to make things faster.

Performance is Cool!

While my boss praised my beautiful UI work, I became interested in the backend: the databases and the code behind more than the UI. I realized that performance was the best predictor of the quality of a product architecture. I already understood the importance of functionality and usability, but I now learned how to reach the performance attribute.

I acquired that knowledge and became a technical consultant at Smart Solutions International. I traveled to the Caribbean, Central America, the United States, and Canada. Most of our clients were government entities, but not all of them. I had the chance to fix issues that were derailing implementations. The problems were mostly about performance. And I had the solution. The migration took a whole week. I optimized it to complete the migration in 12 hours. The import took 20 hours. Now, it takes 1 hour.

One day, the dot-com bubble crashed, and being a consultant was no longer the most sought-after job. I needed a job, and it did not matter what it was. A consultant who rarely travels will only be a consultant for a short time. I landed at a company called Ultimate Software.

Can you relentlessly test your way to quality?

I enjoyed the interviews. One of the interviewers was Paul. Like many people hired at Ultimate Software, after meeting Paul, I realized I did not know as much about databases as I thought. That was a good sign.

Still, my first few days learning the product caused me to think I would not spend more than a couple of years at this new job. After handling products with complex and well-designed architectures, spending time with UltiPro was painful. It could have been a better-developed product. The core of the business was the payroll engine running within the UltiPro Backoffice desktop application. The design was beyond anything I could imagine. Talk about a big ball of mud. My first thought about the ugly baby came from this time.

I was a Performance and Test Automation team member, and it was my first time on a QA team. While that was not the title then, I was what they call a quality engineer today. I set up, optimized, generated, built, etc., anything related to the infrastructure needed for testing. I came as a Team Lead. The part I enjoyed most was working with the performance testing team. We looked at issues and set up complex tests. I wrote about that work in a previous blog post.

People’s Relentless Pursuit of Higher Quality

While the product code we tested was terrible, the new people coming to the company and working with the team were relentlessly obsessed with achieving the best outcome. Paul, Jason, Atul, Balaji, John, Brian, and I pursued an ideal. We had a vision of what a high-quality product should accomplish.

We debug, fix, and criticize others' code like crazy. We constantly raise the quality standard and try to reach the next level. We drive a lot of engineers crazy and push them hard. The fruit of that relentless pursuit made UltiPro a much better product. The work done to improve the product's performance is essential to Ultimate Software's continuous success in the marketplace.

A Culture of Continuous Improvement is Essential

Eventually, I implemented my vision after going through three promotions in less than two years. We did some seriously outrageous things, like achieving 90% automation test coverage on a codebase with over 20 million lines of code. It was the early days of Agile, and we implemented Scrum across the company. We introduce teams to TDD and ATDD. John and I put together the first software testing class.

When I learned about Lean and the culture needed to build high-quality products, I realized why Ultimate Software was such a great company to work for. An essential part of the puzzle about quality was now in place. You need a culture that embraces continuous improvement and is willing to try things and fail.

At Testaify, we embrace a culture of continuous improvement and relentless testing. We build products to help teams improve quality through AI-driven software testing.