Source: https://blog.lelonek.me/how-should-we-do-code-reviews-ced54cede375

This week’s reading is a blog about conducting code reviews properly by Kamil Lelonek. It gives a general overview of code review as a process of giving feedback about another person’s code. By utilizing this process of rejecting and approving certain changes to the codebase, it will generate improvements as a whole. However, it goes much further beyond code review as it is not as simple as it seems. Even though benefits such as catching bugs early and ensuring that the code is legible and maintainable moving forward. The post makes it important to realize that developers are very protective about the code that they write and will attempt to defend against criticism. So, it provides different approaches to mitigating problems that could rise while undergoing code review. The benefits of these approaches should be able to correctly reach out without appearing as a threat. Some of these techniques would be to distinguish opinions from facts, avoiding sarcasm, and being honest with yourself. Also, by understanding the ten tips provided, it should make code reviews more effective for everyone involved.

What I found interesting about the article is how straight forward it is towards addressing one’s ego. They are right when they say that developers would like to say that they have wrote good code but sometimes they need to leave the ego behind them. By not opening themselves to criticism and addressing it as threats is detrimental to the team as a whole. Also, when actively code reviewing, I can see that providing evidence for nitpicking at certain lines of code should make it easier for the reviewee to understand what you are addressing specifically. However, I believe that avoiding jokes and sarcasm should be remembered as top priority. Especially when you are reviewing code for a friend. Recalling from personal experience, I do believe I did not help my peer to the best of my abilities by using sarcasm during code review. This also applies to distinguishing opinions from facts where sometimes through practice, you are led to believe that one technique is better than another. In conclusion, these tips are great for improving code review sessions.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.

This week I read a post of Joel Spolsky, the CEO of Stack Overflow. This post talks about the term “simplicity” when we refer it to a software product. There have been an old ‘80/20’ rule meaning that 80% of the people use 20% of the features. So, you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies. Unfortunately, it’s never the same 20%. Everybody uses a different set of features. In a period in the past, dozens of companies tried to release ‘lite’ word processors that only implement 20% of the features. Most of the time, they gave their program to a journalist to review, and the journalist reviewed it by writing their review using the new word processor, and then the journalist tried to find the ‘word count’ feature which they needed because most journalists have precise word count requirements, and it was not there, because nobody in the target 80% would use this feature. The journalist ended up writing a story that attempted to claim simultaneously that lite programs were good, bloat was bad, and he could not use this program because it would not count his words.

Making simple with 20% feature products is an excellent bootstrapping strategy because you can create them with limited resources and build an audience. So, you sell “simple” as a wonderful thing and coincidentally, it’s the only thing you have the resources to produce. Bootstrapping strategy has advantages in certain situations, however, it would not be good for long term strategy because there’s very few obstacles to prevent the next two-person startup from cloning your simple app, and because eventually you can’t fight human nature of wanting the features.

Success is a result of a combination of things: building an audience, evangelism, clean and spare design, emotional appeal, aesthetics, fast response time, direct and instant user feedback, program models which correspond to the user model resulting in high usability, and putting the user in control. All of these features share a common character of having benefits that customers like and pay for, but none of them can really be described as “simplicity.” With many years of experience running his own software company, Joe Spolsky saw that nothing he have ever done at Fog Creek has increased the revenue more than releasing a new version with more features. When a new version came out with new features, there was a sudden, undeniable, substantial, and permanent increase in revenue.

It is fine to use the term “simplicity” to refer to a product as meaning that the user model corresponds closely to the program model, so the product is easy to use. More, it is fine to use the term “simplicity” to refer to a product with a spare, clean visual appearance. However, if you think simplicity means “not very many features” or “does one thing and does it well,” you can’t go far with a product that deliberately leaves features out.

Article: https://www.joelonsoftware.com/2006/12/09/simplicity/

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

This blog from Microsoft Developer is related to what we are doing in class, specially to the final project. “Simplify REST API development for modern Single-page apps with SQL Server” by Jovan Popovic, talk about Single page app architecture, persisting JSON models in database.

