Hello and welcome back to benderson’s blog, after a three week hiatus, I’m back to talk about a topic in the applications world of computer science which is if a developer can force users to update their app without their decision. This topic is from a recent report from the blog TechCrunch where they discuss how android developers can now force users to update their apps. The news is that at an Android Dev Summit, Google announced the launch of the In-app updates API, this API update allows developers two new ways to push users to update their apps. The blog talks about how google developers were asking for this for a long time and are excited that it is coming. The news updates API is in early testing with a few partners, according to the blog and should be open to more developers in the future. After the build times in Android Studio have slowed down, the team did some tests and found that Gradle, which apparently is the core of the Android Studio build system, is getting a lot faster. The Google team is building new profiling and analysis tools to allow developers to get more insights in their build times.

I choose this blog to discuss this week because the idea of updating apps is such a cool concept to me. Being able to update your software as it is already out in many people phones, computers, etc. is something that doesn’t feel as easy to me as it sounds. Android now being able to force their users to update their apps can make some people upset though since some apps when they come out with a new update aren’t the cleanest version so people just wait till the bugs are fixed on the update but now android developers can just make their users go to the next update immediately. Anyways though, this gives the developers a lot more power and freedom with their apps which is pretty nice for a developer. Another reason I choose this article for my blog is because they talk a little about how their Android Studio Build System uses Gradle which is what we are using in my software class. It was cool to see that stuff that I’m using in my class today is used for a big part in a big company such as google. That is all for this week on benderson’s blog, Thank you for joining me and hope to see you soon.

Link: https://wordpress.com/read/blogs/136296444/posts/1743246

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

Hello and welcome back to Benderson’s Blog with me, Ben Anderson. This week we are discussing what is quality code for programming purposes. I grabbed a blog post from the blog Simple Programmer written by Peter Grainger where they discuss quality code and what makes up quality code.

The blog begins with what you should know to write quality software and they recommend a book to read that will give the directions more precisely, then he writes a section that is pretty interesting called “What you don’t code is more important than what you do code” and he sums it up with “The more code you write, the more potential bugs you could introduce”. I haven’t thought about it that way but that line definitely makes sense. Then he goes into setting goals and targeting a persona, you got to set what you want and what your users want from what you’re making and making quality code for that software is a mixture of the two and you go to be precise as you can. A key paragraph in the post is titled “Define the structure of the software in as much detail as possible” This is an important part of quality code as being the most detailed you can be, the more you will, and other people will, understand what is going on with the software.

The last couple sections discuss a couple things that I have talked about in past blogs such as the more tests you do, the better your code will be and the less bugs you will have, also the more reviews you have of your code the higher the quality and the fewer of errors you will find in the code and you just got to maintain your code and make sure its readable for future users and even yourself.

This blog was very informative on the subject of quality code and provided a great insight on what the writer thinks the common coder should know to write quality code. For me, an up and coming coder, its great to know how to write quality code for my future colleagues that I will be working with. The more they able to read and understand my code, the easier it will be for them and I to cooperate and work together on projects that are boss wants us to complete. In my class we are writing quality code to be tested to see if it will pass and we are doing that in groups which will already help me work in a team environment. I highly recommend checking this blog out, I provided the link at the bottom of this blog so you can go check it out. Thank you for joining me this week on Benderson’s blog and I will see you next week!

Link: https://simpleprogrammer.com/quality-code/

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

Hello and welcome back to Benderson’s blog where we talked about computer science related topics. This week I’m pulling a blog posted by STC Admin at Software Testing Class where it discusses the difference between Integration and Unit Testing. The author begins with an analogy where he talks about a Personal Computer with all it’s separate parts and how they all work together but in order for them to see if they will work together, you must do a compatibility test after the integration test. Then it goes into a system test and lastly an acceptance test. This leads into his next paragraph where he discusses how a software application is developed where it goes through the same type of tests that a Personal Computer would go through. The author even has a neat little diagram in the blog showing you a flow chart of how the testing goes. Then the author goes into each of the individual testing that he talked about before: Unit testing, Integration testing, System testing and Acceptance testing. Giving a brief explanation on what each of them do. The next paragraph talks about the advantages of system testing and lastly the differences between Unit Testing and Integration testing to wrap up the blog.

