For this week’s blog post I will be looking at another design pattern, this time called Façade. This time once again from the handy site of SourceMaking.com. The overall intent of the design pattern is to provide a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, wrapping a complicated subsystem with a simpler interface. The problem that faces it is a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. Essentially façade discusses encapsulating a complex subsystem within a single interface object, thus reducing the learning curve necessary to successfully leverage the subsystem. The only access point for the subsystem will limit the features and flexibility that power users may need. The façade object should be a fairly simple facilitator. “Façade takes a “riddle wrapped in an enigma shrouded in mystery” and injects a wrapper that tames the amorphous and inscrutable mass of software.” With the quote from the site above the name really comes into play here. A good example of this would be something like that of a catalog. Where the consumer calls one number from the catalog and speaks with costumer service. The customer service representative acts as a façade, providing an interface to the order fulfillment department, the billing department and then the shipping department. Façade defines a new interface where in the Adapter design pattern it uses an old interface. The site/article then goes on to explain some general rules of thumb that can prove useful to those wanting to learn more or follow the design pattern even more. All and all the site is an excellent resource for anyone looking to learn more about design patterns and more with this article proving that with valuable information on a new design pattern I have not seen or used before.
For this week’s blog post I will be discussing another form of testing called Acceptance testing. Acceptance testing is a form of testing where a system is tested for overall acceptability. The reason for this is to see if the systems compliance with certain business requirements and assess whether it is acceptable for delivery. The site shows a helpful diagram illustrating when you uses this testing, with Unit Testing on the bottom, Followed by Integration testing above that, System testing above that and with Acceptance on that the top of that one. The site also gives a good analogy of what it is exactly happening with the illustration. During the process of a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are all produced separately, and unit tested separately. After this they are assembled and begin integration testing, with System testing following this. With of course Acceptance testing last to confirm once more that the pen is ready to function properly. Black Box Testing is the most common method used in performing Acceptance Testing. The testing does not follow any strict procedure and is not scripted but is rather ad-hoc testing. Ad-hoc testing is random testing or Monkey testing, essentially throwing stuff at a wall trying to see what sticks and what does not. You perform this testing after system testing like mentioned above in order for the system to be made available for actual use. Internal Acceptance Testing is performed by members of the organization that developed the software but who are no directly involved in the project, usually this is members of the Product Management, Sales or Customer Support. The opposite end of this is known as External Acceptance Testing where it is performed by those who are not employees of the organization that developed the said software. This is then broken up into two different fields, Customer Acceptance Testing and User Acceptance Testing. Customer Acceptance Testing is a pretty self-explanatory name where it is performed by those who purchased the software or are customers of the company that developed it. User Acceptance Testing is performed by the end users of the software, customers’
All and all this website was pretty well organized and explained everything very clearly and so forth in a manner where it made extremely simple to read and understand.
As a follow, up to my Regression testing post a few weeks ago, Sanity testing is almost a subset of it because it is performed when we do not have enough time to do the testing. It is used to carry out the checking on whether the bugs reported in the previous build are fixed with regression being introduced to fix these issues not breaking any of the previously working functionality. Sanity checks to see if the functionality is working as intended/expected instead of doing the entirety of regression testing. The test helps avoid wasting time and cost involved if the build has failed. After the regression introduction has been completed Sanity starts to kick into full swing. With it checking the defeat fixes and changes done to the software application without breaking the core functionality. It is usually a narrow and deep approach to testing, needing to concentrate limited and main features of testing in detail. Sanity testing is usually non-scripted helping to identify the dependent missing functionalities. It is used to determine if sections of the application are still working after minor changes. The objective of this testing is to not verify thoroughly the new functionality but rather to determine if that the developer has applied some rationality while producing the software. For example, if your scientific calculator gives the result of 2+2 = t! then there is no point in testing the advanced functionalities like sin 30 + cos 50. Sanity testing is usually compared to Smoke Testing which is used after software building is completed to ascertain the critical functionalities of the program is working fine. But smoke testing is for another topic for another day. All and all the website I looked at was very insightful into what sanity testing is and what it does.
Visitor Design Pattern
For this week’s blogpost I will be discussing another design pattern, this time I will talk about the Visitor Design Pattern discussed on Source Making’s website. Essentially the Visitor design pattern allows you to add methods to classes of different types without much altering to those classes. Allowing you to make completely different methods depending on the class used. Because of this you can also define external classes that can then extend other classes without majorly editing them. Its primary focus is to abstract functionality that can be applied to an aggregate hierarchy of element objects. This promotes designing lightweight element classes due to the processing functionality being removed from the list of their responsibilities. New functionality can be added later easily by creating a new Visitor subclass. The implementation of Visitor beings when you create a visitor class hierarchy that defines a pure virtual visit() method in the abstract base class for each of the concrete derived classes in the aggregated node hierarchy. Form here each visit() method accepts a single argument – a pointer or reference to an original Element derived class. In short, each operation to be supported is modelled with a concrete derived class of the visitor hierarchy. Adding a single pure virtual accept() method to the base class of the Element hierarchy allows accept() to be defined to receive a single argument. The accept method also causes flow of control to find the correct Element subclasses, once a visit method is involved the flow of control is vectored to the correct Visitor subclass. The website listed below goes into much more detail into what exactly happens but here I summed it up so that most should be able to follow. But essentially the visitor pattern makes adding new operations easy, simply add a new Visitor derived class but if subclasses are not stable keeping everything in sync can be a bit of a struggle.
Example of Visitor Design Pattern
The example they use in the article is that based around the operation of a taxi company. When somebody calls a taxi company (literally accepting a visitor), the company dispatches a cab to the customer. Upon entering the taxi, the customer, or Visitor, is no longer in control of his or own transportation but the taxi driver is.
All in all, I thought this website was really good at explaining what the Visitor Design Pattern is. I have used this website before for previous research into design patterns and more.
For this week’s blog post I will be discussing Agile Testing, describing what it is, its principles and more. First of Agile Testing is a software testing process that follows agile software development-based principles. Essentially agile testing is a continuous process rather than being sequential. The testing begins at the start of a project becoming integrated into the testing and development of the entire project. Now there is a testing like this called waterfall testing where waterfall testing is a bit more structured and detailed while agile testing is more minimal. From the blog I list down below there is a large compare between the two that I will save for the viewer to visit as it covered in fall better detail there than what I could write here.
Main Principles of Agile Testing
The main principles that come out of agile testing are as follows. Testing is continuous ensuring the continuous progress of a project with Continuous feedback that provides an ongoing basis for what your project’s requirements are going to need. Tests are performed by the whole team, the developers and the business analysts of a project also test the application instead of just the test team. The decrease in time of feedback response, this is essentially due to the continuous testing allowing a better understanding of what is happening allowing for a better response rate. Simplified and clean code, Less documentation, and test driven are all key principles that arise from the continuous testing as listed above several times, allowing for all of this to be done in a much cleaner fashion.
Advantages of Agile Testing
The benefits from agile testing are simple as it all comes from the continuous model it follows. First and for most it saves time and money, due the testing taking place right from the beginning and not at the end. Less documentation is needed, along with it being very flexible and adaptable to changes throughout its progress. Regular feedback is provided once again due to the continuous model.
In conclusion the agile testing not only facilitates early detection of bugs/defects but reduces time spent on fixing them. This model of testing can yield a much better-quality product/project due to its constant testing processes. The article written here is very informative about agile testing, I just only wish that some of the ideas were fleshed out a little more with perhaps a few examples showing how it works in reality.
For this week’s blog post I will be discussing the decorator design pattern discussed in Derek Banas’ Design Pattern Video Tutorial’s found on YouTube. Here you can find pretty much any design pattern you are interested in where he will discuss it in a video usually under 15 minutes.
You use this design pattern when you want the capabilities of inheritance with subclasses but know you need to add functionally at run time. You can modify an object dynamically because of this. Decorator Design is more flexible than inheritance. Simplifies code because you add the functionality using many simple classes, causing you to be allowed to extend with new code. The example he uses explaining the pattern is a great one. You have a pizza and you want to be able to put multiple toppings on top and such. He shows how messy it can be with simple subclasses and an inheritance-based system. Then he shows how to do it in the design pattern showing how useful it can be in situations like this. Essentially you make a pizza interface, with a concrete class being a plain pizza where you can modify its toppings. Then you have a Topping Decorator abstract class where the bases for the toppings will go, followed by a topping class for each topping you’d like to have. Next, he runs through what this would like in code. He writes the code out improving upon the previous inheritance-based code he had down before. What he writes is a much cleaner and simpler version of what he set out to do which is made possible by the decorator design pattern.
This entire YouTube channel, specifically this playlist of his is perfect for learning any of the design patterns we may or may not discuss in class or you want to learn on your own. Like I said above he explains everything in detail in a good pace where almost anyone could understand what is happening in the video. Along with the examples he shows and writes in real time, I recommend this channel/playlist to anyone who is interested in learning design patterns.
For this week’s blogpost I will be looking at an article from ReQtest that explains what regression testing is and its benefits. Regression testing ensures that previously developed and tested software applications are working the same as they were before recent code changes were done. Tests cases are re-executed to check to see if this occurs. Regression testing is needed when new features are added or when changes in requirements and code are modified per changed requirements. Bug fixing and fixing performance related issues are also instancing of when regression testing is needed. When a system is changed errors may arise, this is when regression techniques come into play.
- Retest All: this re executes all the tests that exist in the test bucket. This usually requires a large amount of time and resources making a very expensive resource.
- Regression test selection: this executes the selected part of the test suites for example re-usable test cases or obsolete test cases
- Test case prioritization: Prioritization of test cases depends on business impact and used functionalities.
The benefits of regression testing come from its basic idea, when your system is not working prior to changes made. Regression testing increases the possibility of tracking bugs caused by these new changes. It also helps in finding unwanted side effects that might have been caused due to a new operating environment. Of course, this will help identify bugs and errors in the early stage as well. Where this probably shines the most is when constant changes are required in the product. There are different types of regression testing as well. Corrective regression is used when there are no changes introduced in the existing product specifications, usually used to conduct a desired test. Progressive Regression is used when modifications are added in the specifications of the product and new tests cases are created. There are many more types of regression testing that is listed in the article such as Selective, Retest-All and complete regression. Some of the best tools for regression testing are WinRunner, QTP, vTest, Regression Tester and AdventNet QEngine.
All and all I thought this article was very informative, as I learned about a new testing method I have yet to learn or know about. It also seems to be very important especially if your system is working then after a change something goes wrong after said change occurs.
CS443 Blog Post
For this week’s blog I looked at bug reports and a template to perhaps help create better bug reports. Firstly, a software bug essentially is an error that produces unexpected or incorrect results, therefore when something is not working in the software as it should be it is inferred as a bug in the software. A bug report is a document that is extremely useful in communication to the developers that tell which parts of the software/application are not behaving as expected. These reports should have enough information that helps the developers pinpoint the exact issue helping them resolve it. The quality of the bug reports is crucial as a high-quality report reduces the chances of the bug in the future. While a bad bug report may cause the developer not to replicate the bug and not be able to fix it. Well what does a good bug report consist of? Well a good bug report has the following characteristics
- A good bug report has a unique identifier number to easily identify the bug and set it apart from the rest
- It contains all the information required to reproduce the bug and fix the issue while prioritizing the bug for fixing and outlining the expected behavior
- It usually covers a single bug, for multiple issues multiple reports should be created
- A good bug report can be easily understandable by the tester and the developer, implicating that the bug report should portray the same meaning between those who created the report and those who will be trying to fix the bug
- A good bug report follows a standardized bug report template while promoting collaboration between others and allows the bug to be fixed in the shortest amount of time
Bug reporting software’s such as ReQtest will help you in your bug tracking initiatives. Usually bug reporting software will help you report, document, store, manage, assign, close and archive bug reports. ReQtest is one of these tracking software’s that allows you to create a professional bug report. The template consists of fifteen different fields of information ranging from the ID number used to uniquely identify the bug report to the frequency of the bug occurring to the linked requirements that are linked to the bug report. Looking at the site you can see what each field requires and does exactly. Finally, after the bug report template has been used a checklist is usually required. Is the bug report clear to follow? Was the bug reported previously? Have you tried to reproduce said bug with the help of your own bug report? And so forth.
I thought this article was interesting as it gave me some good insight on how a bug report should be and such. The way it explains the bug report template is straightforward to pretty much any audience along with the entire article which is very nice to newcomers of the topic. Coming into this I had a general idea of what bug reporting consisted of but this article made me understand more of it. Overall I liked this article as it was informative and straight to the point.