Testing Code

 

Source: https://blog.bugsnag.com/better-software-testing/

I found a blog post called “You don’t have enough tests and you never will!” by William Starling. This post he talks about how there is never enough tests for coding. The reason why people do test is because the earlier you find a bug the cheaper it is to fix it. The sooner a developer finds the bug right after writing the code they can quickly fix it. He then goes off by talking about different tests such as unit testing, integration testing, and system testing. Testing is hard and software is complex. No matter how many testing you do there will always be a bug. He says a lot of software teams gets too caught up on trying to measure how much testing is being done. Sometimes they would do an unhelpful testing that would say the program is 100% correct but they are testing for the wrong behavior and the test itself could be buggy as well. So what is the best testing strategy? Typically the best is where you are testing for major and the most obvious bugs at first. Then you would test things that would affect the security or integrity of the program.  An example he talks about is that what if you want to make a self-driving car so you don’t want to have it drive off the road thinking it’s still within the lines. More tests does not mean there are going to be less bugs. Focusing the tests in the right places can be the difference between a good code and a bad code. Examples of areas where testing can make a difference is complex logic, public accessible interfaces, and high impact code. You should also design your code to be able to modify later on to fix those bugs. Once the program is out for the public the best way for bug testing is the consumer themselves. When people are using the software they will find things that many programs will never think of so that way.

I chose this blog because testing code has come up a lot whenever I write code. In class, we do code that no matter how we wright it once it prints that final line we are done with it. However once we get out into the real world we are going to be writing code that will be used constantly and would be seen by billions of people and sometimes it won’t run the way that we expect it to and we would have to fix it so reading up on how to text and what test we should do is a good way to prep-ourselves for future projects

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.

Design Patterns: Creational

URL: https://www.codingblocks.net/podcast/episode-11-design-patterns-part-1-you-create-me/
Design patterns, specifically Creational Design Patterns. That is what my podcast for this week is about. Design Patterns can be split up into four sections: Creational, Structural, Behavioral and Concurrency. From each of these Design Patterns, there are different types. Structural Patterns include adaptors, bridges, flyweights, facades, and proxy’s. An observer, strategy, and Chain of Responsibility go along with Behavioral. Concurrency carry Blockchain, Scheduler, and frameworks. Last but not least, Creational holds Factories, prototypes, builders, and singletons. All of these part of Design Patterns are crucial to learn and understand if you want to become a better program, which was my main reason for watching this.
Now to get more in depth on the types of Creational Design Patterns, getting a rough understanding of Design Patterns first needs to be figured out. In this podcast, one of the speakers state’s first, “When I see the word factory in a code base after snickering to myself, I know what that class does, what to expect when I open that file, same thing when I see a builder, adaptor, visitor. They have meaning which allows me to shortcut reading those files, and comprehend what’s going on at a higher level”. They are used to help programmers solve a common problem by creating and designing these applications or systems. Creational Design Patterns help make a system independent on how objects are created, composed and represented.
There are many more types of Creational Design patterns, but for this podcast, Factory, Builders, Prototype and & Singleton’s were all roughly talked about. Factory was the first of the four, which was in my opinion, the hardest to understand. With Factory, it can be split up into different parts: Factories, Factory methods, and Factory patterns. From there Simple Factories were talked about, and Abstract Factory patterns. Then at the end they mentioned the pros and the cons. The pro’s being that is adheres to the open-close principle and that they can be used with inputs, mostly switch statements. The cons were that it uses but mostly can use reflection quite a bit and that it can be extremely complex.
Builders were next, which are more about having the caller put together the objects. While factories really know how to put together the object, the builder on the other hand does not really know what the user wants the object to look like. The pros of builder was that it is a great way to build complex objects and has an elegant feel to it. The cons to it were that it can be a bit more verbose and that it is like adding an ingredient one at a time and can take some time. Prototypes were talked about very shortly which is where one creates a new object by cloning the existing object at runtime. Lastly, Singletons were talked about, which is a single instance of a class, the class that restricts the instantiation of a class to only one object. The downside for this was that decisions have to be made right then and there.
I was really excited to hear this podcast for a number of reasons. One being that, now that I have learned most of the basics of coding, it is really interesting to now learn about the difference designs and learn new ways that will help me become a better coder and programmer. It is as always so easy to understand these guys and I cannot wait to listen to their other podcasts about the other topics.

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