I chose this blog to discuss this week because it has a lot of information jam packed in there about two types of testing that I had little knowledge about. After reading the blog, I like to think I gained a decent amount of knowledge on the topic. Like for example, now I know the order of the system testing approach which begins with unit testing and ends with acceptance testing. I even learned the importance of each of the parts of testing like with unit testing I learned it is also known as white box testing that is carried out by the developer or with System testing it is known as black box testing which tests the overall functionality of the system. I also learned some reasons why it is advantageous to some system testing such mitigating after production go live issues and defects. Lastly, I learned the difference between the Integration and Unit testing such as one is white box and the other is black box, one surfaces from interface specifications and the other is from module specifications and lastly one is conducted by testers and the other is conducted by developers. This blog was very interesting and was a great read.

Link: https://wordpress.com/read/feeds/39452620/posts/2017866494

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

Hello and welcome back to Benderson’s blog! This week’s blog will focus on the documentation and formatting you would use for testing software. I found a blog that talked about the right format for documentation and formatting by Chris Kenst. At the beginning of his blog, he talks about how you know what is the appropriate documentation for a test and says it will depend on the degree on the test technique and approach you use. He talks about a couple different techniques in a short sentence but in the end says cramming all of them into one system isn’t really a good idea. The next paragraph talks about how much you need for documentation which he sums up with a small amount because you need to focus more on the project itself than the documentation that you put in there. The time it would take to make all the documentation for the test, you would run out of time for the test and documentation it self. The next and final paragraph focuses on stay agile, “Focusing on the appropriate documentation for your tests and then creating the smallest amount you need to do your job well also allows you to have agility”, this sentence from the blog sums up the whole paragraph really well.

This blog was very informational on the topic of test documentation and formatting and how much you should focus on it. I haven’t really been big on documentation in my four years in college as I always find it as an additional thing that I really don’t have to do but over the years, I’ve began to realize how important it is to have in your code. My reasoning usually is that I know what each of those methods do so it doesn’t need to be documented and formatted but I realized that in the actual work world I will have other people reading my blogs and they won’t know exactly what each method does unless I document it. So going back to this blog, getting all the information I need to know how much I should document and how I should format is very helpful for not only me but my future colleagues who will have to read my code. Knowing exactly what you’re testing is probably a pretty good thing to know. Also, knowing some tidbits such as focus more on the testing than the actual documentation and write a small amount so you have time, will help me make sure I get the tests done and have a good amount of documentation.

Link: https://www.kenst.com/2018/09/appropriate-test-documentation-formatting/

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

Hello and welcome back to Benderson’s blog where we discuss computer science topics that are happening in present time. This week we are going to discuss what is software testing and why it is important, I got this topic from a blog post posted by Harshit Satyaseel at Technotification. He talks about everything to do with software testing which is very helpful for people to understand and get what is software testing. He first starts by talking about what is software testing and he defines testings as “confirming that whether the actual results match the expect results”. Testing is a long process that makes sure that each and every software component/system passed the expected standard of performance set. Testing in software can be done manually or using automated tools. He then goes into why it is important to test your software and lists off reasons like finding defects/errors in the code, the quality of the software, and some more important reasons. Then he goes into software testability and lists off some characteristics of testability. Generally, what testibility is, is the guidelines and rules of testing and what you should look for to fix and make an improvement on.

