Web Application Testing

Source: http://www.softwaretestinghelp.com/web-application-testing/

This week I decided to look up different types of testing and I found a blog that talked about web testing. This website called software testing help had a blog that talked about web application testing and it gave a complete guide about testing web applications. I tried to find who the author of the post is but I could not find the name but the author talks about some web testing cheklist that programmers should go through before deploying their website. Which are

 1) functionality testing:

you should test your website to make sure that all of the links, forms, cookies, html, css, and database all work fine. It is important to make sure that the links are not broken links and that the code that you want to display onto the website are displayed correctly and in the right position.

2) Usability testing:

The usability test means that the website should be easy to use, any and all instructions that are on the website should be clear. There should be a main menu link on every page and it should be constant though out the website. You should also make sure that there are no spelling errors, all the fonts, colors, frames, etc. are all on the right setting.

3) Interface testing:

Check if the interacting between the website and the servers are functional and any errors that are given are handled properly.

4) Compatibility Testing:

Make sure that the browsing compatibility is available for all sorts of browsers and OS such as Firefox, google chrome, AOL, windows, MAC, Linux and other OS and brewers that are available today.

5) Performance testing:

You should make sure that the website can handle heavy load of traffic though the webpage so it does not crash and would be able to handle large user request simultaneously. A web stress test is to test the specific limits of the website and sees how the system reacts when it crashes and recovers from those crash.

6) Security testing:

Finally you want to make sure the security for the website especially a website that would take personal data and save it on its data base be secured enough for people to log in and feel safe that their personal information is protects.

I like this blog because right now in our class we are going to be devolving our own website and even though we are not going to have it be deployed to the public there are some testing in here that are good to remember when writing our code. In future situations when I am writing programs for websites this blog is a good reminder of what kind of tests I should do to make sure that I am doing everything before I deploy a website.


Refactoring Code

Source: https://snipcart.com/blog/tips-on-code-refactoring-from-a-former-addict

This week I decided to write about refactoring code. I found a blog written by Charles Ouellet called “tips on Code Refactoring, from a Former Addict” this blog talks about his own experience on refactoring code. Refactoring is rewriting existing code and redoing it to make it more readable and more maintainable. When Charles first started he career as a developer he had a serious refactoring addiction where it even hindered his own work and delaying him from sending out his code to the consumer. For this blog, he talks about his own perspective of what are good reasons to refactor code and what are some bad reasons to refactor code.

Some of the good reasons to refactor code is to avoid technical debt. When you write code and the business takes off after it starts to grow even more there may be new problems that arise out of it. Refactoring code can be a cheaper option of fixing the program then to write a brand-new program to do the same thing that you want it to do. Another reason why it is good to refactor code is that it can be able to teach new people that are joining the project half way though to learn the base of the code. This way it allows the new coder to see every class that is related to the application and they would be able to understand most of the code that was written before him. Finally, with technology evolving every day refactoring code to adapt to those new technology is a much cleaner and easier option to do then to write a brand-new code to adapt to the new technology that is out on the market today.

Some of the bad reasons to refactor code is to make the code look prettier. Most of the time coders would look back after a few days or weeks because the code they wrote was just ugly and wants to go back and fix it. However, that is a waste of time and money for both the coder and the company. If the code works fine you should not refactor the code just for the sake of refactoring. Another reason is to integrate new useless technology. When you are refactoring your code to integrate it for a new technology you should take a step back and think about what does this new technology bring to the table of your product and would it be worth it to even refactor the code for something that is just a one hit wonder.

I like this blog because it is from an experience developer and his own opinion of when it is good to refactor code. I think this topic is very good to learn because in school we are always changing out code to make it look nice and make sure it works so we are constantly refactoring it but in the real world we would not have the luxury to keep changing our code to make it look nice and to just re work it all together. So this blog gives you a good base of when you should refactor your code and when you shouldn’t

Test Automation

