Hello to all readers new and old, thank you for taking your time to read this brief introduction to my blog. My name is Andrew George, and I am a senior at Worcester State University. For the past couple years I’ve been studying Computer Science and slowly adding skills to my repertoire. I am once again looking forward to researching topics pertaining to my major, this time with a focus on the Software Design process. I do encourage you, if you have not already, to read my previous introduction pieces found on this blog as those have a more in depth explanation of where I started and how I got to this point today. Thank you once again and until next time!

-AG

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

Throughout the cumulative experience I’ve had with testing, most of it focuses on the program’s logic and ensuring that it yields a correct result. One aspect of testing I have no experience with is security testing. Here one must find flaws within a system/program’s security and report them to developers so they cannot be exploited later in the product’s lifespan. Security testing has much higher stakes than that of unit testing as vital information such as consumer personal information and system source code may be leaked if there is a security breach. Therefore, testing security is of utmost importance when releasing a service to the public, as failing to do so will damage the service’s integrity.

Security testing hosts several different types of tests, each of which focuses on different aspects of a system. The article Security Testing posted by user pp_pankaj highlights the principles upheld by this testing and what each test achieves. Some of these tests, Posture Assessment, I found quite interesting. Posture Assessment combines the testing methods of ethical hacking, risk assessment, and security scanning into one report to provide an overall security posture of a system (pp_pankaj). Each of these subtests has a shared goal of having a hacker, hired by the development team, find security vulnerabilities within their system and report it to the team. Another form of testing I found interesting was social engineering testing. This deviates drastically from what we as programmers come to understand tests as. These are emulated attacks through communication such as email. The purpose of this test is to train developers to avoid suspicious engagement and to find new ways to breach a system without making direct contact. Whether a development team gets successfully breached through the socially engineered test is dependent on the team’s understanding of who they must respond to. A few weeks ago I was researching a data breach that happened earlier this year at Microsoft. Hackers were able to control a testing account and had direct access to employees on the project. From here they were able to obtain information they naturally should not have access to. All of this occurred due to developers not knowing that they must not communicate with a testing account.

A general metric as to whether security testing is vital to a project is to consider whether your product is liable for holding personal information that is not your own. If this is the case, then it’s in the development team’s best interest to uphold their principle of confidentiality and integrity by running security tests throughout the lifespan of your product.

-AG

Source: https://www.geeksforgeeks.org/security-testing/

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

Beyond Unit Testing, there are several ways one may go about testing a developed system. One of these ways is through combinatorial testing. While researching this topic I’ve seen a couple of steps that I’ve taken in testing that match with this testing method. For example, earlier this semester I learned about how behavior tables can help guide Unit Testing by showing what aspects of a program will be covered by one test. Combinatorial testing achieves a similar effect by first taking all possible inputs (from a pool of predetermined inputs) and then creating a set of tests that will test each unique combination from the pool. A source that helped me grasp this topic is Combinatorial Testing by Shanika Wickramasinghe. In this article, Wickramasinghe provides an example of how they would develop tests. It’s important to note that in this example only combinations are created, NOT permutations, meaning that overall much fewer tests would be needed to fulfill a combinatorial test. This does raise a question for future reading of whether there is such thing as “permutative” testing and how that and combinatorial testing differ.

