When I started swimming competitively, my coach would have been the first to tell you that he thought I was going to drown. He thought that I was never going to go very far, my technique was horrible, I could barely make it across the pool before I got winded, and I was far from being an “athlete”. Fast forward a few years to an awards ceremony in which I was named Athlete of the Year, and my coach recalled that story to the school district. He talked about how I put in the time it took in the pool, in the weight room, and on the track to become one of the fastest swimmers in the country, and the fastest in my event in the state. It took time to develop my skills, and eventually my technique, my strength, and my experience began to make me a well-honed athlete. Much like my skill as a swimmer evolving over time, the quality of software is shaped through hard work and dedication, both of which will often take time as well.
There are several facets of any app that will affect the quality, ranging from where an app is in the development lifecycle to the complexity of the app. Quality starts at the beginning, but it may not be fully realized for some time. It takes everyone involved in the process to ensure that the foundation is laid to provide a quality app. In the beginning, the quality of an application will never be superb, there is almost always an issue with the way something works or looks. Some of this can be mitigated by focusing on our strengths and knowing our weaknesses.
People might develop an app for a hobby or a school project. Often this app isn’t well-defined or doesn’t have a finite end to it. It could simply be a proof of concept, or just something someone made while playing around with code. These apps might have a specific use case, but they don’t necessarily need the polish that a more robust app would need. They may lack the quality and luster that more complex apps made by a company have, but they were likely made very simply and potentially very quickly to demonstrate proficiency in the code. As people gain more experience, they begin to work on more complex apps or begin to give that simple app more polish. These are the foundations of creating a quality product.
When I joined an electronic charting company for small doctors’ offices, I never expected that I would follow this path. I was just looking to expand my technical support role in a more defined way. I wanted to be able to focus on fixing issues that people were having. I started my journey in the world of software development after being offered a role as the sole QA Engineer on a new software update. I was starting at the beginning. I had little experience and little direction. Most importantly, I was capable of error. With little guidance, I was very much a hobbyist in a professional setting. I was guilty several times of not correctly testing, or even not testing the feature that I was working on very well. As I gained insight from the developers, project managers, and Google, I began to provide higher-quality testing. As I became a better and more confident tester, I began to see why our app was very buggy. It was only after some time that I was able to see that the lack of quality came from a lack of experience. Everyone was as new to the game as I was. We had not had enough time personally to develop our skills as project managers, developers, and QA and our lack of time was apparent in the quality of our latest flagship software. Quality is not just about taking the time to build out software correctly, but taking the time to learn, and learn from our mistakes.
As time moved on, I realized that I had reached the peak of my ability to learn and grow there, so I moved on to new challenges and experiences. I found myself in a new space, working to develop software for improving customer experiences. I started working with a team of people that had time in, that had the experience necessary to make a quality app. It was great to have mentors that not only wanted to teach me new skills but would take the time to do so. I was part of a team where another QA Engineer and I were responsible for sharing the workload. The software we were working on was established, and while we were developing new tools and reporting for our program, I had time to learn while doing so. We had project managers that defined use cases very well, and we had developers who had been working on developing similar technology for years over many projects and many iterations. The QA team had good leadership with a manager who took the time to teach and got in the trenches when he was needed. He molded my perceptions and attitude. He stood for quality over quantity. He showed me that it was okay to take the time needed to test, and to be confident that we were shipping a sound product. It was the start of my philosophy that good quality takes time.
As my company continued to grow, some very large changes were made. First and foremost, the product I was working on began to overtake traditional forms of reporting for our customers. It quickly ballooned as it offered the best insights and the best strategy to improve overall experience, not only for our customers, but for their customers as well. At the same time this was happening, several members of the team, including my manager, decided to move on. It seemed like overnight that we went from 5 QA and a QA Manager to 3 QA, with no real leadership. We didn’t have the time anymore to truly hammer and test the app. We still had great direction from our project managers and developers, and they could respond quickly to any defects we found, but we found ourselves having to triage and manage risk to complete testing by the deadlines. Quality began to slip. We went from having the rare hotfix to having 1-2 patches per deployment. We just couldn’t provide the quality in the time given. The cycle was only getting worse, because every patch cost us that much more time. The only solution that was obvious to me at the time was to hire more people. It fell in line with good quality takes time: if we had more people, we would have more time.
I pushed for more people and some involvement in the hiring process. I knew in my mind that enough good people would help, and the investment in time to get them would be worth it in the end. Shortly, we had more people on the team, and due to my involvement in hiring, and pushing for better quality, I was asked to be the team lead. Soon we were back to 5 QA and a leader. We had the people and our quality was getting back into shape. I knew that as we grew, our team would need to grow, not only in size but in experience. Again, I would invest time in the short term to get quality in the long term. I took the best tenets from my previous leaders and experience to instill testing quality in my team. We had weekly trainings ranging from how to use our product to testing best practices. QA was growing and quality was winning, until we had an opportunity to be included in the Forrester Wave, a prominent ranking of businesses that other businesses could acquire tools and services from. This was a chance to put our software on the map with large companies around the world. It also meant tight timelines: we had to have our new insight engine out to our customers and working well in a fraction of the time. We had enough people to tackle the job, but we didn’t have the time. Our developers were working diligently to write new code and finish features. We had it planned out so that we were leveraging our developers in a way that wouldn’t cause them to step on each other’s toes, but they also tried to complete the work as quickly as possible. What happened was a problem where testing and regression testing were not accounted for, causing our developers to be on overdrive. They were moving so quickly trying to write new code that we began to find more bugs than we could handle in such a short time. So once again, we were forced to triage the greatest bugs against the new and needed functionality. Ultimately, we were forced to cut some functionality to ensure that we delivered as promised and were able to maintain some semblance of quality.
Although we got a win and were well-rated in the Forrester Wave, we set a dangerous precedent. We sparked the idea that under pressure, anything is possible. This concept can be valid in the short term, but over time, you begin to sacrifice productivity for tired developers and QA. When you go down this road, it is only a matter of time before quality becomes wholly unattainable. We kept pushing at this pace for quite some time, and during this time we started to lose people, good people. When you push people past their limits and they see their work begin to decline, those people will ultimately leave. When you lose out on good people it is only a matter of time before quality is an afterthought. When priorities began to shift, I began to look elsewhere and landed at Anonyome Labs, and it was a breath of fresh air. I was given the opportunity to step back and jump back into testing fully. I was part of a team that was engaged in quality at all levels. We had top-notch developers and some of the smartest QA I have worked with. In team planning we ensured that we included QA in all facets. QA approved branch merges and were the ones who ultimately influenced whether a build was approved for release. Our team lead and our head of QA were fully committed to ensuring that we took the time to have quality builds. This was put to the test soon after I was hired. We were on a crunch to build a new app and release it to the app store. We had customers waiting, and we needed to get out to the public as quickly as possible. This started to sound familiar, but the difference this time was that QA was planned as part of the effort. We took the time to ensure that we aligned our release with our target quality expectations. Anonyome took the time to hire experienced product managers, QA, and developers. They took the time to plan out releases with quality in mind from the beginning. It was not just an afterthought.
Soon I was given the opportunity to lead a team of QA that was working to build our app on Android. We were working rapidly to catch up to our iOS team. My small team of QA was being pushed to the limit. I began to work with my managers to build our team. We looked into hiring another team member, but other teams needed the focus and the emphasis. I was told that it wasn’t in the cards to hire more QA for my team. I was used to the idea that quality took time, and time was managed by more people and not less. I was at an impasse. If we were working to ensure quality first, and I didn’t have the people that I needed, how was I supposed to manage time without sacrificing quality? Luckily, I have two seasoned managers that were able to enhance my thinking. They were able to open my eyes to the obvious concept, that if we estimated the time it would take to complete our work correctly, we would have enough time to complete the work. We needed to understand better the work that we were doing and start to predict some of the pitfalls that we might face. We could also push back on a timeline that was too short to fulfill what we were estimating to be done. I didn’t need to be a yes man and bow to the pressure. I needed to be honest, quality takes time. If we wanted to produce the high quality that we were known for, we had to take the time.
Throughout the years, I have learned a lot of lessons and learned a lot about QA. The most important to me has been about time management and delivering the most quality product that I can. Quality takes time, but this can be managed in several ways. We cannot always count on having highly experienced professionals on the team. What we can do is make sure that not only do we have enough people to handle the tasks ahead, but that we have properly scoped out the time it will take to handle the workload we are given.
Photo credit: https://unsplash.com/@serenarepice