CS@Worcester – Fun in Function 2017-09-25 23:51:24

The blog post this is written about can be found here.

This blog post explains some of the ways that conversations about software testing can go wrong, and in the process reveals some commonly held misconceptions about what software testing is and how it gets done. This was a good post to start off with because it discusses testing in general terms, not using much terminology I’m unaware of yet, and it lays a good foundation for understanding the software testing field as a whole. I chose it because I wanted to know about mistakes people make with regard to software testing right away, so that I can avoid them, and because it provides some good guidelines for how to approach and think about testing.

One of the misconceptions author talks about is believing that software testing is or can be made more automated than software development. To test something properly, you can’t use “automated testing.” There aren’t blanket solutions to the problems that might arise in your code. You need people who can form a testing strategy, use their judgment and intuition to fill in the blanks that templates for testing can’t, and adapt to surprising results or changing needs. Knowing this, I’ll be careful not to form assumptions that the thought that goes into testing a piece of code can be eliminated with an automated process.

Another mistake people make is focusing on the number of test cases you have instead of what your testing does, whether it’s useful, and how comprehensive it is. As the author states, this is as silly as caring about the number of files created or keystrokes made during the coding stage. With this in mind, I’ll remember to ask further questions about the test cases if I’m told the number of tests like it means something. Additionally, I won’t present the number of test cases I’ve created to someone else as a way of showing how thorough the testing is.

The final mistake I found interesting was conceiving of tests as objects instead of events. As the author writes, testing is something you do, not a physical thing. Although there can be physical things produced in the process of testing – such as data, code, and documentation – tests themselves are not objects, and thinking of them this way skips over the job of the tester. I’ll make sure to remember that software testing is a process, and that what matters is whether I’m performing the process well.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Test Cases

https://blog.testlodge.com/types-of-test-cases-in-software-testing/

In this blog written by Jake Bartlett, he explains the different types of test cases and the importance of knowing the different types to discover which type to use for the right purpose. These types include functionality test cases, user interface test cases, performance test cases, integration test cases, usability test cases, database test cases, security test cases, and user acceptance test cases. 

Functionality test cases are used to discover if an application’s interface works with the rest of the systems and its users. It recognizes if the functions of the software succeeds or fails of what it is expected to do. User Interface test cases are used to confirm that specific pieces of the Graphical User Interface look and work. These test cases can also search for inconsistencies, spelling and grammar errors, and other elements the user interacts with. Performance test cases validate response time and overall effectiveness of an application. Integration test cases are meant to determine how different modules interact with each other. This test case guarantees that interfaces between different modules are working properly and effectively. Usability test cases help identify how a user approaches and uses an application. This test case guides the tester through situations and flows. Database test cases are used to verify if the developer has written code that stores and handles data in consistent safe manner. Security test cases help ensure the application restricts actions and permissions when it is necessary. These test cases main purpose is to protect data when and where it needs to protected. User Acceptance test cases help test the user acceptance testing environment. These test cases main purpose is to verify the application is acceptable to the user.

I chose this blog on test cases because it sparked my interest that there were different types of test cases. With my minimal prior knowledge about test cases, I though there would be at most four or five test cases, when there are in reality, eight test cases. That surprised me at first, but when I started to learn about the different situations of testing software, it made sense that it was necessary to have all these types of test cases to account for every situation.

