Our Future Role

Before shifting into the details and techniques of how we, as developers, can design and improve software for the future, I felt as though it would be better to start off with a more general post about where software is taking us.

As people in this particular technological age, we depend on software to be effective every minute of every day of our lives. In this way, we are spoiled. With new advances in technology being released rapidly, we have almost become accustomed to having so much technical capability right in our back pockets. With this, we have begun to catalog and store everything about ourselves, since the amount of data storage we have is at a relatively infinite capacity. With such capabilities at the touch of our fingers, is it our jobs, as future software developers, to protect the general public against the possible repercussions? Are there evils afoot that come with such good?

To find out more information (and a few answers to these daunting questions), you may turn to non-other than Jeff Atwood, a software developer, who created the blog post “To Serve Man, with Software” on his blog, Coding Horror. He begins by describing the role of programmers today, beginning all the way from the early decades of coding, in the sense that programmers have always been the ones ruling the world. This, at first, seemed like a good thing. Programmers and software developers could change the world and do all sorts of good with their powers! However, is it always good?

What do you do when you wake up one day and software has kind of eaten the world, and it is no longer clear if software is in fact an unambiguously good thing, like we thought, like everyone told us … like we wanted it to be?

This should be a reminder to each of us how powerful software is, especially in our world today. Ensuring that all of the software that is being developed has a morally and ethically right purpose and that it is so specified that it cannot be used for anything other than it’s original intent is gravely important. As software developers, this is a critical concept to keep in mind.

 

From the blog CS@Worcester – Fall 2018 Software Discoveries by softwarediscoveries and used with permission of the author. All other rights reserved by the author.

Post #3: What/Why Software Testing is Important?

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.

Testing & Planning

The podcast that I had listened to for this week was again by Joe Colantonio with guest host Kinga Witko. The two first begin with talking about what Kinga does for a living and as a job. She speaks about the difficulties of her job and how demanding it can be. She also discusses how laws that differ from the U.S to Europe can affect how your testing goes in a job like hers. Afterwards, Joe talks about one of her youtube videos and how she states that you need time for big fixes. She specifically talks about the hardest thing people do not understand is the comprehension behind their project or software being a whole. Many tend to divide their project in two sections, so when they need to do deal with bugs or fixes, they see as something completely separate from their core features. People think that bugs are different from functionality, which is wrong, Kinga expresses. She then goes on to give tips on how to be aware of this. To know that testing is part of the process and bugs should not be part of a separate bit. One tip that she recommends is that a tester should always keep in mind that they should 25%/30% of each task/ development task for something which is unexpected. This doesn’t mean that it has to be a bug, it may be an environmental issue, or something you can not predict from the beginning. She also mentions that people should state problems early on, to avoid risks of even more problems. Lastly, her best approach for testers is to do exploratory testing. Get along with exploratory sessions and try to think outside of the box.
There were a lot of reasons why I really liked this article. The biggest being was that she was a women talking about testing, and computer science as a whole. All of the podcasts that I have listened to thus far have all been by men. I do not mind that because I knew from this beginning that this was a male dominated field, but I am always looking for female coders or testers. I also really liked that she was from Poland because I have not heard/ listened to any European CS people. What she had to say was even more interesting. Even I myself, who has not worked on hardcore projects for a job so far, feel like I already separate my projects into certain areas. I like that she was big on trying to keep it as a whole. A lot of her tips and tricks were very interesting to hear.

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

Single Responsibility Principle too much or no?

Have you ever heard of the Single Responsibility Principle? What does it sound like when it comes to mind? To me it kind of sounds like an object is tasked to do one thing.

In Jon Reid’s “Single responsibility Principle: Is it a fundamental mistake?”, he talks about the different problems that arises when applying the SRP. He starts off explaining that in order to apply the principle, we must keep subdividing until the class cannot be subdivided any further. That task sounds like a nightmare right? It gets worse. He goes on talking about classes and an important concept called “Cohesion”. Simply put, cohesion expresses how closely related parts of your code are with one another. For example the more each method uses the same instance variable the more cohesive the class is therefore that class must be narrowed down according to Reid. There is a such thing however as extracting too much from classes but he doesn’t really go into detail describing when you know you’ve narrowed down too far he only states you’ll know when you’re there which doesn’t help much.

I thought this blog was sort of confusing because he didn’t go into detail about how to not make the mistake about breaking down your code too far; I guess he just wants us to learn through trial and error which makes sense over time. I don’t think I will try to change my way of coding because the way he described SRP kind of made me want to sway away from the idea. There just seems to be too much room for error in my opinion. Yes I agree it is good to narrow down your code but you do run into the problems he mentioned.

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.

B3: Behavior-Driven Development

