http://www.ques10.com/p/2192/what-is-data-flow-testing-explain-feasible-paths-1/

Finally, for this week I decided to write about Data Flow Testing. I found a blog site called Ques10 and there was a question about what is data flow testing. The blogger Ramnarth ansered the question by explaining what Data Flow Testing is. Data Flow Testing is a test that tells us that a programmer can perform a number of test on data values which are collectively known as data flow testing. With data flow testing it can be performed at two levels static and dynamic. Static testing is performed by analyzing the source code and doesn’t involve in running the source code. It is performed to reveal potential problems in the programs which are also known as a data flow anomaly.  And with dynamic testing it looks at the path of the program from the source code and with this you would draw a data flow graph of the program select a critical testing area, then identify the paths in that data flow and test the derive inputs. He talks about how testing critical section on the data flow chart by breaking it down into paths and tests such as how we did it in class. Were we would look at the DU-Paths and look at all the edges and nodes to see if they make sense. I like this blog because it does involve some of the things that we did in class such as DU-Path testing, edges, and node testing. I like that the things I learned in class is also reflected into real life things we can do. I think data flow testing is just something we could be doing because it is just a bunch of tests that you run through so that way you do multiple test at the same time.

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.

Source: https://dotnetcodr.com/2013/10/17/the-dont-repeat-yourself-dry-design-principle-in-net-part-1/

For my last week I decided to write about Don’t Repeat Yourself design principle. I found a blog called dotnetcodr and there was this blog about (DRY) written by Andras Nemes where he talks about (DRY). The idea behind (DRY) is that you should not add repetition of logic in multiple places in the code. He talks about the motto that you should be following “Repetition is the root of all software evil.” Repetition does not just refer to writing the same piece of logic in two different places but also the repetition testing, debugging, deployment, ect.

He then gives an example of repetition where he writes out the person and then where the live as well. In this code he hard codes everyone’s name and address. This way it is a very good example of reputation because since he is just copy and pasting whenever he would need to add or remove a person or address he would have to go back into the code and manually change it himself.

I found this blog to be very informative because it is very true you do not want to repeat yourself and the logic of a certain code in multiple places and multiple times. There are times where I do this a lot because I find it much easier to repeat the code since it is going to be the same every time I want to call something. I think the thing I get out of this the most is that I will start to try and not repeat myself when writing code. Also I can use this for future knowledge when I do write things that do call things multiple times and like it shows in the blog we can make stings that have getter and setters that would make a 40 line code down to a 10 line code which would save much more space and time as well.

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.

Source: http://www.castsoftware.com/blog/five-reasons-to-measure-software-complexity

This week I looked up Software Complexity blogs. I found a blog called “Five Reasons You MUST Measure Software Complexity” written by Jonathan Bloom. This blog talks about how sometimes complex code aren’t the best thing. He gives you a few methods developed for measuring software complexity. Which are Cycomatic Complexity, Halsted Volume, and Maintainability index. With these methods companies and use the information found by them to capitalize how they are writing the code such as. Greater predictability because knowing the level of complexity of the code can make it easier to maintain and show how much maintenance a program will need. The software risk mitigation which manages the software complexity lowers the risk of introducing defects into production. Reducing cost because with lower mateine cost the origination can spend that money on other things. It extends the value of the programs because excessive complex application causes issues. With this it keeps the software in cheack and keeping the complexity of it in check. Finally, decision support with this it allows the owner the information to tell if it is worth the cost of even fixing the code or if writing new code be worth it.

The benefits of software complexity analysis are that it improves code quality, reduce maintenance cost, heighten productivity, increase robustness, and meet architecture standards. Because of this a lot of bigger and smaller business try to add this analysis to make sure that they are not losing money because the software is too complex for what they need. I like this blog because it backs up one of my other blogs that talked about keeping code short and sweet. We should do code as basic as we can to keep things neat and organized and don’t make it crazy so that way we don’t waste time doing things we didn’t have to do. I think I will keep this in mind when I move on to my next step of my life. Keeping code nice and simple is the best way. I also think that I will keep this in mind when I am working on the final project for many of my classes because we don’t want to write too complex programs for our robotics class and our software constr class as well

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.