Bartlett’s blog was very informative to me. He broke down each test and explain what each test’s purpose and goal was. As a software developer striving to become a video game programmer and developer, it is important for me to know these test cases because I’ll need to create effective applications that are well tested to run and execute a successful video game. If I don’t properly test my video game software or if I am unaware of which way to effectively test my software, my video game software is as good as a dead software with no purpose.

 

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

9/25/17 Software Design

https://www.joelonsoftware.com/2016/12/09/developers-are-writing-the-script-for-the-future/

This week I picked Joel on Software. The blog lead me to a 20 minute video on how software is changing the future. The video is of Joel talking on software and technology changing the world. He mentions technology and tools we use everyday and the program behind them. For example Uber is a program someone created to call for rides whenever needed. This is a step up from being in the city and trying to hail for a taxi. There is even code written up for something as simple as an alarm clock, allowing the user to decide when the alarm should go off everyday. More complex algorithm ad program are used online for different sites like social media. Facebook and twitter have special algorithm that manipulate certain viewing of post for people to see. The algorithm will put up certain posts to make the user feel happy or angry depending on what the post was about. An example Joel used was someone asking his friend to go to a party with him. The friend could not saying he was sick or to busy to attend. The first person later went on Facebook only to learn his friend went to the party with his ex girlfriend. The post made the person angry. Twitter uses a similar algorithm as well. Twitter pulls up tweets onto the users’ feeds based on if the tweet will make the user happy or not. One user created a fake news post on twitter on busses arriving that held protesters during the election. The tweet went around the site thanks to the algorithm. The tweet even reached the president elect to which he tweeted it but saying that the bus were carrying his supporters for the election. Algorithms used for news site and social media post pages based on the user’s interest. It does not post pages from everyone’s point of view on a topic just the certain point of view that the user prefers and wants to learn more about. Joel also talks about the site Stack overflow, which he created to help programmers with their programming. There users post question about a piece of code that they are working on and other users can comment and correct the code or give advice where needed.

I liked this blog a lot along with the video. I liked how he talks about various sites that people use everyday and the coding and program behind them. This explains how different sites work and a warning to not fully believe in the story or news that are posted. This gives an insight of how software and programming is changing the future of our world and what to expect from it.

From the blog CS@Worcester – My Blog by rens14 and used with permission of the author. All other rights reserved by the author.

The Common Code (Smells)

The blog post this is written about can be found here.

This short post from Coding Horror is an overview of common code smells, which the author wrote in response to being asked why he didn’t recommend a certain book on refactoring. He doesn’t think people ought to be relying on one set specific way of refactoring code in response to a particular smell, but that the important thing is to watch out for warning signs in the code you write.

I chose this post and this topic because I wanted to know right away what I shouldn’t be doing. I didn’t want to develop bad habits and then have to unlearn them later. Code smells were included as one of the topics in the syllabus, so I know we’ll be covering them at some point.

This post proved useful right away because of its commentary on comments. I know that my natural instinct would be to comment my code liberally for the sake of clarity, but knowing that too many comments can obscure has made me reconsider this approach. With this in mind, I’ll be more likely to ask myself whether I can make the code itself simpler to understand and limit my comments to useful ones – ones that explain why my code is written a certain way, not what’s going on.

Speculative Generality was also helpful to read about, because I know I’d want to try to anticipate what might be needed in the future instead of just solving the problem at hand. I hadn’t considered the drawbacks of this approach. It does make sense to limit yourself to addressing the problems that actually arise in the future, since over-planning might result in unnecessary code. I remember this being mentioned in class.

We also just today talked about how the strategy pattern can be used to avoid a mountain of conditional statements. The Conditional Complexity code smell mentions this, and it also recommends the patterns decorator and state. The decorator pattern sounds similar to the example of the strategy pattern we used in class today, only with behaviors being added to specific instances of a class instead of to subclasses. It’ll be good to know these approaches exist in the future, since in the past I’ve written some truly unwieldy nests of if statements in order to accomplish a task.

At the moment, the code smells that have to do with multiple classes are more theoretical for me than the intra-class code smells, but they’re good things to keep in mind for later (and I enjoyed some of the names).

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Software Design Patterns