First is single page app architecture – end-to-end, similarly to what we are doing in class, there are 3-tier pattern architecture in single-page applications.

Client-side is from users view, from web apps or mobile apps, this using frameworks or library such as Angular, JQuery, ect. This side executed and communicate with some middle application via REST API, then provides or accept data as JSON. JSON requests obtained from client-side and create some SQL queries to get or store data to the database.

If the client wants to get the data from the database, developer would need to add a few sub-layers in the applications layer. Developer would have some data access component to execute the query and fetch data, then some kind of “view model” to view the results of the query. The objects would take that information in JSON format to display to the client.

Second part is Persisting JSON models in database, as we know many modern web applications is running on the client side. We can use frameworks that enable developers to maintain state of the application on the client side. When the application saves the state being sent to the app layer via REST service.

To save the state provided by client-app, developer need to analyze JSON text from the client, use some data transfer objects and save data transfer objects into the database.

This blog cover mainly back-end of REST API. To show Built-in JSON functions in SQL and SQL Database, enable you to simplify your application layer code and work with database using the format that is already used on your client-side apps. I thought this blog somewhat useful since we learned about Angular, Node.Js and SQL in database class. I want to learn how all that fit in with each other. Web design really good and useful skill to have, specially this is how we view the internet though our eyes.

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

We learned few techniques of testing in class such as Boundary Value Testing, Decision Table-Based Testing, Path Testing … however there are other techniques. In this article,  “Test Design Techniques overview” there are other techniques like Classification Tree Method, State Transition Testing, Cause-Effect Graphing, Scenario Testing. Different techniques are useful in different scenario.

Classification Tree Method. When to use it: we are testing hierarchically structured data or data in a form of a hierarchical tree. Identification of test relevant aspects and their corresponding values, then combination of different classes into test cases. Draw hierarchical classes as graph as shown below, then make projections of tests on a horizontal line using one of the combination of strategies.

           State Transition Testing. When to use it: a tester is testing the application for a finite set of input values, also test sequence of events that occur in the application under test. This will allow the tester to test the application behavior for a sequence of input values.

            Cause-Effect Graphing. When to use it: To Identify the possible root causes, the reasons for a specific effect, problem, or outcome. To set up, identify conditions and effects, draw the graph with all logical dependencies and constraints. Convert the graph into the decision table, tracing each combination of causes that lead to an effect from the effect. This technique helps us to determine the root causes of a problem or quality using a structured approach.

           Scenario Testing. When to use it: to help understand a complex system to test better where in the scenarios are to be credible which are easy to evaluate. Tester put yourself in the end user’s shoes and figure out the real-world scenarios and use cases. Before using scenarios for creating test cases, they are layout described using a template. Then create specific test cases using equivalence partitioning and boundary values techniques.

I like this article because the simple structure, and information with example. In the “Specification-Based Testing Techniques” section, different techniques divide into different group, and which scenario fit better to techniques. I think it’s would be better if there are example with the source code. We can look that the Test Techniques with real life scenarios, to have better understanding.

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

For this week’s blog post I will be looking at another design pattern, this time called Façade. This time once again from the handy site of SourceMaking.com. The overall intent of the design pattern is to provide a unified interface to a set of interfaces in a subsystem. It defines a higher-level interface that makes the subsystem easier to use, wrapping a complicated subsystem with a simpler interface. The problem that faces it is a segment of the client community needs a simplified interface to the overall functionality of a complex subsystem. Essentially façade discusses encapsulating a complex subsystem within a single interface object, thus reducing the learning curve necessary to successfully leverage the subsystem. The only access point for the subsystem will limit the features and flexibility that power users may need. The façade object should be a fairly simple facilitator. “Façade takes a “riddle wrapped in an enigma shrouded in mystery” and injects a wrapper that tames the amorphous and inscrutable mass of software.” With the quote from the site above the name really comes into play here. A good example of this would be something like that of a catalog. Where the consumer calls one number from the catalog and speaks with costumer service. The customer service representative acts as a façade, providing an interface to the order fulfillment department, the billing department and then the shipping department. Façade defines a new interface where in the Adapter design pattern it uses an old interface. The site/article then goes on to explain some general rules of thumb that can prove useful to those wanting to learn more or follow the design pattern even more. All and all the site is an excellent resource for anyone looking to learn more about design patterns and more with this article proving that with valuable information on a new design pattern I have not seen or used before.

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

