http://blog.qatestlab.com/2011/03/01/difference-between-white-box-black-box-and-gray-box-testing/

          I found an interesting bog post this week that talked about the differences between White Box, Black Box, and Gray Box Testing. It started with black box testing by explaining that it is an approach where the tester has no access to the source code or any part of the internal software. The basic goal of this testing type is to make sure that inputs and outputs work from the point of view of a normal user. The blog goes on to talk about the main features of this testing type by explaining that the test design is based on the software specification and detects anything from GUI errors to control flow errors. It is a short prep test which helps make the whole process much faster but lacks the needed detail to test individual parts of the software. The blog goes on to talk about white box testing which allows the tester to have access to the source code. This testing allows the tester to know which line of code corresponds with which functionality. This allows more detail for individual tests on code functionality. It allows more detailed testing with the ability to anticipate potential problems but takes more time and can be complex/expensive. As for grey box testing, the blog explains that it is an approach where testers only have a partial understanding of the internal structure. The advantages and disadvantages of this technique are incorporated from the related white and black box testing.

       I chose this article because I remember that we learned about this subject in the beginning of the year. I wanted a better knowledge about the advantages and disadvantages which is what sparked my initial curiosity. I found that this content was really interesting because it explains how testing can be when dealing with different amounts of access to data. I enjoyed how the post explained the types of testing sequentially while also explain how they can be different from each other. I was able to grasp an understanding of these testing types while also understanding the importance and vital role that they play depending on the situation. The most interesting part of the blog post was the grey box testing because it combines the aspects of black and white box testing. It also deals with regression testing and matrix testing which are very important when testing code bits of code at a time. I found that the diagrams used in the post allowed an easier flow to the readings which helped me understand it better. I found the blog to be a great source that summarized and simplified the detailed ideas within the post.

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

https://www.qasymphony.com/blog/test-automation-automated-testing/

          The blog post I wanted to talk about today covers the difference between Test Automation and Automated Testing while also explain new concepts like Continuous Testing. The post starts by explaining that there are two types of automation known as Automated Testing and Test Automation. It defines Automated Testing as the conduction of specifics tests through automation while Test Automation is the automation of tracking and managing different tests. It continues to talk about Test Automation and why it is critical to continuous testing. Continuous testing ensures that the test quality is as high as it can be at all times. Usually tests are completed at the end of the development cycle but now tests are done throughout the development cycle whenever they are needed. However, in the real world, testers need to verify and schedule test cases which means they have to be in communication with other members of the team and the product owner to make sure that the original product requirements are still being met. They must break down these requirements to write the tests and track the progress of each test which can take time. These models make continuous testing a viable option and it works very efficiently but now testers need to think about test management more carefully if they are going to integrate it into development.

        I found this article interesting because of the new concepts it showed me for software development and testing. I enjoyed the enthusiasm this post had for Test Automation and Continuous Testing because it paints these concepts in a light that really makes it seem like this is a new step forward in making any generic development cycle more efficient. The post explained the definitions of these terms clearly and then went into detail about their integration into testing while also explain how that would affect the overall development cycle. The most interesting part of this post was when they explained the pros and cons of this testing integration. I found that the pros of having a more efficient development cycle made sense, but I would never have thought about the amount of work that the testers would have to go through as well to make this work. This showed me that even though the system would ideally work, there is a vital part of communication as always in a development cycle that can help or hurt the process. I found this to be a good source of information to learn about how testing is woven into development and through the explanations, shows the reader that there can always be new ways to make testing more efficient.

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

