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.