The reason I choose this blog to write about besides the fact that the course I’m taking is focused around software/code testing is because it had some interesting tidbits and good guidelines to look for when testing mine or someone else’s code. The writer also talked about what software is which most blogs really don’t do when they are talking about something inside computer science, they always assume you know exactly they are talking about regarding the topic. For me, I know what software is but for the common person trying to gain knowledge on software being told what software is and why software testing is important makes the reader more knowledgable on the topic. He even gives the fact about Alan Turing in 1935 with the theory of software which was a nice touch. When he talks about the reasons for testing software, I like how he listed them out instead of creating a huge paragraph that is a jumbled mess about it. They are also very well listed and easy to understand regarding to software development. I will keep the guidelines and rules that the writer talks about in my mind whenever I test my code now, they are very good things to keep in mind. Thank you for joining me this week and reading my blog post.

Link: https://wordpress.com/read/blogs/74482552/posts/18309

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

Hello fellow readers and thank you for reading my blog. This week I want to talk about code reviews which are essential to the testing process in computer science. I read a blog post by greenido (Ido Green), where he talks about how code reviews will improve you. He begins his blog by talking about how code reviews promote social interaction as you would like your team members make comments on how to improve your code so it is the best it can be. Most companies like Facebook, Netflix and Google are also using code reviews as a way of promoting social interaction and improving as a company. Then Mr.Green goes into other reasons you would ask for a peer review and they are: Bugs(Accidental errors/Structural errors), helps you get better and lastly they will help make sure it is readable/testable. It also benefits developers in many ways such as increases productivity, reduces unit testing/debugging time, less time performing rework and many more reasons. He also dug up some data and research and provide several different examples of times where code reviews have helped. Lastly, he talks about what not to do which is skip a peer review due to time, never judge coder off the review and always suggest solutions.

This blog was very well written and helped me understand why peer review code reviews are important to the testing development. I’m pretty self conscious about most of my work, back when people had to peer review essays for class, I would always hate when someone read my paper because I felt like it was bad. Well with code I know I’m not the best and I understand after reading the blog that to get better I need to have someone help review my code. What makes sense to me, may make no sense to someone else that is reading my code and I need to make sure my team members know what is going on during a certain part of my code. That goes back to part of the blog where Mr.Green talks about readability in your code and how the peer reviews are important for discovering if everything will make sense. Also if you’re working on a project with someone else, you would want the opposite where you want to review their code and make sure you get the general grasp of it so you can understand what it does. In my recent projects that I have had in my computer science classes, I try my best to make sure my code is easily readable for the teacher. Code reviews are essential to the testing process without it coding would be worse.

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

Have you ever wondered if your tests are adding value to your work? Well I was reading a post by Andy Knight at Automation Panda who talks about the worries of testing and why people may think that it isn’t adding value. Andy begins by talking about how important testing is to software engineering stressing that people make a job out of it so it must be important. He clarifies that testing is important with one word: Bugs. Bug counting though is not the best way to make sure your test are adding value. Andy talks about three main facts that make bug counting not the best way to see if testing is adding value. They are fast feedback, good testing reduces bug count, bug counting drives bad behavior and bugs are usually rare. He goes into detail on all of these and how they effect the value of testing and he has some really good points for all of them. After he establishes why bug counting hurts testing, he goes onto talk about metrics that would be good for testing. He provides three different metrics being: Time to bug discovery, coverage and test failure proportions. He provides reasoning for all those metrics as well.

I don’t know too much about testing, mostly because the class I’m in is going to teach me about testing but this blog post provides a lot of insight on why testing is important and not a waste of time. Testing is a big part of programming as it makes sure that your code doesn’t have too many bugs so it runs as you want it and if it does have bugs, that you find them and able to fix them as soon as possible. I was able to learn that bug counting isn’t the best metric to figure out that your tests are adding value as they have many negative side effects such causing bad behavior or believing that its a waste of time because there are little bugs even though that means its just good code. It is just good to know that there is other metrics that make testing feel more valuable to the software engineering process. After reading about coverage being a metric, it makes a lot of sense why that would be more helpful of a metric than bug counting, covering a wide spread for testing would make it better to find the bugs and makes sure everything is in smoothly. Testing is an important part of software engineering and since it is so important, you want to use the best metrics for it and this blog post provides the best.

Link: https://wordpress.com/read/blogs/122508714/posts/9140

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