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?


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.

Posted in CS-443, CS@Worcester | Comments Off on End-to-End Testing

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.


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

Posted in CS@Worcester | Comments Off on Guessing Game

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:


A counter argument to stackoverflow decline:



Further Reading:

release of typescript 2.0:


Developer Certifications:


Testing tips:


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

Posted in CS@Worcester | Comments Off on StackOverFlow and Keeping Up with Changes

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.

Posted in CS@Worcester | Comments Off on Software Testing??

If It Breaks, It’s All Your Fault (9/30/16)


Ever had the chance to work in QA before? Sitting in a cramped space repeated test cases over and over again on different builds for 8 hours plus overtime a day for 5 days a week? Its not that bad, not at all. You are just doing your job which completely relies on patience (you know that thing many people don’t really have now-a-days) with the occasional trip to the vending machine once every couple hours. Oh and more thing, the entire project you are working on relies solely on your shoulders, if something breaks at launch and you never found it, or if you found an issue that was never fixed, the fingers all point to you (or the other QA lab rats you work with, but since you’re reading the blog, you’re the only one working in QA).

Kind of funny how its the guy that barely resembles anything in the SCRUM chart that tries their very best so the people receive the greater good of the product they are working on,  and in some cases they end up proud for what they did. Infused in their minds the reason, “well, we have to start somewhere to move up”, they had to keep track of SO many actions by jotting down a load of test cases, and using different platforms/devices to do the same thing over and over again, but if QA is happy with the product then the customers will be too. But will they care? It’s not like they will be SO happy with the product they search hard enough to find who worked on it or tested it so they can thank them properly. When its the complete opposite though, then people care enough to rant to the company that made the product and then all that hate gracefully trickles down to you, the guy that is suppose to expose the broken to be un-broken.

Want an example of the type of  bugs that could’ve been missed or not fixed before launch? Unexpected behaviors. A really great demonstration of that is a fun test using hot key conditions conducted by QA Hates You. When testing Mozilla Thunderbird, (an e-mail hub app kind of like Outlook),  QA Hates you manages to trigger unexpected behaviors in the app by doing two actions at the same time that the users would never do. Will QA testers ever test the irregular activities of human beings or just what they always do instead? Whatever you choose to do whether instructed or not instructed to do as being the QA guy, just remember: if it breaks, it’s your fault.

Source: http://qahatesyou.com/wordpress/2016/08/fun-test-hot-key-race-conditions/



From the blog CS@Worcester – Dan's Tech Rant by danbarbara and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester, WSU | Comments Off on If It Breaks, It’s All Your Fault (9/30/16)

Flexibility = ???

Admit it, we as the people want technology to do everything for us. People want something that can play music, download movies, track fitness levels, helps concentration, schedule appointments, socialize, shop online, and complete assignments simultaneously for them all in one app. Now an app like this doesn’t exist (at least I don’t think it does…) but imagine the flexibility the app would possess if it did. Ultimately, when we think of qualifications for “good technology” , flexibility is a key requirement.

When it comes to software testing the qualifications are mutual. The goal is for test suites to be flexible; meaning it is adaptable in any given condition and is able to correctly handle any given situation that may be presented to it. This seems great and all but if you ask me, the greater the flexibility is, the greater the complexity becomes.

To test whether or not this is true: assertTrue(flexibility.equals(complexity);


From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Posted in CS@Worcester, Software Testing | Comments Off on Flexibility = ???

Tips for Becoming a Better Programmer

Have you ever hit a wall in which you feel like your coding is not getting better? After coding for hours upon hours you feel like you are not getting any better at it? In this blog i will give you some tips on how to become a better programmer provided by http://blog.smartbear.com/code-review/tips-for-writing-better-code/.

They broke the tips they got from real programmers into 8 different sections. Selecting the right tools, understanding the role of testing writing and maintaining code, starting with the requirements, education and career development, code review and profiling, collaboration on devlopment teams, and revisitng your writing process.

Lets start with the first section which is selecting the right tools. Part of being a good programmer is staying up to date on the latest tools and new technologies. Learning new technologies and tools may help becuase they may offer betters ways into solving a problem.

Next is the role of testing. Developers suggest that you use Test Driven Devlopment in your coding, with this better code quality comes automatically.

When writing code, you also want to make sure it is maintanable. You want to make sure that it is easy to understand so that new developers who are looking at the code for the first time can understand it quickly. It is very important to write clean code.

Next is starting with the requirements. When doing this you want to make sure the requirements are clear and unambiguous. You need to communicate about them, Forcing the concepts into sentences can help you think about them

Another importand step into becoming a better programmer is learning and education. One developer stated that in order to become a better programmer you should find “good” code, and look at how it is structured. Then try to emulate the practices that are used in the code.

Next is code reviewing. It is importing to review other peoples code and learn from what they do, and to have your own code reviewed. This way you can see what can be improved upon in your programming.

Developer collaboration is also very important in becoming a better programmer. You need to meet with your team and discuss what “better” means to the team. Also it is very important to help eachother out, and learn fom eachother.

Finally is revisiting your writing precess. It is suggested that you spend some time to structure your code before coding it. This helps to avoid rewrites, and makes your code more organized.

Taking the tips from each one of these sections is important if you want to become a better programmer. If you can do all of these things successfully, you will see your code improve dramatically over time.

Other interesting blogs that i looked at are:

Become a better programmer:



8 Ways to become a better coder:

8 Ways to Become a Better Coder


10 Steps to becoming a better programmer:



10 Golden roles for becoming a better programmer:




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

Posted in CS@Worcester | Comments Off on Tips for Becoming a Better Programmer