https://airbrake.io/blog/design-patterns/software-design-patterns-guide

Design patterns provide guidelines for software developers to help deal with problems that could occur during their process in developing the software itself. In this blog written by Andrew Powell-Morse, he gives a brief overview about why design patterns are necessary in the world of software development and its origin.The origin of software design patterns can be extracted from the teachings of the book Design Patterns: Elements of Reusable Object-Oriented Software, which was published in 1995. The book explains object-oriented design techniques and different software design patterns, which are split into 3 categories: Creational, Structural, and Behavioral. 

Creational design patterns have several aspects that identifies that it is a creational design pattern such as abstract factory, builder, factory, prototype, and singleton. This type of design pattern emphasizes the automatic creation within code.

Structural design patterns have aspects such as adapter, bridge, composite, decorator, facade, flyweight, and proxy. This type of design pattern focuses on compositions of classes and objects.

Behavioral design patterns have aspects such as Chain of Responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template, and visitor. This type of design patterns focuses on the communication and assignment between objects.

I chose this blog because I wanted to know more of the basic overview in software design patterns. In today’s class lecture, the professor gave an example about how design patterns are useful with an example of a super class of ducks with sub-classes of different types of ducks and their behaviors. I was very interested in the example of ducks within the lecture, and after the lecture ended, I wanted to know a little bit more. I wondered if there were different design patterns and this blog led me to an answer that there were 3 categories of design.

Morse’s blog on design patterns was very informative and brief which was to my liking. It wasn’t too in depth because I only wanted to know a little more on the brief concepts of design patterns. This blog made me realize that there are many more design patterns out there in the world of software development. I’ve learned that the reason why there are so many design patterns out there is because those design patterns are meant to solve different problems that occur in many instances within the code during the process of developing the software. Considering that I do aspire to become a video game programmer and developer, I need to firmly grasp design patterns so when I go and create software for games, it’ll be easier for me to do so.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Post #1

This week, I am going review and summarize Episode 262 of Software Engineering Radio.  This episode’s guest is Bill Curtis, Chief Scientist of CAST Software and Director for the Consortium for IT Software Quality.  Bill is on the show to discuss what software quality is and how architecture, Lean management, and following in big tech companies’ footsteps can help organizations achieve higher quality software.

Bill begins the podcast by defining high quality software as software that not only meets the functional requirements specified but also meets the needs of the user.  He insists that, in order to develop high quality software, the architecture of the system must be built properly in order to continually support the system as it grows.  To support this claim, Bill gives an example of a system that failed, at launch, due to a poorly built architecture – Obamacare.  According to Bill, the system architects for Obamacare built it in such a way that its users received, via download, more documentation than they probably needed, causing a rapid consumption of the Obamacare website’s bandwidth.  He believes that the Obama Administration was partly to blame for the failure because they requested that changes and additions be implemented late in development which only allowed for 2 weeks of testing to be conducted prior to launch.  I was intrigued by this story and chose this podcast to be the subject of this week’s blog post because it goes to show how crucial rigorous testing is to the production of high quality software.

Bill goes on to list his tips for improving software quality:
– Look at the architecture up front; it is incredibly difficult to refactor it in large systems.
– The most effective software engineering methodology to implement is one that combines Waterfall and Agile; building and testing for rapid feedback leads to structural quality.
– Strengthen management; Implementing a system similar to CMM or CMMi which transforms the organization into one that can effectively build big systems, dividing labor reasonably, giving developers and testers appropriate deadlines, getting control of commitments and baselines, weeding out practices that aren’t effective — stabalize, standardize, optimize, innovate.
– Follow rigorous processes for testing and measuring; allows organization to know what they can and can’t do, why they make mistakes, raises quality and improvement levels

