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

This week I decided to look into software frameworks, and I picked this blog post because of its concise explanation and because it included advantages and disadvantages to using them.

Software frameworks provide developers with ways to create applications without starting from scratch. Instead of writing every piece of functionality, you only have to write the pieces that are unique to your application. Like a framework for a building under construction, they’re bare-bone essentials for the type of project you want to create. Using a framework allows software to be developed more quickly and with higher quality, as software frameworks are pre-tested. With less to worry about coding and testing themselves, developers can focus on fulfilling their specific requirements instead of reinventing the wheel.

Software frameworks adhere to the inversion of control design principle, in which the general framework instantiates and invokes the objects and methods specific to your application. This contrasts with using a software library, in which a custom application instantiates and invokes the objects and methods that belong to the library.

Some other advantages to using software frameworks, as the blogger writes, are that they can encourage better programming practices and appropriate use of design patterns. Upgrades to the framework can also provide benefits to the framework users without them having to do additional coding of their own. Lastly, software frameworks are by definition extensible.

Among the downsides are that if you wish to create your own software framework, it’s more difficult and time-consuming to create the first application that utilizes it than it would be without the framework. However, if well-made, the development and testing effort will be reduced in all future projects that utilize it.

Another disadvantage is that frameworks can be difficult to learn. This can negate the advantages of the framework for the first project a developer uses it for similarly to how they’re negated for the first project that utilizes a brand new framework. Finally, frameworks can grow increasingly complex over time with updates and additions.

Though they certainly have their disadvantages, software frameworks seem like an intuitive solution to me. If I’m tasked with doing something a hundred times with slight variations, after a while, it only makes sense to find the commonality between all the instances and use that as a base to add the variations to. Additionally, in the future, I will keep an eye out for whether software frameworks are available for the type of project I’m trying to create and use them if the benefits outweigh the effort needed to learn them.

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

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

This article gives an overview of web application testing, which has several aspects unique to it compared with other software testing. I chose the article from a few sources on web testing because it was easily understandable while providing enough detail to get a feel for what’s involved.

One of the forms of testing highlighted in this article is usability testing. This includes verifying that there’s a consistent look and feel throughout the site, the application is easy to navigate, and it’s clear to users what options they have available to them. The article also makes note of the 1998 amendment to section 508 of the Rehabilitation Act, which outlines accessibility requirements for people with disabilities on information technology systems belonging to the US federal government. Section 508 compliance isn’t necessary for any non-federal website, but making sure to include accessibility features opens your web application up to a wider audience. The article gives the example of what your application should do if a user fails to enter a required field: simply changing the field title’s color to something noticeable like red, as is commonplace, wouldn’t be useful for someone who has trouble distinguishing colors. Another visual cue like an asterisk would be useful in this situation.

HTML verification is another form of testing for web applications. Testing for correct syntax is the obvious form, but it also includes testing the way your application displays across different internet browsers, OSes, screen resolutions, and device types. Your application may be usable and look great in one context, but break in another.

Load testing must also be done on applications that are intended to be accessed through the internet. They have to be able to function during times of high traffic, and testing of this sort can be used to find bottlenecks. In addition, performance tuning is prudent. All pages of your application should load quickly – the article suggests within 15 seconds.

User acceptance testing is used to determine whether your application does what it set out to do and makes something easier for the user instead of harder. One way this can be done is with a beta release.

Finally, of extreme importance in web applications is security testing, which should be done by qualified security specialists. The damage that can be done if this is neglected is immense.

This article gave me a good introduction to the additional testing required for web applications. Of all the details, I found adherence to section 508 especially interesting. It might not be a legal requirement for anything I design in the future, but if I ever do design a web application destined for the real internet, I will definitely want to make it accessible.

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

There’s been a lot of automation mentioned throughout the Awesome Testing blog.

A popular topic in testing is apparently the automation vs manual testing debate. Advocates of manual testing state that an automated test is never going to compare to a humans intelligence and possible deductions. Which I can definitely agree with. Human intelligence is a very important aspect of many projects. It’s this aspect that machine learning tries to replicate in machines through code. It’s why identifying what’s in an image is so difficult.

But according to the post, the crowd who argues this is slowly losing ground because of the advancement and evolution in production cycles. With Continuous Development and Integration, release cycles have become shorter and more frequent. As the releases are more and more frequent, the human intelligence doesn’t have time to figure out problems.

It is much easier to let automated test find almost all of the bugs in your product and then release. If any glaring issues are discovered by human users or others later, the product can simply be rolled back to a previous stable release. It’s a question of balancing risk and profit. With Continuous Integration, and things like Blue Green testing mentioned in earlier posts, letting some issues go isn’t such a big deal. And this speed of release is much more profitable and productive than waiting for manual testing to find almost every issue.

However, in security testing, the risk associated is much, much higher. If you release with a security flaw in a service product like Facebook, users can have their valuable information stolen and used for malicious purposes. They can lose money and have their identities stolen. It’s impossible to simply roll back to a previous version and fix any damage caused by a security bug.

