https://www.toptal.com/agile/art-of-war-software-development

This blog talks about how the concept of  “Art of War” applies in the world of software development. He starts with explaining the history of “Art of War”. The idea dates back to  fifth century B.C., by an Ancient Chinese military strategist named Sun Tzu. The text from the book is divided into 13 chapters, and still used in military schools in the East, and is suggested reading for the west. The concepts of “Art of war” have not only applied in the military at war  but as well as in politics, sports and software development. This blog goes through certain chapters and section of the book, and explains how it is used in software development. The first section comes from Chapter 2. The idea is teamwork. If everyone on the team is working on a program and they have no goal or no deadline for the project, then the people become frustrated and the effort in the project declines. The next part from chapter two is about timing. This one states, the faster you can get a program running and turn it in with out bugs, the quicker you’ll get feedback from the client. Chapter three is based on leadership. With a team of programmers one on a program there needs to be a leader to make sure everything is running smoothly and going the way it should. Chapter six talks about repetition. Using one method for one project might work well, so you’ll try the next project with the same method as the previous one. That might not be such a good idea. Instead, learning how to write in different coding language, and different methods will help you become a better programmer and help the program run better itself. The next sections talk about constantly improving to make things better. In programming, programmers are constantly fixing bus to their programs to keep it running smoothly. The next section again talks about teamwork, how everyone on the team has to work to the team has to work together on the project and not one member alone can do everything by himself. Again with teamwork, talk about making changes to the program with other members, instead of doing them yourself without anyone knowing. The next section talks about motivation, to keep the team going and help make the program get finished faster. The next section states if a piece of code looks bad, but work fine don’t change it or destroy it, just leave it alone and let it be. The last section talks about anti- patterns. Which means do as told and don’t stray to try to change things to make it netter because it might not work out in the long run. The author concludes that though these idea were first used for warfare the idea of teamwork, efficient and time can apply to software development as well.

Again, another good blog. I like the talk about teamwork for programming. Again this shows teamwork and the importance of it when working on a project. Which occurs in any job field with programming.

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

In this blog post, Justin Albano gives advice on working on code written by others. It can be tough making changes or adding to code that you did not write yourself, another reason why clean code is so important, it helps other have a clear idea of what’s going on. The author notes pitfalls that you should watch out for when working with someone else’s code:

Our Ego: We think we know best, but must respect the code and original author.
The ego of the original author: Working on code written by someone else may lead to questioning decisions made by others which must be met with working with the original author.
Fear of the unknown: Many times you are going to be working on code that you know very little about and will be responsible for those changes. It’s important a framework is built to ensure changes can be made comfortably with no worry.

Some techniques for maintaining clean, functional code:

1. Ensure Tests Exist When current tests are not sufficient, you must create them yourself, which can be challenging. Other times, having tests provided for you, you can learn from the tests what the intent of the code is.
2. Talk to the Person Who Wrote It Communication is key, if you have the chance to talk to the author of the code you’re working on you can get some insight if you’re having trouble.
3. Remove All Warnings This ensures quality of code, and reduces code rot.
4. Refactor Changing the internal structure to make it easier to understand without modifying behavior.
5. Leave it Better Than You Found It Do your due diligence when it comes to maintaining quality for you, and future people working on the same code.

I chose this resource because it gives advice on working with other people’s code, working with existing test cases, or adding your own. It reinforces the idea of clean code because you should leave the code better shape than you found it (if that’s possible). I feel the article had some good information that I will definitely use in the future. I will be working with code that was written by someone else, and will need to write test cases for changes made to the code and maintain it still functions the same. I learned techniques for dealing with code written by others, and doing my best to respect the original purpose of the code.

The post How to Work With Someone Else’s Code appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

A topic we recently discussed in CS-343 was Factory Design Patterns. The factory design pattern is an object-oriented design pattern that deals with the problem of creating objects without specifying the class of the object that will be created. Creating an object usually requires complex processes, which may lead to a lot of code duplication and an insufficient level of abstraction. Factory design patterns handle problems like this by defining a separate method for creating objects.

http://javadesign-patterns.blogspot.com/p/factory-desig.html

