Monthly Archives: September 2016

Use Old Tests or Make New Test?

The article I read this week was very short and straight to the point. It addressed the issue of using old tests vs implementing new ones.

If someone is trying to find old tests that have been run for a code, and use them again to test if the code functions, they are probably better off implementing new tests. The reasons behind this are simple. A tester is constantly learning new methods to test, and they have move knowledge today than they did a couple months ago. There is a higher probability the tests they come up with this time will be more detailed and more extensive then the “old tests”. Also another big reason why it is better to re- write the tests is because the code may have changed since the last time you tested it. If someone major has changed, the old tests may not even work, and you will be spending unnecessary time trying to resolve these problems while you could spend this time implementing new test. If anything changes with the code new tests should be made. This ranges from new coders to a new method. Reading and using old tests also stops innovation. If you start over with the tests, you may think of different ones then you had before, and incase all fails you always have the old tests to turn back to if you can’t think of what to test. 

Start From Scratch vs Old Test Documentation:

http://www.testthisblog.com/2016/03/start-from-scratch-vs-old-test.html

 

Other blogs i looked at

http://www.testthisblog.com/2016/02/test-planning-is-throwaway-testing-is.html

Open Source Database Testing Tools

Open Source JavaScript Code Analysis

Distributed Testing with Selenium Grid


From the blog CS@Worcester – Site Title by jonathanpaizblog and used with permission of the author. All other rights reserved by the author.

Week 2: “Variable Testers”

This week I decided to research and look up the most popular Software Testing blogs.  The name James Bach came up on nearly every website, so I started to look through his page.  I came across a post called, Variable Testers, posted kind of a while ago but I enjoyed reading it.  He talked about a personal experience he had where the vice president of a software engineering company told everyone that “they need to formalize their work”.  James went on to tell the story of how he immediately raised his hand, even if it wasn’t the most appropriate thing to do that the time, and argued that his statement was completely wrong and he couldn’t possibly of meant it.  The point of this article was to make it clear that variability is not a problem at all.  He uses the example that there are a bunch of different cars on the road, but is that really a problem?  I completely agree with James.  As a tester, why would you want to be exactly the same as every other tester?  Yes, of course there is always going to be a tester that is per-say “better” then another, but does that make them bad?  Just because someone has a different way of doing something, it doesn’t make it the wrong way!  James thinks it’s absolutely insane that someone that high up and familiar with the engineering process can even make a statement like that.  I liked how James was not afraid to raise his hand and totally tell the guy off.  I can see why people like his blog so much! He is very honest, I am definitely going to read his stuff more often.

From the blog CS@Worcester – Alex's Comp Sci Blog by alexsblog13 and used with permission of the author. All other rights reserved by the author.

Scala | Why I hate Java

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.

How Google Deals with “Flaky Tests”

Read the Full Article

This post, by John Micco, talks about how the Software Developers at Google deal with and minimize the damage of “Flaky Tests”. Micco defines a flaky test “as a test that exhibits both a passing and a failing result with the same code.” He goes on to state that this causes major problems because how difficult it is to find the cause of the flaky tests and the frequency of which these kinds of tests appear. There is also the issues of a flaky tests being dismissed only to find out later that it was a real failure which sometimes results in passing through broken code.

There are several strategies that the developers at Google use to minimize the damage and confusion that is caused by these flaky tests. One way is to only report a true failure if the test fails three times in a row. This, however, can be costly if the test that is being run takes a large amount of time to complete. Another way is that they implement a tool that monitors the flakiness of a test. If the tool determines that the flakiness for a test is too high, it removes the test from the critical path. The last strategy they have is to use another tool that monitors flakiness levels. When the levels change, the tool tries to find the reason for the test’s change in flakiness.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

My take on Agile

In my blog exploration on testing I see that it seems that testing has changed in how it is done over the years. I am still green when it comes to testing and well the development process in general so I can only speak on what I read about and the limited testing that I ave actually done so far. I am looking forward to see how this blog evolve over not only this semester, but my career. For this week I chose to talk a little about Agile development and testing.
I have noticed in a few articles that some companies, well maybe more than some have split teams that don’t communicate with each other effectively or at all in some cases. When I say teams I am talking about testing and dev teams. What happens is people end up passing the buck when something doesn’t go right or the customer runs into issues with the product. What I like about the Agile methodology is that the testers or at least someone from the team is in with the dens so unit testing can be written when they decide to make changes to the code or what not. The blog article that I read had explained that in the company talked about there were big issues because there wasn’t any transparency between teams for a while and that once they adopted the agile style, things started to turn around.