Acceptance Testing

For this week’s blog post I will be discussing another form of testing called Acceptance testing. Acceptance testing is a form of testing where a system is tested for overall acceptability. The reason for this is to see if the systems compliance with certain business requirements and assess whether it is acceptable for delivery. The site shows a helpful diagram illustrating when you uses this testing, with Unit Testing on the bottom, Followed by Integration testing above that, System testing above that and with Acceptance on that the top of that one. The site also gives a good analogy of what it is exactly happening with the illustration. During the process of a ballpoint pen, the cap, the body, the tail and clip, the ink cartridge and the ballpoint are all produced separately, and unit tested separately. After this they are assembled and begin integration testing, with System testing following this. With of course Acceptance testing last to confirm once more that the pen is ready to function properly. Black Box Testing is the most common method used in performing Acceptance Testing. The testing does not follow any strict procedure and is not scripted but is rather ad-hoc testing. Ad-hoc testing is random testing or Monkey testing, essentially throwing stuff at a wall trying to see what sticks and what does not. You perform this testing after system testing like mentioned above in order for the system to be made available for actual use. Internal Acceptance Testing is performed by members of the organization that developed the software but who are no directly involved in the project, usually this is members of the Product Management, Sales or Customer Support. The opposite end of this is known as External Acceptance Testing where it is performed by those who are not employees of the organization that developed the said software. This is then broken up into two different fields, Customer Acceptance Testing and User Acceptance Testing. Customer Acceptance Testing is a pretty self-explanatory name where it is performed by those who purchased the software or are customers of the company that developed it. User Acceptance Testing is performed by the end users of the software, customers’

Customers essentially.

All and all this website was pretty well organized and explained everything very clearly and so forth in a manner where it made extremely simple to read and understand.

http://softwaretestingfundamentals.com/acceptance-testing/

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

From the blog Sam Bryan by and used with permission of the author. All other rights reserved by the author.

Hello reader!

Today’s blog,  will discuss the differences between Unit, Intergration, and System testing. I will briefly explain the benefits for each test, as well as pointing out their distinct features. I will also be sharing my analysis of Software Testing Fundamental’s-“Software Testing Levels” article from which I read. Let’s begin!

Software testing levels are various phases of the development sequence in which the testing is conducted. The main goal of system testing is to assess the system’s agreement with the specified needs. There are different testing levels that help check behavior and performance. These testing levels are designed to see missing areas and accordance between the development lifecycle states. There are three levels of software testing that I am going to talk about: Unit, Integration, System, and Sytem Testing.

Unit testing is a level of the testing process that tests individual units of a software. The goal is to show that each unit of the software works as designed. Intergration testing is a testing process that combines and tests individual units as a group. The goal of this level is to show faults in the interaction with integrated units. System testing is a testing process in which a program is tested for acceptability. The goal is to evaluate the program’s agreement with the business requirements and to see whether it is acceptable for delivery.

These three testing types cannot just be applied randomly during the forming process. There is a sequence that should be considered to in order to lessen the risk of failures. By increasingly testing the more simple things in the system and moving on to the more complex things, the testers should know that they are carefully examining the software in the most efficient ways possible.

Testing early and often is definitely worth the effort. Having a efficient approach to testing allows the tester to find any faults in the system sooner, which leads to less time and less money wasted later on.

Software Testing Fundamental’s-“Software Testing Levels” was written very well and it was very easy to understand. It taught me a great amount of these three types of testing. I hope I was able to extend what I learned in a informative way.

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