I chose to write this week’s blog on this example of a Factory Design Pattern because I thought it was a simple example that makes understanding Factory Designs easy and also gives readers a straightforward understanding of Factory Designs.

The blog lists when to use factory patterns in a straightforward manner by stating that you can use factory patterns when a class does not know which class of objects it must create, a class specifies its sub-classes to specify which objects to create, or when at runtime you need to create an object based on input parameter.

The blog then gives a good example of Factory Design by imagining that we want to develop a Media Player application, which should play mp3 and mp4 format audio and video files.

In the example, the author creates a Decoder interface, a MP3Decoder class, a MP4Decoder class, and a player class. The problem that arises is that the classes MP3Decoder and MP4Decoder are tightly coupled with the Player class. This could become a problem if Player needs to support a new format because then a new decoder needs to be added to the Player class, so every time you would have to modify the Player class.

To fix this problem, the factory design pattern can be used. The author applies the factory pattern in this example by introducing a DecoderFactory class and moves the Decoder objects from the Player class to this new one, then by modifying the Player class to use the new factory class. With this new implementation, if the Player class needs to support a new format then no modification is required in the Player class because you will only need to put the new type of decoder in the Factory class.

I chose this blog because it efficiently explained the Factory design pattern, which we are learning in class right now, and gave a new example that helps further my understanding of the design pattern even more. It was simple and straightforward and did not leave me confused when trying to understand 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.

Link: https://dojo.ministryoftesting.com/lessons/the-philosopher-and-tester-with-israel-alvarez

This podcast was recorded at TestBash Philadelphia last year, and it features Israel Alvarez who is a speaker at the event. The podcast begins with a little background information on the guest Israel Alvarez. Israel is relatively new to the Software Testing field only having 2 years of experience. His background is not in testing however , he has degrees in Philosophy and Mathematics , and this podcast focus mainly on how his Philosophy background shaped his career in testing.

Israel begins his talk by talking about how philosophy has helped him in his testing career. Israel calls himself a context driven tester , and philosophy helps with critical thinking which reflects on his context driven testing. As Israel continues talking about testing and philosophy, he talks about when he first started out and trying to figure out when to actually stop testing. They look at this philosophically asking the same question but from a philosophical approach , asking at which point do you stop think about and updating your beliefs. Although they do not give a concrete answer it is an interesting question comparing real life thinking and software testing thinking.

At this point the podcast goes a little bit off topic. Israel talks about how he go into philosophy, stating religion as being one of his main influences. Although i didn’t think this part was very relevant , Israel goes on to say how he believes religion is a packaging of ideas which i thought was an interesting look at it. A big chunk of the podcast talks about James Bach Socratic questioning , Which Israel studied at RST. Israel says the main thing he took away from this is the ability to articulate and defend his views. This type of questioning puts pressure on the Tester to defend his views on a specific talking , with somebody else asking them a series of questions doubting his views and the tester defending himself. This is used in questions such as if something is a bug or not which not everyone might agree on. This seems very helpful for flushing out bad ideas that are not very well thought out as well as helping you not get entrenched in specific views. The podcast ends on a bit of a tangent with them talking about automation in testing. Israel talks about how he does not think it is mandatory to use automation in testing but if can provide the team with a lot of confidence in their tests. Israel also talks about how he does not immediately start automating a system until he knows that system very well.

I chose this blog because recently i have been getting a lot more into philosophy which i feel helped my every day life, and this seemed like an interesting topic to see how it could effect programming and testing. From this podcast i learned some interesting ways to think about testing and philosophy. The biggest thing for me was the Socratic questioning by James Bach which sounded very interesting and helpful, in not only upgrading your ideas and elimination bad ideas, but also in how to articulate them and flush them out before you implement them. This can be used to avoid many simple mistakes one might make in testing. I have been reading The meditations by Marcus Aurelius and one thing i noticed about philosophy in Software development is that it can help with thinking logically , staying on task , not getting overwhelmed by the future or the program as a whole and tackling things one step at a time. I believe that all of these things will help you become a better software Developer. My only complaint is that the podcast did not dive super deep in to the philosophy in testing with more examples, but it was a very good introduction point. This podcast has definitely sparked an interest for me in this topic and i am going to be looking for more information on the topic in the future.

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

