Category Archives: Week 6

B6: Model-View-Controller

Model-View-Controller

          This week, I chose to write about a blog that went over the understanding of Model-View-Controller. The post first started by explaining each term separately by saying that the Models represented the knowledge while the View was a visual representation of the Models and the Controllers were the links between the user and the system. It talked about Models first, saying that most of the time there should be a one to one correspondence to make sure everything is easily understandable. The blog then goes on to talk about Views as a presentation filter, it would be used to easily convey information. As stated before, this is helpful when it is a visual representation of the Model but it can also be connected to the model which allows it to know more about the attributes and data. This leads to the controllers that essentially allow the user to see outputs based off of menus and other ways of giving commands and data. It uses this output to then make changes back in the Views section which will them give out another output.

          I chose this article because it seemed important to know more about how to explain code using models and controllers in this sense to other people. This post used examples that allowed this idea to be understood much easier for me, as the summary was a bit confusing. When they used the example of HTML code in the browser it made much more sense. The way I understood it after that was that the model was the information the creator wanted to put into HTML while the CSS was the view which acted like the “code” that displayed everything in a clean visual representation. This all came together within the browser which they linked to a controller as it is what combines and connects the entire thing. As I said before, the content had ok definitions but the examples they used made up for it since it allowed an easier understanding. I thought this topic was important since we will be learning about this subject as it is a software architectural pattern. This material affected me by showing me a system to show the user simplified information through the use of code. I think that if this were to be implemented within coding, it would be best used as a way to reuse code along with implementation of user interfaces. As a software architectural pattern, I could see this being important to future practices as it seems to be used a lot within popular programming languages and even web application development.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Bug Taxonomy – Classifying Software Bugs

This week I have decided to change things up a bit. Seeing as we are now past the halfway point in the semester, I decided to start exploring some blogs other than the group I normally browse, just to try and find a different voice, a different point of view. I am happy to report I have succeeded in this mission, and have found a blog post by Michael Stahl on stickyminds.com that clicked with me.

One of the recurring problems we face as testers is making sure that we have covered everything that could possible happen in a piece of software, good or bad. Stahl suggests using bug taxonomy as a way to think of new ideas on what needs to be covered. This type of taxonomy is not trying to compare types of testing with type of bugs, but trying to put software bugs into categories. If you have a list of categories you can go to each time you run through the testing gauntlet, it may allow you to think of new tests that need to be written for your product. A few bug items under the category of performance he suggests are from Testing Computer Software, by Cem Kaner, Hung Q. Nguyen, and Jack Falk: slow program, poor, responsiveness, and no progress reports. His list goes on, but you get the point.

Once I saw this list of categories, this strategy totally made sense to me. Basically, have a list that is entitled “Have I covered:” or something to that extent. Running through the list forces you to think of scenarios you may not have covered, but should be covered. And since the list is categorized (i.e. performance, user experience, etc.) it allows you to focus on one testing area at a time. I can tell you that after reading this post I made a list of things I need to go back and check on for something I am working on at work. So, this strategy has already paid dividends for me.

Although other testers list can be useful and is a good way to share ideas, Stahl strongly suggests making your own list to reference again and again. This is because you may not agree with how another person’s list is laid out. For example, in the list from Testing Computer Software, Stahl mention how under the performance category is “no progress reports”. He feels it should be under a user experience category. I agree that is should be under user experience, but these lists are all up to the testers opinion, so it is not wrong that the book has it in a different spot. This can be avoided by making your list.  

I really enjoyed this blog because making a bug taxonomy list seems like a relatively simple way of trying to find new tests. It practical, and be applied in everyday use without a big hit on time. We always talk about how important time is with testing, so if there is a quick and efficient way that is going to help make my tests better, I am in.

Link:

https://www.stickyminds.com/article/using-bug-taxonomy-design-better-software-tests

Link to picture: https://images-na.ssl-images-amazon.com/images/I/710avuIF12L._SY550_.jpg

 

 

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

What is Smelly Code and Why Your Code May be Stinking Up the Room -Continued…

So, we meet again with what makes code stink. As I mentioned in my blog last week, this is a continuation from the same post that I covered last week, as there were simply too many points I wanted to hit upon to fit in one post. For those who missed last week’s post or can’t remember, smelly code is basically trends in code that commonly known to cause problems. The goal is to make sure you code doesn’t stink when you are done with it, or you’ll regret it later down the line.

