https://www.toptal.com/freelance/why-design-documents-matter

This week I read on why writing a software design document matters. This blog goes through the steps of what is needed in a design document. The program idea could start with a call or Skype meeting between the programmer and the client, with the client telling the programmer what he wants in the programmer. The programmer is then left to create the program once and outline is created, and meets up with the client one last time when the program is finished to make sure it is what he wants. Chris Fox, the author of the blog entry, goes through each of the steps with a brief summary and a picture or diagram of what each of the steps would look like. The specification of a software design document show that the design goal of the project is going to be. This is created by the developer and the client on what is needed to be done and how the program or in this case application should work. The interface is the framework of the application. This is also the most problematic trying to get it to look perfect to what the client wants. Functionality how the application works and what it is supposed to do. Milestone, what the application is supposed to do once finish. The blog also gives examples of outlines for the document which features all of the steps. The outline should include the goals of the program, the function of the program, the users’ interface, and its milestone.  The author’s example of a UI description that he used was for an app used on an iPhone. The description included a navigation bar that controlled the app and where to go to different locations of the app, and a table of a layout of what will appear on the screen of the phone, including images and texts. Steps may change overtime as the application is being designed and programmed. The author gives us these steps and what to do as an example of a free lancer with one client.

This was another interesting blog. This blog showed another reason why we need a design map or outline for any programming. The diagrams show how the steps for the outline works, whether it is written on paper or typed up on the computer, both show the outline for the program and how it is expected to run for the user. Not only does this design work for programming site, it also works with programming applications. This shows that you need a design outline or diagram before creating any kind of program. This blog gives another method for designing a program. I would probably create an outline of what the program needs to do and how it should run, create a UML diagram for it then try to create the program itself.

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

After the last post my mind has been on the future of software testing, but after a week or so it’s taken a bit of a journey and now I’m wondering about my future in software testing. And as it usually does when I think of the future, negativity is on the forefront. Which is why potential pitfalls are something I’m really interested in. So wonderfully, I found a helpful post on Awesome Testing listing possible software testing traps and describing them. The ‘traps’ in this case are mistaken implementations or uses of software testing that lead to very unfortunate results, based on the authors own experiences and what he has read or discussed with others.

It is incredibly interesting seeing the ways companies mistakenly attempt to optimize use of testers. Rating them on the amount of bugs found or incentivizing them to find as many bugs as possible only were issues that seem obviously awful to me, but I have hindsight on my side. A good amount of the traps were something I didn’t consider, issues with not having developers do any testing themselves. By leaving only testers as the ones to run tests and do quality assurance, it led to developers using testers being turned into scapegoats for issues or testers becoming a commodity that is moved around too often to do their job correctly.

Trap number three shows the human side of the process, to me at least. If testers make bad tests and have to constantly fix them, or the tests offer very little information due to their issues, then developers become disillusioned with them. It becomes safer and more likely for the tests to become more and more ignored. Software testing is not just finding bugs in programming, it must do so reliably and in a way that aims for improvement. Developers and testers are also not as  clear cut as one would think. Or they shouldn’t be, at least.

I feel much more confident now knowing many of the issues that one can accidentally fall into in the process of software creation and testing, and how to possibly avoid them. I also found the idea of testing not simply being about finding bugs, but just a part of a greater system working towards an end goal of a wonderful software product insightful. It is incredibly useful to understand the full Software Engineering Life-Cycle no matter where your job lands on it.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

This week I have decided to read about “Design Smells” from Bartek’s Coding Blog. So, while   this blog is rather short, the reason why I have chosen this one in particular is because recently in my studies, my biggest question that how do people figure out the errors of a design without testing or even refactoring. I want to understand the logical thinking in recognizing the errors that point to a wrong design.

This blog post basically goes over seven hints of design smells that points to places that the code is not going as intended. These seven hints are rigidity, fragility, immobility, viscosity, needlessly complexity, needlessly complexity, and opacity.  For rigidity and fragility, they point to the belief of a simple change will fix everything but other unexpected things can happen and the code can fall into pieces. Immobility and viscosity, on the other hand, point to “moving” and using codes to be improving the design but preserving it while implementing new features might be difficult. Needlessly complexity and repetition are easy to understand. They point to implementing something complex and copy and paste that is not needed at all. As for the last hint, Opacity, points to making a code clear and easy to understand.

