User data that is stored on websites is very important to keep secured. Although there are some technicalities when signing up for websites that allow you to upload pictures, movies, or other media, you should always take certain precautions when uploading anything to online. Security breaches are no surprise and with massive social media websites such as Facebook, Twitter, or Tumblr, there are bound to be hackers trying to break in the back end to rob and dump data. Unfortunately, breaches like this aren’t too uncommon. Just recently, Facebook was hit with an enormous security breach. About 6.8 million users’ data have been exposed. With a company as large as Facebook, you would think that their security and software back-ends would be able to block attacks, however this is obviously not the case. So what exactly happened? A bug slipped through in the API, an overlook by the software QA team at Facebook.

Facebook released a statement saying that their Photo API had a very vulnerable bug that let app developers access the photos of over 6 million users. The worst part of it was, the bug wasn’t noticed until 12 days after it had occurred. Not only were the users of Facebook affected, but app developers that utilized Facebook’s Photo API also suffered the consequences of this too. Reportedly, there were over 1500 applications that utilized this API.

What can we learn from this? Software testing is not exclusive to how code or programs run, but it also applies to security. There are teams that are dedicated to only testing for security and backdoors in programming for this reason – so the end user can be confident in their products. One small error in the quality of Facebook’s Photo API caused a major breach with a ton of collateral damage. Over 700 app developers and over 6 million Facebook users were affected by this. Interestingly enough, this isn’t Facebook’s only massive data breach in recent times and their end users are definitely not happy about it. Repeated vulnerabilities like are not good and are detrimental to a software’s future in quality and security. Making sure that you have protocols in place that check for these is very important to avoid these types of situations.

Article: https://fossbytes.com/facebook-hit-by-another-security-breach-6-8-million-users-photos-leaked/

From the blog CS@Worcester – Amir Adelinia's Computer Science Blog by aadelinia1 and used with permission of the author. All other rights reserved by the author.

Today I learned more about the Iterator Design Pattern and how it specifically applies to Java. The reason for choosing this topic is that during my project and talking with others the Iterator has come up a number of times throughout this semester. Now, I already knew about the Iterator in Java from taking Data Structures, but I never realized it was a design pattern before this course. The Iterator is actually a Gang of Four design pattern and it is classified as a behavioral pattern with object as the scope (GoF 257). The article gives a short summary of the iterator pattern and the reason it is used in Java. It is basically a way of accessing elements in a collection in order without having to know about the internal representation of the structure, a nice way of using abstraction. The author then gives a nice simple example in Java of how to use the Iterator pattern to access a collection of elements. He does this by creating a basic shape POJO with an id int and String name and stores them in another class that is an array of shapes. He then creates an Iterator class that defines the next element and if there is another element after the current one. This may be my favorite design pattern I’ve seen yet. It is simple to implement, but yet effective at its purpose, especially the way this article showed its implementation. I really like that once you’ve created an iterator for a type, all you need to do is pass in a collection of elements to it in order to process it. When I was working on the backend for my project I realized the need for something like an Iterator, especially with all the endpoints that were looping through the whole database. I wish I had implemented this so that I did not have to keep rewriting conditions to check that the data wasn’t out of bounds. In the future when I create my own programs with collections of elements I will make sure to implement an Iterator so that I can easily cycle through the data without having to worry about how to do it or constantly bounds checking the collection.

Source: https://www.javacodegeeks.com/2015/09/iterator-design-pattern.html

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

Whenever I’m testing any of my programs that allow users to input data, I usually try to remember to enter invalid values to ensure that the program does not function when such values are put into the system. Then, in one of my lectures, we briefly covered fuzz testing, which does this process for you! So, I wanted to know more about it and why it is very important to include as part of testing. I found this information from the following tutorial: https://www.guru99.com/fuzz-testing.html.

Fuzz testing, or fuzzing, is used in the context of security testing, where loopholes or vulnerabilities are exposed. It can be a form of black-box testing, so that even without source code, the tester can still determine faults that come up.

The steps that fuzz testing takes to perform are as follows:

1. Identify inputs taken by the system to be tested
2. Generate random input or data
3. Executing tests using this data
4. Monitoring behavior of the system and its accompanying tests

There are multiple ways that fuzzed data can be created for use, including the 3 listed:

• Mutation-based fuzzing – alters already-provided, valid data samples to create new test data
• Generation-based fuzzing – creates new input data based on the type of input needed for the system
• Protocol-based fuzzing – based on the protocol format specified by the program, invalid data or packets are sent to the program being tested

Through fuzz testing, several different kinds of bugs can be uncovered, which go beyond simply finding invalid input. Some bugs may severely affect the security of an application, like causing memory leaks. Other bugs, called correctness bugs, may come up, which are errors in the overall function of the program. Because it can become time-consuming to come up with many fuzzing inputs, there are various tools that automate and speed up this process.