I thoroughly enjoyed the discussion in this episode and felt that it was really pertinent to the work I have been doing lately.  I got a professional understanding of what it means for software to be of high quality,  learned the importance of rigorous testing and measurement throughout the development process, heard some examples of how failing to follow process can lead to failure, and received tips on how to improve quality of software architecture, organization, and management.

This blog post(1/9) is part of an assignment for the Fall 2017 session of CS443 @ Worcester State University.

From the blog CS@Worcester – RM by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Mobile App Development

Jonathan Stark on Mobile App Development podcast

This podcast talks about the process of developing a mobile application and the different aspects to consider before creating one. Jonathan Stark talked about the general things needed to develop an app. Jonathan was saying that deploying a mobile app requires so much more than what people think. When you deploy an app in the app store, whether is google play or itunes. Your app would be reviewed by the store on whether your app is reliable, perform as it should, and free of offensive materials. Apps are reviewed based on technical, content and design of the app. He also said that sometimes it can hinder investors since even though you have a very nice app, but it didn’t pass the review, it is worth nothing. Jonathan also talked about using Progressive Web Applications (PWA) versus the Native Apps. He talked about the advantage of using PWA and coming from a web developer background, how it is better than the native apps that most are developing. Jonathan said that PWA is faster, more secure, reliable and most importantly it is like a one size fits all. Developers would not need to develop multiple apps across multiple platforms anymore. While in the Native apps, you have different apps for different OS, whether it is iOS or Android. He also talked about React Native. React Native is a real mobile app it is not a “mobile web app”. In React Native you can create apps the traditional way, just like using Objective-C and Java. Jonathan also talked in this podcast about the importance of design while building an app. Since phones don’t come in one size, you have to consider how your app would work in different phones. Sometimes you might have to move the interfaces from your app across different phones. There are many more things to list here about mobile app development that they talked about in this podcast.

I chose the topic of Mobile App Development since everybody, I feel like uses a smart phone nowadays and that we are basically using applications every time we open our phones.

From this podcast, I learned different things to be considered while making an application. That even the smallest thing like, what if you are trying to click on the menu but your finger covers the options while doing it. Things like these that I never considered before was just as important as coding the actual app.

From the blog cs-wsu – Site Title by csrenz and used with permission of the author. All other rights reserved by the author.

Intro To Incremental Testing

For this week’s blog I wanted to keep to the theme of learning a new type of software testing. I discovered softwaretestinghelp.com from our classes Slack channel as I know a few people recommended it. For my article I chose “What is Incremental Testing: Detailed Explanation With Examples” because I have not learned this type of testing and it was one of the more current articles posted.

While I can infer things about incremental testing based on its name, this article covered it in detail. To start, incremental testing is one approach of integration testing and combines modular testing with it as well. Basically each module will be tested on its own and then integrated one by one to make sure that each module that is added interacts how it should. This is where the term incremental comes from.  Once each module has been integrated, the application or system is considered built. All modules should then be tested together to ensure smooth interaction and data flow.  A couple advantages for this type of testing are that defects can be found earlier and defects can be easier to target based on what module was added last. This can also reduce the cost and time of rework if modules were not added and tested incrementally.

There a few different methodologies in which incremental testing can be done. Three that are discussed are top down, bottom up, and sandwich testing. While there are different methodologies, they effectively use the same principles. They all utilize layered testing, a hierarchical design, and integrate modules one by one.

After reading about incremental testing it seems like a really good strategy to implement. I like the idea of testing a system piece by piece to avoid a possible large amount of rework. It also adds confidence as you work through a project that everything is working together correctly. I think this allows developers to give a more accurate and reliable time estimate for a project’s completion as well. My reason for this is that if defects are found earlier per each increment you can adjust and communicate time tables more effectively. The only downside I can see with incremental testing is repetitiveness. With each module that gets added, there will still need to be testing done for the modules that were already added and tested to make sure the current system still works correctly. This testing is still useful however I can see how it may increase the amount of work to be done up front.  In conclusion I’d like to try incremental testing on an upcoming project to weigh the advantages and disadvantages first hand.

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