Author Archives: Akshay Ganesh

Test-Driven Development

Hello! Welcome back to my next blog post. This post is about Test Driven Development, also known as TDD. I used this article to do some research on it: Test driven development: What it is and the benefits of using it

I chose this article because it goes into further detail about what we already learnt about in class. I chose this topic because we just went over it in class recently, and we also had a homework assignment on it. At first, I was very confused on what to do in the assignment, and I had no idea what I was supposed to put in the testlog file. But by the end of the homework assignment, I kind of understood everything more, and realized that the testlog file was just meant to help me organize my test backlog, and make all of my commits with notes left behind. It took me a lot of time to come to these realizations, but once I did it helped me a lot.

This article talks about something we briefly went over in class, called the “red-green-refactor development cycle.” What this means is that first you want to write a test, which you already know is going to fail – This is the red part. Then, you want to write very simple code; Just enough to make sure the test you wrote passes – This is the green part. Finally, you want to refactor your code, and make sure not only the first test passes, but also all of the previous ones as well. Refactoring is probably the most difficult part of the process, since the other two are sort of bare minimum procedures.

I was instructed to do this in the homework assignment, but with Test Driven Development, you are supposed to only do one test at a time. I think this is smart because sometimes you can get ahead of yourself or get lost while you are trying to make multiple tests pass at the same time. Sometimes with coding I feel like you can make more mistakes trying to be fast, which ultimately slows you down. While if you take it step by step, it actually could end up being quicker than if you are rushing and not being careful.

Overall, TDD is a very interesting topic, and it was helpful that we not only went over it during class time, but also had a way to practice this with the Kata homework.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Path Testing

Hello! Welcome back to my next blog post. This post is about path testing. I used this article to do some research on it: Basis Path Testing in Software Testing | GeeksforGeeks

In class, we learnt about this in depth in one of our POGIL activities. This type of testing has to do with actual code, and creating charts to further analyze and organize each step of the testing. Program graphs are graphs created with circles and arrows pointing to other circles to showcase the flow of the code. For example, loops will have arrows that point back to previous circles, until the entire loop is completed. Branches can be shown by splitting one circle into two other circles with two arrows; one pointing to each one.

In the article, they called it a “Control Flow Graph.” The article called a node with two or more arrows exiting it a decision node. They also called nodes where there are two or more input arrows junction nodes. This article went even more in depth than we did in class, because it talked about regions as well, which are basically just certain areas of the graph.

This article was very interesting, and it was made easy to understand because there were several pictures indicating each type of code and how it would look like in one of the graphs. They showed examples for do while loops, if statements, and many more aspects of code. This is the reason why I picked this article; since it expanded on what we already learnt about in our class.

Some more information that we learnt about in class beyond just the graphs was about DD-Paths, where the previous graphs I just mentioned are condensed into smaller, easier to understand graphs that are organized based on each type of node. Similar nodes are condensed into one node, but the first and last node are separated.

Overall, I think this was an interesting topic to both learn about in class, and also learn more about with the article I looked into. This is definitely an important part of testing, since it helps organize everything. Sometimes, reading code is not very easy or organized and this method helps with both of those problems.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Black Box VS White Box Testing

Hello! Today’s blog is about different types of testing methods. This is a topic that we learnt about very early on in my Software Quality Assurance and Testing class semester. I found an interesting article that expanded on what we already learnt in class, and even introduced a new type of testing; gray box testing. The article is linked here: Black box vs white box vs grey box testing

The definition of black box testing that we were given during class was testing based on the specifications of a component/system only. The definition of white box testing that we were given during class was testing based only on the internal structure of a component/system.

Now, this may make sense to some people, but many people who don’t deal with code may have trouble understanding exactly what this means. The article I read helped me understand it a lot more, and that is the main goal of this blog post as well.

Black box testing is exactly how it sounds. Imagine a box, and everything inside it is blacked out. You cannot see what is going on inside of the system, you can only see it from a user’s perspective.

With white box testing, you can actually see all of the internal systems and functions going on. The user can actually go into detail and analyze what is occurring.

