Link to blog: https://testlio.com/blog/how-to-be-an-efficient-software-tester/

Currently as a college student majoring in Computer Science, I made the decision that I wanted to do a concentration in software development instead of data analytics. This is because my passion is to become a video game developer. While learning on the concepts of how software is designed and tested, I wondered what would be the necessary fundamentals of being an efficient software tester besides learning all of the test cases, techniques and terminologies. In this blog written by Willie Tran, he explains the seven tips on how an efficient software tester should be.

First, Tran identifies that sometimes, testing software can be chaotic and relates it to those who have experienced it in working in the field.

“Anyone who has been working in the field for any extent of time has experienced unreasonable lack of organization, poor scheduling, and daunting bug reports. Working through this mess is a task of its own. The best way to avoid this situation is to create order in your own habits. If you can create a common and consistent order for any work you touch, then you will set an example for your colleagues.”

Later, he highlights the tips that a software tester should do to be successful and efficient. These tips include organize everything, write detailed bug reports, write clear test cases, take part and communicate, ask yourself questions, be positive, and don’t test.

Organize Everything:

Creating an organize structure is important. When you create an organized structure to store all of the important details, it is easier to gather the relevant details and and perform the right testing strategy for the specific assignment you’ve been given.

Write Detailed Bug Reports 

Writing clean, detailed bug reports helps a lot, especially if you’re working in a team. This means that if you do this, your team will be able to understand more clearly on what it is you are writing and what bugs that you’ve identified in your project. Tran also adds that the three points that he stresses when it comes to writing these reports are:

1. Write with detail
2. Write with clarity
3. Write for others

Write Clear Test Cases 

Don’t create long test cases. Try to simplify as much as you can to avoid problems and save time.

Take Part and Communicate

If you are working in a team, communication is key. This makes it so that testing is a team effort. If everyone knows what they are doing with each other as well as what their tests do, the testing process will be successful.

Ask Yourself Questions

Asking questions to your self is also important in a sense that you are checking yourself as you go to see what can you do to improve the tests and make them more efficient. Ask yourself what the tests are answering and doing.

Be Positive 

Testing with a positive attitude, especially in a team can be a huge factor and contribution. If your team sees that you have confidence in your work, everyone can become successful in the effort towards creating tests.

Don’t Test

Don’t test at all at the start. Once you make the tests, see what parts of the tests need improvement. Once you’ve done that, then you can test.

This blog by Willie Tran helped me understand on what an efficient software testing looks like. I picked this blog because I wanted to know more about what makes a software testing efficient besides knowing all the concepts of software testing. Knowing these tips will help me in the future to become a video game developer because most of the time, I’ll be working in teams when testing and creating game software. It will be important for me to communicate with my team and stay positive throughout the process when I work and test the softwares.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Manifesto for Adaptable Software Development

This post is from the same blogger as last week’s. This post is about the manifesto of software development. The blogger gives a list of activities in to columns. The left columns are activities that faces challenges on the right column in software development. The blogger briefly goes over what they mean and gives an example of each. Experimentation instead of Specification: Instead of writing software program with specifications, write a software program with room to experiment and make changes along the way as needed.Example: Build a minimum viable product which allowed the programmer to delay decisions until the last responsible moment. Sound engineers build flexible software platforms to support cost effective experiments.  Evolution instead of Implementation: Instead of writing the system for implementations write it where there is room for it to evolve over time. Example: Domain modeling allows users to capture the essential aspects of an application while enabling future specializations. Adaption instead of modification: Write code that can easily be changed over time when needed, instead writing code with the modified changes and no room to make future adjustments. Example: Frameworks with several alternative components that may be chosen at a time needed. Extension instead of growth: Instead of writing a system for allowing the code grow overtime, create extensions making easy access to change the code when needed. Example: Plug-ins allow the user to add new features to an existing application without increasing its size or complexity.

This was an interesting blog. This blog how software development changes over time and how to keep up with the new changes. I like the example the blogger gives for each item on the list. They gave me an idea on how to adjust code when needed. This also give me a better idea of what plug in are. I’ve seen the word in the past on my computer when I try to run a game or a video on the internet. Shortly after that I am notified to update the flash on my computer and then usually the gam or video starts working again. Sometimes it does’t but that’s when the computer is old and outdated. Framework is something I already knew from this class and several other previous classes I took. This blog gave me a better idea on how frameworks can help make adjustments to coding over time, by being able to add and move parts at different times when needed.

