This week i chose to write about the article Restest Vs Regression Testing – How much Regression Testers Should be Doing? by Swati S.

The article begins by defining both Retesting and Regression Testing, this was especially helpful since i am new to all forms of Testing.

Retesting was defined simply as testing again, “the reason does not matter(Swati 1)”. The reason could be as simple as you were not paying attention the first time that the test was run.

Regression Testing is a little bit more complicated. The article gave an example that i believe beautifully illustrates it’s function. “Imagine yourself making a block tower, by adding one block over the other. You don’t take the time to reinforce or strengthen the base. It won’t be long before the tower crashes, isn’t it?(Swati 1)”. It is based on the idea that software continues to grow and as you continue to release updates it is important to go back and test the base of your software to make sure it is still stable. This is a version of retesting, the only thing is that there is a specific reason this time. The reason being to make sure updates to the software have not made any “before working functionality unstable”.

Before a Regression Testing is implemented it is important to do a “Regression Analysis” in order to understand how much testing needs to be done. This is something that is application specific, depending on what is being updated perhaps you do not need to test all the way back to the bottom block but only half way down. According to the article there are three important factors when doing a “Regression Analysis’:

• “Nature of the change”
• “Relationship/impact of the change on the current system/feature”
• “Availability time and resources”

Based on those above factors and the decisions that the developers make they can do a few different types of regression tests:

• Unit Regression – Only test the area of the application that has been modified.
• Partial Regression – Test the are of the application that has been modified and all those areas that interact with that area.
• Full Regression – Retest the entire application regardless of where the actual change was done.

Essentially the difference between the two types of testing is that Regression Testing is only implemented when there is a change to the application. Yes it is a version or Retesting but it is different. Retesting can be done without a change, for any reason the developer sees necessary.

Here are some other articles that i found interesting:

http://www.mkltesthead.com/2016/10/the-humans-in-machine-talking-machine.html

https://www.stickyminds.com/better-software-magazine-article/evolution-software-monetization

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

This week i decided to write a post regarding the article, Testing on the Toilet: What Makes a Good End-to-End Test by Adam Bender.

Of course being fairly new to the software testing industry, End-to-End testing was a new concept to me, although it seemed fairly simple to understand what it would entail. This is actually true, End-to-End tests are simply that, a test that tests an entire suite of software from one end to the other, while treating much of the code in between as a black box. This is especially relevant because i am currently working on black box testing in general and understanding the real world applications of that really helps.

It is true that the concept of End-to-End testing is simple, however the actual work that goes into making and maintaining sustainable End-to-End tests is not. There are a great deal of benefits that outweigh the costs in the right situations. An End-to-End test can “provide confidence about the health of your system in a near production state(Bender 1)”. Again in the right situations this can be an amazing advantage, and deploying the system becomes less of a nightmare.

End-to-End tests are more slow and more expensive than unit or integration testing can be, it is due to this that it is used to test things that those tests would not be able to well. The examples that the article gives are “resource allocation, concurrency issues, and API compatibility(Bender 2)”.

As i myself am not an expert and am just learning of End-to-End testing i thought it would be useful to bullet the author’s main points regarding the issue.

• “For each important use case, there should be one corresponding end-to-end test”
• “allocate at least one week a quarter per test to keep your end-to-end tests stable”
• “Focus your efforts on verifying overall system behavior instead of specific implementation details”
• “Make your end-to-end test easy to debug”
• “It may be more difficult to make an end-to-end test fully hermetic

In case you were wondering, hermetic means complete and airtight(i know i was).

Here are a few other articles that i found to be interesting:

https://gojko.net/2016/09/18/whats-next-agile/

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

Serverless architectures: game-changer or a recycled fad? by Gojko Adzic.

This article discusses something that i had not necessarily heard of before this point, or at least not in a formal sense, “serverless architectures”. Much like noSQL databases the name can be a bit misleading, meaning that there are in fact servers involved, perhaps even more than a normal “server architecture”. Serverless actually refers to the fact that you do not have to maintain your own server hardware, nor do you have to rent racks at a traditional data center.

In order to understand why this new idea is such a big deal i will attempt to explain the more traditional architecture, from there i can elaborate on the incentives of going “serverless”. Gojko talks about the most important thing when considering server architecture is “keeping the hardware busy”. This was to get the most bang for their buck in a way. In order to accomplish this they would bundle a number of processes together to make the most out of the hardware. Of course this meant at some points bundling things that shouldn’t necessarily be bundled for purely financial reasons. He goes on to discuss how the introduction of cloud computing did not address this issue and the need to bundle remained the same. This caused situations where you could have a bug in a rarely used process that was bundled with more important ones, and that bug caused every one to be held up.

The “serverless” architecture changed all of that. The idea is based on the “container farm idea”. Although i am still working to completely understand the implementation the financial aspects are quite obvious. Instead of reserving computing capacity you only need to pay for the time that a process spends executing. This means that it doesn’t matter if a process is rarely executed since we only pay when it does, instead of having to allocate space for that process regardless. Which then means that there is no need top bundle eliminating a large deal of the headaches that go along with that.

It was quite an interesting article and i suggest it to anyone who may even be slightly interested, the author does an amazing job of explaining the technical details.

Other Interesting Articles:

http://qahiccupps.blogspot.com/2016/09/giving-back.html

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

Hello, my name is Joshua Tassone. I am currently a Senior Computer Science major with a concentration in software development at Worcester State University. I am creating this blog to document and demonstrate my understanding of various Computer Science topics.

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