Category Archives: Week 5

Your First Language

This week I am reviewing another pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. For this week’s pattern I decided to go with the chapter “Your First Language”.  The context of this chapter is you have a shallow understanding of one or two different programming languages. This chapter grabbed my attention because while I have been in school for four years learning software development, I still feel that I only have a shallow understanding of a few different languages (in this case Java, C, and python, but Java is definitely my strong-suit). I feel that from the perspective of the classroom we know a decent amount about our languages, but from a real-world point of view, we only know the proverbial “tip of the iceberg” meaning that we still have much  more to learn about our languages. The problem presented by the book is that we feel that we need to be masters at our first programming language in order to be a good programmer and a purposeful part of your team at work. While the book says that you should not stress over the fact that you only know one programming language, they also point out that most jobs require that you know at least one programming language inside and out to get the job. This is a “catch 22” because jobs expect you to be masters in a language and be extremely proficient but at the same time they understand that you likely have little to no experience with your language because all you have had experience with is programming assignments in school. This kind of puts us at the disadvantage because we are expected to be masters at our trade to get an entry level position at a company we  may not be at forever. The solution proposed by the book is to improve your learning of your first language. How does the book propose this? By having actual problems to solve with your programming language skills and knowledge. I think this is important because using your skills to learn how to solve actual problems helps you retain your programming language skills and makes you a better programmer.

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

Are we now Full-Stack Web Developers?

As you may know, for our end of semester senior project we worked in groups of two in charge of developing a web application that had some sort of functionality. When we were first introduced to this we didn’t know whether to feel scared, nervous, excited or all of the above. What is HTML, CSS, angular, boostrap, etc.? So many things were thrown at us but in the end we made it. We learned all of it and no the question is.. are we full-stack devs? Maybe Eric An can answer that question in his article, ‘What is a full-stack web developer?’

The article begins with a big red T shaped image. The T-shaped model is a concept that describes the abilities/characteristics of an individual where a person has many generalized skills with a specialization in few. The full-stack web developer supposedly knows many technologies but specializes in few which is front-end development and back-end development.

Front-End web development is the presentation of the website which includes HTML and CSS and sometimes JavaScript; pretty much everything that the user sees when clicking a link. The goal is for users to provide a platform for users to interact with. Some other skills may be UE/UI design. For our project we learned the basics of HTML and CSS and I also learned how to use bootstrap to make things much simpler. Front-end development was a success!

Onto the back-end web development.. The creation of data collection processes haunts us to this day. We redefined the definition of struggle when it came to the back-end part of this project. Back-end development is associated with the front-end where as a server is being created to communicate with that the user is trying to do on the front end.

The definition of a Full-stack web developer is an individual who is in charge of performing both front-end and back-end so that all of the technologies put together makes up a website. After reading this article, although we are not experts in front-end/back-end development we could be considered full-stack developers!

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Importance of Code Review

Towards the end of the semester we were working more intensively in group settings and even increased the number of individuals in our group which required greater collaboration among peers. I recently came across a post ‘Code Review: The Unit of Work should be a Single Commit’ by Paul Hammant. In this blog Hammant talks about the benefits of Code Review and how the end result is significant change in the way the program was written.

Some of the benefits he listed was:

– Two pairs of eyes catch more bugs (which saves hours of debugging if fixed early)
– Enforce coding standards, style guides (keeps overall readability & code quality high)
– Mentoring of new developers (learning from mistakes without breaking stuff)
– Establish trust relationships
– A good alternative to pair programming.

Our last few classes we as a group came across all of these aspects and more. We worked collectively as a team code reviewing some program and found that we listed many similar mistakes. Another important point he makes is that there is only so many times something is modified in review before it is considered ‘done’.

Although Hammant talks about reviewing code over Git and we did ours as a group in person the idea remains the same. Some steps he talked about were to lock a commit for the duration of each review and also how to move forward with which review change when two individuals have different points of view. I found that this article was relatable to our experience.

As always, subscribe if you are interested in Computer Science ideas/technologies/topics!

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

Clean Code Blog 1

This week I decided to read a blog post for my blog entry. The blog post I read is titles “These tools will help you write clean code” by Adeel Imran. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

Besides all of the great resources that it gives, a major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have this labeled well. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

 

https://medium.freecodecamp.org/these-tools-will-help-you-write-clean-code-da4b5401f68e

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

Code Reviews -Blog 1

Hello readers, welcome back. This week I will be talking about code reviews and why they are essential to the testing process in computer science. I read  a blog titled “what is code review and why is it so important” by Eugene L. who is a project manager. He begins his blog by talking about how code reviews is a great form of communication between team members and for junior developers, they can become more proficient through this communication and at the same time help improve the code. Although code reviews are used to spot bugs, they have resulted in teams understanding each other better which companies enjoy. Another point brought up in Eugene’s post is that code reviews increase productivity. Because the code will be reviewed by someone else  the developer will be motivated to write better code and make sure its flawless. Finally another reason code reviews are essential is that it helps the developer understand the product better and as a result will be able to communicate better .