For this week’s blog entry, I found an article on the SOLID principles that I found to be rather interesting. The article teaches and reinforces the popular object oriented principles that have stood the test of time in a way that other articles have failed to do. This article explains the programming definition and relationship with each principle, then applies a real-life example to further illustrate each principle, which is why I chose it. Instead of breaking down every principle, I’ve decided to highlight the ones that stood out to me the most.

For the first principle, “S” the “Single Responsibility Principle”, the article explains that this principle states that each class should only do one thing and uses the duck boat as a real-life example of people failing to follow this principle.  The duck boat tries to be both a car and a boat instead of serving one purpose, meaning that maintenance is doubled. When trying to maintain an application, if a class serves many functions, finding where a bug lies, and even just properly maintaining the application becomes inherently more difficult if each class is trying to do too many things at once.

“I” for “Interface Segregation Principle”. This principle explains that it is better to have five smaller interfaces than one monstrous one. The article uses the idea of a soup of the day on a menu not being important enough for everyone to be listed on the menu every day. If this was the case, there would need to be a different version of the full printed menu for each soup of the day, each a new implementation of the “menu” interface. By keeping the concrete detail of what the soup of the day is off the menu, this allows the restaurant to use a different interface for the soup of the day, asking the server.  I feel like this principle has strong ties to the “S” principle. If interfaces are kept segregated, they become cleaner and seemingly, keeps the responsibilities of the implementations more precise.

These two principles along with the other three form a strong list of guidelines for any developer to follow when writing object oriented applications at the very least. This article’s use of real-life examples is what separated it from the rest of the pack and is why I’ll remember what each letter of SOLID stands for.  I know I’ve violated several of these principles in the past but I hope to follow these principles when writing applications in the future to help future-proof my code and become a better developer overall.

Here is the link to the original post/article. https://dzone.com/articles/the-solid-principles-in-real-life

From the blog CS@Worcester – Learning Software Development by sburke4747 and used with permission of the author. All other rights reserved by the author.

Coding Blocks – I for interface- Episode 1

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. I think I am really going to enjoy these podcast episodes because they began by talking about things that I could relate directly to. The three presenters started this episode by defining what an interface is to them. Although I have an understanding of what an interface is, hearing what is means to professional programmers gave light to some different ways of looking at what an interface is. My favorite was “ An interface can somehow be seen as the guard rail on the highway”. I think I “vibed” the most with this definition because that along the lines of what I see an interface to be. After several definitions, the question was then asked what the difference between an abstract class and an interface was. It was at this point that I realized I might have pushed the definition of an interface too far but luckily, this podcast straighten me out. The presented settled on the definition that an abstract interface contained more information and made allocations for storage unlike the interface, which just provided guides for what is to be implemented. The abstract class provided guides and instructions and also storage allocations for the type of data or information to be implemented. Wow!

Again the discussions progressed rapidly, it was discussed that an abstract class has to be inherited but an interface must be implemented. An abstract class can’t be instantiated but needs to be inherited. I thought this topic was very important because I recall the first couple of classes, we often found our selves lost in discussions to try and understand the differences and functionalities between these programing concepts. For best practices, it was mentioned that foregoing naming conventions in interfaces sometimes makes it easier to read and also utilizing underscores would group the abstract classes in the top of the file directories when looking at the directory tree structure. Also, they did advise to also prefix all interfaces that we create with an “I” so that everyone that looks at the program will know what it is. Didn’t know that was the standard in the real world.

“You can’t define constructor methods in an interface” – This means we can’t create an interface that informs the classes that are to implement the interface how those classes can be implemented. Again this is a confusing statement but by pondering on it for a few hours, it becomes pretty clear. Instead it makes sense to utilize a base class. Overall this podcast has a lot to be learned from it. They really emphasize on explaining technical concepts and terminologies. Will be posting a different episode next week.

Link – Episode 1

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net

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

GUI Testing

