Greetings reader!

In today’s blog,  I will be discussing the differences between black box and white box testing. This blog will briefly explain the benefits for each test, as well as point out their distinct features. I will also be sharing my analysis of QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article from which I read. Without any further introduction, let’s begin.

Black box testing (BBT) is a testing method in which there is no access to the source code or the internal structure of software. The main goal of BBT is to check to see if everything works well from the view of a user.  Black box testing focuses on incorrect or missing functions, data structures errors, any graphical user interface errors, faulty software performance, and for any control flow errors.

Some advantages of black box testing are as follows. First, the tester can start designing test cases just after the specification is ready. Secondly, tests preparation time is short, and finally, there is no need for a tester to know the programming language of the application. The disadvantages of black-box testing: it is hard to design test cases without a specification, only some paths are covered , and it is impossible to to see what part of the code can cause a problem in future.

White-box testing (WBT) is a testing method where there is access to the source code and internal structure of the software (opposed to BBT). This testing type insinutates that a tester knows which code line is called for each function. It allows the tester to better choose an entry data set and to check errors and exceptions efficiently. White-box Testing focuses on bad code writing, conditional loops, the working flow of the code, and memory leaks.

Advantages of white-box testing are: there is no need to wait for the GUI application, it can conduct more detailed testing with more cases covered, and it can predict the potential problems in the software. The disadvantages of white-box testing is that a tester must know the programming language of the software, it can take much more time than other methods, and it can be expensive.

To conclude, there are advantages and disadvantages to both methods of testing, so there is none that is “better” than the other. They are both necessary and complementary.  The QATestLab’s-“Difference Between White Box, Black Box, and Gray Box Testing” article that I read was extremely informative and very easy to comprehend. I greatly recommend their articles to expand your computer science knowledge.

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

In his post “The Psychology of Design”, Blogger Jon Yablonski writing for the blog “A List Apart”, discusses the importance of software developers to understand some principles about heuristic psychology that are helpful in improving user experiences and overall design.

Yablonski begins by explaining the concept of Hick’s law, the notion that the amount of time it takes a user to respond to a situation depends on the volume of information the person is presented with. He uses the example of a television remote, and how as the number and complexity of devises increases, the more confusing the remote controls become. But by abstracting the features to those only absolutely necessary, we’re able to create a much more user friendly product, as demonstrated by the apple TV remotes.

The author also goes into the idea of Miller’s law, which is the assumption that people can commit to memory seven plus or minus two different objects. Yablonski goes into strategies designers have used to work around this inconvenience; namely chunking. Chunking is used to break up large or complicated amount of information into chunks, like the digits in a phone number, or breaking up a news page in discrete parts.

Finally, Yablonski explains Jakob’s law, that people tend to form their expectations based on previous models that we have learned. For example, most video game controllers tend to have a similar arrangements of inputs. This serves to lower the learning curve required in adopting a newer model.

Personally I think heuristic psychology is very useful in the area of software development. Understanding how our minds process information is an integral source of data to help us achieve our goals of creating efficient, user friendly software. By applying smart strategies like design patterns to help implementation, combined by the insight of psychology, we should be able to handle a broad range of situations and have a good array of tools to help solve the problem.

From the blog CS@Worcester – Bit by Bit by rdentremont58 and used with permission of the author. All other rights reserved by the author.

In our Software Construction class, we have been going over the design patterns used by developers everywhere. Our last test covered all of the design patterns, and after I got the test back, I decided to research more into the design patterns topic and I found the article, “How to make the perfect Singleton?” I found this article whilst browsing the internet looking for other articles, and this one jumped out at me.

The article starts off by discussing the purpose of the Singleton. I liked this section of the article because it provided some specific examples of when this pattern would and should be used. For example, it said it is “used when you have to control resources” (Patel), and it is used in database connections or sockets.

The article then goes on to show the reader how to create the perfect Singleton. It explains how to initialize it, and it explains how to make the class thread, reflection, and serialization safe. I actually didn’t know what it meant to make a class thread, reflection, and serialization safe until I read this article.

The interesting part of this article is how many new terms it introduced me to. The volatile keyword was brought up in this article, and I personally haven’t seen this keyword anywhere in my few years at Worcester State. The volatile modifier makes it so that the write of a certain variable is guaranteed to happen before the read of said variable. I also learned that making classes thread safe is essential for any “multi-threaded application environment” (Patel). They use Android applications as an example. I also learned how to make my Singleton class safe from Serialization, which is simply just preventing others from creating new instances by serializing and deserializing the singleton. I also learned how to prevent Singleton failure due to reflection. This was also very simple as you just have to throw a run-time exception in the constructor.

This article was a great read and contained a lot of useful information. I plan on using this information that I obtained in the future when I create more classes using the singleton pattern.

Link: https://medium.com/exploring-code/how-to-make-the-perfect-singleton-de6b951dfdb0

From the blog CS@Worcester – My Life in Comp Sci by Tyler Rego and used with permission of the author. All other rights reserved by the author.