So, based on the blog post with the insights I find behind it, I would say this was a simple but interesting blog to read. The author explained each of the seven hints with a simple take of every day programming work while giving the literal term along with it. From my experience in finding something wrong in a design, it’s usually testing which takes a considerable amount of time depending on how much writing there is into it. If there are unrelated errors occurring within testing, then it would be where I will try to figure out which part of it is the source of the problem and then try to debug it as much as possible.

From this blog about design smells, what I learned is that to avoid conflicted attention described by the hints, there should be consideration always in preserving the original design codes. The ideas that I have been taught is while it might be inconsistent to use the codes like that, there is no need to be “afraid” in both using general codes for future reference and bending the original design a little to improve the programming process. Learning the ideas from this blog shows me that for future practice, I should try to find features implemented in designs and trace down codes that give a complexity on the urge of repeating itself. That way, I can try to get the simple thinking of identifying problems without having to recreating codes like that. With this knowledge, I hope to assist others with great analyzing and fix codes better than I used to.

-Dennis Tran

Link to blog: http://www.bfilipek.com/2012/11/design-smells.html

From the blog CS@Worcester – Onwards to becoming an expert developer by dtran365 and used with permission of the author. All other rights reserved by the author.

There’s a small company out of Estonia that is making a big splash in the world of software testing.  Testlio was founded after CEO Kristel Kruustük was on the team that won the 2012.  A September 15th 2017 article by zdnet.com does a profile of the CEO and the company to provide insight on the software testing company’s mission and outlook on testing (http://www.zdnet.com/article/how-testilio-wants-to-rethink-software-testing/).  The CEO Kruustük worked at several companies around the world and noticed flaws that she saw within the software testing community.  Kruustük and her company take a different approach to their hires and their view toward junior level testers.  Testlio has found that companies that had strong diversity in their employees also had a clear improvement in their productivity.  Testlio has implemented this diversity hiring practice at their own company and have found the same increase in productivity.  Another practice that Testlio follows is putting more emphasis on junior level testers and move away from senior testers.  While Testlio has aggressively embraced this outlook on hiring youth it may not be what most people think..  Kruustük goes on to explain that this is not necessarily just the age of the tester or how long the tester has been in the business, but staying away from testers that have been in the same position and are less willing to try different methods or take advice from outside sources.  Kruustük and Testlio does not see testing as just a mundane task that has to be done, but instead as its own separate business.  This mentality has allowed Kruustük to grow Testlio into a business that has two offices, one in San Francisco and the other in Tallinn.  They also have 200 testers that work with roughly 650 million monthly users.  With the number of users and testers that Testlio has it is hard to deny that their unique approach to testing and employment process yields significant results and is part of a sustainable business model.  Testlio is a new company that is embracing junior testers that it’s found are more open to new ideas and thinking outside of the box.  I have a feeling that Testlio is a company that will continue to grow as they open their doors to a younger more diverse workforce.  They will soon become a very common name in the industry and I think will be a pioneer for a new outlook on testing, embracing diversity, and constantly bringing in new talent to their ranks.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

The blog post this is written about can be found here.

I chose this blog post because it directly relates to the material we learned on equivalence class testing and our assignment based around it, and because it led me to a deeper understanding of what equivalence class testing is and the ways it can be applied more broadly. In it, the blog’s writer takes apart the Wikipedia article on equivalence class partitioning from a professional tester’s perspective.

The blogger defines an equivalence class as a set of things that have some quality in common that makes them more or less equally able to reveal a certain kind of bug, if it were present in the code. He writes that equivalence classes are not necessarily limited to classes of input data, even though common definitions of the concept characterize it that way. Instead, equivalence class partitioning can apply to anything you might be thinking of doing which has variations that could influence the outcome of a test.

The blogger takes issue with the Wikipedia article saying the technique is meant to reduce the number of test cases, since (as I learned earlier) the number of test cases tells you nothing. He writes that instead, equivalence class partitioning is a method that reduces test effort; and this is only a side effect of focusing test effort, which is accomplished by making educated guesses about where the bigger bugs are most likely to be. He stresses that the technique is based heavily on our mental model of a piece of software and that it’s a fallible method of testing.

I found it particularly useful when he used the real-life scenario of pushing against a door to try to open it as an example. If we push against one part of a door and it won’t move, we won’t try pushing every other spot on the door, because we intuitively understand that most places you can push on a door are more or less equivalent. Pushing once was enough discover it was jammed, and we feel confident in assuming that pushing elsewhere within the set of door spots you can push will have the same result. This thought process is the same as the one used in equivalence class testing.

Having read this post, I will make sure to have a good understanding how a piece of code is meant to work before I set about trying to determine the equivalence classes for it, and I’ll keep in mind that the concept of equivalence class partitioning can be used with things other than inputs.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

In this blog post, Harinath Kuntamukkala discusses different approaches to the Singleton pattern. The first implementation he goes over is the Bill Pugh Solution, which is similar to the implementation we learned in class except it uses a static inner helper class as in the example below:

public class Logger {
    private Logger() {
        // private constructor
    }
    // static inner class - inner classes are not loaded until they are
    // referenced.
    private static class LoggerHolder {
        private static Logger logger = new Logger();
    }
    // global access point
    public static Logger getInstance() {
        return LoggerHolder.logger;
    }
    //Other methods
}

This would be the best approach but it’s possible for more than one instance to be created with the use of Java reflection. For example:

public class LoggerReflection {
    public static void main(String[] args) {
        Logger instance1 = Logger.getInstance();
        Logger instance2 = null;
        try {
            Constructor[] cstr = Logger.class.getDeclaredConstructors();
            for (Constructor constructor: cstr) {
                //Setting constructor accessible
                constructor.setAccessible(true);
                instance2
                    = (Logger) constructor.newInstance();
                break;
            }
        } catch (Exception e) {
            System.out.println(e);
        }
        System.out.println(instance1.hashCode());
        System.out.println(instance2.hashCode());
    }

The solution to the problem suggested by Joshua Bloch, is to use Enum. The reason we use Enum is because Java ensures that any Enum value is instantiated only once. Using Enum, this is what the Logger class would look like

public enum Logger {
    INSTANCE;
    //other methods
}

It’s still possible for more than once instance to be created if a singleton object is serialized, then deserialized more than once. In order to avoid this you can implement a readResolve() method in the Logger Singleton class:

public class Logger implements Serializable {
    //other code related to Singleton
    //call this method immediately after De-serialization
    //it returns an instance of singleton
    protected Object readResolve() {
        return getInstance();
    }
}

The reason I chose this resource is because we are currently learning about design patterns and just reviewed the singleton pattern. This post goes into the best implementations of the singleton pattern and why that is, I would like to stay on-top of the most effective, clean and efficient implementations of design patterns. I think this is a useful post, and learned about the Bill Pugh Solution and the Enum solution to ensure there’s only one instance of a singleton object. The author concluded that the Enum approach is the best solution as it is

“functionally equivalent to the public field approach, except that it is more concise, provides the serialization machinery for free, and provides an ironclad guarantee against multiple instantiations, even in the face of sophisticated serialization or reflection attacks.”

I expect to take what I learned in this article and use it whenever implementing the singleton design pattern, and I might rework the code I have now to make use of the Enum approach talked about in the article.

The post Singletons: Bill Pugh Solution or Enum 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.

Integration Testing

When I read the blog entry about unit testing last week, the author had mentioned about integration testing as a tool to detect regressions. Since the topic of that blog entry was unit testing, I did not have a chance to research this type of testing. Therefore, I decided to choose integration testing as the topic for this week’s entry. Because I did not know much about this type of testing, I found a blog entry that had detailed introduction of integration testing. This blog was written by Shilpa C. Roy, a member of STH team, who was working in software testing field for the past nine years. Below was the URL of the blog entry:

http://www.softwaretestinghelp.com/what-is-integration-testing/

In this blog, Shilpa introduced the definition of integration testing, its approaches, its purpose along with the steps to create an integration test. In Shilpa’s opinion, integration testing was a “level” of testing rather than a “type” of testing. She also believed that the concept of integration testing could be applied in not only White Box technique but also Black Box technique. Beside the two approaches of this testing, which were Bottom Up and Top Down, she also mentioned another approach called “Sandwich Testing”, which combined the features of both Bottom Up and Top Down approach. Moreover, Shilpa gave an example how integration testing could be applied in Black Box technique.

I thought that the “third” approach called Sandwich testing was interesting. I always thought I could only test either top down or bottom up, but this really change my way of thinking. By starting at the middle layer and moving simultaneously towards up and down, the job was divided into two smaller parts, which was more efficient. Unfortunately, this technique was complex and required more people with specific skill sets so I really doubted if I could use it in the future. But the general idea that I could start the process at the middle part would be useful.

According to Shilpa, validating the XML files could be considered as part of Integrating testing for a product that we only knew its architecture. Since the users’ inputs would be converted into an XML formats then be transferred from one model to another, validating the XML files could test the behavior of the product. In my opinion, this example was easy to understand how integration testing could be applied in Black Box technique. I always thought that it could only be available for White Box technique, but this example had proved that I was wrong. Now that I knew about it, I could try to apply it the next time I encountered similar scenarios.

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

Today I will be summarizing and providing commentary on a blog post from The Developer’s Piece called “8 design patterns that every developer should know”.  I was immediately attracted to the title but I was even more pleased when I actually read the article; it not only provides clear and concise descriptions of each pattern, it also provides examples of each pattern in practice in the form of code chunks.  Among these reasons, I primarily chose this article to be the subject of this week’s blog post because it lists patterns that we have and will cover in class.  Like I said in my last post, nothing is better than when you have thorough understanding of why you are covering a piece of material in school.

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

In java, you can use one type as template of making another type. The new type can inherit all the same behavior as the original type. This is known as inheritance. Java class inheritance allows you to reuse existing type functionality and let you make modification in behaviors as it fit. Inheritance in the other words is when you design your classes by what they are rather than what they do. This is also term as “Is-a relationship” which sometimes can be misleading. For example, an SUV car or Sedan car can inherit the supper class base Car/ Vehicle on the “Is a relationship” functionality. The same time, it could be implemented based on the “Has- a relationship” functionality because, a car has a tire, break, engine etc. so when it comes to determining which one to implement, this becomes a little bit confusing. This seems to be very bad to me because the sub classes are base on the super or base classes and when something accidentally changes from the base classes, it automatically affects the sub classes.

Composition in the other hand is a design technique use to implement has-a relationship in classes unlike an inheritance which is an “IS A” relationship classes. Composition is basically designing the class base on what they do. According to Wikipedia, composition is a principle that classes achieve polymorphic behavior and code reuse by containing instances of other classes that implement the desired functionality rather than inheriting from the base or parent class.

Again, in composition, we can control the visibility of other objects to the client classes and reuse only what we need.

In general, composition is has-a relationship between objects, it is implemented using instance variables, code can be reused, it hide visibility to client classes and more importantly is it flexible to use.

Now, what do I learn from this study? I have come to learn that implementation of composition over inheritance basically start with the creation of various interfaces representing the behaviors that the code will perform.

I have also learn that inheritance will not only encourage you to go predicting the future which may or may not work but it also encourages you to built the branches of object very early in the project and you are likely to make a very big design mistake whiles doing that because we cannot predict the future even though we feel like we could. To me, inheritance is very bad way of designing classes as sub classes may inherit some functionalities from the supper classes which will never been used but cannot do away with it. With regards, I do not see myself designing a projects using inheritance unless for educational purpose project that will explicitly require me to use of inheritance. I will always go for composition when designing project with multiple functionalities.

Citations:

https://en.wikipedia.org/wiki/Composition_over_inheritance

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