Week 10

Backend testing sounds like a scary word. To be able to take out the intimidation from this idea we need to break it down into its components that usually make up a backend:

• Database(s)
• API’s
• Servers

Honestly that all! Now that we broke it down into terms that we have heard before it become easier to think about how we would go about testing each one of these components.

Databases:

How would you test a database? Well lets start with what does this component should provide.

• Lists of data
• Quick Responses
• Secure connections

Now there is a lot of room for error if your database is not properly configured. Security relies on both the UI restricting access, and security patches being up to date. Quick responses is something that should not be too hard, yet if you create complex queries without the hardware to handle the transactions in mass quantities, bottlenecking could occur. The same could be in the inverse. If you have a poor query and have multiple collections of data stored and variable you may use more time than thought to manipulate the data. This is why you want Entity relationships to be properly initialized to leverage the Databases design for relational queries that are cached and fast.

So how do we test this? well the answer is pretty simple. SQL! you want to create queries of equal complexity of your application and gather results and statistics on how your database handles the queries. By doing these tests a developer is able to leverage the optimal way of extracting data for their application.

API’s:

API’s are Application Program Interface’s that allow you to connect to a suite of public functions that are open for use. These are usually decided upon early on. So testing for these can begin early to allow for re-evaluation of the goal/implementation if problems arise. The trouble with many API’s is that they can be depreciated and this is common as many companies improve their software and databases. You can create custom tests and view the logs to see the output of the API call.

Servers:

Now this is a topic which is hard get specific but say you have a server with a OS and tools that server the purpose needed then the steps you can take to test this just like any part of the database is benchmark softwares. This allows the tester to grade the performance and many other factors of software and other tools.

Working on a backend in a way may sound scary but remember this is not something we have not worked with before, it just could be on a larger scale :).

Resource:

How to Perform Backend Testing

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 9

I have been enjoying the Software Testing Help Blog. The writer has a way with keeping me interested while making me think in a few different ways. When I saw this post I couldn’t help but read it. Sushma goes on to many points and explains both sides of the coin for Developers vs Tester. I love the start and it just makes sense, Developers think “how can I build this application” and Testers think “how can I break it”. She goes on to explain that this game of cat and mouse is like Tom and Jerry ( a Cartoon that makes up a large portion of my childhood so it rang with me) when they work together you get a beautiful end result. Although much of her article explains how testing at the end of an applications development cycle is just expensive and impractical. That testing is something that should and is commonly done throughout the development cycle.  The ending of her blog sums up some great ideals of both a Tester and Developer that really shows how they are designed to work together to achieve an end result. Throughout she explains how a tester needs to think about how an input form may react to different inputs based on the requirements. This to me only makes sense yet the whole time I was thinking the developer should be wise enough to put in place these error messages and handlings. She ended up wrapping this up in a nice description of what a developer’s goal is and what a tester’s goal is.

I could not write this portion any better and it made the whole blog meld together perfectly for me. It really sums up the job descriptions to see how they end up with the same goal in mind, a great piece of software/1=

Resource:

The Difference in Perspective of “Testers” and “Developers”

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 8

Coding as we all know can have its challenges, yet sometimes you just get stuck and frustrated with seemingly no solution. Then you decide you need a walk or coffee break and you come back solve your problem almost immediately. Trust me it has happened to me more than I can count. Taking a break is not always just to get through a coding wall but also to allow yourself to think more clearly of your goals and the direction you choose to take.

Sometimes you can go on a coding marathon and at the end realize you have overcomplicated the solution and need to refactor. This is why we are seeing so many companies in the tech industry encourage their employees to stop and take a break from their work. Stress can be a motivator but also a hindrance to clear thought. The open environments that companies such as Google or Facebook have are not just to keep their employees happy but to make them feel less constricted and stressed, they can solve problems in an environment that encourages creativity as well as being human and playing a game or interacting with coworkers. Companies like Google have seen the power of leaving computer nerds with free time and plenty of passion (and an NDA that owns every cool Idea you have :P). Taking a break is not just for getting stuck but also can help us take a step back and realize the big picture and not just the piece you are working on.

Inspiring Resource Blog:

http://brianburridge.com/2007/07/08/increase-programming-efficiency-by-taking-breaks/

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 7

What if there is just not enough time to test your software?

Well this is something that every company has to deal with and ultimately tough decisions must be made.  The company needs their product launched and the user needs something stable enough for them to keep coming back. As we learned early on in our Software Testing Quality and Assurance course is that your test cases can become exponential. And just down right impossible to test it all, as well as you can address many cases yet the test quality can be lacking making this process even more of a headache. So what do you do?