https://blog.codeship.com/behavior-driven-development/

          This week, I found a blog post that talked about Behavior-Driven Development and explains how to implement it within Computer Science. The post begins by defining behavior as the way the user wants the application to behave. It explains that you must have a clear idea on the user needs for this implementation to be successful. The implementation of this is done by dividing the user needs into small stories which have selected keywords to help define the behaviors of the application. The post uses examples very well to explain these ideas by highlighting and explaining important phrases. The selected keywords are used to put the stories into a more “readable” format while also creating behaviors based on the user needs. The post gives some advice after this, saying that the most important behavior to the user is the best starting point for these stories. Then you just keep building off that idea to encompass a final product that you can show to a client to make sure that all needed scenarios are covered.

            I chose this article because I was curious as to what Behavior-Driven Development entailed within the computer science world. I had no idea what this term was before reading this article, but I have gained a much better understanding now. I found this content enlightening in the sense that it taught me to think a bit differently. I enjoyed how the post explained the importance and implementation of this development through the use of these stories. I found this way of understanding user needs very helpful and a fresh new perspective compared to other things I’ve tried. I was able to understand how the development process works by starting at the user needs first. This will affect my development process by allowing me the option of working with the user to create better specifications. The most interesting part of this blog was the overall explanations for the development process. It was intriguing and informative while teaching the purpose of properly addressing the clients by starting with their needs first. I found this subject very interesting and this source was a good resource to understand with its use of examples and visuals.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

Model-Based Testing

This week’s blog is going to be about “The challenges and benefits of model-based testing” by Greg Sypolt.  In this blog, Greg talked about what model-based testing(MBT) is, how it works, how model-based testing differ from other kinds of testing, the challenges that are faced when using model-based testing, and the benefits of using it. Model-based testing is a kind of test where test cases are automatically generated from models. It focuses on the models based on the system requirements or specifications. The model-based testing works by generating tests automatically from models created by the software developers and testers, then it runs assertions for both generation of tests and execution, and reports the testing results. Model-based testing is different because it is more in the software development process than a scripting task. It focuses more on building a testable application and creating models based on user’s perspectives.  There are many challenges to address before you can use model-based testing to its full benefits. Software developers and testers have to be trained on model-based testing. The tool has to be scalable and be able to handle complex models and provide a reliable test coverage. Fine-tuning the MBT tool could also be challenging. However, it will offset the long-term goal of reduction of test maintenance. Test coverage is guaranteed and there is zero test suite maintenance.

I think this blog post is very helpful in introducing model-based testing. It is fairly brief but still shows you the idea behind model-based testing. This blog post is really interesting since model-based testing is a move away from the traditional testing. Instead of having a set of particular tests with defined test objectives and deliverables that should be achieved, model-based testing is done from models and not from the source code. A thought-provoking section of the blog for me is where he talked about the challenges of model-based testing. Greg said that model-based testing requires a shift in mindset and culture in how to develop and test applications. It made me think of how different it really is from the traditional way of testing. Learning about model-based testing changed the way I think about software testing since it is an approach that I haven’t really seen before. Now, I wonder in the future, what else kind of testing we are going to come up with.

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

TheCurrentStateOf, SD 01110

CS SERIES (4)As someone who will be graduating within the next year, I’m always interested in what software development is currently like. Ekaterina Novoseltseva uses some 2018 statistics and presents interesting facts about software development through Apiumhub—which is a software development company based in Barcelona. The data in this article comes from a collection of over 300 answers from different countries around the world; starting with the challenges in software development.

The information collected on programming languages was interesting to me as Javascript, Java, and Python are the top three current primary programming languages for those companies. On top of that, Go is used around 6% and of the companies who are considering using another programming language in the next 12 months, Go is the second on that list. I like seeing this data to know what is currently popular and may be an upcoming popular language as this is constantly changing. Novoseltseva points out how about 37% “of respondents said they’re not planning to use any new programming languages in the coming 12 months” and it makes me wonder whether it is because they do not want to change their ways or if they are already so on top of the updates that they do not need to for now. It also makes me wonder how companies in the New England region are doing in terms of exploring new languages or ways to keep up to date on their projects.

Although I knew of the current trend(s) for the most part, I was surprised to see what Apiumhub had to conclude on software outsourcing. It shows an infographic where of the people who did outsource software development fully or partially, only 10.06% of them were “absolutely satisfied” and 51.57% were “somewhat satisfied.” Based on what I’d been hearing of people being worried of getting all the tech jobs outsourced, maybe the scare isn’t as bad as people led it on to be. I mean of course, the total majority of responses from that fall under “satisfied” but it was not fully satisfying—this would probably be best for quick, short-term fixes or work. Which shows how there is still more to people-to-people communication in the company’s direct workforce and it puts my mind at ease a little more.

Article: https://apiumhub.com/tech-blog-barcelona/interesting-facts-software-development/

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

Behavior-Driven Development