From the blog CS@Worcester – My Blog by rens14 and used with permission of the author. All other rights reserved by the author.

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Behavioral

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

https://www.codingblocks.net/podcast/clean-architecture-programming-paradigms/

This podcast, coding blocks episode 69, talks about various aspects of coding paradigms. So in this post ill summarize some of the topics i found interesting and insightful.

firstly, before their main discussion they talked about a question from a viewer that is definitely worth mentioning. The viewer is a project manager with the question: “if there is a room full of programmers working on a project, and another room with just a handful of programmers, which room is more productive and why?” The general consensus from each of the hosts concluded that there is a lot of valuable communication that gets streamlined through having just a few people, and blocked by having too many people. However, there is a certain threshold where obviously 300 people can do more work than say 50. So the answer really depends on the situation, which is up to the project manager to decide based on the project itself.

Skipping a few minutes down the podcast, around 40 minutes they start discussing interfaces. Allen states his basic rule for using interfaces, where if your coding something that doesn’t have any behavior, just a bunch of data, there is no reason to use an interface. In any other case however, if your coding something that has any behavior at all, it should be an interface. He says that even if you never use that interface for inheritance, the effort isn’t wasted in assuming that you might use it for something later. Joe jumps in by saying that using interfaces makes it much easier to change or debug your code with less volatility, overall if you don’t know if you should or shouldn’t make an interface, its probably a good bet that you should.

Later on towards the middle-end of the podcast, they start talking about the open closed principle. In this concept, changes can be made to code only by extending it and nothing can change the original directly, in this way all code is completely additive. This concept is very good because literally perfect base code is created and cannot be changed in any way, but still widely used. Joe remarks that some companies actually have a problem where developers are too scared to change base code that they may not fully understand, so they create a copy of it and only change the copy which leads to clutter. however, when done correctly, this concept is extremely efficient and easy because the coder doesn’t have to rewrite certain segments.

I recommend listening to this podcast, these guys are easy to listen to and know a lot about many different subjects of computer science. I’m sure you can learn something new with every podcast as these three hosts have both fun and educational banter.

From the blog CS@Worcester – CS Mikes Way by CSmikesway and used with permission of the author. All other rights reserved by the author.

This week, I will be preparing a tutorial on the Observer Design Pattern and I figured I could assist my own understanding of the pattern by writing a blog post to accompany it.  This post will be a summary of the Observer pattern as it is described on this page of the Object Oriented Design website.  The motivation behind the Observer pattern is the frequent need of objects, in object oriented programming, to be informed about the changes that occur in another object.  An exemplification of this concept in the real-world can be imagined as a stock system which provides data for several types of client; the subject(stocks server) needs to be separated from its observers(client applications) in such a way that adding a new observer would be transparent to the servers.

The intention of implementing the Observer pattern is to define a one-to-many dependant relationship between objects so that when an object’s state is altered, its dependants are notified and updated automatically.  The Observer pattern is effectively adhered to with the implementation of 4 classes:

• Observable/Subject(GOF) – interface or abstract class; defines operations for attaching/de-attaching observers to client
• ConcreteObservable – concrete Observable class; maintains state of an object and notifies Observers when a change occurs
• Observer – interface or abstract class; defines notification operations
• ConcreteObserverA, ConcreteObserver2, etc. – concrete Observer implementations

How it Works:

• ConcreteObserverable object is instantiated in main framework
• ConcreteObserver objects are instantiated and attached to ConcreteObservable object via methods defined in the Observable interface
• ConcreteObserver objects are notified each time the state of the ConcreteObservable object is changed
• ConcreteObservers are added to the application by simply instantiating them in the main framework and attaching them to the ConcreteObservable object

This allows for classes, that are already created, to remain unchanged.

The Observer pattern is applicable in situations where the change of a state in one object must be reflected in another object without keeping the objects coupled, and in situations where the main framework needs to introduce new observers with minimal changes.

The Observer pattern is often used, in conjunction, with other design patterns:

• Factory – A Factory pattern can be utilized to create observers so no changes will be required in main framework
• Template – An Observer pattern can be utilized to make sure that Subject state is self-consistent
• Mediator – A Mediator pattern can be utilized in cases of many subjects and many observers

The Observer pattern is so well-known because its implementation has proven to be quite powerful in event handling systems of languages such as Java and C# and in the model-view-controller architectural pattern.  I am excited to put together a tutorial on how to use this pattern and I believe that having a good grasp on its motivations and intentions will aid me in future if I ever consider using it.