Source: http://codermike.com/starting-c4

This week I decided to look up C4 Models and I found a blog that talked about what C4. This blog post called “getting started with C4” by Mike Minutillo talks about what the C4 model is. The C4 model is a way to let users communicate and describe software architecture. This is really good because when working in a group and asked to draw out the architecture of your code besides having everyone draw up a different drawing than each other everyone would have the same kind of structure across the board. C4 models is a toolbox that allows the team various well-defined layers of abstraction to develop and communicate the static structure of a solution. He then goes and talks about what the toolbox is and abstractly it is a software system that is made up of one or more containers, each of those contain one or more component which in turn implements one or more classes. With C4 there are 4 different levels of abstractions. Context, Container, Component, and Class (which is why I guess it’s called the C4. Makes sense, right?) Context shows key systems, the dependencies between them and the actors that access them. Container shows the high-level technology choices, how systems are decomposed into containers and how those containers communicate. Component shows the internal structure of a container and how it is decomposed into collaborating components. And finally class is a typical UML class diagram showing the internal structure of a component.

Why I like this blog is that in the blog Mike tells the readers step by step how these C4 diagrams are made and the perks of using it. They are very similar to UML diagrams so that way when showing these to the customer it would be easy for them to understand what you are writing and also I like this a little bit more because I feel like with the C4 diagrams they are more meant for programmers to share with each other and if someone were to join the project later on they would look at the C4 diagram and would not be lost on what to do. I think it is great that we have many ways to show our work besides UML diagrams and we are not stuck into one way of showing things and I would be using these types of diagrams in the future. This would be useful for future project in class and even when I move onto bigger and better things.

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.

Source: http://www.softwaretestinghelp.com/web-application-testing/

This week I decided to look up different types of testing and I found a blog that talked about web testing. This website called software testing help had a blog that talked about web application testing and it gave a complete guide about testing web applications. I tried to find who the author of the post is but I could not find the name but the author talks about some web testing cheklist that programmers should go through before deploying their website. Which are

 1) functionality testing:

you should test your website to make sure that all of the links, forms, cookies, html, css, and database all work fine. It is important to make sure that the links are not broken links and that the code that you want to display onto the website are displayed correctly and in the right position.

2) Usability testing:

The usability test means that the website should be easy to use, any and all instructions that are on the website should be clear. There should be a main menu link on every page and it should be constant though out the website. You should also make sure that there are no spelling errors, all the fonts, colors, frames, etc. are all on the right setting.

3) Interface testing:

Check if the interacting between the website and the servers are functional and any errors that are given are handled properly.

4) Compatibility Testing:

Make sure that the browsing compatibility is available for all sorts of browsers and OS such as Firefox, google chrome, AOL, windows, MAC, Linux and other OS and brewers that are available today.

5) Performance testing:

You should make sure that the website can handle heavy load of traffic though the webpage so it does not crash and would be able to handle large user request simultaneously. A web stress test is to test the specific limits of the website and sees how the system reacts when it crashes and recovers from those crash.

6) Security testing:

Finally you want to make sure the security for the website especially a website that would take personal data and save it on its data base be secured enough for people to log in and feel safe that their personal information is protects.

I like this blog because right now in our class we are going to be devolving our own website and even though we are not going to have it be deployed to the public there are some testing in here that are good to remember when writing our code. In future situations when I am writing programs for websites this blog is a good reminder of what kind of tests I should do to make sure that I am doing everything before I deploy a website.

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.

Source: https://snipcart.com/blog/tips-on-code-refactoring-from-a-former-addict