Using combinatorial testing does provide benefits despite the time it may take to achieve a successful test. Combinatorial tests are all designed to try multiple inputs simultaneously, meaning that both single-fault and multi-fault assumptions will be made in a full combinatorial test. Once these tests are complete, the developer can better understand which inputs cause a problem within their code. Additionally, once the pool of potential inputs is determined, the tester will have a set number of tests they must conduct. These tests may find faults in the program that require specific input that the development team may not have accounted for. Through feedback such as this, the development team can resolve the bug and create ways of handling errors caused by unexpected input. These benefits do come with equally heavy drawbacks. Manual combinatorial testing is possible, however the testers may struggle with creating combinations from a larger input pool. A way this can be solved is by using an automated combinatorial tester. It’s important to note that this can be limited by how intensive the tests are on the hardware of the automated tester. Lastly, the combinations that the test may provide could be so random that it’s nonsensical to test such a thing. This becomes an issue of resources which will vary from developer to developer. Ultimately whether one uses combinatorial testing or not is up to the developer. There are some instances where the cost of conducting one of these tests would be beneficial to the development process, but this is not a “one size fits all” type of test. By using some of the team’s resources, whether it be labor or hardware-bound, combinatorial tests will yield meaningful results as to which areas of the program need further testing.

-AG

Source: https://testsigma.com/blog/combinatorial-testing/

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

Performance Testing is a subject I just recently discovered is included in the Software Quality Testing umbrella term. Outside of casually monitoring CPU and GPU usage while using demanding software, I have little knowledge of what Performance Testing is. As a future worker in the Computer Science field, knowing how to report and minimize hardware stress must be an invaluable skill.

During my search to understand what Performance Testing is, I found an article written by Tricentis that included an in-depth explanation for each step (or deviation) of Performance Testing. Before going into detail, Tricentis highlights that performance testing is a direct solution to ensuring the stability and scalability of software. If performance testing is ignored, then users may encounter issues with speed, crashes, or data loss within their application. Testing seems to flawlessly integrate with CI/CD models, as testing should occur whenever a working model is available. This allows the development team to fix issues early before they sink too deep into the product’s foundation. Within the realm of performance testing, some subtests aim to find results for specific metrics. A few that I was unfamiliar with are as follows. Regression tests seek to test two states of the program, one being the current model, and the other being one with experimental changes. Both of these models work together to compare the hardware performance. These are used to highlight whether changes from the most recent version are more damaging to the product. Functional tests focus more on the software aspect of the product. Using this test will yield results on whether the UI elements, APIs, etc are all functioning correctly. Lastly, load testing seeks to put the product under great stress by simulating several concurrent users. Testing with this will give the developers insight as to how their product will function once published to the general public. Metris from load testing will help reinforce the product before it can fail after its initial release.

Performance testing will yield several useful metrics to guide the development of the product. These metrics include hardware bottlenecks, response time, and load time. Issues about these metrics must be addressed during the development process as they directly impact the reliability of their product post-release. Untested hardware is an active detriment to the developers, and will further damage the development process. Following the idea of testing software ‘frequently and consistently’, developers must also view how the current state of their product affects the hardware it will operate on.

-AG

Source: https://www.tricentis.com/learn/performance-testing

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

JavaScript is a programming language completely foreign to me. At one point in the near future, I see myself learning the basics just to gain general exposure to it. It differs enough from my first object-oriented language, that being Java, to the point where it seems valuable to have some experience in it. With this in mind, I began my search to see what testing framework would work for this language and how tests are conducted differently.

In my search, I discovered this testing framework named Jest. This is a testing framework that is most known for testing Javascript but has also seen usage with other languages such as Angular and React. According to the author of the blog post The Pros and Cons of Different Test Tools – Jest, Craig Risi, he immediately states this testing framework is much more user-friendly than others. Jest does not require the users to install packages or other external dependencies, as the framework has them already included. Furthermore, the included dependencies are often built on frameworks of other languages, such as Mocha or Chai, which makes Jest an incredibly flexible testing framework. An important inclusion Risi made to his blog post was the inclusion of all features Jest offers out of the box. These range from topics I’m knowledgeable of, such as Mocking and Unit Testing, and some that I’m new to, such as Snapshot Testing and Asynchronous Testing.

