For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

For this weeks blog post I found an interesting blog that listed 6 user testing methods that may seem unusual to others. User testing is a very important part of any good software project, it reveals any bugs you may have skimmed over or glitches for that matter because of this you can make a cleaner product. Using a prototyping tool to user test with interactives wireframes and high-fidelity prototypes you will know exactly how users interact with your app before the real thing is even built. If you were to publish something, then change it later it’ll be much more expensive to change the finished product than a product. The site goes on to mention computer-based testing software but goes on to say human testing is much better considering you are making something for humans to consume/use. The first method they list is participatory design, this essentially is when end users are involved from the very early stages of the design process, working together with you or the design team to define the product you make. Instead of the you are imagining yourself in the shoes of the user, you put the user in the shoes of designers. The second testing method they list is something bit unusual, Drunk people. This may not be the best but what they list is a pretty interesting idea. The testing method involves you testing you own wireframes. Interactive prototypes such as wireframes and more are the way to go when it comes to testing, these prototypes will help you introduce user testing throughout the various stages of development helping you along the way. The next testing method they list is Triading, which is essentially you trying to get the user to compare and evaluate 3 different alternatives without you influencing them with your questioning. The 5^th method they go on to explain involves the users creating their own user tests. Here they referenced a Ted talk by Luis Von Ahn describing massive scale online based collaboration. The final testing method they mention is product reaction cards which is almost as simple as it sounds. Essentially the user gets exposed to the piece of software then given cards with adjectives written on it where they are asked to describe the software using 3 – 5 of the cards. This is a super simple and helpful user based testing method that I like a lot actually. All in all this blog post was very interesting with all the simple user based testing methods anyone could conduct.

https://www.justinmind.com/blog/user-testing-6-methods-you-hadnt-thought-of/

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

https://testfort.com/blog/iot-testing-types-best-practices-through-reliable-testing-strategies

This blog post is about testing types and best practices for IoT devices. The market for these devices is growing at a fast rate and is continually changing. However, IoT testing is difficult because it requires a large base of physical equipment and knowledge about smart devices, IoT systems, and IoT test environments. Proven IoT testing approaches include compatability, security, beta, usability, and performance testing types.

Compatibility Testing

Compatibility testing should be a priority because IoT applications are run on innovative types of devices. This type of testing is necessary to protect software from vulnerabilities and system failures. An IoT testing team should have a well-equipped testing laboratory or take advantage of cloud environments.

Security Testing

It is important to test the security of IoT applications. There are three levels of testing:

• IoT device testing – makes sure that devices are protected from breaches related to APIs, authentication, updates, and setting configurations
• Network testing – protects the application from attacks on the network layer
• System testing – ensures that user data is protected from leakage and hacking

Usability Testing

Usability testing ensures that software is easy to use and intuitive. IoT testers need to make sure that an application is perceptive and configurable.

Performance Testing

Performance testing is used to test an application’s speed within an environment with large data loads. Testers can use cloud platforms to simulate large loads and generate non-standard scenarios to see how an application performs.

Beta Testing

Beta testing involves the development of realistic scenarios for IoT testing. Discovering failures and usability issues during beta testing helps increase the chances of a successful product release.

Overall I thought this blog post was interesting as I have never really thought about the special considerations for testing IoT applications. While I think this post did a good job explaining why testing IoT software is difficult, it could have benefited from being more specific. The author does not go into much detail as to how these testing strategies are uniquely used by IoT software. It serves more as a general overview for the goals of these testing methods. Regardless, after reading this blog I am interested in learning more about IoT software development and testing.

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

When I was reading about REST APIs, the acronym SOAP kept coming up. In this blog post, I wanted to learn more about what SOAP means and how it compares to what I’ve already learned about REST. The article that I am pulling information from, https://smartbear.com/blog/test-and-monitor/understanding-soap-and-rest-basics/, is a thorough resource, detailing features of each service and how each can be considered “better” than the other.

SOAP (Simple Object Access Protocol) uses XML, a language like HTML, to send requests to a server and receive responses. SOAP was designed to be extensible, with multiple acronyms coming with it to support different usages of the services, such as “WS-Security” or “WS-Coordination.” However, when using free, public web services, these extensions may not be necessary to come into play; it is simply convenient to provide extra functions if needed.

One potentially problematic feature of using SOAP has to do with the entry of XML for requests. Because the complexity of XML code to make requests, some programming languages have built-in support to handle such requests. However, some are not as forgiving and require manual building of the XML code. While SOAP has error handling (which helps to identify where the request went wrong, as well as potentially automate fixing such errors using standardized codes), it is still intolerant to errors caused from incorrectly building the XML. REST has more of an advantage here, because of its reduced difficulty when creating requests; instead of having to program an entire XML file (depending on whichever language you use), REST just uses requests through the URL. This results in faster performance with REST.

With this in mind, though, SOAP does provide other advantages. Coming with built-in error handling is certainly a leg up from REST, along with flexibility of services with other extensions that have different functions. While REST focuses more on quick performance and a lack of complexity, SOAP increases functionality and handles errors effectively.

It is also important to note that unless a developer is making their own Web service, most free and public Web services make it clear which access protocol they use, whether it is SOAP or REST. Even if the Web Service that I access for my final project already has a defined access protocol (which is REST), I am glad to understand more about other options out there for different services available.

From the blog CS@Worcester – Hi, I'm Kat. by Kat Law 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.

This week I read the pattern “Create Feedback Loops”. I thought that this pattern was the most one of the most practical of the ones that I’ve read so far because there are so many ways that this could be applied. I also think that this is one of the most crucial patterns that everyone should apply because it has the power of significantly shortening the time it takes to learn, as well as pointing out any potentially catastrophic errors in the way that things get done.

A great thing that this pattern was able to do was telling us some mechanisms that are available for acquiring this feedback. The ways of getting feedback included test driven development (TDD), using type-checked languages, as well as just simply asking a colleague. Of those provided, my favorite is TDD. I am a huge fan of TDD because it gives you instant feedback letting you know that the functionality is implemented correctly, but even more important than that, it lets you catch regressions even faster. I find that TDD is even more effective when someone else has written the tests, and when there are negative tests cases written as well. Fortunately this is something that nearly every tech company practices so I will not have to convince anyone of it’s value. The method of getting feedback that can be the most daunting is asking a colleague or boss, but it can be very valuable. It can be difficult to honestly assess yourself (as this pattern stated), so having the opinion of someone else can help give you a more true vision of your performance. When it comes to asking another for their opinion, the author hit upon a very important idea which is essentially that the given feedback must be “useful”. So if the feedback that you receive is negative and there is no way to grow using this feedback then it is absolutely worthless.

I agree completely with this pattern, and it is one that I intend to use throughout my career. The learning potential using this pattern is extremely high, and if applied correctly will lead to extreme success!

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