Reasons to test your code

For every person, there are things they like and things they don’t. One such thing for me is testing my code. Is it laziness? Is it the fact that I’m awful at it? I’m not particularly sure why but in “5 Reasons why you should test your code” by Frank van Wijk, he talks about five important reasons on why we should always test our code.

Reason number one: Regression testing. The example he gives is that your code is fully functional and working but then one feature breaks in your code and now you’re left staring blankly at your code. Given that if you have 100% code coverage, you know there is a fully functional test suite. For example, you run the test suite, then you modify some parts of your code and then you run the test suite again. Now if tests are failing after the modification, there is an assertion done for this case. This is good because after every modification or as your program becomes more dense you could repeat this process each time to get rid of newly formed bugs.

Reason number two: Improve the implementation via new insights. After you finish your writing your program the first thing you might want to do is walk away grab a beer and reward yourself but before doing so you should write start writing tests for your methods. If you find that it is difficult to write tests for your methods then in may be an indication that there is room for improvement in the way you wrote your methods.

Reason number three: It saves you time. Although it takes up a huge chunk of your day writing tests for your code, in the long run it would actually save you time. The reason being, if you refactored your code, your tests should catch most of the bugs and allow you to fix it without having to sift through the entire program searching for what went wrong.

Reason number four: Self-updating documentation. There are many ways to understand code; read comments, read the implementation, or by reading the tests. It serves as a type of documentation that allows the reader to know what is suppose to happen.

And the final reason Wijk gives is because it is fun.

For the most part I found this blog quite fun to read because the author made a few valid points. Writing tests may be a pain but in the end it does make you a better programmer and ensures that there is less room for errors. I know my biggest weakness is testing my code because I never have in the past and moving forward I will start to.

Thank you for the read!

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.

QA Career Paths

I’m a Computer Science major, about to graduate this year, without a real understanding of where to go after my degree. Since my future is fairly open, I was curious to research the professional QA field and how some testers got their start in the industry. After a quick google search, I followed the link below and found some helpful insight from current professionals on the topic.

https://techbeacon.com/6-new-careers-paths-ideas-software-qa-testers-professionals

Firstly, it surprised me to find out that many QA testers ended up in their positions without a lot of intention. To quote QA professional Shelley Rueger, “I don’t know that there is a standard way to start in QA.” Originally, Rueger went to MIT to become a research physicist, quite a long step away from her current career of 15 years so far. Its surprising to me how somebody could invest so much into their future but mysteriously end up in a different field entirely, a trend common across all majors. I suppose the future is just that unpredictable, which actually offers me relief since I’m so unsure of where I’ll end up.

All that being said, going into QA is certainly worth planning out long term if anybody is considering it professionally, since the first few years are typically rough. Jeremy Hymel, the QA manager at QAlytics, shares his experience; “The early years in a tester’s career are rough, the pay is not great, and they are not treated as well as developers.” Once the hardships are over however, this article lists multiple points to jump off of as a QA tester. I will summarize the following paths: Product Management, DevOps, and Customer Experience.

Product management is a common fit for advancing QA testers, since they have extensive experience ensuring the best software possible. This quality is essential to the success of software reliant companies and they will often recognize a good QA tester to take the role of feature development.

Testers are more suited than software developers in the advancing role of DevOps. QA testers can easily practice the skills needed for a career in release management, product stability, or automation engineering.

It also makes a lot of sense that a QA tester could pursue a Customer Experience role. The tester assumes the role of the customer with every software test, therefore they have plenty of experience seeing the point of view of the user.

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

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.