This blogpost is focused on Sushma S’s article Understanding The Difference Between Unit, Integration and Functional Testing.  The focus of this article, as one could infer from the title, is to differentiate between Unit Testing, Integration Testing, and Functional Testing.

Unit Testing:

• Unit testing tests the smallest part of the application that is testable
• Unit testing is done before Integration testing by software developers using white box testing techniques.
• Unit testing does not only check the positive behavior, but also the failures that occur with invalid input.
• Finding issues/bugs at an early stage is very useful and it reduces the overall project costs.  Issues found at this stage can be resolved very easily and their impact is minute.
• A unit test tests small pieces of code or individual functions so the issues/errors found in these test cases are independent and do not impact the other test cases.

Integration Testing:

• Integration testing tests the integration of two units in the application
• The aim of integration testing is to check functionality, reliability, and performance of the system
• Integration testing determines whether the the combination of units provides the desired output or not

Functional Testing:

• Functional testing is a black box testing technique, where the functionality of the application is tested to generate desired output by providing certain input
• Functional testing is based on the requirements provided

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Week 4

Mutation Testing is something that I was not familiar with until the past few months. What is really useful about this form of testing is that is does not test your code, it tests your …TESTS! This is something that may seem dumb to people who do not know how easy it is to create ineffective tests.

Ineffective tests are ones that are supposed to test a certain path or piece of your code, yet although it may seem like you tested the whole method you may have just cover a fraction of your path possibilities. Mutation testing not only modifies your tests to find where they might fail but sees the “Code Coverage” of your tests. This is very useful to know because if you know you covered 99% of your code you can be confident in its output and features. Yet if you only covered 40% or less then this should make you ask, What would the other 60% of my code do if called upon?

Now this is something that can bite you in the butt down the road if ignored. In fact this has bit many people even years after, some developers may think the code they have no tested is unreachable so why remove it or test it? What if you are a bank and this functionality could cost the bank money. When put in this light it only seems to smart to dot your i’s and cross your t’s.

Code coverage is something that we have access to unlike any other time. We can see what lines of code we hit and what we didn’t so use these tools to better your reliability and quality of code. These tools are evolving constantly and give more and more statistics on your code, so go and explore the world of mutation testing!

Mutation Testing sources:

AWS Code Coverage Presentation

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 3

Laravel happens to be a new adventure of mine that I have had the pleasure of cramming all the information I could in about a month. I used this Framework to build a project for my Software Construction course and my eyes have been opened to this great exciting new world.

Lets just cover what I know it can do (I have not even scratched the surface)

• Create user logins in a instant
  • Password resets
  • Password encryption
• Create boilerplate scaffolding
  • Models
  • Database migrations
  • Controllers
• Built in secure routing
  • To create a secure way to traverse your web application/site with out allowing a user to step where they shouldn’t
  • If it is not defined as a valid place to be a link then you get returned to a error page
    • This may seem intuitive yet it is not many hackers can inject SQL or hidden values through your app and laravel does a great job of keeping your app secure with tokens being required for all input forms.
• Html/PHP Blade templating Engine
  • Allows for shorter syntax
  • new ways to interact with your database data
  • So much more that I have yet to learn.

Laravel is a Model-View-Controller Architecture. What this means is that you have your application separated into three pieces. The Model or the Database Entity, this is where you should prefer your logic and relationships to be. A great tip I learned through many tutorials is to keep your Models fat  and your Controller skinny.  We will get to this in a second when I explain controllers. The View is exactly what it sounds like, its the user interface. The views you make are designed in Html and PHP allowing a lot of flexibility to your applications look and feel. The Controller is the part of your application that controls the data being passed to the view and in a way is the bridge between the Model and View. Now in many attempts and tutorials it is tempting to create complex queries and logic in your controller but this is not good practice I have learned. This is because you can design your applications relationships and specific queries in your Model and this allows the database to have more predictable queries from a operational standpoint and much like any other database driven application you can make relationships using joins and other queries yet this is more expensive and unpredictable to your framework, by using the Models to its full potential you leverage the design of the database management system by having predefined relationships and reoccurring queries.

I promise I could talk about laravel for many posts, yet this was just to give you a flavor of what a Framework can do for your development by helping you focus on the details and not a hard parts like tokens and validation etc.

Laravel’s Documentation Page:

https://laravel.com/docs/5.3

Laravel Collective- allows for sleek form generation using simple syntax:

https://laravelcollective.com/

Laravel tutorial experts:

https://laracasts.com/

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

Week 2

So recently Google Inc has released a new library to allow Fuzzing for Open source applications to find various bugs, call OSS-Fuzz. This is useful because as Google mentions on their blog about this tool, Open source software is what runs the internet of things. Having a bug in this sort of system could mean bad things for everyone.

So we have to ask a few questions for noobs like me.

• What is Fuzzing?
• Why would I want to use this?

