Link to blog: https://www.computer.org/publications/tech-news/trends/application-security-testing

The whole semester we have been exploring various ways of testing code, namely styles that ensure the code works as it should. However, there is another aspect of testing we have not discussed yet; security testing. 

It is of the utmost importance to ensure that your software, database, website, etc. is safe from hackers and leaks. Security testing would help just that: making sure your system is unbreakable, or at the very least mostly protected from vulnerabilities and flaws. I think it is important to learn about this aspect of testing, which is how I came across Adam Stead’s article What is Security Testing? How to Check The Security Strength of Your Application.

Stead stresses the importance of security in software and also lists some important security testing techniques, such as vulnerability testing, black box testing, penetration testing, and more. There are many benefits of security testing besides identifying vulnerabilities. Some examples listed by Stead include protecting sensitive data, enhancing customer trust, and cost-effectiveness. Data leaks have been pretty common as of the past several years and it is a huge deal for those companies to lose their customers’ trust and their own reputation. With increased security comes increased trust, which is beneficial to both the business and the customer. 

Stead mentions some security testing best practices, and reinforces the idea of starting early and prioritizing risks. Security testing early on in development can help prevent flaws in your code, and you should continue to test throughout production. Prioritizing risks ensures that your important flaws don’t go unnoticed, and you fix your biggest holes before fixing the smaller ones.

Stead ends the article by discussing some attributes of effective security testing (thoroughness, continuity, scalability, etc.) and stresses the importance of checking the security strength of your software regularly.

I selected this article because this is a topic we have not discussed much in class even though it is still a very important part of software testing. This article emphasizes the key elements of security testing and how important it is to include it as a part of your testing regime.

The content of the resource was very informative and understandable for someone who already has a bit of understanding of software testing. An interesting thing I learned was about fax online, which is a method that businesses use to securely send documents. I did somewhat enjoy the article, it was informative, however I wish it included some examples of certain testing types. I expect to apply my newfound security knowledge to future jobs and software practices.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Link to blog: https://medium.com/swlh/intro-to-javascript-testing-with-mocha-1366dad9b973

For the next (and last) couple weeks of class, we are required to create our own in-class activity as if other students were going to use it. We were tasked with choosing something different than we have done already, so my group decided on testing JavaScript programs with the Mocha framework. I personally have no experience with Mocha, but I do have a tiny bit of experience with JavaScript, so I was interested to learn more about how different testing looked compared to what I was currently experiencing. This is how I found Valerie Foster’s blog post Into to JavaScript Testing with Mocha. Here’s what I found. 

Foster does give a few instructions on how to install the Mocha framework to your project, but I’ll mainly focus on the pros and cons of testing within the framework. They include a codeblock of a simple test, however it was not 100% clear to me at first what each line meant. Here are a few things included in the codeblock, and what they do:

• describe(string, function)
  • According to Codeacademy.com, the describe function groups tests together and uses the first parameter, the string, to explain that group. The second parameter, the function, is a callback function which has ‘it’ tests (I’ll get to that in a moment)