Source: http://www.cigniti.com/blog/why-you-should-take-automated-testing-seriously/

This week I decided to write about Test Automation. I found a blog that talked about Test Automation. However I have never heard of test automation before so I had to do some research and find out what it was at 1st. from what I read online test automation is basically testing programs by using other testing software outside of the application itself. Test automation has been around ever since the computer industry has been out. Testing is not like what programmers do where they just run their code in different situations and different fields and input and outputs. These test automations were people who were dedicated to testing out software not like debugging it but running it though tests. This was a much larger and more complex system that even was to be thought of as a discipline worthy of study apart from programming.  With testing it was not just some AI testing the programming for incidentally, accidently but inherently for human errors and human interaction with the program. Test automation cannot reproduce the thinking that testers do when they conceive of tests, control tests, modify tests, and observe and evaluate the product. Test automation cannot perform sapient testing. Therefore, automation of testing does NOT mean automation of the service provided by the software tester. With Test Automation it should not be programmers testing out the code themselves and seeing if things work but people who have no idea about what they are working with or doing to test these codes and seeing how human action affects the program they are using.

This topic I read was kind of interesting because it talks a bit about what the first testing there was in the computer science world. To me I think that this kind of testing should be used a bit more because I don’t think that the people who are writing the code should test it all the time because there could be mistakes that you don’t notice and especially programs that are going to be used for the public having someone who has no idea about what code is and how to read it test out the program is useful. I think I would use this in real life situation when doing testing for code I write because like people say old but gold.

Object Oriented Programming

Source: https://medium.com/omarelgabrys-blog/the-story-of-object-oriented-programming-12d1901a1825

This week I decided to write about Object Oriented Programming. I found a really helpful blog written by Omar El Gabry. This is his own blog talking about object oriented programming. I honestly wished I wrote about this sooner because it would have explained things to me much easier then when I was trying to learn for class. This blog explains all about object oriented programming. He breaks things down step by step even explaining what objects, classes, attributes, behaviors, etc. mean. I really like this in a blog because when someone with little or no programming background can be able to understand what he is talking about. In the blog he even gives real world examples talking about object orientation. He then talks about abstraction and what abstraction means. He uses the example of a car and what do you think about when you hear the word car with abstraction it’s the color or the size of the car and that is basically what abstraction is. It is the adjective of the car. He then talks about encapsulation where in code we don’t want to write out super long programs because there are things that we write that we don’t want someone to read or have access to so we would just hide the classes we write and restrict access to it. He gives a very true statement that I think every coder should take to heart is that when you encapsulate something we should hide as much as possible because in the real world you do not want everyone seeing what you wrote. He even added code so people can mess around with it and see how it works. In the code he has classes called animal and then dog, duck, and kangaroo that extends to the animal class and the main class uses the animal class to prints the name of the dog and the color of the dog and everything like that.


I thoroughly enjoyed reading the blog because it was a good refreshment of what I just learned and a much easier explanation of what I did before. To me I don’t think it would affect my future learning practices but I do think it’s a good recap of what I did before. I may just come back to it if I ever want to have a quick refresh or even send it to a friend who is thinking of learning about programming.

Decision table

Source: http://www.softwaretestingmaterial.com/decision-table-test-design-technique/

This week I decided to write about Decision tables.  I found a great blog called Software testing materials.  They had a blog post called Decision Table Test Case Design Technique. Written by Rajkumar. In this blog he talks about decision table test case. This test technique is appropriate for functionalities which has logical relationship between inputs. In designable they deal with many different combinations of situations, inputs, and test and they would give you examples of what kind of output would be expected with the inputs. Here he gives a few examples of decision tables. In the examples he gives conditions to be able to transfer money. Conditions are account already approved, one time password matched, sufficient money in account. Then according to if each one is true or false it would do an action such as. Transfer money, show a message as “insufficient amount”, block the transaction in case of suspicions transaction. Then according to if one of the conditions are false it would do action 2 or 3 but if everything is true it would transfer the money. A much simpler decision table test that he gives is the case of entering a username and password. The conditions are Valid user ID and Valid Password. The actions that would be given is Home page or Show a message as “invalid user credentials” if any time the username or the password is False it would show the message for invalid user credentials. But if both are true then it would go to the home page.

