Hello everyone, and welcome back to my 443 blogs where I post many interesting topics that I am currently learning. Today blog post topic is about boundary value analysis and equivalence partitioning. Boundary value analysis is a testing technique where you test between valid and invalid inputs. Boundary values are also known as lower/upper values and errors are often observed in those ends. It’s considered a black box testing technique. Equivalence partitioning and boundary value analysis can co-exist and used together to test many more areas of the test. Boundary value analysis test is proficient because it can test most of the test product. Equivalence partitioning is when we categorize the values into ranges and test one input from each of category. This is also a black box test design technique and can be applied to several different test like unit, integration, etc. Equivalence partitioning would have numerous amounts of test cases that we cannot test all. All in all, this blog post is about Boundary value analysis and equivalence partitioning. The resources that I gather my information was from https://reqtest.com/testing-blog/what-is-boundary-value-analysis-and-equivalence-partitioning/. I thought this blog was good but didn’t provide much information about this topic other than basic. The examples that this blog provide wasn’t descriptive enough for me to truly grasp on the idea of equivalence partitioning and boundary value analysis. After reading this blog, it didn’t change the way I think about the subject because I already knew most of the content, but I was looking for more details. I thought the blog should of include more visual examples with actual test inputs. I learn some useful tips on this subject like for example that we can’t test all possible cases in equivalence partitioning because the test cases would be too large. Also, even though this resource was simple it’s was easy to understand the material and the example wasn’t complex, so it was easy to follow. I agree with everything in the article and like the way it explains the topic. In conclusion, this was my 443-blog post and I learned many interesting things from this recourse that I used.
Hey everyone, welcome back to phan’s cs where I discuss my recent 343 CS course related topics that I’m currently learning. Today I’m using Edureka blog about object-oriented programming for my resource which can be found on https://www.edureka.co/blog/object-oriented-programming/. Java OOPS concepts which stands for object-oriented programming is a programming style that includes concepts like class, abstraction, object etc. The core of oriented-oriented programming involves these four concepts inheritance, encapsulation, abstraction, and polymorphism. First, the concept of inheritance is where the properties of one class can be inherited by the other. A great analogy is a parent and child, where the child inherited properties from the parent. In programming, this would be called a parent class which is a super class and a child class which is known as a sub class a sub class. There are classified into 4 types single, multilevel, hierarchical, and hybrid. Second, encapsulation, this means to hide your data to prevent any modifications. This can be done by two ways, first, declare the variables of a class as private and constructing public setter and getter methods to get or change the variable. Next, abstraction which is basically hiding the details and providing the vital things. A good example cell phone that they provide in this blog is a cell phone which a user can make calls, take pictures, etc. and there’s a lot of code that runs in the background that the users doesn’t have to worry about. Finally, there is polymorphism, which many forms. This when you can have multiple implementations for an interface or method. All in all, object-oriented programming is a programming style which involves these four concepts inheritance, encapsulation, abstraction, and polymorphism. The reason why I choose this topic is because I wanted to review the main objective of OOPS. I think this article is very informative and provides many analogy and examples of the concepts which made it easier for me to understand the material. I agree with many of materials that it provides and think it was very accurate. After reading this blog, I think it change the way I work because I now have a better understanding of Java OOPS.
Today blog is about Decision Table Testing. “Decision table testing is a testing technique used to test system behavior for different input combinations” and known as cause and effect table. The table consist of rules, cases, and test conditions. This tutorial has a good and easy to understand example. It created a decision table for a login screen where the output is true if both conditions, username and password are true else the output would be false. There were four rules because there were two variables. There was also another example that was similar which had eight cases because there were three variables. The test would only pass if and only if three of the conditions were true else it would return an error message. This test method is important because it allows us to test several combinations of tests which allows us to have more coverage of on the tests. There are many advantages of decision table testing:
- “When system behavior is different for different input and not the same for a range of inputs”
- It provides better coverage for testing because it has many combinations.
- Any complex conditions can be converted into a decision table.
- Great for low input combinations, will cover all testes.
But there is one big problem with decision table testing and that is when there are many inputs the table gets complex and complicate things. This article was very helpful to me. Because I have a better understanding of decision table testing now. This tutorial had many good examples and even a video on decision table testing. The formula for possible combinations is 2 ^ n, where n is the number of inputs which is shown in this article which I remember during class. I think after reading this article I change the way I think about decision table testing because I now know what it’s best used for. I found this article very interesting because of the clever examples that it uses its. All in all, the decision table testing is one of many important testing methods out there.
This blog post is about second of level of software testing. Integration testing is when individual units are merged and tested as a group. The purpose of integration testing is discovering errors in the interaction between integrated cases. A good example of integration testing is a basketball hoop, the rim, the pole, and the net. They are created and tested separately in the same facility but when two unit or more are ready they are tested together which is integration testing. Black box testing, white box testing and gray box testing can all apply to this method. There are many approaches to integration testing:
- Big Bang – when every or most of the units are merged together and tested at the same time.
- Top Down – when lower level units are tested after top level units.
- Bottom up – when top level units are tested after lower level.
- Sandwich/Hybrid – combination of both top down and bottom down testing method.
Integration testing is important level of software testing because for example if you have a two separately created and tested units like a door and door knob, even though both door and door knob were tested you don’t know if they would fit because they weren’t tested together. There could be many faults for example like the door was inch in width smaller or the door knob was didn’t fit with the door. With integration testing the door and door knob would be tested together after each of the unit is ready so if there any error that makes the door and the door knob to be non-compatible then the test cases will fail which shows that there’s an error and you can fix it.
After reading this article I have a better understanding of integration testing. This article changes the way I think about software testing because I more knowledge about one of the levels of software testing. I now know why integration testing is so important. I find this method useful in many ways in testing in general outside of software testing. All in all, integration testing is important level of software testing.
Today blog is about Flyweight Design Pattern. Flyweight design pattern a structural design pattern like the adapter pattern that we learned in class and decorator pattern in home work two. Flyweight design pattern is applied in a situation when we need to instantiate a large number of objects of a class. It reduces the amount of memory consumed and execution time by sharing objects that similar in some way. Flyweight objects can’t be modified once they have been constructed which means in short, it’s immutable. HashMap is used in flyweight pattern to reference of the created objects. The Object property are also divided into two properties intrinsic and extrinsic. “Intrinsic properties make the object unique whereas extrinsic properties are set by client code and used to perform different operations.”. An example of Intrinsic state is that if there a Shape object that already created we don’t have to create another color feature because every shape has a color related instead we can just use the already created object. The extrinsic state is the size of the shape which is different for many objects. To return the shared objects we have to create a flyweight factory which is used by the client programs to create the object. All in all, this design pattern is used to speed up the speed of the program by sharing objects instead of creating new ones. I think this design pattern is complex. I don’t see this pattern used often unless the program is creating insanely number of objects. During this tutorial, I learned a lot about this design pattern, they used a shape example which shows the result of flyweight design pattern. I thought this was interesting, but I couldn’t think of many other situations that this design pattern can applied to. The tutorial was straight forward so I didn’t disagree with everything. This design pattern is complex so the I had trouble understanding it but when I actually implemented and ran the code I had a better understanding of this design pattern. This content did change the way I think because I now know there is many ways to increase the performance of my code.
Today blog is about Black Box Testing vs White Box Testing. First, Black Box Testing is when we’re testing if a system is functional or non-functional without knowing the internal structure (code). There’re many techniques that can be used for designing black box tests like Equivalence Partitioning, Boundary Value Analysis, and Cause-Effect Graphing. All these techniques are similar as they all are testing input values with valid output values. There are also many advantages with Black Box Testing. First, the tester doesn’t really have to be a programmer or need to know how the program is implemented. Second, the test is using done more hands-on and with user’s point of view which allows reviews of the product to be more unique in a way that every tester/user have a different opinion on the product. There are also disadvantages for Black Box testing. First, there are not a lot of many inputs that can be tested which means there is still many of the area of the product that are left untested. Second, without the specifications the test cases are difficult to design. Also, testes can be redundant because of the lack of test. An example I think is good for Black Box testing like tester testing an app by using it and checking if every action works as it should.
White Box testing is when you have full access to the information of the product and test the internal design. It tests the input of the test’s cases with the expected output. A great example of White Box Testing is “like the work of a mechanic who examines the engine to see why the car is not moving”. White Box testing is usually applied to unit testing, but I think it’s the most effective method because you have all the specifications and most all part of the product will be cover. The disadvantages are that it requires skilled developers because some tests are complex.
All in all, both Black Box testing and White Box testing are both effective in their own way. Black Box testing is mainly for Acceptance testing and White Box testing is for unit testing. I like White box testing more because I full access to the code which means I can better understand the mechanics of the system.
This week blog post is going to be about one of the creational design patterns, Factory Pattern. Factory pattern has many advantages:
- “Factory design pattern provides approach to code for interface rather than implementation.
- “Factory design pattern removes the instantiation of actual implementation classes from client code. Factory pattern makes our code more robust, less coupled and easy to extend. For example, we can easily change PC class implementation because client program is unaware of this.
- “Factory pattern provides abstraction between implementation and client classes through inheritance.
When we have a super class, which can be an (interface, abstract class, and concrete class) with many sub classes and we want to return one of the subclasses based on a specific input, this can be done with Factory Design. The benefit of factory design is that we don’t have to instantiate a class every time we want to use a class instead we can just call the Factory class.
For example, if we had an interface named Game System and we created more than one sub class that implements it (ps4, Xbox, and pc) and then we wanted to use one of those objects in a test class, we would have instantiated one of the sub class every time we created an object from the class. This way is very tedious, that’s why Factory design is so helpful. Instead creating a object every time, we can create an Game system factory which allows us to input for example enter a string name “ps4” and create a ps4 class instead creating for example GameSystem gs = new ps4(); every time.
I think factory design pattern should be used mostly every time if there are more than one sub classes just because it removes clutter and simplify the code to be more readable. From my personally experience I think factory design patter help me think more about organization when coding. I always think of ways to make my code more reusable after reading this article. All in all, Factory design pattern is very helpful and is an important method when it comes to Object oriented programming.
This blog is about Static testing vs dynamic testing. Static testing is when the code is not executed. It’s when we manually check the code, requirements, and design to find errors. The main objective of static testing is to find errors in the early stage of the development cycle to improve the product. Dynamic testing in the other hand is when the code is being executed. Its testes the software system, memory/cpu usage, and the overall performance of the system. The main objective for dynamic testing is to confirm if the overall of the product, perform as expected by validating the output with the expected result. This can be done with black and white box testing because either method just requires comparison with the actual and expected value.
I think both testing methods are both useful. Static testing is for more for early stages of the software projects in my opinion after reading this article because it seems like this method revises the code and making comments and documenting errors and potential problems. This is useful because it allows to transition to dynamic testing later when we get to execute the actual program and there’s less errors and more problems that we aware of because of static testing, if we are using both methods to test a software.
I now like static testing a lot more now after reading this article because we get to review the design and the requirements which will make the product better. Making changes early and finding defect will save on cost. Making sure the everything is clean before the actual work is my ideal testing because it saves time and headaches when actual implementing the program when finding errors.
I think dynamic testing is more straight forward because you are really testing the actual output with the expected output and find the error if the two output don’t match. Doing this for every module is having them all pass assure that the product is completely running as expected. This method is used more by me because I think it’s a lot quicker to run the program and find the error if outputs don’t match and fix it but after reading readings this article I am assure I will be doing both for my future projects because static testing will save time. I think of it as if I static is writing pseudo code and dynamic is coding. In conclusion, both are useful methods and are used to improve a software product.
This week blog post is about Java Singleton design pattern. The reasons for Singleton pattern are to restricts the instantiation of a class and ensures that only one instance of the class exists. This article explains and show examples of the many different approaches of Singleton pattern implementation, the problems with the approach.
The approaches of Singleton pattern implementation:
- Eager initialization – pros: easiest way to create a singleton class | cons: instance variable is created even though it might not be used.
- Static block initialization – Similar to eager initialization but provides option for exception handling.
- Lazy initialization – This is the approach that was we used in class and it’s a completely fine for a single threaded environment, but potential can cause problems for a multi-threaded environment.
- Thread Safe Singleton – resolutions for Lazy initialization but reduces performance. Requires synchronization.
- Bill Pugh Singleton implementation – Best method for singleton implementation. Contains a inner static helper class by doing so the instance is not created unless someone calls on the getInstance() method. Doesn’t require synchronization.
- Using Reflection to destroy Singleton Pattern – This approach destroyed the singleton pattern.
- Enum Singleton – resolution for reflection method. Not flexible. Any enum value is instantiated only once.
- Serialization and Singleton – Use to store it in file system to retrieve it later. Cons: when deserialize it creates a new instance of the class.
I found this article very helpful with understanding Singleton design. This article explains to me when to use and the consequences that comes with each different implementation. The content of this blog was the best. The example code of this article was very clear and made easier to understand the materials. This change my way of using this method because I now know which method to choose in certain situation. The lazy initialization will be used more while I’m in school, but I think Bill Pugh method will be used more in the future because it’s very popular and it’s easy to understand. I agree with all the contents, but I read the comments of the other readers and they had some issue with some of the content which I have to read more about the subject to find out what’s right and wrong.