Towards the end of Risi’s blog post, he mentions the direct pros and cons of using Jest. As previously mentioned the versatility between languages, easy start-up, and abundant features are a testament to its practicality. Unfortunately, no testing framework is flawless. Several of these issues originate from the sheer size of Jest. Downloading this framework and testing smaller projects offer an issue of scalability. There are countless smaller frameworks, in terms of digital size and complexity, that are better suited for testing software. Additionally, all the features Jest includes come with their own learning curve. Users may never utilize some features as the scope of their testing does not call for Jest’s extensive collection. With both the pros and cons in mind, Jest is incredible in what it can achieve but development teams must consider the scale of their project to determine whether using it is appropriate. Reflecting on my experience with testing frameworks, I can understand the value of having that much utility from one framework, yet I don’t see myself creating a project ‘so big’ that would call for it’s entire library of features.

-AG

Source: https://www.linkedin.com/pulse/pros-cons-different-test-tools-jest-craig-risi

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

Before being exposed to JUnit, my only experience with automated testing was through CxxTest while I was learning C++. Once I started to learn JUnit both the syntax and general format seemed to ring a bell. This caused me to check back at my previous C++ programs to find that the assertion-based testing was identical to that of JUnit. After seeing these two side by side I was curious about the comparisons between these two testing frameworks and whether CxxTest had any advantages over that of JUnit.

While looking for an article discussing the full capabilities of CxxTest, I stumbled upon a blog, Exploring the C++ Unit Testing Jungle by user @noel_llopis, which seemed to provided extensive explanations of each popular testing framework for C++ at the time. Do note that this post was written in 2010, so popular testing frameworks from then may have faded into obscurity and new frameworks may be used in their place. My main allure to this article was Llopis’s section describing his experience with CxxTest and how testing frameworks required a little more work from the user back in 2010. Llopis praised CxxTest for it’s relative simplicity in how it’s imported into a program and how it requires much less dependencies. From his explanation, I’ve learned that testing frameworks used to require certain formatting within the file and potentially other libraries for the tests to function. CxxTest, similar to JUnit, can operate by itself with much less dependencies than it’s competitors (at the time). A feature that JUnit lacks that CxxTest contains is the ability to natively mock objects. JUnit does have this ability, but requires the user to add another resource to JUnit meanwhile, CxxTest has this functionality immediately. One downside that the author does mention is that CxxTest did require “use of a scripting language as part of the build process”(Llopis), this may create a barrier of entry to less experienced developers.

While comparing these two testing frameworks, I found myself asking a new question of ‘how accessible or inaccessible were testing frameworks of the past’. Llopis seemed to be enthusiastic about features that I held to be common for all frameworks to have. Additionally writing about this did make me wish that I spent more time in the past programming with C++ outside of classes. Reading this did help expand my knowledge of how CxxTest operates, so when I do inevitably go back to refine my C++ skills I’ll be ready to pickup this framework once more. Between JUnit and CxxTest, there are many surface layer similarities, as both are unit testing frameworks. The differences seem to lie in smaller features that some developers may depend on, such as mocking. After having experience in both I find it hard to chose one or the other as they both generally function the same and have similar levels of accessibility.

-AG

Source: https://gamesfromwithin.com/exploring-the-c-unit-testing-framework-jungle

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

Throughout my experience with Software Quality Assurance, I’ve used two different types of testing frameworks. The most recent is JUnit as I’ve just learned how to use it earlier this year, and the other being CxxTest which I’ve forgotten most of (including its name) until writing this. Each of these operates for different languages, JUnit for Java, and CxxTest for C++. The differences between these two made me curious whether a framework worked for more than one language at once. Note, that frameworks such as CTest that work for both C and C++ I do not include as both exist within the C family. As I searched for a framework that answered my question I stumbled upon Selenium and subsequent articles comparing it to that of JUnit. These comparisons drew my attention and sent me down a path to understand what Selenium is.

