Skip to main content

Shailesh Rao on Quality Assurance

In this episode (number 219) of “Test Talks,” I was able to hear Shailesh Rao’s insight into having quality software. He compared it to a “paper-free office” or a “stress-free life,” both worthy goals, but are hard to achieve. They can be strived towards, but it is near impossible to get it 100%.

He brought up the issues that bad software can pose to potentially millions of users. Bad software can open the doors to hackers, who might be able to take down websites like Twitter or Reddit. Also, it might stop airlines from being able to function — an annoyance to most, but Mr. Rao asked, “what if there was time-sensitive and lifesaving medicine onboard?”

I found this podcast brought up some aspects that I had not thought of before when if comes to quality assurance. I suppose that I’ve thought about the various things he brought up, but as a consumer and never as a creator of the software.

A very thought-provoking topic brought up was the fickleness of consumers. They don’t have the patience to put up with a buggy app. They will move on to the next thing. It is easier than ever to launch a software project to a very wide audience, and it’s become apparent to me that it should be done right the first time around because customers don’t always give a product that flopped a second chance.

Another point brought up that will affect the way I think about testing and quality control is that you should test for all possibilities or you might not know the market you missed. People often say to themselves “it won’t happen to me,” and think their software will not be downloaded millions of times, but if they didn’t prepare for those conditions, they won’t get that chance.

The core message that was hammered home was that developers should have quality at every step. With as complicated software can be, it is extremely difficult to have it be truly bug-free, but it is possible, and we should always strive to be as close to it as we can.

Comments

Popular posts from this blog

Mark Richards on the Evolution of Software Architecture

For this week’s blog on Software Architecture, I listened to Episode 3 of the “Software Architecture Radio” Podcast, which featured Mark Richards, an independent software architect. He has 32 years in the industry, with more than twenty years as a software architect.  They mostly talked about the evolution of software architecture. Although some of the things they talked about went a little over my head, I was able to pick up on the majority of what they were talking about.  He divided up the evolution of architecture into five stages. He talked about evolution happening in vertical and horizontal slices, that is within each layer and one layer affecting those above and around it. The layers were (1) hardware, (2) software, (3) human interaction, (4) social interaction, and (5) the environment, such as the internet of things. He said one thing in particular, need, drives change the fastest. As an aside, he also said that that’s the best way of teaching something i...

Sprint 5 Retrospective (Capstone)

It is a shame that we are so close to the end of the semester. We were gaining so much momentum. It took us a while for us to get off the ground, but once we did, we never stopped gaining speed. I feel we will be able to keep this up through this last sprint. My hopes at the beginning of the semester for what we could accomplish were unrealistically high, but I am not disappointed with what we accomplished. We have not completed a full working component quite yet, but we are very close. I think our efforts are best spent finishing the one we are currently working on and doing it right. If we divided our efforts into starting something new, we run the risk of not fully completing anything. In the sage words of Ron Swanson, “Never half-ass two things. Whole-ass one thing.” If we are able to get the tabs working beautifully, I will be happy with our effort. I have felt that our group has done a phenomenal job this sprint and every sprint before with our communication. We have a few ...

Sprint 4 Retrospective (Capstone)

This sprint, in my mind, one of the most important things that I was able to figure out was getting connected to AMPATH team through the Zeplin app. It seems that someone, perhaps accidentally, disconnected me from the group. Once reconnected, I was able to connect the rest of my group. Although it hardly was a difficult task, it is hard to overstate how important it is to be on the same page as the team you are building the product for. It could have prevented a lot of wasted time on our end, and it makes it more likely that they get the end product they want. Probably the most important thing I did in terms of learning about the tools we will be using was creating a “spike.” It is a new term I’ve learned that I will add to my lexicon, meaning to build a prototype of a product, diving deep to learn as much as you can. I touched upon it in my last apprenticeship patterns blog post, on “breakable patterns.” I failed to make a successful working prototype that did everythin...