Fuzz testing provides crucial advantages. It can expose serious security threats and holes in the program which may not have already been covered. If there are other, possibly less significant bugs in the program that may have been overlooked, fuzz testing is a great way to find these as well. However, while fuzz testing is incredibly useful, it cannot be used alone. Rather, it can be a supplement for other testing strategies that may be used to enhance security testing or discover other bugs. Fuzz testing only really looks for simple errors that may arise from invalid input, but there can easily be other, more complex bugs in the program as well.

This post concludes my blogging for the fall semester! Thanks for reading, and I’ll be back next semester!

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.

This post will discuss more bad practices when coding that focus less on design patterns (post about anti-patterns here: https://kathleenmlaw.com/2018/12/03/some-software-development-anti-patterns/) but more so on problems in source code that may cause a bigger problem in the program, called code smells (reference found here: https://sourcemaking.com/refactoring/smells).

The most common code smells can be grouped into several categories. I have included 3 examples of each code smell that can arise, though there are other

• Bloaters – code (like classes or methods) that grows so large that it is difficult to work with
  • Long methods – methods longer than 10 lines are probably too long
  • Primitive obsession – use of lots of primitives in code rather than creating smaller objects, or many different constants
  • Long parameter list – more than 3 or 4 parameters used when calling a method
• Object-orientation abusers – code that incorrectly implements object-oriented concepts
  • Switch statements – switch statement has many cases, or conditional has multiple “if” branches in a row
  • Temporary field – only have a value when needed by objects in the program, and are otherwise empty
  • Alternative classes with different interfaces – two classes with the same function but only differ in method names
• Change preventers – code that, when changed in one spot, requires change in other parts of the code as well
  • Divergent change – changing many methods that are unrelated when making change to a class
  • Shotgun surgery – when making any changes to code, the developer has to make many other modifications to different classes
  • Parallel inheritance hierarchies – when creating subclasses, the developer has to create subclasses for other classes at the same time
• Dispensables – unnecessary code that would increase readability when removed from the program
  • Comments – when code is full of comments that it is difficult to even read the program
  • Lazy class – a class that doesn’t really have much function in the overall program
  • Data class – a class that only has fields and accessor/mutator methods and serves as a data collector for other classes to use
• Coupling – code that contributes to coupling (where one section of code may depend heavily on another section, and changes in the former results in forced changes in the latter)
  • Feature envy – when a method accesses data of another object more than its own
  • Inappropriate intimacy – when one class uses internal fields of another class
  • Message chains – when one method calls another, which calls another….

I have absolutely made several of these mistakes in my programs, so I’ll be sure to keep a look-out when coding in the future.

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.

When I thought of the word “mutation,” I tend to think of it with negative connotation as something that changes internal structure and can potentially cause problems with the structure later on. However, in software testing, mutations have a positive function. This post will go over how mutation testing works, and some advantages and disadvantages of using it. My reference can be found here: https://www.guru99.com/mutation-testing.html. When going over mutation testing during lecture, I found the subject very interesting, and this website provided great further information about it.

Mutation testing takes a program and changes around various statements (introducing faults) in the source code, so that when running unit testing or other testing suites on the program, the tests written for the original program should fail, if they had already passed before. So, when the mutant program fails the test case, then the mutation is “killed.” If the mutant program still passes the test case, then the mutant “survives,” and the tests should be written differently so that they not only pass the code that is originally written, but they also fail other possible scenarios, whether or not those other scenarios were explicitly written in the program.

There are many different kinds of mutations that can be created and used, and they fall under 3 categories: operand replacement operators (which replaces operands in an expression with another operand or with a constant value, like changing x > y to x > 5), expression modification operators (which modifies an operator in an expression, like changing x > y to x <= y), and statement modification operators (which modifies the logic of the program by changing or deleting different statements, like removing an “else” branch of an if-else conditional).

This method of testing provides several advantages. It can uncover missing test cases that weren’t already included in the test suite. It also points out the different places in source code which may be vulnerable to error. It looks beyond simply statement and branch coverage to find any faults which may be overlooked. This enhances the quality of software testing taking place on the program.

However, there are still some disadvantages of using this testing strategy. Because there are many places in source code where these mutations may take place, it would be tedious to manually insert the faults, and automation is a necessity. Time may also become an issue, because each mutation requires a run through the test suite. Finally, this method would not be appropriate for black-box testing, as it involves directly examining the source code.

From the blog CS@Worcester – Hi, I&#039;m Kat. by Kat Law and used with permission of the author. All other rights reserved by the author.

https://testingpodcast.com/

This week, I listened to PerfBytes Black Friday, Hour 4 at the link provided above. This podcast is centered around the business practices of major retailers and how that reflects on the work of IT departments. Especially right after thanksgiving, retail companies see a huge spike in consumer activity with black Friday and the holiday season, which results in a big strain on eCommerce.

They begin a practical assessment of retail websites by scoring the load times and response requests over time. They discovered that some retailers don’t put enough resources into their websites. Olight is a manufacturer of flashlights whose website scored a D, which is unacceptable from a consumer standpoint especially around black friday and the holiday season. For comparison, they also scored a competing website, Maglight, which performed the same or worse in all areas.

Clearly, these shopping websites were not up to par with the expected performance and don’t seem to have an interest in upgrading. Major online sellers like Amazon and Home Depot also sell these products but with a much more marketable look and feel to their web pages. This test proves that these manufacturers should invest more in their website and might make more revenue by selling directly rather than paying a margin to the dominating online retailers. The need for quality assurance exists, but there also exists a trend from not well known companies like Olight and Maglight to let bigger shopping websites carry the majority of their sales for them at a cost. In this way, it may seem not worth the effort of upgrading a website.

Next the hosts go over ways to better communicate performance engineering between multiple departments especially around high traffic times of the year. Typically, the conversation starts with cost estimates going by a specific plan for that year. The priority for business leaders higher up the corporate chain is to cut costs as much as possible, however, cutting the IT departments budget results in drastic sales consequences. The best way to cause change in the industry and prevent these risks is to better communicate cost.

From the blog CS@Worcester – CS Mikes Way by CSmikesway 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 designing social interface which is the next level of software design issues, after you’ve got the UI right, designing the social interface. Software in the 1980s, when usability was invented, was all about computer-human interaction. A lot of software still is. But the Internet requires a new kind of software: software that’s about human-human interaction such as discussion groups, social networking and online classifieds. It’s all software that mediates between people, not between the human and the computer.

When you’re writing software that mediates between people, after you get the usability right, you have to get the social interface right. The social interface is more important because the best UI software would fail with an awkward social interface. More, let’s look at an example of successful social interface. Many humans are less inhibited when they’re typing than when they are speaking face-to-face. Teenagers are less shy with cellphone text messages, they’re more likely to ask each other out on dates. That genre of software was so successful socially that it’s radically improving millions of people’s love lives (or at least their social calendars). Even though text messaging has a ghastly user interface (just being a little bit improved recently), it became extremely popular with the kids. The joke of it is that there’s a much better user interface built into every cellphone for human to human communication: this clever thing called “phone calls.” It is so simple that to dial a number, and after that everything you say can be heard by the other person, and vice versa. However, many people choose the way that you break your thumbs typing huge strings of numbers just to say “damn you’re hot.” Clearly, it more awkward to say this than texting!

In designing social interface, you have to look at sociology and anthropology. In societies, there are freeloaders, scammers, and other miscreants. In social software, there will be people who try to abuse the software for their own profit at the expense of the rest of the society. Whereas the goal of user interface design is to help the user succeed, the goal of social interface design is to help the society succeed, even if sometimes it means one user has to fail.

Social interface has rapidly grown and developed together with social networking. Software companies hire people trained as anthropologists and ethnographers to work on social interface design. Instead of building usability labs, they’ll go out into the field or online space and write ethnography.

Article: https://www.joelonsoftware.com/2004/09/06/its-not-just-usability/

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

In his post Six Things That Go Wrong With Discussions About Testing, James Bach lists six different things that can often go wrong when testers are discussing testings. His six reasons can be summarized as testers misunderstanding the purposes of testing and not following the proper procedure when it comes to testing.

Your goal when testing is to discover any vulnerabilities in your program, but also to find strengths and things your program is doing well. This covers James’ first two points. When it comes to testing, quality is much more important than quantity. It is better to have a more complete coverage of your program and all its branches than to have a bunch of tests doing the same thing and missing different parts of your program. This is why it is important to think of tests as events instead. What is important is what your test is testing and how it goes about that, and it shouldn’t be thought of as some ‘Generic X Test.’

Often times people get carried away with automated testing and rely too much on it. While it is good to use automated testing, developers have strength far beyond that, and should use automated tests as tools to better accomplish effective testing, not as automated workers that do your work for you. Thinking of automated tests in this way also distracts from the purpose of testing, and makes it easier to forget why you should run certain tests in the first place.

James’ last point is probably his most important one. Testing isn’t just some set task that can be navigated a certain way every time. What I’ve learned this year is that testing is about thinking critically about a program and the way it COULD act, and design your tests according to those parameters. Consider where things can go wrong, and try to test the strength of weak parts of your code. But most importantly, be ready to learn, as every program has a different set of tests with a different strategy that is most effective for testing. Testing is a dynamic thing, and testers must be dynamic people.

From the blog CS@Worcester – Let&#039;s Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.