All in all, from what I can gather this seems like a great ideology to follow and lends to a better office environment and better over all cohesiveness. I look forward to actually putting some of these techniques into practice in the future and get excited as I read and do and learn more every day.
Defining Agile:
https://thoughtsontest.wordpress.com/2016/09/27/defining-agile/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
Software Testing Help Blog:
http://www.softwaretestinghelp.com/agile-retrospective-meetings/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Softwaretestinghelp+%28softwaretestinghelp%29
Write Clean Code For Your Tests:

https://iamalittletester.wordpress.com/2016/09/27/write-clean-code-for-your-tests-by-using-the-separation-of-concerns-principle/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
The Evolution of The Testing Pyramid:

http://james-willett.com/2016/09/the-evolution-of-the-testing-pyramid/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+mottestingfeeds+%28Testing+Feeds+-+Bloggers%29
My Unexpected Journey To Becoming a Tester:

http://www.softwaretestinghelp.com/my-journey-to-becoming-a-software-tester/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Softwaretestinghelp+%28softwaretestinghelp%29

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

When to stop!

This week I read an article called When to Stop Testing (Exit Criteria in Software Testing). The article talks about when to stop testing a software product.

No matter how much we test we can never be absolutely sure that the product is bug free. There is no methods that we can use to prove that a software product is absolutely bug free. The only thing that we can do is iteratively test for all possible defects. However, testing costs money. So when do we stop? Do we stop when we run out of money? Run out of time? Have reach a certain number of bug count? Have fixed a certain number of bugs?

The following are the factors to consider when deciding to stop testing.

Testing can be stopped when:

Requirements:

  • 100% Requirements coverage is achieved.

Defects:

  • Defined / Desired Defect count is reached.
  • All Show Stopper defects or Blockers are fixed and No known Critical / Severity 1 defect is in Open Status.
  • All High Priority defects are identified and fixed.
  • Defect Rate falls below defined acceptable rate.
  • Very few Medium Priority defects are open and have a workaround in place.
  • Very few low priority open defects that do not impact software usage.
  • All High Priority defects are re-tested and closed and corresponding Regression scenarios are successfully executed.

 Test Coverage:

  • Test Coverage should be 95% achieved.
  • Test case Pass Rate should be 95%. This can be calculated by formula
    • ( Total No of TCs Passed / Total number of TCs ) * 100.
  • All critical Test cases are passed.
  • 5% Test cases can be failed but the Failed Test cases are of low priority.
  • Complete Functional Coverage is achieved.
  • All major functional / business flows are executed successfully with various inputs and are working fine.

Deadlines:

  • Project Deadline or Test Finish deadline is reached.

Test Documents:

  • All Test Documents / deliverables (Example – Test Summary Report) are prepared, reviewed and published across.

Budget:

  • Complete Testing Budget is exhausted.

 

 

From the blog Software Testing – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

End-to-End Testing

This week i decided to write a post regarding the article, Testing on the Toilet: What Makes a Good End-to-End Test by Adam Bender.

Of course being fairly new to the software testing industry, End-to-End testing was a new concept to me, although it seemed fairly simple to understand what it would entail. This is actually true, End-to-End tests are simply that, a test that tests an entire suite of software from one end to the other, while treating much of the code in between as a black box. This is especially relevant because i am currently working on black box testing in general and understanding the real world applications of that really helps.

It is true that the concept of End-to-End testing is simple, however the actual work that goes into making and maintaining sustainable End-to-End tests is not. There are a great deal of benefits that outweigh the costs in the right situations. An End-to-End test can “provide confidence about the health of your system in a near production state(Bender 1)”. Again in the right situations this can be an amazing advantage, and deploying the system becomes less of a nightmare.

End-to-End tests are more slow and more expensive than unit or integration testing can be, it is due to this that it is used to test things that those tests would not be able to well. The examples that the article gives are “resource allocation, concurrency issues, and API compatibility(Bender 2)”.

As i myself am not an expert and am just learning of End-to-End testing i thought it would be useful to bullet the author’s main points regarding the issue.

  • “For each important use case, there should be one corresponding end-to-end test”
  • “allocate at least one week a quarter per test to keep your end-to-end tests stable”
  • “Focus your efforts on verifying overall system behavior instead of specific implementation details”
  • “Make your end-to-end test easy to debug”
  • “It may be more difficult to make an end-to-end test fully hermetic

In case you were wondering, hermetic means complete and airtight(i know i was).

Here are a few other articles that i found to be interesting:

Oblique Testing

What Should The Software Testing Industry Watch For as the HPE–Micro Focus Merger Plays Out?