When I read the definition about one of the course topics, Test Automation, on Wikipedia, Graphic User Interface (GUI) testing had made me curious since I hadn’t tested the GUI “formally” before. In the past, I only tested the basics like the behaviors of the components, the expected outputs, and the layout of the GUI. In order to understand more what I should do when testing GUI, I chose a blog that had a complete guide about GUI testing. I hoped that after reading this blog, I could learn the ways to test the GUI correctly. Below is the URL of the blog.

https://www.guru99.com/gui-testing.html

This blog explained the definition of GUI and GUI testing, the purpose, and the importance of GUI testing. It also provided the checklist to ensure detailed GUI testing: checking all the GUI elements, the expected executions, correctly displayed Error Messages, the demarcation, the font, the alignment, the color, the pictures’ clarity and alignment, GUI elements’ positions for different screen resolution. Moreover, it mentioned about the three approaches of GUI testing: Manual Based, Record and Replay, and Model Based. It also included a list of test cases and testing tools for GUI testing and its challenges.

After reading the checklist, I recognized that there is one test case that I never paid attention before: checking the positioning of GUI elements for different screen resolution. This mean that neither images nor content should shrink, crop, or overlap when the user resized the screen. When I thought about it, it really made sense that users probably would not use the application again if it was hard to read the content or see the pictures just because their phones/PC/laptops did not have the same screen resolution as the default screen resolution the developers set up. Therefore, it was important to remember to test the GUI elements’ positions for different screen resolution. I would remember it and apply it the next time I tested GUI.

About the approaches of GUI testing, I only had done manual based testing and model based testing. Record and Replay approach was interesting in my opinion, where I could “record” all the test steps at the first time, then “replay” it whenever I wanted to test the application again afterward. The blog did not provide a lot of information about this approach beside the brief introduction and a link redirected to one of the tools used for this approach, which was called QTP. Since I had not used it before, I did not know about its advantages and disadvantages. Therefore, I would have to research and try it first before deciding to use it in future.

From the blog CS@Worcester – Learn More Everyday by ziyuan1582 and used with permission of the author. All other rights reserved by the author.

In “TDD Guided by Zombies”, James Grenning shares a seasonally-appropriate acronym for developing unit tests — just in time for our class to wrap up its unit testing section!  ZOMBIES stands for Zero, One, Many/More, Boundary behaviors, Interface definition, Exercise exceptional behavior, Simple scenarios/Simple solutions.  The first three letters (Zero, One, Many) describe, in order, the complexity of the behavior undergoing testing — for example, a queue with zero, one, and then many entries.  The second set of letters (Boundary, Interface, Exercise Exceptions) give the order in which to build test cases — start with boundaries, design the interface undergoing testing (or ensure that the code meets the interface requirements), and then test exceptional behavior.  The last letter tells the tester to create simple scenarios with simple solutions — add the minimal possible behaviors to production code in order to pass the tests generated by the first six parts of the acronym.

Grenning spends the bulk of the article on an example of a circular queue implementation in C++, showing how he progresses through each step.  He gives clear examples of both what to do and not to do.  However, I’m more concerned with the underlying principles and process, so in the interest of brevity I’ll skip a detailed review of his example and simply say that it’s thorough and worth a longer period of study.

I chose this article not just because of the season (or that it coincides neatly with our in-class work), but because it helps to answer the question of how.  We’ve learned many methods for generating unit test cases, but how do we pick the order?  How do we work backwards from tests to code in a way that makes sense and satisfies the specification that we’re handed?  This confirms what I learned in 343 last year: ZOMBIES are the key to TDD and to successful unit testing.

And what can I, as a learner, take away from this?  Firstly, and perhaps most trivially, it can help to wrap important concepts in cute acronyms.  It makes sharing and remembering knowledge easier.  Secondly, it clarifies the most important sets of values to test, and the most important times at which to test newly-instantiated objects (or other language-apprpriate constructs): when they are fresh and empty, when they have a single value, and when they contain many values.  Thirdly, the article really drives home the importance of minimalism in testing and test-driven coding.  If a simple solution is all that it takes to meet the specification, then use it.  If a complex solution can be simplified, simplify it.

This semester and onward, when I need to develop unit test cases, I’ll be thinking ZOMBIES.

Article link.

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