Skip to main content

Quality Assurance at Apple


For this week’s blog for quality assurance and testing, I decided to read an article from Wired Magazine that focused less on the testing process itself and more of how a company can benefit from it. The article I chose is a little less than a year old about Apple’s securities and vulnerabilities. The article confirms some of what I had hoped — that Apple still has a strong reputation for security. However, some vulnerabilities have damaged how the company is perceived by many. 

In High Sierra, all that you had to do to gain root access was type the word “root.” They fixed it impressively quickly. However, the article wonders if the security flaws like this are emblematic of deeper problems. There have been many more bugs and vulnerabilities found, such as wonky autocorrect on the iPhone. Although not every bug (like the autocorrect) is not always a security issue, it is incredibly irritating. 

One advantage that Apple has over its competitors is that most of its customers update as soon as there is an update. The advantage of this is that people will not be vulnerable using a software without the security fixes in the update. However, Apple might lose this edge if people are wary of updating if it seems like there are always too many bugs in every update.

One of the big problems these days is that it seems that everything seems rushed out. There is a big focus on new features, and not as much focus on fixing the bugs on the features that already exist. The article talked about a 2009 release of “Snow Leopard” which built on the previous release “Leopard.” It heavily focused on getting bugs fixed.

Another issue about perceptions is that even if the mistakes are fixed quite promptly, they are still remembered, with what is described as a pile-on effect. That is, a fixed security flaw won’t be “erased” from a customer’s mind.

The takeaway from all of this is how important quality assurance is to any product. It perhaps is more important than new features. If the old and new features are continuously full of bugs, it is hard for a customer to trust that company anymore. It is better to have solid core software than one with a million extra bells and whistles if it means there’s just as many bugs. Unfortunately, the article concluded that it seems like Apple is leaning towards the latter.

https://www.wired.com/story/apples-security-macos-high-sierra-ios-11/
Labels:

Comments

Post a Comment

Popular posts from this blog

Data Structures Primer

I've been a tutor for this past semester to students taking Introduction to Programming. Many who have come to my session are moving on to Data Structures next semester. They asked if they could have a primer as to what to expect. I have some resources that I have found helpful both while taking the course and tutoring it in the past. It will take me a little bit to compile a good list of those, but for now, here is a bare-bones list of topics of topics you might expect to see for a data structures course: Part 1: - Running time of code segments (Big-O Notation) - Abstract Data Type (ADT) - Interfaces (when to use "implements", cannot instantiate them, what inheritance is) - Superclass, subclass, method overriding/overloading - Abstract classes Part 2: - Binary Search Trees - Stacks (and its four methods — push, pop, peek, empty) - Linked list (single, double, circular) - Prefix and postfix notation (compare to infix) Part 3: - Min/Max Heap - Hash Table...
Post a Comment
Read more

Apprenticeship Pattern “Practice, Practice, Practice”

The apprenticeship pattern framed the problem is that if you do not have room to make mistakes in your day to day programming, you will not have room to grow. The next line hit close to home, “It’s as if you’re always on stage.” I learn quite a bit from my school assignments, but I don’t always think I have mastered each area before moving on to the next topic. The problem arises when I know my code could be improved upon, but it’s currently working. I don’t want to restructure my code too much, because I’m afraid of making it worse. The term comes to mind, “If it ain’t broke don’t fix it.” I have problems with this way of thinking, but when you’re pressed to make something work before the impending deadline, “good enough” is sometimes feels like the only option I have left. This pattern champions a different approach to this kind of mentality. I like the idealized version that they have laid out based on the research of K. Anders Ericsson. This describes where a mentor would ass...
Post a Comment
Read more