http://www.discoversdk.com/blog/unit-testing-with-junit

          This week, I found a blog post about Unit Testing, specifically, JUnit. The post began by explaining what Unit Testing is in programming terms and how Junit is a unit testing framework for Java and is tied into Test-Driven Development (TDD). The post explains the features of Junit focusing on how organized and simple it can be compared to other frameworks and testing methods. It specifically compares Junit testing to manual testing showing how tedious manual testing could be. It explains how annotations also work in Junit giving examples such as @Test and @Before while also explaining what they do. It uses real code to show simple tests being completed while also providing and explaining the outputs of each test. The post goes on to talk about the Junit rule which is a principle that works with Aspect Oriented Programming. It essentially means that Junit intercepts the testing method which allows the tester to manipulate things before and after certain test method executions. Junit can also provide a TestRule interface which allows the tester to create their own JUnit Rule for specification and customization.

      I chose this article because I found that I really loved learning about JUnit and wanted more information behind what it can do. I found that this blog post was important as a learning resource for me which made it more interesting to read. I was learning more about JUnit and its many other functionalities in testing which I previously did not know about. The post had a lot of information in it but used coding examples and definitions together to create a flow that read well and was understood much better. I enjoyed how it used these examples with comments and explanation within it to explain what was happening at each line of code. I was able to understand other uses of JUnit, specifically more about the annotations. I found that learning about the @Before and @After was very important to test methods and how they interact with the program while executing. The most interesting part of the post was the part where it explains how JUnit Rules work and how they can be customized using the TestRule interface. I found it very interesting that JUnit allows such customization for rules which makes it flexible as a framework. I thoroughly enjoyed reading this blog post as it did a great job introducing new concepts of JUnit in an understandable fashion while also refreshing the old concepts.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience 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.

https://blog.codeship.com/behavior-driven-development/

          This week, I found a blog post that talked about Behavior-Driven Development and explains how to implement it within Computer Science. The post begins by defining behavior as the way the user wants the application to behave. It explains that you must have a clear idea on the user needs for this implementation to be successful. The implementation of this is done by dividing the user needs into small stories which have selected keywords to help define the behaviors of the application. The post uses examples very well to explain these ideas by highlighting and explaining important phrases. The selected keywords are used to put the stories into a more “readable” format while also creating behaviors based on the user needs. The post gives some advice after this, saying that the most important behavior to the user is the best starting point for these stories. Then you just keep building off that idea to encompass a final product that you can show to a client to make sure that all needed scenarios are covered.

            I chose this article because I was curious as to what Behavior-Driven Development entailed within the computer science world. I had no idea what this term was before reading this article, but I have gained a much better understanding now. I found this content enlightening in the sense that it taught me to think a bit differently. I enjoyed how the post explained the importance and implementation of this development through the use of these stories. I found this way of understanding user needs very helpful and a fresh new perspective compared to other things I’ve tried. I was able to understand how the development process works by starting at the user needs first. This will affect my development process by allowing me the option of working with the user to create better specifications. The most interesting part of this blog was the overall explanations for the development process. It was intriguing and informative while teaching the purpose of properly addressing the clients by starting with their needs first. I found this subject very interesting and this source was a good resource to understand with its use of examples and visuals.

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

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.

https://blog.testlodge.com/levels-of-testing/

          I found an interesting blog post this week that talked about Levels of Testing within Software Engineering. It explained that there were four main levels that were known as Unit Testing, Integration Testing, System Testing, and Acceptance Testing. The post used a basic diagram to help explain the ideas alongside explanations for each level. It explained that Unit Testing is usually done by developers of the code and involves testing small individual modules of code to make sure that each part works. Integration testing is explained as taking individual modules like in Unit Testing and combining them to see if they work together as a “section” of modules. The post explains System Testing as the first test that works with the entire application. This level has multiple tests that works through application scenarios from the beginning to the end. It is used for verification of multiple requirements within the software such as the technical, functional, and business aspects. Acceptance Testing is defined as the final level of testing which determines if the software can be released or not. It makes sure that the requirements set by a business are completed to make sure that the client gets what they want.

          I chose this article because I remember that the syllabus only states three main levels, excluding Acceptance Testing. This is what sparked my initial curiosity as to what these levels of testing were and what Acceptance Testing was. I found that this content was really interesting because it explains how testing can be structured into different levels with each level building off of the last one. I enjoyed how the post explained the levels sequentially while also explain how they interact with one another. I was able to grasp an understanding of these software testing levels while also understanding the importance and vital role that testing plays within the development process. The most interesting part of the blog post was the Acceptance Testing because it reminds the reader that in almost every scenario of software development there is always going to be changes to the requirements of the original project. This level builds off that idea and essentially allows the developers to make sure that the product they are working on meets the flexible criteria of a client. I found that the diagram didn’t make sense when I first looked at it before reading the post. However, as I understood the subject more, I found it to be a great source that summarized and simplified the detailed ideas within the post.

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

