Author Archives:

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.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Decorator Design Pattern

For this week’s blog on Software Design, I decided to watch a short tutorial on one of the design patterns I didn’t pick for a previous assignment. I picked Proxy Design pattern to cover before, and now I’m going back to learn about Decorator Design Pattern. It is only a thirteen minute video, so I won’t be going as deep as I would had I picked it for the assignment. I am also going to talk about my reflections on it rather than create a tutorial, so I am not going to reteach it to the person reading this blog post.
The tutorial I chose was made by Derek Banas on YouTube. He used an example of a pizza parlor to illustrate the wrong way to code it by using inheritance. He shows the problem with this because you would have to create a very large number of subclasses for all your objects (in this case pizzas).
Composition, on the other hand, is a dynamic way of modifying objects. Instead of creating as many subclasses, you add functionality at run time. It has the benefits of inheritance, but is better to implement in many cases because it is more flexible. Instead of rewriting old code, you extend with new code.
This seems like a more intuitive way of doing things. In the example in the video, he uses the example of creating different kinds of pizza. If you were to design a menu for the same pizza place and there was twenty ingredients and different prices for each, it would make more sense to list the cost of the sizes “Small $5, Medium $7, etc.” and the prices of the toppings in a similar way, with Pepperoni and Sausage being 50¢ and 65¢ respectively. The customer would then choose the size and toppings and add all those together to get the total price.
It seems like the decorator does exactly this. It would seem silly for a pizza shop to list every permutation of toppings and sizes. It would make sense if there were only a handful of pizzas to choose from, but it does not make sense to do this if there are too many ways to list. Same with inheritance instead of decorator design pattern. The same logic is true with inheritance. This seems like an incredibly useful and versatile tool to use. I think learning about this will be incredibly invaluable for the future.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Quality Assurance as a Career

I decided to take a somewhat different tack for this week’s post for software quality assurance and testing. Instead of focusing on testing itself, and all there is to it, I found a video from a tester in the field, Alan Richardson, on his advice for someone who is interested in getting into the field.
He strongly urged someone getting started not to think of a position in quality assurance as a “stepping stone” to being a software developer. If you do, you will inevitably find yourself in a dead end because you really aren’t interested in the field. “If you want to be a software developer, start as a software developer.” 
He encourages the viewer to read everything they can on the subject. A lot of it is free, so there is no reason to necessarily buy anything. However, he gives some book recommendations. He gives a good insight why books can be so valuable to learning. “An expert in the field took a year to concentrate everything they know into those pages,” (paraphrased).
He doesn’t value certification, but he realizes that many companies do. I didn’t realize there was certification. Even if I don’t end up getting it, it’s useful to know that it exists. He also said that it is easier to go into testing from designing software. 
He also urged testers to find companies that valued the work they did and that provide opportunities for them. He said that oftentimes testers are paid quite a bit less than they’re worth compared to software designers. Not only is picking the right company important, but you should advocate for yourself because the work you do is important.
I thought that he offered some sound advice. I haven’t seen that much other software quality assurance career advice, but this all seems to fit what I’ve heard over the years for computer science or general career advice. I am excited to start working for a company, perhaps one day as a tester.
Strangely, I don’t often think about all the different positions within the computer science field. I tend to lump everyone as a “software developer,” even if I know there’s a lot more to it than that. I am starting to rethink that and consider going to quality assurance. It is something I enjoy, and it is something I can see myself doing.
YouTube Channel: EvilTester – Software Testing

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

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 in this field, by establishing why a need exists and then later explaining the concept.
There are three things covered that influence architecture. First, agility, which is the speed and coordination to change. Most companies try to embrace this, but many businesses fail at it. Second, velocity, which is the speed of something in a given direction. Third, modularity, which is when independent parts can be combined in lots of ways. They went over the upsides and downsides to each, and you have to compromise many times at one aspect for another
I thought one of the most interesting parts of the podcast was when he said that if you wanted to see what was coming next in technology, read academic papers from twenty years ago. It takes that long for one level of the level of architecture, hardware, to catch up to another, software. It is only recently that we can implement this technology.
Another interesting thing he said was that one of our biggest inhibiters to evolution is the integration of data and functionality. He foresaw a paradigm shift in how we handled this.
As a parting message, he was asked, “what would one piece of advice you would give to an aspiring software architect,” and his answer surprised me. He said to work on people skills, and that was the “hands down” most important advice he could give. This skill is so key in everything you do, including lead and mentor. I found this incredibly interesting, because I am often reminded about how we never do everything in a bubble, and it is extremely important to be able to “play well with others.”

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

A simple design principle

This week blog will be talking about DRY design principle and it will be based on this article. These principles are really useful for software development yet there are still quite a lot of people tripping over it.

