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.

The Importance of Names

I’ve heard a lot of great things about “Clean Code” by Robert “Uncle Bob” Martin, and when I saw that the Coding Blocks Podcast had done a small series reflecting on the material of the book, I jumped right in.

Clean Code (although I haven’t read it yet) is a book that aims to set a standard in software craftsmanship, so that code isn’t lost as a result of being difficult to reuse, refactor, or even… well, read. The podcast reflected on Chapter 2 of the book, Meaningful Names. Allen Underwood and Michael Outlaw discussed major points that the chapter touched on and their personal experiences with each.

The segment that may have had the most impact on my outlook towards this subject was one of the first ones in the podcast — that the names of variables and methods should be as descriptive as possible, so that you don’t necessarily need to write a comment that explains what it does. This seems self explanatory, but I’ve already caught myself feeling compelled to comment every variable I declare in order to explain the differences between nondescript declarations like numDays and dayNum. Even if it’s just a small personal project, getting in the habit of writing effective variable names is a practice to start sooner rather than later.

They made another great point later on during the show too — Don’t be afraid of long variable/method names! So far in my educational experience, I don’t think I’ve needed to bother with a program that was more than ~500 lines total. In this case, it’s pretty easy to scroll to find what you’re looking for in each class. However when you’re dealing with a full software program, having a variable name that is easily searchable can save an enormous amount of time.

Certain topics touched on, like the “Hungarian Method” for example, I was completely unfamiliar with. I think standards like that may have been more niche or were perhaps prevalent before my time writing code. I agreed with what they said about it in the podcast, and I think the idea of a common naming convention is a good one however having code that is clear and easily readable is a better alternative.

This series of podcasts were really good, so I’ll likely be writing about it a lot more in the near future. There was a whole lot more that they went over, and it definitely made me interested in reading this book.

Here‘s a link to the episode on their website, check it out!

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

Blog 2 CS 443

My blog this week is based upon this article in which the author explores “shift left testing” which is simply a fancy way of testing earliest in the production of a program as possible. In this article the author goes into detail about several different forms of shift left testing, all of which try to push the testing earlier into the development of a program. The author also reviews why the common practice of testing late in production phase has been a major harm to system and software testing.

I found it interesting that the testing phase is often left so late in the development, with some major consequences pointed out by the author. One of these consequences the author highlights about this method is that it often results in “wasted time”. This can happen because “Many requirements, architecture, and design defects are not uncovered and fixed until after significant effort has been wasted on their implementation.” This article also focuses on what I feel is a much better approach to the development in which each part of the original “V-model” of production is broken into separate “V-models”. This means that for every part of the production phase, whether it be design, coding, fabrication, it is accompanied by a testing phase. This does require more time in the production but will ultimately produce a better program with fewer to no faults. I believe employing this strategy in one’s own personal work would be a very smart idea. This can be done for example while creating a program yourself, with every part of the program you write, you test it to make sure it is correct. This will help by the end of the program when you could generally have several mistakes causing errors throughout the program. One final thing the author points out which I believe could be relevant to those not employing this method is that late testing can lead to missed deadlines, whether it be for a company or for a student working on a project.

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

Blog 2 CS 343

My blog this week is based on this article which talks about the author philosophy behind debugging and how people often fail to debug properly. One of the first things the author talks about is how it is important to once presented with a program to debug, the best thing to do is know and admit that you do not know the answer immediately to whatever problem there is. He says this to follow up with the importance of gathering the information about the problem that will help much more then just simply trying to “guess” a solution. One other important point that the author made in this article is that most programmers tend to try to find a “bandage” for the bug they are presented with. The author believes if someone debugs a program properly “you’ve actually caused some part of the system to go away, become simpler, have better design, etc. as part of your fix”.
I personally found the authors advice of trying to understand the problem further before even attempting to create a fix to be very helpful. Looking at how I’ve done things in the past I know that I would often simply try different things to come to a fix for a problem. One way the author suggests to help fix this is to gather data about the bug until you fully understand the cause of the bug in the first place. You can do this by trying to recreate the bug for yourself to see the cause of the issue, or try referring to the way a proper program should behave. Another point I took away from this article was that when you are debugging something you should be eliminating code to make the program simpler and better in design. Often times you can think the proper way to fix a problem is to add something to the code to handle whatever problem is occurring, when you should rather be making the code simpler to begin with. I feel this is a very smart way to code/debug because anytime you can make the code of a program simpler, yet act in the same way, is good for both other programmers to look at in the future and for the users of the program itself.

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

The Benefits of Unit Testing

This article by Ekaterina Novoseltseva on DZone (DevOps Zone) is about 8 benefits of unit testing. In the article, she breaks down how her company, Apiumhub, utilizes unit testing in order to stay Agile. She also breaks down several of the benefits of unit testing including relation to Agile, quality of code improvements, reduction of costs, and several others.

I found this article interesting because while I knew some of these benefits of unit testing, I never thought of some of the specific examples like the relation to Agile. She points out that unit testing facilitates “safe refactoring” by forcing developers to use the smallest functionality possible for testing a single unit. I agree completely with her in regards to Agile especially after she pointed out that this goes hand in hand with extreme programming and test driven development.

Personally, I’d never used test driven development at a large scale before so I’ve never really considered the benefits. The section on the benefits to design really pushes the idea that test driven development makes code more optimized, with cleaner designs. When breaking everything down into a unit first, figuring out what each unit is, and defining what the functionality is through tests, you are forced to consider the designs of the actual functions before writing them.

Another point that she makes that is probably one of the most important to the business is that unit testing reduces costs for the development process. Unit testing finds bugs early in the process because the tests are either written before the code is even written, or before moving onto the next snippet of functionality in order to stay Agile. This means that application-breaking bugs are less likely to be found in the later stages of the development process like “system testing” or “acceptance testing” as Ekaterina points out in the article.

I wholeheartedly recommend this article to anyone who is relatively new to unit testing and doesn’t is any bit unsure of the possible reasons why unit testing is so important. I can see myself utilizing unit testing more in my personal projects in the future as I already try to work on them in some resemblance of an Agile process.

From the blog CS@Worcester – The Road to Software Engineering by Stephen Burke and used with permission of the author. All other rights reserved by the author.