1. Prepare, and analyze what is important
2. Stand by your thoughts of what your software needs
3. Ensure no critical bugs are released.

This may seem difficult but like I explained in my last blog about web application testing it is about tying up loose ends and ensuring the functionality required is up to par. First ensure your data integrity is bullet proof and that all of your CRUD functions properly. You do not want loose ends in your database because this could become a immediate problem when a field is deleted and makes your application crash. What also is important is input validation!!! I can not stress this enough, if you ensure that your input is valid every time you will reduce the possible causes of your bugs and this can reduce the cost to you and your company down the line.  After reading a couple blogs about this topic it is clear that some social skills is useful when describing what issues could lie in your software and what the risks associated with these potential bugs are. Interface bugs that are just aesthetic is not a priority over your relationships and functionality being hindered. Using Mutation Testing and code coverage tools can give you a better feel for what areas need to be addressed and what other places you need to move on from. This topic of what to do in this crisis is very open ended because it comes down to per situation and requirements for the client. So there is no one cut and dry approach to this yet with many more applications being released yearly we can grow as a community of developers educating each other on what worked best for you and your team.

I really enjoyed the first link I have below because not only does it talk about how to prioritize, but also how to deal with others who may have a different perspective on the product you are producing. Social skills go a long way in these situations and how you present your potential issues is vital to having the situation controlled and keeping your credibility.

Related Reads I used:

http://www.softwaretestinghelp.com/what-if-there-isnt-enough-time-for-thorough-testing/

You can’t test it all

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 6

As I described earlier web frameworks can be amazing, but regardless if you are using one or building a website or web app from scratch. There are a few places to start. After reading a few websites the options are pretty obvious, and from experience designing and building many websites these obvious points will still come to haunt you if you are not thorough. Trust me its the little things!

Lets start from the Obvious to less so:

• Website routes/links
  • Ensure they all work properly and no dead links exist
•  Input form testing
  • Valid input
  • Invalid input and validation handling
  • Ensure your CRUD functions properly
• Secure/Authenticated Route 
  • Ensure you can not access routes that require login
  • Ensure users can not manipulate the url to gain access to other information than what they are give
  • This can include cookie testing for logged in sessions
• Cookie testing
  • It is important to ensure your cookies are properly encrypted
    • This can contain data that the user or yourself as a developer would not want exposed
• In Depth Interface testing
  • This can include anything from usability to the look and feel
  • Is it intuitive? Could a user use this without prior knowledge? Too complex or want a feature Explain it to your user!
    • Many apps now have neat and sleek introduction walkthroughs to guide a user through the new interface
• Web compatibility!
  • Honestly this one should be first! I can not stress enough how unsightly it is to use a unsupported browser and to have a completely different user experience or just have some functionality not work.
  • Image Links in chrome do not show borders, underlines, or history color changes, yet IE does?
    • I know what you are thinking IE is just horrible. YES that it is but you need to ensure your site not only preforms properly but looks great

Website  links may seem like a given yet it could be easy to forget a simple link that could cost you. For example for a friends business venture I for the first week forgot to have the logo redirect you to the home page, yet this is an almost expected feature at this point yet if you are a sole developer its easy to miss.

Input testing is a must, time and time again developers talk about elegant and flexible applications. Allowing invalid input is just unacceptable and should be handled properly for any production application. Not only should you prevent this you must inform the user of what is allowed or why the input was not accepted and what should they change it to. Using a framework such as laravel makes validation a breeze and really leaves no excuse for anything less. The next main point for input forms is your CRUD functionality, does your database handle when a user is connected to many aspects of your design and deletes themselves,  this is when you need to ask yourself is this data important for others or can I cascade on delete. And more importantly does it properly cascade throughout your relationships? This is something that could become a big headache for both you and your users.

Authentication is something I will briefly mention, it should be known that a user should not have access to data they are not associated with or have the ability to access pages without being a validated user.

Cookies are a resource to not be taken lightly, some users don’t allow them and therefore does this make them unable to use important aspects of your application? It shouldn’t. Cookies can hold vital data such as remember tokens that store login sessions and if in the wrong hands can compromise your users data or more.

Testing your interface is important not only for debugging but it can and will also expose cumbersome tasks that could be minimized or eliminated by adding a interface feature.

I don’t think I should need to say much about Web compatibility. A clunky and inconsistent application is not intuitive for users and can be confusing or just ugly. With web design ensuring your web interface looks and feels great or at minimum the same will carry a lot of weight for you and your users.

Now get out there and start perfecting that application your work so hard on!

. Resources:

http://www.softwaretestinghelp.com/web-application-testing/

