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.

Here are 6 tips to make sure that you have enough time to properly test your code as provided by Swati S. in her blog What To Do When There Isn’t Enough Time To Test.

1. ESTIMATE ACCURATELY – Overestimate the amount of time each step is going to take.  Do not forget to take into account your team, tools, and processes.
2. HISTORICAL DATA – Swati suggests asking the following questions:

• How long did the earlier release test cycles take?
• What kind of issues caused interruptions to the previous test cycle?
• How many runs did most test cases take before they passed?
• What defects were reported?
• What defects caused the testing to be interrupted?

3. ASK THESE QUESTIONS – Swati suggests asking the following questions:

• Find out Important functionality is your project?
• Find out High-risk module of the project?
• Which functionality is most visible to the user?
• Which functionality has the largest safety impact?
• Which functionality has the largest financial impact on users?
• Which aspects of the application are most important to the customer?
• Which parts of the code are most complex, and thus most subject to errors?
• Which parts of the application were developed in rush or panic mode?
• What do the developers think are the highest-risk aspects of the application?
• What kinds of problems would cause the worst publicity?
• What kinds of problems would cause the most customer service complaints?
• What kinds of tests could easily cover multiple functionalities?

4. USE A TEST MANAGEMENT TOOL – This will reduce the amount of time testing takes             at every stage of the process.

5. DON’T REINVENT THE WHEEL – Make sure to look at the Unit test results to                            determine whether or not the build was a success and to see which tests failed.                        Reviewing the results will ensure that the same errors are not repeated.

6. MEASURE YOUR PRODUCTIVITY – Pay attention to the goals that you set and make                sure they are obtained.  If your goals are not being achieved, reevaluate the time                      allotted for those goals.  Consequently, if you are achieving goals at an accelerated                  rate, reevaluate the time allotted for those goals.

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

Although this blog is very loosely associated with testing, I still think it is important enough to warrant my attention. In his blog, Erik Dietrich outlines a list of criteria for “what is reasonable to expect from your IDE.”

1. BUILDING THE SOFTWARE – His first criteria is that the IDE should be able to easily build your software. Additionally, the IDE should alert you of any problems and make it easy for you to locate those problems.  Ideally, the IDE would even suggest solutions to those problems.
2. INTEGRATED DEBUGGER – Another essential aspect for an IDE is an integrated debugger.  The debugger should allow you to go through your code line by line and see the behavior of your code at runtime.
3. PLUGINS AND CUSTOMIZATION – Any effective IDE or text editor relies on plugins.  Plugins and customization make you more productive and enhance the the coding experience.
4. AUTOMATED REFACTORING – Here is the aspect that relates this blog to software testing.  Dietrich explains that he is a huge proponent of TDD.  A major factor in TDD is refactoring, and he suggests that an IDE that automates refactoring removes much more human error from the TDD process.  Not only does it remove error, but it is also much more efficient.
5. INTELLISENSE/NAVIGATION – The last criteria is pretty self-explanatory.  An IDE should make navigating your code easy, and offer type-ahead support.

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

Before you start. KIDDING. Alright so for this week’s blog I’m mixing it up and recapping a blog I read on softwaretestinghelp.com written by Renuka K.  This blog can be found here.

Well Renuka paints the picture of the typical tester.  Enthusiastic at the start and losing fervor with every run through the code.  Which makes sense, the more times a tester looks through the same code, the less interested that tester is going to be in that code. Especially because, if the testing is done correctly, the tester will find less defects with every run.  So then the question is, when is it okay for the tester to stop?

In the first scenario, for discontinuing testing, Renuka broaches the idea that a tester can stop testing when all of the defects have been found.  Unfortunately, there is no way to prove that software is free of bugs.

In the next scenario, Renuka suggests exit criteria, including, time, budget, and extent of testing.  Unfortunately, as Renuka points out, the quality of the testing process is compromised when these constraints are applied.  Before testing begins, conditions to be fulfilled should be established in order to conclude testing.

Below is  a useful yes or no list Renuka provided to help you decide if it is time to stop testing:

• Are all test cases executed at least once?
• Is the Test Case Pass rate as defined?
• Is complete test coverage achieved?
• Are all functional / Business flows executed at least once?
• Is the decided defect count reached?
• Are all Major High Priority Defects fixed and closed?
• Have all Defects been Retested and closed?
• Has Regression been done for all open defects?
• Have you exhausted the testing budget?
• Has the Testing end time reached?
• Are all Test Deliverables reviewed and published?

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

Yes, I know, Brendan Connolly again.  Out of the ten blogs I have gone through so far, his are the only ones that I have continued to read until the end.  His blogs are straight to the point and that keeps my attention.  Anyway, onto the blog.

First of all, let’s take a broad look at the purpose of testing.  In a very general sense, we test to reveal problems. Then those problems are reported so that they can be resolved. In his blog, Connolly asserts that, “A tester needs a clear understanding of what a problem is in their context in order to effectively relay their findings to stakeholders.” He relates the his model to the Scientific Method, so even if you don’t know much about testing, you can get a grasp on the idea behind it.

Connolly suggests a good way to grasp testing is to have groups of two working together, with one person as the tester, and the other as an observer.  The key for this to work is verbalization.  The tester needs to relay to the observer the actions he is taking and the thought behind his actions.  The observer is not silent, he must be paying attention, adding his or her input, and watching for bugs.  The important factors the tester and observer must agreed upon are the coverage of the project and the tempo at which the individuals work.

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

• Reproduce
• Explore
• Analyze
• Communicate
• Triage

Every tester has to deal with bugs, but how should we deal with them? Brendan Connolly suggests that we REACT.  Connolly says that the first step in resolving a bug is to REPRODUCE the bug by tracking down the steps that caused it.  The next Step is to EXPLORE the nature of the bug.  Connolly warns that acting too hastily can create more problems than the bug does.  The next step is to ANALYZE the severity of the bug.  Steps one and two have given you an idea of how big the bug is and where it is, step three is where you must decide which action you should take based on the impact of the bug.  Now it is time to COMMUNICATE.  The next step is to report the bug, either to a bug tracking system, your team, etc.  Finally, the last step is TRIAGE.  After the bug is reported, the process isn’t over.  You must continue to clarify the issue as best you can.

From the blog cs443 – TayNock's Blog by taynock 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.

Today I start my first blogging experience.  I’m not all that thrilled about it, but here we go.

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