I like this blog because it breaks down how decision tables work.  Raikumar gives very easy and understandable examples of how each of the decision table work. He explains it step by step that anyone who has no knowledge about decision tables would be able to understand what a decision table is. I would use this blog for future homework or even use this information to show future students are learning about decision tables to show them how they are used and made. I think that decision tables can be used in everyday life not in just computer science but in making choices for everyday life big and small.

Design Patterns

Source: http://www.bambielli.com/posts/2017-04-02-decorator/

This week I am writing about Decorator design pattern. I found a blog by Brian Ambielli called Design Patterns: Decorator. Here he talks about decorator and how it works. Decorator patterns allow us to extend object with added functionality at runtime. It allows developers the power to compose objects that are purpose driven for the current demands for their users. He talks how decorators can be thought of as super types where they are wrappers around the object they are decorating. They can be used and passed in a program in place of the original wrapped object. He gives us an example using pizza as the topic where you can make a pizza either a deep dish or thin crust pizza and gives us choices of what kind of topping you want the toppings are wrapped by a decorator that allows the user to choose either the pepperoni topping or cheese topping. With this blog, he even talks about the downside of the decorator. Some of the limitations that the decorator pattern has is that the code relies on the type of concrete implementation that you are wrapping. With decorators, they often have numerous small classes that are each responsible for one behavior modification. This makes code hard to read and understand.


What I like about this blog is that is has a very good example of how decorator design patterns work and they even give us the code to even test it with. With this we can even test and mess around with decorator designs. In the blog he talks about when you should even use decorator design patterns and this is very helpful for people who want to try and test out these design patters in their own code. I also like how he doesn’t just talk about the good of decorator design patterns he talks about the bad about it. So we know which kind of design patters would work for different situations. What I would do this this blog is that I think I would read up more about different deign patterns and try and test it out with some of the code I write seeing which ones I like the best.

Software Testing Life Cycle

Source: http://blog.mallow-tech.com/2016/02/software-testing-life-cycle/

This week I looked up software testing blogs. While searching the web I found this one blog called mallow-tech. there was this one blog post called “Software Testing Life Cycle” written by Periannan, a test engineer for Mallow Tech. In this blog it talks about what software testing life cycle (STLC) is. Software testing talks about the testing process that has specific steps to be done to make sure that the code meets the quality standards. For many companies they have different phases for STLC however the base of it is the same for every company. STLC usually has six phases. Requirement Analysis, Test Planning, Test Case Design, Test Case Execution, Re-Testing and Regression, and Final Testing and Closure. In the Requirement Analysis phase this is where the team talks to the client about what they want and talks to the team of developers about what parts are testable and how they would run those tests. The next phase is test planning which they see what kind of they are going to use to test out the code. Number three is test designs this is where test cases are created according to the specifications for the project. Next is the test execution. Here they execute the tests in logical sequences with specific test data. Next is the retesting and regression testing phase by this time the tests would have been done and the bugs would have been reported. The team would then fix those bugs and then run the test again to make sure everything was fixed. Lastly final testing and closure is where the final parts of the STLC is completed and they start to send it out into the public to find out if the code works.

This blog was very helpful for me because I did many blogs about different tests that we have to do but this blog talks about the process of testing. With this blog I think it is super helpful as an add on to my other blogs. In the real world we are not going to just run tests one right after another. We need a plan on what to do and when to do it. This shows me that everything in the computer science world is not just doing code and making sure it works it is all about doing things in steps just like how we write code it should be neat and organized and planned.