So lets start by answering the first question, Fuzzing is a method of black box testing that uses injection techniques to find security flaws. The main thing we should focus on is the “injection part”  if we were to send a value that was not supposed to be allowed or not an option than this means we must gracefully handle this issue ,yet not all software can handle all forms of invalid input. Fuzzings aim or in this case Googles Ozz Fuzzing library allows you to automatically run these tests on your software making sure it won’t crash and leave things vulnerable. If even not vulnerable you still can have your application down allowing a hacker to win by implementing a real Denial of Service attack. This is a big issue for many sites, because if they crash who knows what could be exposed to the viewer.

I think I answered both questions in one long winded swoop. Now I read a little bit on how to use this library for chrome componets and they make it seem really quite simple.

https://security.googleblog.com/2016/08/guided-in-process-fuzzing-of-chrome.html

Resource:

https://security.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html

From the blog CS443 – Triforce Code| Exploring and Learning by CS443 – Triforce Code| Exploring and Learning and used with permission of the author. All other rights reserved by the author.

This blogpost is focused around Renuka K’s article 9 Ways to Quickly Improve Your Writing Skills as a Software Tester.  She wrote this article in order to help software testers to better communicate through written medium.  If software testers do not think that being able to effectively convey thoughts through writing, Renuka provided a list of examples.

• Various Test Documents – Strategy/plan/test cases/summary
• Status/Progress Reports
• Defect logs
• Presentations
• Job Specifications
• Resumes
• Knowledge Tutorials
• Emails

Now that’s a lot of writing!  Of course testers are not necessarily writing novels, but something as simple as an email still needs to be well written, concise, and direct in order to accomplish its goal.  Here are Renuka’s nine tips to improve your writing.

1. Always keep in mind the purpose of writing
2. Know your audience
3. Reading improves writing
4. Use proper formatting
5. Keep it Simple and easy to understand
6. Passive voice is not always appropriate
7. Correct spelling and precise use of grammar is a must
8. Always review your work
9. Practice!

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

I was introduced to Slack this past summer.  It is a free messaging application used by development teams around the world that provides many useful features for collaboration.  AST, also known as the Association for Software Testing created a Slack team last month for their members.  If anyone would like to join the team, simply send an email to marketing@associationforsoftwaretesting.org.  AST has promoted this as a forum for testers to get together and discuss past, present and future projects.  As a proponent of the app, I’m happy to see more and more people using it.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

After a short tangent, I am back to discussing software testing.  I read an article written by Laxmi entitled, The Complete Beginner’s Guide to Responsive Web Design Testing.  She points out that users are increasingly accessing websites on mobile devices, yet many websites are not optimized for such platforms.  Laxmi insists that testers should be testing the responsiveness of these websites.  The basis of her article is Responsive Web Design (RWD), an approach created by Ethan Marcotte.

Simply put, RWD means websites should “react to their device, resolution, and be able to render and adapt correctly.”  The main advantages of RWD, are improved user experience, a single URL is used for multiple devices, and the layouts are fluid.  Laxmi points out that there are three main components of RWD: flexible layouts, media queries, and flexible media.

The following are the scenarios for testing RWD

1. Responsive website link or URL should be same for all browsers in each and every device irrespective of the screen resolution.
2. The display location of the content of a responsive website should change dynamically as per the change in the screen resolution.
3. URLs of a responsive website should also be resolution specific.
4. The images in the responsive website are resolution specific.
5. Any data or text which is not hyperlinked should not initiate and redirect to any other page or content.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

My brother has taken it upon himself to learn the recently released Angular 2 and utilize it at his company.  The response has been nothing short of praise.  Angular 2 is much different from its predecessor, but the changes appear to be improvements.  Next semester I will be doing my capstone and the potential of using Angular (hopefully Angular 2) is a very exciting possibility.

With this idea in mind, I decided to read up a little more on Angular 2.  In all accounts Angular 2 is, “a faster, more powerful, cleaner, and easier to use tool than we had with Angular 1.”  It is based on new JavaScript standards and practices, which makes it a more worthwhile tool to learn than Angular 1.  Angular 2, “would make it easier to write clean, testable code that would run on more devices and platforms.”  In the ever growing app-driven world, learning Angular 2 would put any developer in a good position to be able to build better mobile apps.  I intend on putting in an immense amount of time in the coming weeks learning and using Angular 2.  The link posted above contains a lot of good information on the tool, and is useful reference for the developer who wishes to learn.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

For this week’s post I’m going to step away from discussing software testing, and I am going to discuss the PHP framework, Laravel.  This semester I worked with a partner on a project that relied very heavily on Laravel, and we found the framework to be extremely helpful, even integral to the success of our project.  In that spirit, I thought it would be pertinent to share some information on Laravel.

For this blogpost, I read an article by Vijay Verma that he wrote about the excellence of Laravel.  Verma defines a framework as, “a real or conceptual structure intended to serve as a support or guide for the building of something that expands the structure into something useful.”  Laravel is an open-source web application framework that assists developers in creating web applications quickly and easily.  Certain features, such as authentication, can be created with one command.  This allows developers to use Laravel for large projects and small projects.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.