A bit background about DRY. DRY stands for Don’t Repeat Yourself. It is really simple but important to understand. It is essentially know as a philosophy that packages the logic into representation. This design principle has been known for a long time and its acronym is mentioned in the book The Pragmatic Programmer, which is published in 1999. The concept of DRY wouldn’t be a big of a deal when you are writing a small program, a code snippet or a short script. However, when it comes to a big software project, not applying this principle would not only cause a lot of problems but also can waste resources and increase the length and complexity to your programs, and all of these would lead to the increasing requirement of your clients’ machine. Besides, it is not just bad for the hardware itself, it would take more time for you and other developers to just understand your code.

To achieving DRYness, a simple way to put it is to divide your system into components, where each of these components represents its own subsystem’s functionality. For instance, if you are building a file sharing system, your program should break down into multiple pieces like git system, file management system, etc. and inside user management system, there can be subcomponents like role management system and access control system. As the program is divided further, there would be a clear hierarchy where each subcomponent would only have one function to support the components themselves, and it would greatly reduce the complexity.

I really like the part where the author quotes that “Every piece of knowledge must have a single, unambiguous, authoritative representation within a system” meaning that if you are repeating any piece of information, you are doing it wrong. This can be really easy to make mistake and I actually did quite a lot when I first started programming. For example, instead of making the connection to the database every time you need it and then close it immediately after you are done with it, you should make a separate class that handles the connection to the database as a singleton and it should open the connection to the database when the first time you call the function and close it when a specific event is triggered. In a perfect implementation, every piece of information should be encapsulated its knowledge in the form of variables, objects or a class property.

It is absolutely impossible to achieve 100% DRY, but the more DRY your code is, the better for you and other developers to maintain it. It is a concept that is worth looking into while revising your code whether it is a small or large project to develop a good habit of doing it.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