Mediator Pattern

      This week, I chose to talk about a blog I found that went over the mediator design pattern and its implementation. The blog post starts off by explaining that the mediator design pattern is a famous pattern found in the Gang of Four book. It is known to reduce coupling between classes that can communicate with each other. The basis of this pattern is to create a mediator object that has control over the channels of communication between the objects. All messages to other objects essentially must go through the mediator to be directed to another object. The blog post says that this eliminates the need for the deploy objects to have knowledge of the receiver objects. The post goes on to talk about the removal of direct dependencies as it can simplify communication in programs with a large number of classes. It then talks about some of the positive effects this may have like making the code easier to read overall and the maintainability for future editing. The post then goes on to explain the pattern with an example that uses communicating between colleagues and mediators within a project.

      I chose this blog because it was a design pattern that focused on communication between classes which I find very interesting. I found that the explanations this blog uses makes it very easy for me to understand how this design pattern works. The easy to digest wording allows for an easy read that works well with the examples used. The phrasing within the examples allowed the UML diagram and the definitions of the classes underneath to make more sense. The only issue I had was with following the code at first glance due to the fact that it was written in C# but it didn’t take me long to piece it all together. The test classes were well written to show meaningful variable names as well making it easier to understand the parallels they were making from the examples. Through this information I was able to learn that if there is a mediator it can be implemented to make sure all the objects don’t hold unnecessary amounts of code in terms of communication. This will cut down on code within class heavy projects that need objects to remember each other’s addresses. This will help me in my future practice by making the code run much more efficiently and create a better sense of organization that makes it easier to read when dealing with many classes.

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

Chain of Responsibility

      This week I chose to write about a blog that talked about the behavior design pattern known as the chain of responsibility. The post explained that behavioral patterns are used to build foundations that allow objects to communicate and give each other jobs to do. The chain of responsibility pattern makes it easier to chain objects into an order set and when a logical requirement or command is sent through the chain, it checks through the chain until an object is found that fulfills this requirement or command. It then goes on to explain some real-life applications for this design pattern like government and business systems where there is high value in order of commands. The post also clarifies that in the chain of responsibility the order moves upward rather than downwards which means that it starts at the bottom of the list and moves up. There is code shown afterwards that shows how the pattern works in a programming setting using book titles as an example. Using book titles, authors, and cover types, a chain of responsibility is created and tested by calling those objects based off one of those specific properties.

      This post really interested me because it was noted as a foundational design pattern which made it seem important to learn. The examples were helpful in this post as they allowed an easier understanding of the material using real code. The analogies that were used could be a bit better but overall, they weren’t too hard to grasp. The real-life applications that were shown were interesting but in my opinion there could have been more explanation as to what specifically this pattern could accomplish within business and government. The blog helped me solidify the idea that the chain of responsibility is created with objects and goes through each object to find the specific requirement needed. I did not know that the chain started from the bottom and went upwards which is good to know but I would like to know more about the efficiency of the order in the chain. More specifically, is there a way to efficiently order the objects in the chain to make it run faster? Does the order matter within the chain enough to influence efficiency? These were some questions that I still had after reading this post, but it was a good source of information to help me get an introduction to the design pattern. This material affected me by showing be a new way to code using a foundational design pattern. This will affect my future coding practices as I can now identify situations where I can apply this pattern to make it easier to organize and run better.

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