Before getting into specifics I must introduce a few definitions that help differentiate these two frameworks. Unit testing is the method of testing smaller increments of source code to ensure that each ‘unit’ works as intended and meets the developers’ specifications. This lays the foundation for later development. End-to-end testing focuses on testing components where the user interacts with the program directly. This tests components such as UI and web applications. JUnit focuses on unit testing with code programmed in Java meanwhile, Selenium focuses on end-to-end testing with multiple different languages including Java. Fundamentally these frameworks are testing different aspects of software development, therefore any comparison between the two must be taken with a bit of nuance.

With definitions aside, we can now talk about what makes these frameworks unique. A community post on StackShare, JUnit Vs Selenium, gives a concise view into what make these frameworks differ. My experience with frameworks has only existed within IDEs however, Selenium is supported on browser and web driver tools. Additionally, Selenium tests run within a browser, meanwhile JUnits require a Java Virtual Machine to be created. One downside of Selenium is its requirements for dependencies, as opposed to JUnit which can be imported into your program. I’m more partial to JUnit as I only have experience with back-end development, so Selenium isn’t directed towards a developer such as myself. With that being said, those who are more experienced in front-end development may find the requirements for dependencies and browser configurations to be a small cost for its flexibility with testing.

I have a little experience with front-end development, so I can understand how the tools provided by Selenium could be invaluable. A lesson I’ve learned from this dive into Selenium is that all aspects of development (Ex: Front vs Back end) will require some form of automated testing. Additionally, testing that may be easy for one department may be more complex for another. With these different areas of testing also come different methods. End-to-end testing will be noticeably different than unit testing, as each method focuses on a specific function of the software.

-AG

Source: https://stackshare.io/stackups/junit-vs-selenium

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

While writing about static testing, I spoke about my positive disposition toward dynamic testing due to its ease of access. Over the time spent writing the last blog In Defense of Static Testing, I grew to understand the benefits of testing with that approach. Now I seek to learn why dynamic testing may not be as “easy” as I once understood it to be.

One lesson I learned from the previous reading on static testing was the idea of ‘time and place’. Both testing methods are to be used under certain circumstances, rather than interchangeably. The blog post, Dynamic Testing, written by Swati Twade brings up this very idea. Twade states that due to dynamic testing’s cost, it ought to be used in effective ways. Furthermore, she warns that if dynamic testing is not used enough during the early stages of development, then there will be much more costly issues down the line. Here a certain balance must be found. The development team must use dynamic testing sparingly to reduce costs, yet must use it frequently enough to prevent larger issues from forming during the final stages of production. In these situations, static testing may be appropriate, as between dynamic testing intervals the development team can review the code and documentation to ensure that all aspects of the program are meeting their specifications. Naturally, if the team was only focused on these two aspects, then static testing could help in minimizing the use of dynamic testing however, dynamic testing captures much more than the code. According to Twade’s definition of dynamic testing, it seeks to capture both errors during the program’s runtime and how the execution of the software affects the hardware. These two focuses of testing cannot be captured by static testing, and require resources to use dynamic testing.

Through this reading, I’ve slowly begun to understand why both dynamic and static tests must be used under certain circumstances. Before researching this topic, I thought the two could be used interchangeably, without considering the resources it takes to conduct each test. Furthermore, each test focuses on reviewing specific content. Dynamic testing places high priority how on the program behaves once executed, meanwhile static testing places its priority on both the source code and documentation. Using these tests interchangeably without first understanding the conditions they work most effectively under will yield less than successful findings. Ultimately between these two blog posts, I have reinforced my knowledge of the testing processes, and have learned under what circumstances each thrives in.

-AG

Link to Original Post:

https://www.educba.com/dynamic-testing

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

Recently in our course, we began an exercise in which all groups utilized static testing to find errors within a program we did not write. During this exercise, I could only think, “This would be so much easier if we could just run the code”. Rather than settling into this rut of compliance with instruction instead, I sought to find what makes static testing such a valuable approach.

