This is my final post, at least for the foreseeable future, and it is based on Martin Fowler’s article Mocks Aren’t Stubs.  In unit testing, the ability to test a unit is sometimes dependent on other units, which may not have been created yet.  Mocks can be used in this case.  Fowler point out that “the vocabulary for talking about this soon gets messy – all sorts of words are used: stub, mock, fake, dummy.”  So for clarification, here is a quick vocabulary lesson:

• Test Double: A generic term for any kind of pretend object used in place of a real object for testing purposes
• Dummy: An object that is passed around but never actually used. Usually used to fill parameter lists.
• Fake: An object actually have working implementations, but usually take some shortcut which makes it not suitable for production
• Stub: Something that provides a canned answer to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. A stub may also record information about calls
• Mock: An object pre-programmed with expectations which form a specification of the calls it is expected to receive

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

This blogpost is focused on Sushma S’s article Understanding The Difference Between Unit, Integration and Functional Testing.  The focus of this article, as one could infer from the title, is to differentiate between Unit Testing, Integration Testing, and Functional Testing.

Unit Testing:

• Unit testing tests the smallest part of the application that is testable
• Unit testing is done before Integration testing by software developers using white box testing techniques.
• Unit testing does not only check the positive behavior, but also the failures that occur with invalid input.
• Finding issues/bugs at an early stage is very useful and it reduces the overall project costs.  Issues found at this stage can be resolved very easily and their impact is minute.
• A unit test tests small pieces of code or individual functions so the issues/errors found in these test cases are independent and do not impact the other test cases.

Integration Testing:

• Integration testing tests the integration of two units in the application
• The aim of integration testing is to check functionality, reliability, and performance of the system
• Integration testing determines whether the the combination of units provides the desired output or not

Functional Testing:

• Functional testing is a black box testing technique, where the functionality of the application is tested to generate desired output by providing certain input
• Functional testing is based on the requirements provided

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

This blogpost is focused around Renuka K’s article 9 Ways to Quickly Improve Your Writing Skills as a Software Tester.  She wrote this article in order to help software testers to better communicate through written medium.  If software testers do not think that being able to effectively convey thoughts through writing, Renuka provided a list of examples.

• Various Test Documents – Strategy/plan/test cases/summary
• Status/Progress Reports
• Defect logs
• Presentations
• Job Specifications
• Resumes
• Knowledge Tutorials
• Emails

Now that’s a lot of writing!  Of course testers are not necessarily writing novels, but something as simple as an email still needs to be well written, concise, and direct in order to accomplish its goal.  Here are Renuka’s nine tips to improve your writing.

1. Always keep in mind the purpose of writing
2. Know your audience
3. Reading improves writing
4. Use proper formatting
5. Keep it Simple and easy to understand
6. Passive voice is not always appropriate
7. Correct spelling and precise use of grammar is a must
8. Always review your work
9. Practice!

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

I was introduced to Slack this past summer.  It is a free messaging application used by development teams around the world that provides many useful features for collaboration.  AST, also known as the Association for Software Testing created a Slack team last month for their members.  If anyone would like to join the team, simply send an email to marketing@associationforsoftwaretesting.org.  AST has promoted this as a forum for testers to get together and discuss past, present and future projects.  As a proponent of the app, I’m happy to see more and more people using it.

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

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.