Now that I summarized both of the main types of box testing, I want to introduce the idea of gray box testing as well. This testing is kind of a combination of both black box and white box testing. With gray box testing, you can access the code from a user’s perspective, but you also have access to some of what’s inside the code as well.

Out of all three types of testing, black box testing is the most user-friendly. Black box testing is pretty much designed for users who do not have much knowledge of the actual internal functions of the code, but they still need to be able to access the code. This would be like how websites have lots and lots of code that go behind them (even including the website you are reading this blog post on), but it is simplified for the user by having labels and buttons. I do not need to know how to read HTML to be able to use this website. Although this isn’t testing, that is one example so that you can kind of visualize what this type of testing is made of.

White box testing, on the other hand, requires the user to have extreme knowledge of the coding at hand. Since you can only access the inside with white box testing, the only way to be able to make use of it is if you know how to manipulate the code based on your own knowledge.

Overall, this was a very intriguing topic to me, which is why I decided to write about it on this blog. Both the classwork and the articles I read were very helpful and informative.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Introduction

Hello! Welcome to my blog. My name is Akshay and this is my first blog post for my CS-443 class.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Scrum

Hello, and today’s blog post is about Scrum. For those of you who do not know, Scrum is basically a way to work as a team efficiently and effectively. I am glad that Professor Wurst chose to expose us to Scrum in his curriculum this semester because this method of teamwork is very interesting, and it actually seems like it could be useful to me in the future. The thing I really like about Scrum is that it is INCREDIBLY organized. Each day is planned out to an hour, and I think that having a schedule that is organized and efficient is very important when you actually want to get work done. Planning out your schedule/agenda ahead of time ensures that everyone on the team stays on track with minimal distractions. This method also is all about improvement. There are reflections/retrospectives at the end of every sprint (which is pretty much another way to say “project”). We went over this in detail during our class time, which engraved a lot of the Scrum knowledge in our heads. We also took official quizzes which helped us become “certified.” I think taking these Scrum tests were beneficial because we had to reach a certain score, and if we didn’t get it, we would have to re-do the tests until we had a much better understanding of the concepts.

Scrum uses the Agile framework, which I talked more about in one of my previous blogs. Scrum is based off of three pillars: transparency, inspection, and adaptation. The official Scrum website described the process of working using Scrum as “working through small experiments, learning from that work and adapting both what you are doing and how you are doing it as needed.” Scrum also has important values: courage, focus, commitment, respect, and openness. These values are each crucial to making this process work.

The article I chose to help me explain Scrum for this blog is linked here: An Introduction to Scrum | Lucidspark

This article describes Scrum as “an iterative, adaptable approach to software development.” It talks about how most software development methodologies are very linear, meaning there is not much room for improvement. Scrum on the other hand, as I mentioned before, follows the Agile approach rather than the Waterfall methodology, which makes for great adaptability. The article also re-iterates how Scrum is all about teamwork and collaboration. It goes into detail about each role in the Scrum team, and what all the events are in the sprints. I think this article is worth a read, and it is supposed to be just an 8-minute read as well.

Overall, Scrum is definitely one of the best software development methodologies that are in sync with Agile ideologies, so I am glad that we learnt about it!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Software Licenses

Hello WSU blog! In this post I am going to talk about what I learnt in class in regards to software licenses. We watched an informative video on it in class, and then we worked in groups to practice with the information from the video. I actually learnt a lot of simple things about copyright that I never noticed until this class. One thing I learnt was that there is actually an automatic copyright for things that you don’t license. This means that if you want someone to be able to legally use your code, you HAVE to license it, and pick the permissions that they have to use your code. When you license your code, you do not in fact give up your copyright. The copyright will always belong to you, however licensing it lets other people use your code in certain ways.

In this activity we also compared two different licenses. We compared the MIT License, and the GNU General Public License. The MIT License is simple and permissive, meaning that it allows the users of the code to do more things with it. On the other hand, the GNU General Public License has a few more conditions, such as disclose source, same license, and state changes. An extra permission for the GNU license is Patent use. We also briefly looked into non-software licenses as well.

The blog post I researched for this week’s blog is linked here: What is a Software Copyright?