https://www.tutorialspoint.com/software_testing_dictionary/web_application_testing.htm

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 5

This idea of Mocks are not Stubs is something that in class we have discussed and in a way has kept my head spinning. So today I have setout to answer this question in a simple and concise way. Many site give lengthy explanations with examples of code. I am going to just stick with the ideas here and try and rationalize the difference for my reader and myself.

Lets start simple, what are Mocks and Stubs?

• They are testing dummies or doppelgangers for unit and integration testing
  •  Mocks are supposed to mimic object behavior
    • They have set expectations before the test, and this is how you can set what behavior you are looking for.
  • Stubs are supposed to be predetermined/hard coded objects that are placeholders for unit testing.
    • Martin Fowler referred to this as canned responses. State verification

For me to wrap my mind around this concept I had to cut them down the middle and say Mocks have a expectations that are supposed to reflect the desired behavior. Where Stubs are hard coded methods and objects to ensure you can just test a unit without having a object dependency being dynamically generated. This can add a layer to the tests that take away from the unit test, so having placeholders can make your tests more defined and narrowed in on a specific portion of your design.  Many sites use these words to signify placeholders for dependencies and this is true but in reality these two ideas are two very different approaches to this placeholder need.

I read the following to better understand this concept:

http://martinfowler.com/articles/mocksArentStubs.html

http://www.g9labs.com/2014/06/21/mocks-arent-stubs/

Why not to mock tooo much : -Very cool read!

https://www.thoughtworks.com/insights/blog/mockists-are-dead-long-live-classicists

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 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.

Hello Everyone!

Today my topic is the Scala programming language. This is a Language that I was introduced to in College at UMASS Amherst.

Scala is a very cool Language because it runs on the JVM (Java Virtual Machine). Not only does it run on the JVM but it uses java libraries at its core. Essentially Scala’s aim is to have a highly scalable development language and also offer all the perks of Java. Scala is an Object Oriented-Functional Language, now this may seem odd if you have not encountered a functional language before but its is amazing and I can’t wait to show you why!

Immutable Data Structures

So to start Scala has all the basic data structures you could ever want. Lists,Maps, etc.

These all inherit from the trait Traversable. Now Traits at a basic view point is a interface that can have some implementation. Although I am not sure if they offer the same benefit of no overhead like interfaces. (Add that to the list to learn) Since all of these Data structures all are a “traversable” object it has methods that allow you to “convert” your structure to a list, map, array, set and a few more without any effort.

EX:

CODE Goes here ….example of a list that is made into a array.

Now lets think for a second…..since they all are a traversable object than would it not makes sense for it to have functions that allow you to TRAVERSE your structure. Of course you’re a genius! (Or Scala Creators are)

You can simply iterate through your structure and preform functions on each element much like you would in java but….no for loops!

EX:

CODE Goes here …. example of a list being multiplied by any number and some output to prove it.

Wait! I have not addressed the elephant in the room…All of these structures are Immutable. Now if you are new to coding or have not seen this before this means that the structure can NOT be changed. Every time you modify the data structure it will create a “new” structure with the changes you have made. This allows it to be safe to be used between threads with no issues because it can not be corrupted adding known reliability to your project.

Readable code

Now I am sure some seasoned developers out there may not like this because all languages are designed to be “human readable” yet so far in my experience I have not read anything that is so intuitive to read and understand. Most java algorithms can be rewritten in Scala with less lines and a simpler feel to them. Now its time for me to back up my claims;

• No Semi colons
• Spaces instead of the dot to call upon a method of a object.
• Operators that are created to reduce the words used
  • +: this operator is how you append an object to a list
  • :: will add to the beginning of a list

I could go on for a while so check out the API docs: http://www.scala-lang.org/api

Scala EX VS Java EX:

CODE Goes here

Object Creation

As many of you know a Object is instance of a Class. Yet when you have a Main method to access your program it is normally a class. Yet when you run your program it will become an object. Scala lets you define your Main method as an object to only allow one instance to be defined. This can be useful in the case of a database class that you would only want one object accessing your data at a time.

Pattern Matching

Functional Programming

Now to put functional programming in simple terms it is a language that has functions/methods that always output a value. Of course it has an equivalent to void yet it allows you to pass a method a function that has areturn type of int and it will accept your method as a valid argument. This is very different from traditional Object Oriented programming, where you would have to store the returned result as a variable and pass it to the method after. This as you imagine reduces code length and keeps it short and sweet.

Sources for more technical explanations:

Immutable Data Structures Pros and Cons:

https://www.quora.com/What-are-the-advantages-and-disadvantages-of-immutable-data-structures

Scala API:

http://www.scala-lang.org/api/

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.