From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.

Link to blog: http://www.itexico.com/blog/bid/99765/software-development-kiss-yagni-dry-3-principles-to-simplify-your-life

Throughout the time the I spent as an individual when it comes to coding, it takes me awhile to write the perfect code that I need for my college homework assignments. Sometimes, I would try and write code during my free time if I’m bored and implement a certain design that I would attempt to do. After I finish writing the code, I feel that I could’ve done it more quickly and efficiently without having to write so much code, or try to edit and fix the code so many times. I know that I have a tendency to repeat code and make it more difficult than it already was. As I’m trying to improve on being an efficient programmer I know that I have to stop myself from repeating code, and to keep it simple when it comes to a specific design pattern while fulfilling the necessary specifications.  In this blog written by Jonathan San Miguel, he identifies three principles to keep the life of a developer simple as possible. These principles are KISS, DRY, and YAGNI.

KISS: This acronym stands for “Keep it Simple, Stupid!” It basically means that try to keep your code clean and simple as possible. The simpler the code is, the simpler it’ll be to maintain it in the future in case if you want to edit it. Miguel also adds “avoid using fancy features from the programming language you’re working with only because the language lets you use them…use them only when there are perceptible benefits to the problem you’re solving.”

YAGNI: This acronym stands for “You Aren’t Gonna Need it!” This means that as the programmer, you need to focus on your specification and write the code that does that particular task without adding anything extra such as features you think you might need in the future.

DRY: This acronym stands for “Don’t Repeat Yourself!” Try and prevent yourself from writing code that is similar to others that you previously wrote. “Maintain the behavior of a functionality of the system in a single piece of code” as Miguel noted in his blog. This principle is useful especially in big applications where they are constantly maintained, changed, or extended by many programmers.

Among these three principles, I think I need to focus on the DRY principle the most because I do have the tendency to repeat code. If I can improve on that, I’ll be golden, and coding won’t be that much difficult for me. Jonathan San Miguel briefly explained that main points of each principle, which made it easy to understand. He also gave his advice on some of the principles and identified which principle was useful for certain circumstances. Understanding these three principles will help me in my future career as a video game developer because when I write the code for video games, I’ll have to condense and simplify as much as I can within the design so the software can run smoothly and efficiently. It will also help me save time to do other things with the code too.

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

I decided to write this week’s blog on Observer Design Patterns because I am going to be writing a tutorial on this in class next week. I chose a tutorial posted by author Santosh Kumar on the blog “WalkingTechie”. I chose this blog about the Observer Design Pattern because Kumar gives an in-depth explanation of what an Observer Design Pattern is, how it’s implemented and gives UML and code examples of it which I found to be extremely helpful.

Kumar starts by giving a definition for the Observer Pattern, which he states “defines a one-to-many dependency between objects so that when one object changes state, all of its dependents are notified and updated automatically.” He also states that this is a part of the Behavioral Design Pattern.

Kumar furthers explains the Observer Design Pattern by giving a real-world example with a newspaper subscription. There are two variables – Subject and Observer. In this example, the newspaper publisher is the subject and goes into business by publishing newspapers. The observer is the subscriber who subscribes to a particular publisher, and everytime a new edition comes out it gets delivered from them. A user can unsubscribe which will stop papers from coming.

Kumar then implements the Observer Design Pattern. He defines a Subject interface that has a method to register, remove/unregister user and notify users when the object changes state. There is also a DisplayElement interface that has a display method, and an Observer interface and all concrete classes – BinaryObserver, OctalObserver, and HexObserver.

After constructing a UML diagram, Kumar goes through the code implementation step by step.

In the first step, the Subject interface is created. This contains the registerObserver and removeObserver and notifyObserver methods.

In the second step, the Observer interface is created. This includes the update method,

In the third step, the DisplayElement interface is created, which has the display method.

In the fourth step, a concrete class DecimalData is created and implements the Subject interface. Then a concrete class is created that implements the Observer and DisplayElement interface. And finally, the ObservePatternDemo class is created to use DecimalData and concrete objects to test observer design patterns.

I enjoyed Kumar’s blog explaining the Observer Design Pattern because he went in depth by defining the Observer Design Pattern, giving a real-world example, and implemented it by creating a java project. This really helped me understand the Observer Design Pattern more and it will come in handy when I do my tutorial on it.

From the blog CS@Worcester – Decode My Life by decodemylifeblog and used with permission of the author. All other rights reserved by the author.