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.
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.
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.
This week I decided to look up blogs about YAGNI also known as “You Ain’t Gonna Need It.” This blog called DevIQ had a post about YAGNI. For me this was the first time I have ever heard of the acronym. This blog talks about how most of the times people code things for the future of the development. However, it is not a good thing to do. For many programmers, they follow this rule because it maximizes the amount of unnecessary work that is left undone. Features that are not necessary is a huge source of waste. In the blog, they compare YAGNI to the Just-In-Time manufacturing. Instead of ordering a bunch of parts based on what you think you are going to get you should order the parts based on what the customers need. This insures that you don’t waste money and time. This is the same as programing where you should just keep things basic and never try to do anything over the top and try to keep things to what the customer wants done. The blog talks about keeping code simple. Avoid adding features and complex designs unless it is needed. There is a good quote that is in the blog also that says “every line of code we don’t write is dollars we didn’t spend, and time on the calendar we get back for free.” This to me is very simple but powerful because it talks about how we should not over complicate things because it would not be worth the time and money we are putting in to trying to make it better.
To me this blog is something I should follow to heart because when I was doing my assignment 1 for a class I was reading too much into the assignments and was making things way too complicated for myself. There were times I wanted to delete the whole code and rewrite it however luckily in the instructions it said not to change anything and just to add a few lines. This kept me on track for my assignment. So with the YAGNI I think I would be keeping this to heart for as long as I code because this is something that many programmers especially people who are programing for the 1st time should hear about.
This week I found a blog called computer science zone. There was this one blog that caught my eye which was called What is Ethical Hacking? Ethical hackers sound like an oxymoron because when you think of hacking you think of people who break into people’s computers, small business accounts, and websites. Where they would go on and steal personal information such as bank accounts, addresses, social, and many other things. The people that I was just talking about fall into the category of black hat hackers. However, there are hackers that are not all about stealing information their people are called white hat hackers. These people are actually hired to hack into company’s websites to find security leaks or holes so that way they can take care of it before someone who is trying to do serious damage can find it. There are a few specialists that this blog talks about as well such as information security analyst, security engineer, and penetration tester. As an information security analyst, they are responsible for solving security problems are companies and origination with substantial technology and informational infrastructure. Because of this there are a team of it professionals that monitor the database for these companies and they even ward off cyber-attacks daily. With security engineer, they are responsible for beefing up the security that they have and even creating new and effective ways to make the security for the company even stronger. With penetration tester, they are responsible for maintaining secure connect ability between internal and external communications. This means that they are often between email servers and accounting and communication software and the internet to keep hackers from invading those firewalls.
I like this blog a lot because it talks about a few future jobs that we have available to us as computer science majors. They even give the amount of money you make what you do at the work place and where they are usually at. This blog is very cool to read because when I was taking data security we learned about white and black hat hackers and I was very into that topic that it was really cool to see that there are different types of hackers in the work and not all of them are out in the world trying to do evil. So, it is nice to see that with computer science we are able to do many different jobs with many different people from small business and even muli-billion dollar companies.
Today I read up on a blog called Codingdojo. This blog was written by Stephen Sinco. In this certain blog post, he wrote a post called “7 Critical Tips to Learn Programming Faster.” In this blog post, he talks about things to help new programmers to learn programming faster. A few of those tips that caught my eye are to learn code by always doing code. When learning a new chapter, you should do little personal projects with the new methods or ways to write the code as soon as possible because that way you will be able to learn the new chapter more efficiently. It also talks about doing code by hand. This is very surprising to me because I always thought that we would always have a pc to work on. To many people this may seem like basic tips and tricks but it is very important to remember these tips.
To me this blog was very helpful especially writing the code by hand. I think I would start doing this every once in a while, to be able to learn code more efficiently. With these tips, I think it is something we all should read while we are coding because there are times when we are debugging things and we just get frustrated and we lose focus so I think it would be good to take a quick break and relax.
Another week into my blog for CS 443 this week I decided to look up blogs about levels of testing. While I was searching the web, I found a blog testlodge by Jake Bartlett he wrote a blog post titled “Levels of Testing In Software Engineering” here he talks about the levels of testing in software engineering. There are 4 levels of testing he talks about. Unit testing, integration testing, system testing, and acceptance testing. The first testing that most people do is unit testing. It involves testing pieces of code to make sure each one is right. With unit testing it helps verify internal design and internal logic, internal paths, as well as error handling. Unit testing is usually done by the developer who wrote the code. The second level of testing is called integration testing. This level of testing test how well each of the code works together. Each class is usually combined and tested as a group. This way it identifies interface issues between modules. The third test is called system testing with this kind of testing it test the entire application. This is done in a test kind of environment where the program would be sent out to. With this kind of test, the application is tested from beginning to end. This test is usually done by the testing team and includes a combination of automated testing and manual testing. Finally, the last test is called accepting testing. With this level of testing it test if the software is ready to be released. This kind of testing is mostly done by the business user and end user. With these levels of testing it show that testing is not just a onetime thing it is multiple test just like my other blog talks about. You have to make the right kinds of test and test often.
I chose this blog because I wanted to stay on the same topic I did for my last blog and keep with testing. I liked this blog a lot because it makes things easy and clear to understand and breaks each testing in to different levels and gives a clear description of what each of the testing is about. With testing ideas, I learned that you will never have enough tests. So, to make sure you are efficient when testing you have to break down your testing into different levels. I think the blog will help me a lot in the future because I will be testing a lot of code for class, school, work, and personal projects. Know what to these how to test and when to test is the best way to use my time efficiently.