This week I decided to write about refactoring code. I found a blog written by Charles Ouellet called “tips on Code Refactoring, from a Former Addict” this blog talks about his own experience on refactoring code. Refactoring is rewriting existing code and redoing it to make it more readable and more maintainable. When Charles first started he career as a developer he had a serious refactoring addiction where it even hindered his own work and delaying him from sending out his code to the consumer. For this blog, he talks about his own perspective of what are good reasons to refactor code and what are some bad reasons to refactor code.

Some of the good reasons to refactor code is to avoid technical debt. When you write code and the business takes off after it starts to grow even more there may be new problems that arise out of it. Refactoring code can be a cheaper option of fixing the program then to write a brand-new program to do the same thing that you want it to do. Another reason why it is good to refactor code is that it can be able to teach new people that are joining the project half way though to learn the base of the code. This way it allows the new coder to see every class that is related to the application and they would be able to understand most of the code that was written before him. Finally, with technology evolving every day refactoring code to adapt to those new technology is a much cleaner and easier option to do then to write a brand-new code to adapt to the new technology that is out on the market today.

Some of the bad reasons to refactor code is to make the code look prettier. Most of the time coders would look back after a few days or weeks because the code they wrote was just ugly and wants to go back and fix it. However, that is a waste of time and money for both the coder and the company. If the code works fine you should not refactor the code just for the sake of refactoring. Another reason is to integrate new useless technology. When you are refactoring your code to integrate it for a new technology you should take a step back and think about what does this new technology bring to the table of your product and would it be worth it to even refactor the code for something that is just a one hit wonder.

I like this blog because it is from an experience developer and his own opinion of when it is good to refactor code. I think this topic is very good to learn because in school we are always changing out code to make it look nice and make sure it works so we are constantly refactoring it but in the real world we would not have the luxury to keep changing our code to make it look nice and to just re work it all together. So this blog gives you a good base of when you should refactor your code and when you shouldn’t

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.

Source: http://www.cigniti.com/blog/why-you-should-take-automated-testing-seriously/

This week I decided to write about Test Automation. I found a blog that talked about Test Automation. However I have never heard of test automation before so I had to do some research and find out what it was at 1^st. from what I read online test automation is basically testing programs by using other testing software outside of the application itself. Test automation has been around ever since the computer industry has been out. Testing is not like what programmers do where they just run their code in different situations and different fields and input and outputs. These test automations were people who were dedicated to testing out software not like debugging it but running it though tests. This was a much larger and more complex system that even was to be thought of as a discipline worthy of study apart from programming.  With testing it was not just some AI testing the programming for incidentally, accidently but inherently for human errors and human interaction with the program. Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester. With Test Automation it should not be programmers testing out the code themselves and seeing if things work but people who have no idea about what they are working with or doing to test these codes and seeing how human action affects the program they are using.

This topic I read was kind of interesting because it talks a bit about what the first testing there was in the computer science world. To me I think that this kind of testing should be used a bit more because I don’t think that the people who are writing the code should test it all the time because there could be mistakes that you don’t notice and especially programs that are going to be used for the public having someone who has no idea about what code is and how to read it test out the program is useful. I think I would use this in real life situation when doing testing for code I write because like people say old but gold.

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.

Source: https://medium.com/omarelgabrys-blog/the-story-of-object-oriented-programming-12d1901a1825