In this case it is much better to have a skilled pentester, a penetration tester, whose job is manually and automatically find possible points of penetration into a system. Speedy releases are not a priority with the level of risk involved. Thus, manual testing by the pentester is required. These are experts in many fields. Networking, programming, psychology, social engineering, and more.

Social engineering and psychology are more important than one would expect, as so much security can be bypassed by getting an admin password from an admin. Humans are a huge weakpoint in most systems that can’t be automatically tested.

In the field of security testing, manual testing is still incredibly important. I originally was nodding my head that automation was much more effective, especially with version control. But this post changed my mind somewhat and showed how important human intelligence still is to computer fields.

Original post: http://www.awesome-testing.com/2017/03/automated-testing-vs-manual-testing.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.

Today I’ve discovered the amazing world of browser testing.

I’ve been learning about tools lately in our final classes, such as Pit Testing. But using an already existing tool, a web browser, to automate tests, was a really cool discovery.

Over on Awesome Testing’s blog, they have many posts talking about Selenium, which made me finally look it up. On the home page of Selenium, they proudly proclaim, “Selenium automates browsers. That’s it!” They know how amazing just that is. By automating a web browser, the capabilities are nearly limitless. You can distribute scripts across many environments. Create bug reproductions scripts, and scripts to aid in automated exploratory testing.

By using versatile and common tools such as web browsers, including the most popular ones like Chrome and Firefox, one can test all manner of things. Browsers can read html, styling elements, javascript, and AJAX. They can gain incredible amounts of information and interact with web pages in ways that with just a small amount of automation can test almost everything about a web page and thus web sites. As browsers also have the ability to view certain files such .pdf files, this increases their ability to test.

The possibilities with Selenium are really wonderful to think about. But the post by Awesome testing today is talking specifically about headless browser testing.

What’s a headless browser? Simply a browser without a Graphic User Interface. So instead one uses a command line like interface or network interface. This is helpful for Continuous Integration in that a display might not always be available. Unix systems, for example, don’t have display outputs on by default. In which case, headless browsers allow us to test them instead of using combinations of other tools to do the same job.

By combining Selenium and a headless browser we can do headless browser testing on servers and web sites. It’s so simple, and also so interesting. This gave me a glimpse of the way professional testers combine multiple tools along with coding, most of the article is dedicated to showcasing java code for headless browser testing in Firefox, to create their own toolbox of software for making sure things work. It also showed a concrete example a testing method used in Continuous Integration, which was nice. I was also introduced to a very exciting new tool, Selenium. Having a new toy to play with is always exciting though.

Original post: http://www.awesome-testing.com/2017/09/firefox-selenium-browser-capabilities.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.

For my last blog of the semester i chose a blog on using penetration tests to strengthen cyber security, the article can be found here. In today’s time cyber attacks are becoming more and more common , and they can affect anyone from an individual to a large corporation. In the last few years alone we have seen a large number of corporations that have had to deal with large scale data leaks. Some of the ways that companies prepare for these attacks is by using vulnerability assessment, Penetration (or Pen) Testing, Security scanning, Risk Assessment, and Ethical Hacking in order to make there system more secure. In this article we are going to be focusing on Penetration Testing.

What is penetrations testing?well in this blog penetration testing is defined as follows:  a sanctioned triggered attack that is conducted on a computer system to assess security flaws, which can otherwise result in a data breach or intrusion within the system. Basically you implement a cyber security attack yourself in hopes of finding insecurity’s that might one day be exploited in a real cyber attack. This can be done both by manual testing or automated testing , and is also referred to as a white hat hack.

penetration testing can be broken down into a few different subcategories. First up we have targeted testing , which is done by the systems IT team and is witnessed by all in the system. Next up we have External testing which tests all the organizations servers that are external facing such as web servers , domain names, and firewalls. This type of testing is to see what kind of damage can be done to the system from the outside. The next type of penetration testing is internal testing , which tests what kind of damage can be done from inside the system with authorized access. The final type of testing is call blind testing and this is testing where the attacking team only has limited information to use for the attack , and this is supposed to simulate a real life attack where anything could happen.

“Gartner in its report mentions that by 2020, 40 percent of all managed security service (MSS) contracts will be bundled with other security services and broader IT outsourcing (ITO) projects, up from 20 percent today. ” As we can see the security field is growing greatly today as the threat of cyber attacks also increases. One way to combat this is with the use of penetration testing. Cyber security can be very expensive so it is important for a company to be able to use penetration tests to figure out where they should be putting there money.

In conclusion, i picked this article because it is a type of testing that i had not seen too much of through out the semester and so it peaked my interest. The thing i found the most interesting about the article is how similar this type of testing is to regular testing. Even though you are testing the security of a system , the testing is done much in the same way , by testing all the different boundaries of the system. Automation can help with this but manual testing is always needed to accompany it. For manual testing security ,many of the different testing options we have discussed would also work here like boundary value testing and edge testing. While viewing many different types of testing this semester, i noticed that they all share a lot of similarities, and they all seem to be made up of some combination of the types of testing we have learned this semester. I have build a solid testing foundation this semester which will allow me to continue learning in the field of testing as i move forward.

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