So, I was reading a blog called Awesome Testing the other day, (really clever name, I know, it’s what caught my attention) and I saw a whole section of pages titled “TestOps”. Intrigued, I ventured further by reading the posts, which led me to the initial blog post that coined the term, by Seth Elliot. The short and sweet of it is that originally testing can be represented by this diagram:

The tests are created, they are run on the system, the results are obtained, the results are checked against the ‘oracle’, and an assessment is completed. However, the interesting thing is the current trend in software products. The most popular products now a days are not simple programs, but are actually services. Facebook, Amazon, Twitter, etc. With this new change, testing becomes a bit more different. Big Data concepts are used, new features are tested with exposure control and monitors. This becomes the new model:

The testing system becomes a whole architecture testers are serviced with maintaining and using. This whole post was incredibly interesting to me. As someone new to Software Testing, my experience up until now has been discrete test cases and suites. With TestOps however, testing becomes a whole new beast. Using Big Data techniques to test how well a service is doing, not just if it runs correctly was a definite surprise. As someone who is currently dipping their toes into Big Data as I take a Software Quality Assurance course, I didn’t expect the areas to meet like this.

The final paragraphs of the post describing how this development is also blurring the lines between tester and developer is exciting. There was the worry in the back of my head, that software testing and development were two divided areas. That one had to choose one or the other. But knowing how much they will intermingle in the present and future helps alleviate this to a great extent.

It also makes a large amount of sense. As the software being tested becomes much more dynamic, testing must as well. Not just testing if software is working, but working well is quite the interesting distinction that requires more complicated solutions. These tests will require a process similar to software development to create. Choosing the right kind of Architecture, using tools similar to software process management tools to cut down on the time QA requires to make new tests or change existing ones, and the continuous updates and integration.

The incredibly interesting blog post can be found here: https://dojo.ministryoftesting.com/lessons/the-future-of-software-testing-part-two

The original blog post that sent me to it: http://www.awesome-testing.com/2016/07/testops-missing-piece-of-puzzle.html

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.

Gregory Falco: Protecting Urban Infrastructure Against Cyberterrorism

         This article from MIT shows the story of Gregory Falco who is a PhD student that works with urban planning and computer science. The article talks about the IoT (Internet of Things) where everyday objects are embedded with the basic functions of communications to other devices through the internet. Falco works with getting this project off the ground and around the world to other countries so that everyone can have the positive effects of this technology. He says it will help solve their problems with sustainability issues and social problems. However, there were concerns with security of this new system as it is possible for new technology to be susceptible to hacking. Falco continues to explain in the article that IoT devices usually have little to no real security software as they only have small amounts of memory and low-power processors. This can become a “gate” for hackers to exploit bigger systems as they may all be linked on one network. Falco is working on the industrial controls and embedded systems within the IoT such as automatic switches. He goes into detail of all the dangers this hack could create for a variety of people. IoT devices can control anything from subway switches to insulin pumps which puts a large number of people at risk.

            I chose this specific article because it was really interesting that as technology gets to be smaller, we are running into roadblocks like this. This is a very important roadblock because it shows that we need to develop technology to meet these needs faster or many people could lose lives. I found it was interesting how hackers can exploit the smallest flaw in a system to extract dangerous information. I think that the resource was quite interesting and made me more aware to the dangers of having little no security on devices. I feel that technology needs to have some sort of real security behind it as we are constantly relying on for our life functions such as water grids and electric grids. I learned quite a bit on this material from how much technology is taking over our lives to how insecure and manipulated it can get. This helped show me the side of hacking where even small flaws within a system can be used to hack into a much bigger system. It can be important to learn this sort of material because it really shows you to be careful when designing programs and working with networks to make sure that you know what data to keep private vs public. If you give the user access to public data, they can use it to break the system and cause a lot of damage to the program.

From the blog CS@Worcester – Student To Scholar by kumarcomputerscience and used with permission of the author. All other rights reserved by the author.

We’ve been discussing this in class for the past couple of weeks so I thought this would be a good topic to reflect upon. Unified Modeling Language, or UML, can be described as the graphical representation of a program’s structure. This is useful for documenting relationships of, for instance, objects and classes in a given structure. Furthermore, UML diagrams can provide general descriptions of the intended behavior and purpose of these classes and objects.

I felt it would be useful to learn more about how to make the “ideal” UML diagram, and Bellekens has a good blog in regards to this topic.

GeertBellekens: UML Best Practice: 5 Rules for Better UML Diagrams

The blog is a good read on the subject because it emphasizes the importance of consistency as well as simplicity when designing UML diagrams. Five general “rules” were discussed in Bellekens’ blog. I will summarize these below while simultaneously providing my personal takeaways from each of them.

Less is more.

When designing UML diagrams, it is important to provide the user with information that is clean, easy to follow, and straight to the point. If a diagram has too much going on, it is bound to confuse and overwhelm the user with excessive information.

No crossings.

Bellekens explains that when designing a UML diagram, there is no need for lines to cross when pointing to the various objects within the structure. Instead, enough space should be allocated to prevent this line crossing from happening. If one is unable to find the space to prevent crossing, this is often a good indication that there’s too much going on in the diagram in the first place.