• it(string, function)
  • The it function is similar to the describe function, as its parameters are the same. However, the string it accepts is instead used to explain what the test itself is checking for. So, for example it(‘should //do something when //condition’, function(){})

Foster then discusses some customization options for Mocha, but then specifies their favorite assertion library in Mocha, called chai. One of the key benefits of this library is that it might make the test functions easier to read (e.g., going from assert.equal(a, b) to expect(a).to.equal(b), according to Foster). 

I selected this article because I wanted to have more of a background on Mocha and testing with Javascript since it is going to be our project. Also, Foster seems capable and comfortable with Mocha and JS, and makes it easy to understand what is going on in tests with a framework I’ve never seen before. A good beginner’s guide is always helpful to a fresh start.

I liked this blog because it felt informative and informal; like I was being taught something new but not in a super serious tone (Foster shared their favorite terminal customization was a Nyan Cat reporter). I learned a bit more about how testing is done in JavaScript, including describe and it functions. This affected me by boosting my confidence in my ability to assist my group with our assignment and it encouraged me to learn more JS and Mocha as a whole. I expect to apply such learned knowledge to future web applications and perhaps even past projects.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Based on this article by Denis Kranjcec: How I failed at Test-Driven Development and what it took to get it right

For the past couple weeks, Test-Driven Development has been the focus of our learning. We’ve done a small project in class creating a simple rover instruction program, which built our confidence and knowledge on how TDD works. Then, we used what we learned to individually create a unique word counter with string input. Since then, I have taken a slight liking to TDD, although it may just be a honeymoon phase. Well, my last blog post was about why Test Driven development is so good. This time, I sought out to find peoples’ personal failures with TDD, and why it failed. This is how I found How I failed at Test-Driven Development and what it took to get it right by Denis Kranjcec. 

Kranjcec begins his article by summarizing that he took a shot with TDD, and missed. But why did he miss? He dives into the reasons, and after a quick discussion on what TDD is and how it is supposed to improve code, he came to the conclusion that it wasn’t TDD’s fault, it was his. 

To start off, Kranjcec was using DDD (Domain-Driven Design), which led to his code being easy to comprehend, but his tests were more complex and difficult to maintain. After trying TDD again, he eventually realized that his biggest mistake was “starting with the simplest use cases and building up to the more complex ones” (Kranjcec). This seems to be a common problem with TDD users, as they tend to stick to more complicated tests than easier ones in exchange for fewer tests total. 

His solution was to change the way he wrote code and designed. This was done by breaking his work down into many smaller steps and lots of commits each day, in addition to refactoring his code. In short, he noticed his code was much simpler to understand and shorter, with other benefits as well.

I selected this article because after only seeing the benefits of TDD, I wanted to see the struggles people had with it. Although this article wasn’t about the faults of TDD, it shows the personal mishaps or mistakes that one can make when working with TDD, which can lead to a greater understanding of it in the end. 

I did like this article because it was an alternate perspective on how TDD can go. I learned to be patient with my code, and to try and stick with simpler tests and design in order to make TDD more effective. I think this article is a good reminder for self reflection on your own work, as it may not always be another’s fault if it doesn’t work. I hope to apply such knowledge in future projects using TDD, keeping in mind that simplicity is key.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Article: https://www.thoughtworks.com/en-us/insights/blog/test-driven-development-best-thing-has-happened-software-design

Last class, we got some hands-on experience with using Test Driven Development. These concepts always feel more concrete and understandable when actually working with them  yourself, rather than only reading articles or looking at examples. I’ve since gotten the hang of this method of development, and wanted to look into how it compares with other development strategies. Such is how I found Test Driven Development is the best thing that has happened to software design by Arek Torczuk.

Throughout the entire article, Torczuk compares the methodologies of code-driven tests and test-driven code. In other words, he judges whether code-first test later is better than test-now code later, respectively. The results for this vary, of course; some companies or teams may benefit more from one strategy than the other. A noted flaw of code-driven testing is that your tests do not challenge the implementation and design of your code. You can create all the tests you’d like on a specific method, but nothing would make you second-guess the way you wrote the method. 

This is where the test-driven approach would come into play. Having already written the tests, you have a better idea of what your code should look like, and how it should act. As Torczuk states, you can ask yourself “What do I expect from the code?” with writing tests before the method (Torczuk). Essentially, with TDD, you know all the answers to your questions and when enough is enough in terms of tests & code. In my mind, it makes the process more streamlined.

Another important part of TDD Torczuk mentions is that it gives quick feedback about the design of your software. You’ll sooner realize the potential issues with your existing codebase, and how it might affect your ability to add new functionality. 

I selected this article because test-driven development piqued my interest after I had more time to experiment with it. This article grabbed my attention specifically because it didn’t just reiterate the concept of Test Driven Development over and over. Another quite useful part of this article is its inclusion of real examples of TDD by the author.

The content of this article was clear cut and organized, and even though it may not have been a ton of new information, it was a different perspective comparing test-driven development and code-driven tests. I learned that generally TDD is more effective at producing well-implemented code than simply writing the method first and tests later. Seeing as we are continuing to learn TDD, I’m confident that I’ll be able to use this in my future projects/jobs if necessary. Or, I could suggest it to my team if we are struggling with writing tests after code.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

In class, we began learning about the use of mocking in software testing. After doing an activity, I realized I only slightly understood the purpose of it. So, I decided to investigate, which is when I found The Art of Mocking by Gil Zilberfeld and Dror Helper.

The article begins by giving an introduction to unit tests for those who might not be familiar. They also give an example in C#, which is the language they use for the rest of the article. However, this does not impact information about mocking besides the syntax of the examples.

Once unit tests are covered, hand-rolled mock tests are introduced: they are classes that the developer(s) code which take the place of the real objects for testing purposes. It might not accurately test the system, but it ensures the business logic of the class works. 

The types of mocking listed are those manually made by the developers and those auto generated by mocking frameworks (Mockito or Moq). The article goes quite in depth into mocking frameworks, in their types, what they do, and what to look for when choosing one. Zilberfeld and Helper also discuss the benefits of mocking, which generally boils down to the fact that mocking cuts loose extra requirements for testing, such as databases and other external/complex resources.

Lastly, the best practices and potential hazards are listed. From what I gathered, the important ones were:

• Only use fake objects when necessary, as too many can create weak/fragile tests
• Understand what you’re testing and the dependency
• At most two assertions/verifications per test

I selected this article because I was struggling a little bit with what mocking was and why it was useful. I had somewhat understood the concept and the idea behind it in class, but needed to go on a deeper dive to get a better grip on it. This resource also seems pretty real, in the sense of it feels homemade and focused; all the important stuff is in the articles themselves, not a subscription or anything. 

This article is superb with its examples and clear, in-depth explanations of unit tests and mocking. The formatting is easy to follow and allows for smooth learning and transitions from concept to concept. I personally believe that mocking is quite useful when applied lightly. I learned that Verify should only be used in fake objects when it’s the only way your program can pass or fail; otherwise, it might not matter whether every method actually calls the expected method. 

This affected me in a positive way as it gave me greater insight to mocking and more confidence in my personal understanding as to why we use it. I expect to apply this in a future job when I might need to test a method that uses database information, but it would take too many resources to use the database for testing purposes.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

https://web.dev/articles/ta-test-cases

Last week, we tracked the path a program would take using program graphs. The program graph is good to represent the overall structure of a program; it shows all the ways the code can go. 

Afterwards, I wondered about the other types of paths a program could take, whether it be the best case, worst case, etc. That’s when I found Ramona Schwering’s article about test cases and happy paths.

Although I primarily read this article for it’s definitions and information on the different paths a software could provide, it also covers the idea of a test case and how to prioritize the right ones. Schwering first reminds us what a test case does whilst checking the results of the program: it verifies the program does what it’s intended to do, and it validates the program is what the customer or user wants. 

Next, Schwering explains what drew me to the article in the first place: test paths and their outcomes. The first path is known as the happy path, since it applies to the most common use case of your program; this is what should happen and what we want to happen. The second path is the scary path, which is used to catch errors and ugly outcomes. 

Schwering lists other test paths that aren’t used as frequently as the first two but could be important to recognize. I’ll talk about a few I find interesting.

• An angry path is supposed to get an error; making sure error handling works.

• A desolate path would be important for programs dealing with input data, as it tests to see if it’s given enough data to function correctly. 

Lastly, Schwering goes over the best practices for writing test cases, and how there are two patterns used to structure the cases: Arrange, act, assert and Given, when, then.

I selected this article because it covered my topic of interest and I also enjoyed Schwering’s straight to the point, easy to understand writing style. I decided to do a deeper dive on Schwering herself and found she’s a software developer and tester that speaks at international conferences worldwide. Reading through the post, I found the organization of the information to be helpful in my learning along with the information itself being reflective of my thoughts on our recent classes. 

The content Schwering provides in this article is great for a quick read for anyone wanting to learn more about testing. I personally believe the paths she went over are important to prioritize, especially happy and scary paths. I refreshed myself on the duties of a test case and learned multiple kinds of test paths, and how their importances varies from situation to situation. I enjoyed this article especially due to Schwering’s little illustrations and how easy it was to understand the paths. I hope to create test cases in the future with these paths in mind, using them to my advantage when possible.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

https://www.testbytes.net/blog/boundary-value-analysis

This past week we began understanding and practicing boundary value testing using simple programs and, of course, simple tests. This blog post discusses that same topic, and gives multiple real life-scenarios and dives deep into the subject. Although it is not a super difficult subject to grasp (in my opinion), I feel this is a good way to reinforce those ideas we learned in class.

This blog by testbytes gives all the information one would need to give them a solid starting ground for boundary value testing. It first explains the concept of the testing model and why it would be done, such as explaining how testers hope to identify errors more proficiently. An example is given, using discount percentages that apply ONLY when purchase totals reach a certain threshold. The lower boundary of the first discount is given, testing if the total is less than $10 (which should mean a 0% discount). Then, the upper boundary of the first discount is checked, with a $10 order receiving an expected 5% discount, so on and so forth. 

Later the blog discusses the different types of boundary value testing as well as their distinctions and the disadvantages and advantages of this type of testing. 

I selected this resource because it gives a quick definition of boundary value testing but then goes into further detail on the subject with good examples and explanations. It is a well thought out post that gave me a more concrete understanding of boundary value testing and edge cases. 

Testbytes on its own is a reliable source for this specific information since it is an entire company dedicated to software testing and quality assurance. Through checking out their other posts, I see they have a variety of testing area blogs including mobile apps, web apps, games, automation, security, and more. 

Overall, this resource is great to refer back to due to its consistent information and easy to understand descriptions. 

As previously mentioned, the content in this blog post by Testbytes is a really solid basis for a good understanding of boundary value testing. I can’t say that it is the highest quality and in-depth education on the subject one can receive, but it’s useful for someone like me who is just getting started. 

Personally, I really enjoyed the material, especially the example given at the start. Although I wasn’t struggling with what we were learning in class, there were times where I had a moment of confusion. This is a quick bit of information that instilled some more confidence in me about this topic. One main thing I learned through this blog is a big disadvantage of BVA is truly how many test cases it may require to check all boundaries/edges, which can lead to a lot of effort on the system and more power/time consumption. I expect to use such advantages and disadvantages when creating test cases for my future individual and work projects.

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

link to blog at the end:

Have you ever heard a word or phrase that you feel like you should understand but you just don’t? It’s happened to many people, and I’m sure it is not uncommon in the software industry. Certain software terms are either confusing or unknown, which is perfectly understandable!

Chris Kenst’s blog post relates to what we studied in class this past week, as it correlates with and even mentions some of the terms we learned, such as black box testing. It will hopefully help the definitions we previously learned stick in my head as the weeks go by.

This blog post is all about lingo. It aims to better prepare students and software-testing newbies for the confusing jargon coming out of their coworkers’ mouths. It is in a simple glossary format, which is easy to understand and refer back to from time to time. There are 50 terms listed as well, so there may be some left out, but the ones listed are what you are most likely to hear in the workplace or in communication. Kenst also mentions at the end of the post that an increased mutual understanding of such terms can lead to increased productivity and collaboration.

I chose to cover this blog post because it is easy to get lost in all the mumbo jumbo tech buzzwords flying around the internet. It is like being a parent and learning what your kids’ slang means; except the kids are your coworkers and the slang is important keywords for your profession. I would not want to be the one guy at a meeting who does not understand “black-box testing” or what “domain testing” is. Jokes aside, this is a great resource for my fellow students to refer back to, especially as we are just beginning our software testing journey. These terms are important to know, because otherwise you might fall behind as new terms and testing variations are created. 

I personally believe this is a great starting point for those new to software testing (like me) and those who might need a refresher every now and then whenever their coworker says something unfamiliar. I learned how “high volume automated testing” involves auto generation, execution, and evaluation of multiple tests that may be weaker and not as thorough on their own, but together expose bugs and weaknesses. I will continue to learn more testing variations and other terms from this list to strengthen my confidence as a software tester and engineer. I hope to apply this knowledge in the future whether it be at a job interview or in a working environment, proving to my coworkers that I understand the language they are speaking and can keep up with their discussions.

Blog: 50 Software Testing Terms Defined – Chris Kenst

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.

Ever struggle to read another developer’s code? Code should be easy to follow along with, especially for a reader entirely new to the codebase. However, sometimes developers write “spaghetti code”, with random variables or methods mixed together in a non-understandable manner. 

Gary Espinosa of Reflectoring.io believes that clean code is the best code, and it’s super important for companies and coworkers. He lists suggestions such as variable names being descriptive, methods shortened, code broken up, etc. Let’s dive into what he suggests.

Espinosa discusses the huge importance of clean code, and how it can make or break a codebase. Not only is code the flesh and blood of a program, but it is also a form of communication between collaborating developers. It helps enable easy understanding of code and editability without errors. Companies who need to ensure their code is clean often spend time and resources just making it easy to comprehend.

Clean code should be readable; this involves grouping similar functions and classes together, similar variables, etc. The document should flow like an “engaging narrative from top to bottom” (Espinosa). If possible, one idea per line and one action per statement is key.

You should also be able to keep your code consistent. There must be a standard for writing code, variables, and methods. Examples of this would be using camelCase for all your variable and method names, using specific indentation rules, and more. A unifying language reduces differences.

One should strive for simplicity, but with descriptive language as well. Variables, methods, and classes should have meaningful names that describe the point of themselves easily. For example, you shouldn’t use a name like “x1” or “yY” as they don’t provide the reader any insight as to what they’re for.  

I selected this resource because it lines up with what we’re currently learning, and it is a key importance to being a software developer in the industry. If you want to have your pull requests approved, write clean, understandable code. This topic intrigued me because it’s quite simple but I wasn’t sure if there were any specific industry standards for clean code. There are definitely certain uniforms industry-wide, but I’m sure that it depends from company to company.

Espinosa’s article was informative, and explained what’s important and why about clean code. It’s useful to those new to programming, or those who are experienced in coding but just entering the professional industry.

I learned how important clean code actually is, not only to the programmer but to their coworkers and the company as a whole. Alongside this, the article taught me how to effectively organize and write code in a clean and understandable manner. This led to an increase in my confidence in my ability to clean up my code. I want to apply this knowledge to my future jobs and perhaps go back and clean up my old projects to make them easier to comprehend.

Article: https://reflectoring.io/clean-code/

From the blog CS@Worcester – Josh's Coding Journey by joshuafife and used with permission of the author. All other rights reserved by the author.