I chose this blog to research because it was pretty simple and easy to understand, while also being very informative. This article mentioned HOW exactly your software is protected due to copyright licenses. It talked about points we covered in class, such as the automatic copyright, which is put into play as soon as the software “is created and saved in some way.” The way the software is written is protected by copyright law, and the owners of the software can give other people access/permission to use their code with the use of licenses. The article also concluded by emphasizing the importance of software licensing and how essential it is for people who want to create or use shared software.

Overall, I think that learning about this stuff while we are still in college is important, and I am glad my professor took the time to include this in the content of this course. Copyright and Licensing is important, and it prepares us a little bit more for the future and real-world applications.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Clean Code!

Hello, this is my second topic-based blog and today I will be talking about something I learnt about in depth over several days in my Software Process Management class. This was a very interesting topic and I learned a lot of things about code that I had previously not known about. Some of the things that I was taught in my earlier days of coding were proven to not be the best way to go about making organized, clear code. One example of this is that I was originally taught to make comments after most lines of code, just to make sure everyone reading the code will understand it. However, it turns out this was just a beginner step to help myself learn. In reality, clean code should be easy to read and understand, making many comments obsolete.

Now I will talk about some examples of obsolete comments. One of these are redundant comments. These are comments that are unnecessary. An example of this would be: z = x + y (sets z to the sum of x and y). As you can see, the code speaks for itself, and this comment is completely obsolete. Another comment type that is unnecessary would be misleading comments. These comments are usually created when someone forgets about a comment after updating the code. This leads to the wrong comment being on a block of code that doesn’t even do what that comment states!

The blog I researched for this post is linked here: Writing Clean Code: Tips and Best Practices – DEV Community

Unsurprisingly, this blog shared many of the same values that I learnt about in class. It gave me an overview of the material I had gotten an in-depth understanding of, with many additional helpful tips and tricks. This blog mentioned using meaningful names for your classes, functions, methods, and variables. This ensures that someone else who is reading your code can easily understand EXACTLY what everything is used for. Ex) “bananas VS. bananasInBasket”

Another thing that this blog shared with what I learnt about is to make sure functions and methods are small and limited to a specific number of lines. You don’t want an entire code that may be repeated inside one method. Instead, create a function that you can call inside the method to keep the code clean.

The website also mentioned good practices for making comments, and to make sure you refactor your code a lot over time!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Agile vs Waterfall

Hello, this is my second blog post. Today I wanted to talk about something I learnt about in my Software Process Management class. The topic of this blog is two methodologies in software development; the waterfall method, and the Agile method.

For those who do not know, the waterfall method is a very “set-in-stone” methodology, where each part of the software development process is pre-determined with deadlines and time constraints. Something I dislike about this methodology is the lack of communication between the company and the people creating software for them. I think it is very important to have a strong connection during the whole process, not just the start and the end. The Agile method is more flexible. There are pre-determined steps, just like in the waterfall method, however, they are conducted in much shorter time intervals and repeated several times. This allows more communication between customers and developers.

In my opinion, both methodologies have their own uses, which is something we talked about during a class discussion. We were asked to speak about which methodology would be better in different situations. I think that for a large-scale community/government project (such as building a bridge), the waterfall method could be useful since a lot of communication is not needed with a certain customer. For projects where the developers are creating an app/product for a company, I think Agile outshines the waterfall methodology by far, due to the reasons listen in the above paragraph.

I also used this website to learn a bit more about both methodologies: Agile vs. waterfall project management | Atlassian

This website reinforced my ideas and outlook on both methodologies. It highlighted that in the waterfall method, you are unable to move forward without completely fulfilling the first “phase.” It also went into detail on how in the Agile methodology is more flexible than the waterfall methodology. The waterfall methodology is much less able to be changed in any way, and it is a very linear methodology. There are also some helpful images on this website which I would recommend checking out to visualize both methods!

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.

Welcome

Hello! This is Akshay, and this is my first blog post.

From the blog cs@worcester – Akshay's Blog by Akshay Ganesh and used with permission of the author. All other rights reserved by the author.