Testing: Like Destroying Sandcastles
In this blog for software quality assurance and testing, I decided to return to the “Test Talks” podcast, presented by Joe Colantonio, for another episode (#223). In it, he sat down with Noemi Ferrera, a software tester for a Chinese mobile gaming company to get her take on the subject.
Noemi gave a few interesting metaphors that I appreciated for how to look at testing. In one, she gave the example of going to a movie where you had already read the book. It was different than how you imagined it while reading it, and testing is a way of making the “movie version” fit the way you envisioned it playing out. 
The other metaphor for testing that she gave was, if you were children at the beach, the developers would be the ones building the sandcastles, whereas the testers would be the ones destroying them. I don’t know if that would be the most accurate way of looking at it, although it is amusing, and I’m sure many developers might harbor some resentment towards testers for telling them their code is flawed.
An interesting side note was something that it sounded like the host said, which was that testing was not in any curriculum that he’s aware of at the college level. He said a lot of computer science majors coming out of college doesn’t know much about testing. I would have thought testing would have been taught more broadly. Perhaps he should take a visit to WSU and audit this class if it truly is not very common. 
She came from humble beginnings, starting to code at nine by fixing bugs in her computer games so they would load faster. Not all of us can say we started coding at such a young age. I was introduced to my first programming class when I was in college. She encouraged listeners to “go to a meet up,” and if there are none around, “make one.” “Be curious and go do stuff,” she said.
I was heartened that she said this because the new chapter of the Worcester State computer science club is holding our first code jam this upcoming Saturday to design out own website. I am excited to do exactly what Noemi is encouraging a beginner coder like myself to do. Although there is probably not going to be as much of a focus on testing at this meet up, I’m sure she would be proud.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

OOP Basics

For this week’s blog on software design, I chose to watch a video presented by Dr. Steve Bagley on some fundamentals of object oriented programming (OOP). I’m embarrassed to say that although I am taking several upper-level computer science classes, I am unsure I would be able to give a good definition of what object oriented design was. To be fair though, it has been several years since I have taken CS 101, and it seemed like such a foreign concept at the time.
I felt silly learning about something so elementary again, but it made a lot more sense when I’ve had as much exposure to OOP as I have now. For the video, he uses a game of “Pong” as an example of how OOP might use objects to represent the “ball” and “paddles.” From there, he talked some about inheritance and touched on a few more topics, albeit briefly.
The main reason why I didn’t understand the benefit of this way of programming is that I didn’t know how else you would do it. I didn’t realize that without declaring objects, how difficult it would be to keep track of everything and make everything work properly. 
This video was made for someone who might be interested in computers, but this is not their specialty. Although this was helpful for me in getting a better background on what OOP is, I felt it did not go far enough. I would have liked it if it went a step further and explained some of the next topics that would logically follow. The video was under fifteen minutes, and most of the videos in the channel are that length, so there wasn’t that much room to expand. 
He said that he would go over the topics like inheritance in another video, but I searched through all the videos with him, but I could not find the “OOP part two” or anything of that nature. I don’t like that the channel doesn’t cater to people with a computer science background, but on the other hand, there are some interesting looking videos that I would like to watch after this. My next step will be to learn about functional programming because I do not have any experience in that area.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Spending Testing Time Effectively

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.”

The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.”

These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class, we have been going over ways to be more methodical when testing. This list is a little more elementary than what we have covered, but it is good information to use nonetheless.

A key takeaway is to treat testing more like a science than throwing it together willy-nilly. There has to be a method to the madness. You have to know what you want the test to do. You should have a clear understanding what the end product should look like and how it should look to the end user.

The final section in the article said testing isn’t “Rocket Science, but it is not a trivial task either.” It should not be seen as something that could be done by almost everyone, which is a common belief in the industry. This is not true. It is an important job that should be done right. It requires being very organized and staying on top of things. There are many things that can be done haphazardly. Testing is not one of them.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Designing the code is more important than you thought

Personally, I always think that the design phase of a program is very important and it should be done almost immediately after I started setting up my git project. Like all other new developers, at first, when me and my cousin were working on an Android project, we thought it would be just a waste of time. Surely after a month, it started to really fall apart as we have all sort of problems like our implementations does not work well together with a lot of lengthy methods that is definitely not necessary to be that complex, and we even used some dependencies that are obsoleted just to make another piece of code compatible with the situation. We learned our lesson and from then, we developed a habit to jot down some idea and implementation to at least let each other and ourselves how we would carry out the project. I actually found this article months ago and I think it’s already pretty neat, so I decided to write my blog this week based on it.

For a start, this article is written by Marcus Biel and it mostly talks about what he called “Clean code”, which is basically the idea to have your code be precise and as close to perfect as possible, even though it is a small project. I really like the part where he says “If you have more code than you need, it shouldn’t be there. There shouldn’t be anything superfluous, and I go so far as to say that there shouldn’t even be superfluous whitespace. You want your code to be as efficient, readable, and maintainable as possible, and instead of only solving the problem.” This is probably what everyone should expect to achieve after finishing their “first draft” of the program.

Some would ask why is it so important to spend a lot of time on this phase. He gave two simple cases that are really relatable to programming. Imagine living in a house that was built without any blueprint and when it falls apart, you would not even know where to start to fix it and eventually, the roof caves in. For instance, when you have a shopping cart, of which function is to put things that you would buy into but people keep throwing trash into it until it spills out and you don’t know which one to put on the checkout counter. In these cases that he gave, it was really clear that there are no boundaries or rules to maintain your object and prevent it from long-term problems. The lazier you are at first, the more efforts you have to put in in order to have it up and running. Even if most of us are not perfectionists, this problem can’t be ignored as our projects would get more complicated the more we develop it.

Now that we know that it is critical, we can look at a few ways to accomplish clean code. The simplest thing that you have to do is to not think it as a coding project, think of it as a design and planning process. Let’s pretend that you are building a house. A strong foundation is what we really need and that can be seen from the coding aspect as file structure, classes, and methods without any bodies. When you have a solid foundation, it would cost fewer resources to maintain as it is already hard to fall apart and even if you want to expand, it is much easier to base on the old foundation, rather than having to build another one.

Not only a solid foundation that we need, but we also need the coherence, or should I say it is easy and makes sense to everyone who read it. The author of this article makes a point that we should follow the idea of “ubiquitous language”, which is to have your variable names, class names, and package names to make sense to whoever is reading your code. This design is called Domain-driven design. In addition to this, I also think that it is important to follow the naming convention, use detail unique name for variables and practice proper indentation so that myself and the one I work with can see the structure and what words mean without having to scroll up and down a lot.

Without any further reading, I think these pieces of information that I have given are quite enough to convince you to think and start to develop the habit to have a design phase before carrying out the project.

From the blog #Khoa'sCSBlog by and used with permission of the author. All other rights reserved by the author.

A Review of Software Engineering Radio’s Conversation with eBay’s Randy Schoup (ep. 109)

I was interested in what someone from such a large website, eBay, would have to say about its architecture. There was a lot of takeaways from it, summarized in four main ideas: partition everything, use asynchrony everywhere, automate everything, and design the system keeping in mind that everything fails at some pint in a large distributed system. Although this is an older talk (from 2007), these all seem to be sound systems to design something so large. He referenced a theorem from 1998 that he said took a while to get traction. Likewise, I am sure his design principles have proven true for the last ten years.

To be completely honest, there was a lot of industry-specific jargon used that went above my head. I took a lot of notes though, and looked up the terms I did not know. I still found it very interesting, though. I found it the most interesting that someone designing one of the largest websites in the world was incredibility realistic of the shortcomings of everything designed. It seemed that everything designed had to have a degree of compromise of what was expected of it. He referenced the “CAP Theorem,” where it seemed you cannot always have all three parts that it stood for — “Consistency,” “Availability,” and “Partition tolerance.” He also was realistic that everything can fail, especially  when the system gets as big as it gets bigger. For some reason it surprised me when someone from such a prominent company would admit this.

Something else that really surprised me what he said one of their biggest limiting factor was something I would not have expected, which was power consumption. He claimed that some companies’ database centers can use more energy than a local power station can support. This makes it much more important to design efficient database structures, especially in a company that deals with data in several petabytes.

It just boggles my mind how reliable websites like this are for millions upon millions of consumers. He said $2,000 worth of transactions were made every second, and that was over ten years ago. The site has grown since then. This gave me some great ideas to run with, as I hope to one day work for a company as esteemed as his.


From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.