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.

Hi All,

This is a coding and nerd blog in general. You will notice there are course related posts but this site will expand to all of my computer interests. I plan to update this weekly at the least. I have a passion for programming, security, and many more areas of computer science that you will journey with me to learn and explore. Hope this site will be usful to others as we move forward.

Triforce ~ Stephen T.

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.