https://www.360logica.com/blog/difference-between-static-testing-and-dynamic-testing/

            While trying to gain more information on Static and Dynamic Testing, I found an interesting blog post that pit the two against each other. It started by explaining that Static Testing is used to test things related to the actual code within a product. The post further says that Static testing is where developers check code to find faults. This testing can be completed without any current applications. The post then defines Dynamic Testing as testing the application with valid entries and checking their outcomes against an expected result. After explaining the two terms, it stated the major differences between them like how Static testing is a preventative measure while dynamic testing is used in solutions. The post explains that Static testing is therefore more cost-effective and provide greater benefits when compared to Dynamic testing. Dynamic testing can take longer as it tests each case separately while Static testing can cover more in a shorter amount of time. The blog post goes on to explain that since Static testing is done in a verification stage, the code can be looked at without any execution. This differs from the Dynamic testing which is done in a validation stage where the code is executed and tested without being looked at.

            I chose this article because I found myself interested in the difference between Static and Dynamic Testing. I understood these terms in a programming sense, but I didn’t quite grasp the concept in a testing setting. My initial curiosity was filled with a sense of what these different testing types meant. I found the post very informative on what each testing type did and how they worked. I can understand that Static testing is better overall because of its speed and benefits but I also understood how Dynamic testing works as well. I enjoyed how the post used multiple examples when explaining these terms because it allowed me to get a better understanding as to the context of the definition. This blog post has taught me that Static testing is the go to style for testing as it is cost-effective and overall better. The most interesting part about this post was the different benefits it stated between Static and Dynamic testing as it gave a better insight to how they both worked.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

While sifting through blogs trying to determine which might be a good read, there was one in particular that caught my eye. We all know as developers we love to start new side projects and never see it to completion am I right? Well that’s true in my case anyway. As I read through Joel Spolsky’s article, “Developers’ side projects”, I learned some fascinating news that I shall keep in mind for the near future.

In the opening paragraph Joel talks about some kind of proprietary invention agreement that most developers sign when working for an employer. Basically what this agreement states is that whatever the developer comes up with or invents while employed by said company will belong to said company. Yes that may seem silly but to the company it is very profitable. Say you are the employer and one of your developers create an app that gets 1 billion users over night. You would want the rights to this app to maximize all profits. Smart.

This article was very interesting because it opens your eyes as a young developer waiting to join the real world. Never did I ever think that once I would be employed as a developer that a company MAY have the rights to the work that I do in my spare time. Spolsky talks about legality issues that might come about if you were to create a product while employed under a company and what could happen if you try to branch away to form your own competitive company. He then states that the only way for independence is to be independent.

Many questions come to mind after reading this article. Should I be afraid to create content once employed? Does every employer attempt to own the rights to every employees’ work? For one, I do agree that there is ease of mind working independently but sometimes that’s not always the best case. Moving forward I will make sure to read contracts thoroughly before I sign anything!

Don’t forget to share and follow

From the blog CS@Worcester – Life in the Field of Computer Science by iharrynguyen and used with permission of the author. All other rights reserved by the author.

This article is very interesting in that it offers a new perspective on the importance of a front-end user perspective first type of testing scheme. It starts off by explaining to us the normal pyramid testing scheme and how at the tip of the pyramid is where the user perspective and UI is. This article is contrary to all of those other testing pyramids because, by how this article explains it, the top of the pyramid is just as, if not MORE important than the lower levels. Typically in a Test Automation Pyramid you have Unit or unit tests at the bottom (long base), then you have your service tests (integration, component, and api tests: middle slice), and finally at the top you have your user interface and ideally what the user sees. Knowing that, this article explains how the pyramid should actually be flipped upside-down, having the user perspective be of larger importance. You would still have your unit tests and integration on the bottom and middle, it just wouldn’t be as large. This is the point the article is trying to make, “Just as a triangle has more area in its lower part than its upper part, so you should make more automated tests on lower levels than higher levels.” This is not an argument; this is not reasoning. Nothing in the nature of a triangle tells us how it relates to technology problems. It’s simply a shape that matches an assertion that the authors wanted to make. It’s semiotics with weak semantics.” Pretty much, the article is saying that the shape of the triangle in which these schemes are based on don’t really carry that much weight into technological problems.

My reaction to this article is that I agree with what they are describing here. Similarly to the article, I also think that when you have a project, each layer above the next can often be a lot more complex than compared to the lower levels. This in turn can also even carry a higher risk. The model the author is talking about is the Round Earth model. The round Earth model states that you should think of technology as concentric spheres and that each layer can increase dramatically. This article made me open my eyes and made a lot more sense of how certain models don’t really understand what they even stand for.

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