Static testing is the approach to debugging where a developer (or group of developers), views the source code of a program and its related documentation. This is to find errors ranging from minor inconsistencies in naming conventions to bugs that will cause the program to break. Since static testing does not require the program to execute, developers can review the code and find errors while the compiler, among other tools, is being developed. Furthermore, all developers should be familiar with the language of the tested program, so the ‘barrier of entry’ is much lower than that of using new software to test/debug. Static testing when done in a group, can help question and apply design philosophies to the tested program. This not only helps reshape the program in the team’s ideal image but may also help developers within the group see how this design philosophy is applied.

The article What Is Static Testing, by Alexander S. Gillis, helps expand upon these aforementioned points in his work. What I found most interesting in this article was how he divides static testing into two approaches: review and analysis. Static review focuses mostly on documentation going over design, specifications, system requirements, etc. Static analysis focuses on the source code by finding errors within the structure and logic of the program. It’s important to note that both of these processes can be automated. Additionally, these types of testing, review and analysis, benefit most when used together and should not be a substitute for another. 

When done on a smaller scale, I can understand the importance of Static testing as it allows the developer to catch fundamental issues in logic or smaller bugs much earlier in the development process of the program. However, static testing may become much more convoluted as the program grows in scale. One issue that may stem from statically testing a larger program is the level of abstraction. If the code is poorly documented, or the intent of the program is unclear, then having a team review it may not be as effective. Ultimately static testing is most efficient when a team of developers understand most if not all aspects of the program, and are already familiar with both the documentation and code. If done manually, this requires much less resources than dynamic testing, allowing those resources to be used in other areas of production.

-AG

Link to Original Post:

https://www.techtarget.com/searchsoftwarequality/definition/static-testing

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

Hello my name is Andrew George and I am a student at Worcester State. Currently I am a Junior and nearly at the finish of my academic program, that being Computer Science. The road to reaching this point has been a long one, however through my struggling I’ve gained insight that I would have otherwise lacked. I speak about my academic progression here (in my original introduction post), so if you are interested in how I’ve reached this point you may read that attached blog post.

Within the three months of last semester I’ve learned so much more about Computer Science, and frankly it was both eye-opening and relieving. Up to this point my only experience with CompSci was the programming aspect of it. While yes programming is completely fundamental, I was craving something more from my studies. Fortunately this hunger was satiated by three of my classes last semester.

The first was a Computer Architecture class, which provided deep analyses on how hardware processes user input, and what that input looks like with machine language. Overall I found this to be the most fascinating of my courses thus far as the concepts we were learning helped click in place with information I’ve learned outside of school. I even found myself working with ‘virtual memory’ through increasing the maximum page size of my PC’s memory.

The next of these classes was a Database Design course. My experience with databases was little to none prior to entering this class. The closest experience I had was working with pseudo big data sets in my AP Computer Science class many years back in high school, which even that didn’t explain much. Needless to say everything I was learning in this course was completely new to me. I found that working with SQL was a nice change of pace, as I primarily only worked with Object Oriented Languages up until that point. My greatest accomplishment from that course was creating my final project around a java program which allowed integration from a database that I created. While yes the Java part of the project did need more time to finish, I was incredibly impressed with my progress and the product.

The last new course I took was a Software Management course, which I had little to no idea what to expect from it. Despite having little initial expectations for the course, I was able to take away many valuable lessons (and tools) from the course. I think taking this course was imperative for preparing me for working in the industry, as it familiarized me with both the tools and processes teams work with. Some content was familiar such as Agile, as I learned the basics of it at a previous college, but other topics such as repositories were completely new. Most topics covered in this course help serve as the glue to keep team-based projects together.

With all these classes considered I had a really effective previous semester in terms of learning new things. It taught me a very important lesson that was ‘maybe it’s important to step away from the compiler every now and then’. I could’ve used the time spent in these classes to focus on my direct coding skill, but instead I learned that will come with time. It’s very important to learn about Computer Science as a whole, rather than pin-holing my focus into ‘just coding’.

Until Next Time

– AG

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