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.

Fundamentally Agile is a very flexible and effective methodology that allows teams to continuously provide a working model of their respective project. When compared to the Waterfall methodology, Agile may seem like a flawless approach to team development and management, however this comparison to Waterfall fails to capture Agile’s flaws. Ideally, by understanding Agile’s feats and flaws, teams can make the most of the methodology.

Agile works best when all members deliver their respective parts of the project on time. This creates pressure on the developers to reach that time quota, as a result they may be more inclined to ‘cut corners’ so to speak while developing their part. Creating faulty code (or a general product) may lead to future issues, which would likely lead to sprint backlog bloat, so the development methodology must balance the value of the work being created and the time being spent to create the aforementioned work.

On the topic of time management, Agile does not offer much flexibility while creating sprints. Sprint length is determined towards the beginning of development, this itself is an issue as developers lack the foresight to allocate enough time in a sprint to take on larger-scale projects. Sprints encourage segments of digestible work for the developer, as Bryar and Carr mention in the article Have We Taken Agile Too Far?, “rather than take the time and uncertainty to develop a new capability, they go with the skills they currently have” (Bryar & Carr). Due to time constraints, developers settle with what they’re most comfortable with, as opposed to seeking potentially more effective solutions. This damages the final product as it heavily depends on the developers’ current experience and does not promote research.

One solution to this issue would be shifting to the Epic-model. Here developers won’t face an imminent time constraint that sprints impose, rather they will take a task (a story) and aim to complete it before the team moves on to the next step (the epic). This type of work structuring does not intrinsically have a set time limit but can be integrated within the Agile methodology. The goal of combining these two types of work structuring is to create a process where developers can have assigned tasks that are components of a larger task, AND to have a flexible time limit before moving on to the ‘larger task’. Another solution would be to fundamentally change how Agile works within a team. Currently, there are very few exceptions to change the duration of a sprint period, so to shift to a variable duration of each sprint would change how Agile works. A downside of doing this would be removing the consistency between sprints, but the benefit of that is that developers may be able to take on more work or do more research into their respective tasks before delivering their first working model. As a development methodology Agile should benefit the developers, therefore shifting from a rigid (preset) working period may increase the quality of work.

-AG

Source:

https://hbr.org/2021/04/have-we-taken-agile-too-far

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 attending my previous university, Becker College, I was introduced to Scrum, Agile, and Kanban with very surface-level information. As we progressed through this current semester, my knowledge of both Scrum and Agile increased, with my knowledge of Kanban tailing behind. So I seek to answer the question of ‘What is Kanban’?

Kanban, similar to Scrum, is a type of work structuring that places importance on visual responsiveness and flexibility. Scrum and Agile run on the idea of sprints, which Kanban does not naturally have, but rather it opts to focus on a time cycle. Time cycles measure how long it will take a single task to move through all stages of development. A potential flaw here would be that if the team agrees upon many stages of development, such as adding multiple testing stages, then the average time cycle will take longer. By not imposing a static time limit, such as those provided by Sprint structuring, it encourages developers to put as much effort as possible into their respective task(s). The key to an efficient team would be to optimize these time cycles and get their average down to shorter periods while maintaining the quality of work.

Within the development process, each task is represented by a card and will move through the Kanban board as it advances in the development cycle. This board helps create the visual responsiveness that Scrum lacks. If a card is stuck in one phase of development, then fellow developers may take notice and help push it to the next stage. While visual responsiveness does help to grant a sense of worth seeing tasks being completed, it best serves as a collaborative tool between developers which further increases team efficiency.

Kanban would be my preferred choice of work structuring as I find that the Kanban board is an incredibly useful tool to both track and collaborate with your team. However, one glaring issue I do have with Kanban is the lack of a direct CD (continuous delivery). Scrum will have the Sprint Review and Retrospective which gives the development team a chance to show their current working model of the project and get suggestions for it. Kanban lacks this dedicated period to show the project and communicate with their partner. This runs the risk of high-effort work being rendered useless as it’s not what their business partner had in mind. Additionally, with the lack of a Retrospective, the team will not have a dedicated period to reflect on their progress and comment on places they may optimize their work. A solution here would be to create sprint-like periods where no work is due, but at the end of the period, developers will have both a review session with their business partner and a retrospective within the team. This increase in general communication will ensure the product will be created effectively and will meet all requested specifications.

-AG

Source:

https://www.atlassian.com/agile/kanban#:~:text=What%20is%20kanban%3F,of%20work%20at%20any%20time.

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

When our class was being introduced to GitLab, and how to post topics on an issue board there were a couple of terms present within the menus that we didn’t go over in class. These terms are story, epic, and initiative, all of which relate to each other. Conveniently all of these terms build off the formers’ progress, and can easily be slotted into a DevOps-esque working environment.

The first of these terms, a story, is what we are most familiar with as it’s another term for an item selected from the Sprint Backlog. A story is a unit of work that can be completed in a one to two-week span. These often come from user feedback, meaning that the product has seen some use outside of development, however stories can originate internally (just like items on a Sprint Backlog). Stories are supposed to be smaller so developers can take multiple during one sprint with the goal being a handful of stories contributing to an epic.

The next term, an epic, is composed of several stories and aims to explain something larger during the development cycle. For example, if you are developing an app that doesn’t have features such as colorblind compatibility, text zoom, and a narrator, then each of these additions could be a story (can be an epic itself depending on the workload). The epic here would be ‘Improving accessibility’.

The final term, an initiative, similar to the former is composed of the prior terms, in this case an initiative is formed of several epics. These run for a minimum of half a year and can continue well past one. These serve to highlight the direction in which the project is aiming to head towards. Continuing the example from the previous term, if we add epics such as ‘Marketing towards non-likely users’ and ‘sign-on bonuses’ it can fit into an initiative that may be ‘increasing user engagement’.

For the purpose of this class, stories are going to be what we encounter the most, with maybe an epic or two depending on the scale of a project. What I’m curious about is whether these terms can be applied to the capstone project course. That course specifically will focus on working on a much larger scale project, so keeping track of tasks via stories/epics/and initiatives could prove to be effective. A reason why I understand these terms not being taught within the course is due to scaling. We focus on learning agile development as it is much more flexible for both smaller and larger projects, meanwhile an epic-based development process may only see great benefits from working on a larger project.

-AG

Source:

https://www.atlassian.com/agile/project-management/epics-stories-themes

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