What is Behavior-Driven Development you ask? To know that you must know what Test-Driven Development (TDD for short) is first. Keeping it short, TDD is a software development methodology that states for each unit of software, the developer must:

  • Add a test
  • Run all tests, see if one fails
  • Write code
  • Run test to implement code again
  • Refactor code to past test
  • Repeat

Knowing what TDD is, Behavior-Driven Development is merely an extension of TDD that makes more specific choices; meaning it focuses on specifying behavior and how the user wants the application to behave.

In Clemens Helm’s blog about Behavior Driven Development, he talks about the initial steps of BDD which starts off with the piece of functionality that is most important to the user; in other words we should develop software by centering our users. The purpose of this is so that developers know where to start and are on the same page in the development process of the project.

Some advantages I see from BDD is that it helps shift the focus to the expected end result and functionality of the program between the developers, QA, project managers, and business team. I found this particularly interesting because I always thought that communication was the utmost important part when it comes to creating anything as a team but I guess in a real work environment that is not always the case. I see that is what we’re learning to do in our Software Quality Assurance and Testing class; working as a team with different roles and I believe this is a very good skill to develop. I think that I will most likely try to incorporate this in the way I work with others in the near future.

 

Share your thoughts in the comments below! ?

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.

Software Development Trends

Today I read an article titled “Software Development Trends in 2018 That Will Dominate in 2019” This was a very interesting article that talks about the current trends involved in software development and how they will continue to be a force to be reckoned with in 2019. The article talks about 5 different trends that will be huge in 2019: Artificial Intelligence (AI), Progressive Web Apps, Blockchain Technology, Cybersecurity, and Low-code Development.

I chose to write about this article because I already knew that AI is one of the biggest current trends in software development, but I thought it would be interesting to read up on other trends in the world of software development. This article did not disappoint as I was able to learn more about Blockchain technology. I personally never heard of that before reading this article. I read that it was being used in the medical field, and it was being applied to the medical data in order to store it safely within a network. This appealed to me because my sister, and mother both work in the medical field, and I am sure that this could be useful in their line of work.

Although, I knew that AI was going to continue to be a huge trend in Software Development, I learned that AI will be used by “more than 40% of the organizations to automate their business in 2019” (Williams).

This article didn’t elaborate on low-code development too much unfortunately, but basically, it allows developers to build software without much expertise in coding. This part actually brings up an intriguing thought. While it does help people without expertise code more, could this be a bad thing for other developers? If everyone is given the opportunity to easily learn code, will that possibly take away opportunities from the extremely hard working developers? I don’t believe that will actually happen because the software development field is constantly evolving, so those with expertise in the field will continue to thrive.

Cybersecurity was the last trend that will continue into 2019, and I do feel like this is a given. The article mentions that 18% of companies did report at least one security incident in 2018. This is still an alarming number because some companies have a lot of important information that shouldn’t be leaked or taken. The trend that will continue is that these companies will look for Cybersecurity developers and thus, better programs will constantly be developed to virtually guarantee complete protection for any company’s data.

 

Article: https://medium.com/@Jessicawlm/software-development-trends-in-2018-that-will-dominate-2019-db1a1681c84d

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

The two ways of testing

So for this week, I have decided to read about “Pros and Cons of Dynamic Testing and Static Testing” from the testbytes blog. The reason I have chosen to read this blog is because I only have heard bits of both testing methods and I want to understand the advantages behind them. This will help me in seeing how they work and be able to use them in an expected way.

This blog post basically goes over as the title says the differences between static and dynamic testing. Both have their own purposes in making sure the software runs functionally. The blog post provides the techniques used and what are the benefits overall in both testing.  Static testing is an early stage of development and can be done manually or with a set of tools. It is useful in seeing the code flaws and giving documents to review the overall software. Another name for this test is verification testing.  With dynamic testing, the code is used to check how well it will perform in a run-time environment. It is to ensure that the end product is designed with the requirements given by the business clients. Another name for this test is execution testing. This one can be used in any levels of development. With both of these methods by their meanings, development companies can use them in to design flawless products in concept.

What I think is useful about this content is the way the ordering goes. From the blog, the definition is explained first to get the basic idea of the testing, then the techniques mentioned get broken down, and finally the pros and cons. The content has changed my way of thinking in how both the testing works. When I first heard about both the testing, I was briefly told that both can be used to find the errors and review coding in the software. However, one can be used faster while the other can be used around the end so that the product can be all set for the client. This was a misinterpretation in quite a time for me before finding the blog.

Based on the content of this blog, I would say this is informal and easy to understand when following along the order of it. I do not disagree with this content given by this blog because it helped me understand the ideas of the testing methods even without needing to see it in action. For future practice, I shall try to refer both testing advantages as reference for software testing.

 

Link to the blog: https://www.testbytes.net/blog/dynamic-testing-and-static-testing/

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.