For this week, I read an article called “JUnit Best Practices” by Kyle Blaney. The article talks about how to use JUnit in the most efficient way and get the most out of the tests. The two main goals of unit testing according to the article are making sure tests are “extremely fast” and “extremely reliable”, meaning your tests should run as fast as possible while also producing correct, reliable results. The article then goes on to point out a number of different important practices when doing unit tests. Some of these practices are ensuring unit tests are running completely in-memory (tests should not read from the filesystem), not skipping unit tests, aiming to have each test only test one thing, using strong assertions, and much more.

I thought the article was extremely informational and very useful. We will be looking at unit testing in CS 443 this semester and having this information should help me produce better unit tests, whether they be self-written or just by using JUnit in the most efficient ways possible. I found it useful that the article mentioned doing things such as using the strongest assertions possible and making sure your tests are reliable. Having strong assertions will mean that if the unit test passes your assertion, then your code should hold up in the long run. However, none of this matters if your tests are not reliable and do not produce correct results. So making sure your tests are reliable is a huge part of the testing process. With the combination of correct, fast tests and strong assertions, your unit tests should be very strong. I like this idea of having strong unit tests because if my code can get through the strongest, hardest tests then my code should be very strong overall.

I agree with all the points made in the article, and I hope to use the information presented to me in the article in the future when I go to do unit testing. I would like to see how applicable these practices are in real life testing and see if they all hold up like they are supposed to. I am looking forward to unit testing because I now know some very important aspects to look out for.

Here’s the link: http://www.kyleblaney.com/junit-best-practices/

From the blog CS@Worcester – The Average CS Student by Nathan Posterro and used with permission of the author. All other rights reserved by the author.

In this episode (number 219) of “Test Talks,” I was able to hear Shailesh Rao’s insight into having quality software. He compared it to a “paper-free office” or a “stress-free life,” both worthy goals, but are hard to achieve. They can be strived towards, but it is near impossible to get it 100%.

He brought up the issues that bad software can pose to potentially millions of users. Bad software can open the doors to hackers, who might be able to take down websites like Twitter or Reddit. Also, it might stop airlines from being able to function — an annoyance to most, but Mr. Rao asked, “what if there was time-sensitive and lifesaving medicine onboard?”

I found this podcast brought up some aspects that I had not thought of before when if comes to quality assurance. I suppose that I’ve thought about the various things he brought up, but as a consumer and never as a creator of the software.

A very thought-provoking topic brought up was the fickleness of consumers. They don’t have the patience to put up with a buggy app. They will move on to the next thing. It is easier than ever to launch a software project to a very wide audience, and it’s become apparent to me that it should be done right the first time around because customers don’t always give a product that flopped a second chance.

Another point brought up that will affect the way I think about testing and quality control is that you should test for all possibilities or you might not know the market you missed. People often say to themselves “it won’t happen to me,” and think their software will not be downloaded millions of times, but if they didn’t prepare for those conditions, they won’t get that chance.

The core message that was hammered home was that developers should have quality at every step. With as complicated software can be, it is extremely difficult to have it be truly bug-free, but it is possible, and we should always strive to be as close to it as we can.

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

http://thetesteye.com/blog/page/3/?utm_source=fuel&utm_medium=referral&utm_campaign=lrfuel

I’ve been delving into the writings of Rikard Edgren, a software tester who writes blog posts on thetesteye.com. I think its useful to see what professionals think works well, so today I’m talking about his post titled “ISO 29119 – a benevolent start” which I’ve provided the link to above. Although this post was written some time ago, I believe it provides general foundations of what a test system should include.

He first states that he tries to see the good in a system first, so a lot of the writing that follows is of appreciation for what this system does right in his opinion and provides suggestions for concepts that should be included in further systems. Edgren breaks down his thoughts about the testing standard into three parts, concepts and definitions, test processes, and test documentation.

Regarding the definitions of the system, Edgren compliments the simplistic terminology used in ISO 29119. Compared to other testing standards, this one is more flexible while also limiting multi-faceted words. He also appreciates the use of Diverse Half-Measures in order to cover all the bases in terms of test coverage.

The test process for ISO 29119 prioritizes testing strategy, which gives way to multiple advantages. For instance, it ensures that important goals are followed, met, and easily communicated for the future. The feedback is also more detailed rather than just a simple pass/fail. Additionally, this is a hopeful sight for test standards to come, Edgren is excited that testing strategy is starting to become more common and more of a priority going forward.

Finally, Edgren praises certain aspects of the test documentation, which incorporates concepts from both traditional and agile projects. The importance of this being that previous documentation concepts don’t have to be set in stone for future projects, breaking traditions is sometimes beneficial. Edgren makes the point that the documentation should also have the stakeholders in mind, so diagrams and simple explanations could go a long way. Bridging the gap between tester and employer is vital, it is very important that both parties are on the same page regarding the results of testing.

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