Orthogonality.

While it is possible to make diagonal lines when pointing from one object to another, I feel it does not nearly look as clean as straight lines and right angles. Other than a few minor exceptions, such as pointing to notes, Bellekens suggests to avoid making diagonal lines in UML diagram at all costs.

Parents Up.

In regards to inheritance and other hierarchies, “parents/superclasses” should always be above their “child/subclass” counterparts. This makes sense to me because whenever I think of something such as a UML diagram, I think of a family tree; oldest on top, youngest on bottom.

Tidy Up.

A great closing argument to Bellekens’ five rules of UML diagrams. Maintaining the validity of UML diagrams and keeping them up to date is just as important as designing a solid graphical representation of our programs in the first place. A UML diagram that is outdated and cluttered with unnecessary information can be frustrating to say the least. Furthermore, keeping objects aligned in an orderly way makes UML diagrams easier to follow and pleasing to the eye.

I look forward to learning more about Unified Modeling Language Design in the upcoming weeks – I am sure I will use Bellekens’ tips on creating solid UML diagrams in the near future!

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

We’ve been discussing this in class for the past couple of weeks so I thought this would be a good topic to reflect upon. Unified Modeling Language, or UML, can be described as the graphical representation of a program’s structure. This is useful for documenting relationships of, for instance, objects and classes in a given structure. Furthermore, UML diagrams can provide general descriptions of the intended behavior and purpose of these classes and objects.

I felt it would be useful to learn more about how to make the “ideal” UML diagram, and Bellekens has a good blog in regards to this topic.

GeertBellekens: UML Best Practice: 5 Rules for Better UML Diagrams

The blog is a good read on the subject because it emphasizes the importance of consistency as well as simplicity when designing UML diagrams. Five general “rules” were discussed in Bellekens’ blog. I will summarize these below while simultaneously providing my personal takeaways from each of them.

Less is more.

When designing UML diagrams, it is important to provide the user with information that is clean, easy to follow, and straight to the point. If a diagram has too much going on, it is bound to confuse and overwhelm the user with excessive information.

No crossings.

Bellekens explains that when designing a UML diagram, there is no need for lines to cross when pointing to the various objects within the structure. Instead, enough space should be allocated to prevent this line crossing from happening. If one is unable to find the space to prevent crossing, this is often a good indication that there’s too much going on in the diagram in the first place.

Orthogonality.

While it is possible to make diagonal lines when pointing from one object to another, I feel it does not nearly look as clean as straight lines and right angles. Other than a few minor exceptions, such as pointing to notes, Bellekens suggests to avoid making diagonal lines in UML diagram at all costs.

Parents Up.

In regards to inheritance and other hierarchies, “parents/superclasses” should always be above their “child/subclass” counterparts. This makes sense to me because whenever I think of something such as a UML diagram, I think of a family tree; oldest on top, youngest on bottom.

Tidy Up.

A great closing argument to Bellekens’ five rules of UML diagrams. Maintaining the validity of UML diagrams and keeping them up to date is just as important as designing a solid graphical representation of our programs in the first place. A UML diagram that is outdated and cluttered with unnecessary information can be frustrating to say the least. Furthermore, keeping objects aligned in an orderly way makes UML diagrams easier to follow and pleasing to the eye.

I look forward to learning more about Unified Modeling Language Design in the upcoming weeks – I am sure I will use Bellekens’ tips on creating solid UML diagrams in the near future!

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

https://blog.codinghorror.com/unwanted-modeling-language/

For this week’s blog post, I chose a blog from Codding Horror where the writer, Jeff Atwood discusses his opinion on Universal Modeling Language (UML) and how he thinks that it is not an effective tool for organizing a program.

I picked this blog because we just went over the section on UML in class and why it is an effective tool to use. Since we’re learning it for our course, we are given mainly the positives about UML and how it can help us code. So I think it’s interesting that there is someone out there who has tried UML before and isn’t a fan of it.

Atwood states that his problem with UML is that it can be interpreted as subjective, which he feels doesn’t fit with programming since it is not subjective. Another point the writer brings up is that UML isn’t bidirectional and that if UML changes the code isn’t automatically changed and vice versa. Atwood also believes that UML does not have any advantage over other forms of documentation. However, these are all one person’s opinions. That does not make everything Atwood is saying about UML a fact, but it’s an interesting opinion to read about.

It’s interesting to get another perspective on UML after learning about it in class, and I think that Atwood is valid to feel this way because the same form of documentation is not going to work for everyone. People prefer different ways to document code and will work with what suits them best. Atwood doesn’t speak for everyone when it comes to using UML and his opinions on it aren’t the only opinion. There are many people out there who think that UML is an effective tool to organize.

This blog does not deter me away from using UML because I haven’t tried using it in depth yet so I can’t say if I will find UML effective or not, but from what I read about UML in class, it seems like a helpful modeling tool to make planning code more effective. I may love UML and use it for all of my programs in the future, or I could be like Atwood and prefer something else.

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