This week I decided to write about Object Oriented Programming. I found a really helpful blog written by Omar El Gabry. This is his own blog talking about object oriented programming. I honestly wished I wrote about this sooner because it would have explained things to me much easier then when I was trying to learn for class. This blog explains all about object oriented programming. He breaks things down step by step even explaining what objects, classes, attributes, behaviors, etc. mean. I really like this in a blog because when someone with little or no programming background can be able to understand what he is talking about. In the blog he even gives real world examples talking about object orientation. He then talks about abstraction and what abstraction means. He uses the example of a car and what do you think about when you hear the word car with abstraction it’s the color or the size of the car and that is basically what abstraction is. It is the adjective of the car. He then talks about encapsulation where in code we don’t want to write out super long programs because there are things that we write that we don’t want someone to read or have access to so we would just hide the classes we write and restrict access to it. He gives a very true statement that I think every coder should take to heart is that when you encapsulate something we should hide as much as possible because in the real world you do not want everyone seeing what you wrote. He even added code so people can mess around with it and see how it works. In the code he has classes called animal and then dog, duck, and kangaroo that extends to the animal class and the main class uses the animal class to prints the name of the dog and the color of the dog and everything like that.

I thoroughly enjoyed reading the blog because it was a good refreshment of what I just learned and a much easier explanation of what I did before. To me I don’t think it would affect my future learning practices but I do think it’s a good recap of what I did before. I may just come back to it if I ever want to have a quick refresh or even send it to a friend who is thinking of learning about programming.

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.

Source: http://www.softwaretestingmaterial.com/decision-table-test-design-technique/

This week I decided to write about Decision tables.  I found a great blog called Software testing materials.  They had a blog post called Decision Table Test Case Design Technique. Written by Rajkumar. In this blog he talks about decision table test case. This test technique is appropriate for functionalities which has logical relationship between inputs. In designable they deal with many different combinations of situations, inputs, and test and they would give you examples of what kind of output would be expected with the inputs. Here he gives a few examples of decision tables. In the examples he gives conditions to be able to transfer money. Conditions are account already approved, one time password matched, sufficient money in account. Then according to if each one is true or false it would do an action such as. Transfer money, show a message as “insufficient amount”, block the transaction in case of suspicions transaction. Then according to if one of the conditions are false it would do action 2 or 3 but if everything is true it would transfer the money. A much simpler decision table test that he gives is the case of entering a username and password. The conditions are Valid user ID and Valid Password. The actions that would be given is Home page or Show a message as “invalid user credentials” if any time the username or the password is False it would show the message for invalid user credentials. But if both are true then it would go to the home page.

I like this blog because it breaks down how decision tables work.  Raikumar gives very easy and understandable examples of how each of the decision table work. He explains it step by step that anyone who has no knowledge about decision tables would be able to understand what a decision table is. I would use this blog for future homework or even use this information to show future students are learning about decision tables to show them how they are used and made. I think that decision tables can be used in everyday life not in just computer science but in making choices for everyday life big and small.

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.

Source: http://www.bambielli.com/posts/2017-04-02-decorator/

This week I am writing about Decorator design pattern. I found a blog by Brian Ambielli called Design Patterns: Decorator. Here he talks about decorator and how it works. Decorator patterns allow us to extend object with added functionality at runtime. It allows developers the power to compose objects that are purpose driven for the current demands for their users. He talks how decorators can be thought of as super types where they are wrappers around the object they are decorating. They can be used and passed in a program in place of the original wrapped object. He gives us an example using pizza as the topic where you can make a pizza either a deep dish or thin crust pizza and gives us choices of what kind of topping you want the toppings are wrapped by a decorator that allows the user to choose either the pepperoni topping or cheese topping. With this blog, he even talks about the downside of the decorator. Some of the limitations that the decorator pattern has is that the code relies on the type of concrete implementation that you are wrapping. With decorators, they often have numerous small classes that are each responsible for one behavior modification. This makes code hard to read and understand.

What I like about this blog is that is has a very good example of how decorator design patterns work and they even give us the code to even test it with. With this we can even test and mess around with decorator designs. In the blog he talks about when you should even use decorator design patterns and this is very helpful for people who want to try and test out these design patters in their own code. I also like how he doesn’t just talk about the good of decorator design patterns he talks about the bad about it. So we know which kind of design patters would work for different situations. What I would do this this blog is that I think I would read up more about different deign patterns and try and test it out with some of the code I write seeing which ones I like the best.

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.