As I take another step towards my journey in software C.D.A. I dive into Design Pattern, where I will be focusing on one of the patterns known as Adapter pattern. While searching in the internet I ran across a blog called Design Pattern Explained – Adapter Pattern with Code Example by Thorben Janssen.  This blog talks about Adapter Pattern which actually is one of the many Design Pattern type. This topic is chosen because it was one of the pattern talked about in my Software Construction, Design, and Architecture class. Since the blog by Thorben Janssen talks about the topic related to a class discuss topic, I choose this blog to write about it and summarize its content in my blog. The content in the blog is about the Adapter Pattern of Design Pattern. I will give a summary of what the blog was about and what it explained from my point of view and understanding.

According to Thorben Janssen research on Adapter Pattern, there are two different version of it. The type that uses inheritance and the type that uses composition.

What is Adapter pattern?

Also known as wrapper, the Adapter Pattern is a software design patter that allows the interfaces of an existing class to be used as another interface. In software development the adapter pattern has the same concept of those in real life, for example phone adapters.  Meaning adapter patter are similar to phone power adapters in the sense that one adapter can be used with many different USB devices cable. Say your at your friends house and you have an i-phone USB charger cable but no power adapter, and lets say your friend owns an android and only has an android charger. He can unplug is USB android cable from his power adapter and hand you his power adapter for you to use with your USB i-phone cable so you’ll be able to charge your phone. An adapter is convenient because it enables incompatible objects or devices to be used for the same purpose. The adapter pattern is also convenient because it allows you to use existing class or interface by introducing a new class that adapts between classes and interface without changing the existing class that is known as an adapter class.

In the blog “Design Patterns Explained – Adapter Pattern with Code Example” by Thorben Janssen he gives an applied example of the adapter pattern he referrers it as Brewing Coffee. I highly suggest you to click on the title so you can check out the example and see how he implements the adapter. I will end my blog here and let you do your own research on adapter pattern.

Thank you for your time. This has been YessyMer in the World Of Computer Science, until next time.

From the blog cs@Worcester – YessyMer In the world of Computer Science by yesmercedes and used with permission of the author. All other rights reserved by the author.

For today’s blog I am writing about agile testing. I found this blog on agile testing called “A Coach Guide to Agile Testing”. The blog talks about the different types of agile testing and the different types of teams/groups/personalities that use agile testing in different ways. The article mentions that people who use traditional ways of testing usually do not like agile testing because they consider it a threat to their job, which is to identify discrepancies between the working system and the specifications. This is different from agile because agile does not have specification documents that are detailed enough to help the tester do their job.  Something I found interesting about this article was when they were talking about the traditional testers and their approach of “follow specifications and report how the system differs from these specifications”. The article says that checking to see how closely the program follows the specifications does not actually say anything about the quality of the program. I think this point really hit home, because you can make a program that follows the specifications to a tee, and it can still be a poorly designed or poorly running program.

For an example, say you are building a program to manage someones bank account. You would need methods to deposit, withdraw, check balance, transfer money, etc. Now let us say the only specification for the program is that it compiles and runs. We could write a program that compiles and runs and in the sense of traditional software testing, we have a passing program. However, what if the method for deposit didn’t actually add money into the account, or the method for withdraw added money instead of taking it out? According to traditional software testing we have a functional program, when in reality we know our program does not do what it is supposed to. This is where agile testing comes in handy. Agile testing will test every method in our program (not just the specifications) to make sure that our methods actually do what they are supposed to. This is why I like agile testing, and try to do it in all my programs. It is a good way to assure you have a quality product that functions as designed and has also been tested and passed. I hope to continue using agile testing in my future programs and reading this article has given me some new tips and tricks to think of when doing agile testing.

Here’s the link: http://www.softwaretestingmagazine.com/knowledge/a-coach-guide-to-agile-testing/

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.

https://www.imaginarycloud.com/blog/test-driven-development/

          This week I’ve decided to write about a blog post that talked about Test-Driven Development (TDD) and its benefits as well as its drawbacks. The post begins by explaining that TDD is the writing of automated tests before actually writing a feature for the product. It gives an example using social networking software and how a coder would first write an automated test and then write the minimum amount of code to pass that test. It uses the “red/green/refactor mantra” to show if tests have passed or failed. The post goes into the benefits of TDD by explaining that sometimes new code can break previous features. This is similar to regressions in the software development path. Using TDD, you are able to test the code before integrating it into the system to see if it will actually work. The blog explains that even though TDD can double check a new feature integration using automated tests, these tests have their drawbacks. One drawback that the post focused on was the overall cost of these automated tests that increased the cost of development cycles compared to those that continue on without them. It continues to say that automated tests aren’t a requirement for every single feature since there is no formal test plan.

            I chose this article because I had read about Behavior-Driven Development on my last blog post and it was constantly compared to Test-Driven Development. I wanted to gain a better understanding as to what TDD was and why it was compared to BDD. I found that this content answered those questions very well by explaining what TDD was while giving its strengths and weaknesses. I enjoyed how the post used examples from software development tracks in real situations to explain this concept. It allowed me to better understand why it is a safer system from new feature integration. I was able to grasp an understanding of when to use this development tactic while also learning that there are times to be cost-efficient as well. I found the parts that talked about how much is really needed with TDD to ensure cost-efficiency very interesting because it really puts into perspective how important budgeting is. I learned a lot from this blog including what TDD is and when to properly use it. I found that the examples were a great resource to understanding the term within context. This blog is a great source of information about TDD and I found it very interesting.

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