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.

For this weeks blog for the topic Quality Assurance and Testing, I read an article titled “5 Reasons you are wasting your testing time.” That is not to say that testing is a waste of time, but rather as the first sentence says, “Not all our testing time is spent effectively.”

The blog goes on to list the five reasons that a programmer might be using their testing time ineffectively, which are as follows: (1) “You don’t set a clear goal for your testing task;” (2) “You don’t understand the value of the feature for your End User;” (3) “You do not keep track of what you tested, your findings and the other ideas you got while testing;” (4) “You do not consult existing information to get insights into your test;” And (5) “You do not do post-test reviews and feedback sessions with your peers.”

These are all straightforward ideas, but I’m sure most programmers testing their code have fallen into several of these, if not all. This list provides a framework to avoid these pitfalls. In class, we have been going over ways to be more methodical when testing. This list is a little more elementary than what we have covered, but it is good information to use nonetheless.

A key takeaway is to treat testing more like a science than throwing it together willy-nilly. There has to be a method to the madness. You have to know what you want the test to do. You should have a clear understanding what the end product should look like and how it should look to the end user.

The final section in the article said testing isn’t “Rocket Science, but it is not a trivial task either.” It should not be seen as something that could be done by almost everyone, which is a common belief in the industry. This is not true. It is an important job that should be done right. It requires being very organized and staying on top of things. There are many things that can be done haphazardly. Testing is not one of them.

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

This week’s topic has to do with behavior-driven development, which a strategy of software development that focuses on the communicating narrative between developers so as to ensure that all members understand the specifications and other requirements of a program. I found an insightful article at the following website: https://airbrake.io/blog/software-design/behavior-driven-development. This blog post is one of a few in a series explaining different development techniques that work together as part of the software development life cycle.

As explained in the article, behavior-driven development, or BDD, works hand-in-hand with other strategies, such as test-driven development, which entails the execution of a failing test and then subsequently writing a minimum amount of code in order to pass the test. The BDD of tests becomes different from this technique when it relies more on the desired behavior of the program, rather than simply writing initially failing tests for all parts of the program, as utilized with test-driven development. BDD defines behavior specifications with user stories that outline various scenarios for the program to be executed or tested. These stories take on a narrative tone that states who and what are involved in each scenario, as well as the conditions that must be met in order for the scenarios to be successfully implemented. By using a common language understood and easily communicated by everyone on a development team, members can easily collaborate to define these specifications and perform tests based on the definitions given with the user stories.

This topic stuck out to me because it somewhat combined what I have been learning in both my Software Design and Software Testing courses this semester. This post discusses different methods of designing programs and their tests, and I thought that BDD clearly incorporated both, with the description of designing the behavior specifications to be met, as well as the concept of testing these specifications. We’ve somewhat been starting to take on both of these roles in the classroom by determining the purpose and desired functions of our programs, and then performing tests to ensure that the functions are working successfully. While we haven’t written out user stories to more specifically outline the behaviors, I think that this process is more implicit for us at this point.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

https://abstracta.us/blog/software-testing/test-automation-patterns-and-good-practices/

This blog post discusses good practices to use with test automation. Automating tests can save time and decrease the amount of work that has to be done. Following these practices will help ensure that you get the most value out of automation.

Test Code Review

• All levels of testing should be reviewed to examine their quality. This will help the tester discover bad practices or mismatches in the tests.

Apply Assertions

• Assertions should be used to identify problems.
• An assertion that’s too generic can create false negatives and false positives, so pay special attention in the definition of assertions.

Behavior-Driven Development (BDD)

• A common language should be created for the business and engineers to be used as a starting point for development and testing.
• User stories are defined and used as input for test cases.
• BDD gives developers clear specifications and brings testability to a system.

Page Object Pattern for UI Testing

• The use of design patterns increases scalability and maintainability
• The page object pattern allows you to reuse knowledge of the structure of an application while having a minimal impact on tests.
• This pattern strengthens tests by decoupling the structure of the user interface from the test code

Data-Driven Testing

• With data-driven testing, automated tests are parameterized so that the same steps can be carried out with diverse amounts of test data
• Adding data to the file creates new test cases

Parallel Execution of Tests

• Using parallel execution options like Selenium will reduce testing time by running several tests at the same time.

I thought this blog was very interesting. While I have learned a little about test automation I haven’t used it enough to learn the best practices for it. It is important to learn these practices because the whole point of automation is to save time, and if you don’t do it correctly you will end up spending more time trying to fix your errors.

I thought the most interesting part of this post was the section on the page object pattern. This is a design pattern that I’ve never heard of. It seems to be very useful because it helps prevent you from breaking your tests when you change your code. This is a topic that I would like to learn more about and will keep in mind when I work with automated testing. Overall I thought this was a useful and well-written blog post.

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