https://gojko.net/2016/09/18/whats-next-agile/

Roles and Boxes

 


From the blog CS@Worcester – Computer Science Journal by jtassone93 and used with permission of the author. All other rights reserved by the author.

Guessing Game

Can you develop a formula to determine how long it will take you to write your project or test that entire project that your boss is waiting for?

That’d be quite the challenge, but estimating hours that will be spent working on specific tasks is required in any positions regarding Software. “Management tends to think of Software Development as an investment”, (Lee Copeland). I’m sure most have heard the saying time is money, which is why management wants to know ahead of time how long a project will take and what the cost will be before it has begun.

Companies will make set dates for big releases; such as going live with a new Software. To do this, they will have to plan accordingly regarding how long it will take to finish current bugs/problems, test the entire system, then take care of more bugs that will surely arise as they always do. At this point, as a developer or tester, you have a date that you HAVE to meet. All of the bugs have to be fixed and tested by said time. Can you account for problems that can be caused from fixing one item? Can you account for discovering new problems while testing?

There will always be an amount of uncertainly in giving a estimate on how long, but take your guess, multiply it by at-least three and you should be all set.

https://www.stickyminds.com/article/why-estimating-software-testing-time-so-difficult

From the blog CS@Worcester – Kyle Polewaczyk by kpolewaczyk and used with permission of the author. All other rights reserved by the author.

StackOverFlow and Keeping Up with Changes

On the “Decline of StackOverFlow”, John Slegers laments the decline of contribution and the extremely draconian moderation that is pervading the site. He also criticizes the toxicity of its community towards newer members and their questions in general. It’s a concerning trend since Stack is when my code runs into issue or I have trouble debugging. One quick search on Stack and my problem will either be quickly solved or the answer will lead me to the right direction.

Even in the most popular topics on Stack, there is a huge issue of contents becoming outdated. There are numerous answers for language and framework that only applies to a version from a couple of years ago. Answers to deprecated methods is common especially in mobile development with Android in a constant flux of change and swift 3.0 officially being released just this month. Problem is even more frustrating in JavaScript, and many times it’s not even the fault of Stack. New versions are constantly being released breaking things left and right. In one blog I read last week for Angular2, it states that “Stackoverflow posts that are older than 6 weeks old are no longer relevant and probably deal with an issue from an old version that I’m no longer using.” The problem is exacerbated even further in much more obscure languages and also proprietary software. Where even getting a decent answer can be a matter of luck.

However, despite all of its flaws and people commenting on its “decline”, Stack is still a great website to solve your problem. Most of the common problems have been answered and is only one google search away. The strict moderation has led to mostly very well phrased questions and answers that not only solve the problem but help people understand the issue. Outdated answers (which are sometimes edited to reflect current version: thank you to all the people who goes back and update), even if outdated, can lead you in the right direction to understand your problem.  Stack despite all the issues above, is still pretty damn good, and is and will continue to be an invaluable resource for all programmers.

 

The decline of stackoverflow:

https://hackernoon.com/the-decline-of-stack-overflow-7cb69faa575d#.2xjk5bv0z

A counter argument to stackoverflow decline:

http://techblog.bozho.net/i-stopped-contributing-to-stackoverflow-but-its-not-declining/

 

Further Reading:

release of typescript 2.0:

https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/

Developer Certifications:

http://techbeacon.com/developer-certifications-friend-or-foe

Testing tips:

https://eev.ee/blog/2016/08/22/testing-for-people-who-hate-testing/

From the blog CS@Worcester – Site Title by nealw5 and used with permission of the author. All other rights reserved by the author.

Software Testing??

What is software testing?

Vimal Singh, an entrepreneur, strategist & mentor gives us two definitions of software testing

Standard Defenition:

Software Testing is the process of verification & validation of a software product to ensure all the expected functionalities are working as per customer’s requirement.

Redefined Definition:

Software Testing is the process of verification & validation of a software product to certify all the expected functionalities are working as per the Business requirement to ensure an accurate, effective and efficient Business operation

I feel as though Vimal redefined the term software testing, because as we all mature, the art of software testing mature’s as well. It goes hand in hand in the testing industry. Also, testing goes beyond the conventional finding of  bugs & checking performance of the applications. Customers now a days are expecting testers and developers to be confident in the quality of their product. The focus broadens out to being a value partner to the customer by ensuring an accurate, effective and efficient business operation.

Testing is important because it will give you an overview on the quality of the product. Testing helps keep healthy relations with the other team members because it spreads confidence to everyone that their product is working as expected or not working.

 

.

Source: What is Software Testing

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