The next item on the list are comments. Comments can be great. They provide insight into how the developer was thinking, why they designed it the way they did, what is going on in that quadruple nested for-loop below the comment, etc. The thing is, if you are really a good developer, an argument can be made that the code can speak/explain itself. Personally, I’ve always found comments useful and insightful, but the point here is that your code should not be so ambiguous or so complicated that you need an entire paragraph just to explain what is going on. While I don’t necessary agree that there should be no comments at all, I do agree that comments should be kept to a minimum, and if you can’t, something is wrong with your code.

Pressing further down Jeff Atwood’s list of smelly code we run into the category of duplicate code. Please don’t duplicate your code. The reasons are self-explanatory, but I will reiterate: it is bad, wasteful, and inefficient. If you need to perform a task more than once, put it in a function, simple as that. You’ll save everyone a few headaches. Similarly, he mentions dead code. That is code that is sitting in there, wasting its life away as a comment or performing some task is never used, wasting resources. There should never be a need to leave unused code. The wonderful invention of version eliminated the need to leave old code sitting in a program.

The last item on his list that I want to touch upon is the bad habit of making items public when shouldn’t be, or as he calls it, indecent exposure. There should be a strong effort to make everything is as private as possible, and there should be a damn good reason if it not private. Exposing the internals of a class is dangerous and unwarranted. Unless something absolutely has to be public, it should stay private.

There were items on Atwood’s list that I felt were unnecessary or didn’t completely agree with, but overall, I found his list of code warning signs useful and brought up many valid points. As developers we want our code to be clean, efficient, and easy to read. I feel that going through this list would certainly help anyone reach that goal. A lot of the items on the list are thing experienced developers should know better than to try anyhow, but it can’t hurt double check when you are done. I know I certainly will try to run through his list in the future.

Link:

https://blog.codinghorror.com/code-smells/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Software Testing Life Cycle

This week I looked up software testing blogs. While searching the web I found this one blog called mallow-tech. there was this one blog post called “Software Testing Life Cycle” written by Periannan, a test engineer for Mallow Tech. In this blog it talks about what software testing life cycle (STLC) is. Software testing talks about the testing process that has specific steps to be done to make sure that the code meets the quality standards. For many companies they have different phases for STLC however the base of it is the same for every company. STLC usually has six phases. Requirement Analysis, Test Planning, Test Case Design, Test Case Execution, Re-Testing and Regression, and Final Testing and Closure. In the Requirement Analysis phase this is where the team talks to the client about what they want and talks to the team of developers about what parts are testable and how they would run those tests. The next phase is test planning which they see what kind of they are going to use to test out the code. Number three is test designs this is where test cases are created according to the specifications for the project. Next is the test execution. Here they execute the tests in logical sequences with specific test data. Next is the retesting and regression testing phase by this time the tests would have been done and the bugs would have been reported. The team would then fix those bugs and then run the test again to make sure everything was fixed. Lastly final testing and closure is where the final parts of the STLC is completed and they start to send it out into the public to find out if the code works.

This blog was very helpful for me because I did many blogs about different tests that we have to do but this blog talks about the process of testing. With this blog I think it is super helpful as an add on to my other blogs. In the real world we are not going to just run tests one right after another. We need a plan on what to do and when to do it. This shows me that everything in the computer science world is not just doing code and making sure it works it is all about doing things in steps just like how we write code it should be neat and organized and planned.

From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.

The Clean Coder 11 & 12 Week 6

The first part of the reading talks about pressure in the work place. Commitments are a big deal in a professional environment and while you should try to avoid them as best you can sometimes other people make them for you. You are not responsible for these commitments if you did not agree to them so you should not stress over them. Keeping everything clean will help reduce stress, so make sure to take the time to make sure your code is clean. I know that if I start coding quickly and dirty that it becomes a mess and I get stressed out. Don’t be too proud to get help, if you’re running behind find a co-worker that is willing to help you.

The second section talks about collaboration, it’s a very important part of programming, we can’t do it all ourselves sometimes. When working with a team do not “own” your code, make the code accessible available to change by anyone in the team. A lot of programmers did not get into their field to work with people, quite the opposite, most did because they don’t enjoy working with people. Unfortunately there is no way to avoid this, working with other programmers and clients cannot be avoided.

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.