This blog had great points and helped me understand why code reviews are  so important to when testing. When it comes to myself, sharing code hasn’t always been a strong suit with me because I tend to get nervous when other people view. I understand that I’m not the best and I understand after reading the blog that one of the ways to improve is by having my peers review my code. Feedback is necessary to have successful code reviews. If you’re working on a project with someone else or a team, you would want to make sure that everyone understands your code and how it effects the product, as a result it will improve the team chemistry. In my recent projects that I have had in my, I try to make sure that my code is understandable. Code reviews are a crucial part in testing and with them, the product will be much better than it would be without it.

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

Security Testing

What is Security testing? Security Testing is a variant of Software Testing which ensures, that system and applications in an organization, are free from any loopholes that may cause a big loss. Security testing of any system is about finding all possible loopholes and weaknesses of the system which might result into a loss of … Continue reading Security Testing

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Unit Test vs. Integration Test

An important thing to consider for software testing is the difference between unit testing and integration testing. The purpose of a unit test in software engineering is to verify the behavior of a relatively small piece of software, independently from other parts. Unit tests are narrow in scope, and allow us to cover all cases, … Continue reading Unit Test vs. Integration Test

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

Mediator Pattern

Between many design patterns Mediator is one of most used in today’s software world. In this pattern, the object encapsulates the processes between other objects, without asking other objects to interfere. We are going to analyze a real-world example that uses the mediator design pattern. This pattern serves as a go-between operator, so other components … Continue reading Mediator Pattern

From the blog cs-wsu – Kristi Pina's Blog by kpina23 and used with permission of the author. All other rights reserved by the author.

No Ragrets(sion) Testing

CS SERIES (5)“Forget about automating your regression tests” is some bold advice from Bas Dijkstra, who has experience as a test automation consultant. It made me wonder what exactly led him to making this kind of statement on regression test scripts and his article, On Ending the Regression Automation Fixation, covered various reasons why.

Two reasons why Dijkstra says starting with automating your regression tests is not ideal includes regression scripts being too long and how regression tests are written from an end user perspective. I find this interesting as a lot of software bloggers are saying automation is not always going to be the answer and their answers have yet to make me disagree.

Sam CS (10)

The reason I chose this is because I am drawn to honesty; two examples above were explained with scenarios with failures Dijkstra has faced from creating inefficient or “plain worthless” cases.

This content will change the way I think about creating potential testing cases as there will be questions to ask myself before proceeding with the task(s) at hand. There will be a lot of reflecting on what could be consuming my test time, which parts are too repetitive, or what can just be done better. I mean of course I’ve already been considering these questions but now there will be a more conscious effort to think about them.

Dijkstra’s process especially considers the difference between how many scripts there could be when a computer is trying to translate what a human could have performed when testing. I realize how that would be an issue when trying to understand what could have went wrong or does not match up fully when there is less (specific) feedback when it comes to automation.

Thanks to this article, I will also try to predict how many layers of regression scripts would be too much of a hassle to develop ways for communication between what is being tested under the application. Overall, this information was useful as we should be reminded that “automation is meant to make your life and testing applications easier”; it should make sense and not be done at random, especially for regression testing.


Article: https://www.ontestautomation.com/on-ending-the-regression-automation-fixation/

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

The Differences between Black Box and White Box Testing

Greetings reader!

In today’s blog,  I will be discussing the differences between black box and white box testing. This blog will briefly explain the benefits for each test, as well as point out their distinct features. I will also be sharing my analysis of QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article from which I read. Without any further introduction, let’s begin.

Black box testing (BBT) is a testing method in which there is no access to the source code or the internal structure of software. The main goal of BBT is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors.

Some advantages of black box testing are as follows. First, the tester can start designing test cases just after the specification is ready. Secondly, tests preparation time is short, and finally, there is no need for a tester to know the programming language of the application. The disadvantages of black-box testing: it is hard to design test cases without a specification, only some paths are covered , and it is impossible to to see what part of the code can cause a problem in future.

White-box testing (WBT) is a testing method where there is access to the source code and internal structure of the software (opposed to BBT). This testing type insinutates that a tester knows which code line is called for each function. It allows the tester to better choose an entry data set and to check errors and exceptions efficiently. White-box Testing focuses on bad code writing, conditional loops, the working flow of the code, and memory leaks.

Advantages of white-box testing are: there is no need to wait for the GUI application, it can conduct more detailed testing with more cases covered, and it can predict the potential problems in the software. The disadvantages of white-box testing is that a tester must know the programming language of the software, it can take much more time than other methods, and it can be expensive.

To conclude, there are advantages and disadvantages to both methods of testing, so there is none that is “better” than the other. They are both necessary and complementary.  The QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article that I read was extremely informative and very easy to comprehend. I greatly recommend their articles to expand your computer science knowledge.

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