Monthly Archives: September 2016

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

fault-injection-software-testing

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.

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.

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:

https://www.git-tower.com/blog/become-a-better-programmer-5-essentials/

 

8 Ways to become a better coder:

8 Ways to Become a Better Coder

 

10 Steps to becoming a better programmer:

http://www.wildbunny.co.uk/blog/2012/11/01/10-steps-to-becoming-a-better-programmer/

 

10 Golden roles for becoming a better programmer:

http://www.codeshare.co.uk/blog/10-golden-rules-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.

Introduction

Hello, My name is Jonathan Paiz. I am a student at Worcester State university and am studying to be a computer scientist. On this site, i will be posting blogs about software testing, and what we are being taught in class.

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

A review of some testing techniques

I have been doing some reading on different testing techniques and will briefly go over a few of them here this week. The first is pair testing. I had never heard of this before, but the concept is rather simple, which I will quote from the blog. “If you have an idea, give your keyboard to your pair and explain what you want to do.”, so basically you pair up with someone and one of you outlines what the test needs to do and the idea behind it and the other person writes and performs the tests and vice versa. I think that this could definitely be useful in certain circumstances. I often have ideas on things and how I would like to do them but sometimes find it hard to actually get it out and end up getting insight on how to do it from a friend or colleague.
The next thing I came across that I found interesting was a blog on Javascript unit testing automation using React components. Facebook describes React as “ A Javascript library for builing user interfaces.”. The component that the blog talks about is the React TestUtils component. There are a couple of ways the utilities are used. Rendering them into a Document Object Model(DOM) or Shallow rendering. Using the DOM method, the component you are testing gets loaded into a fake DOM making it able to run the tests you want on your component. The Shallow rendering on the other hand didn’t seem to be as useful. It allows testing without the DOM, but only allowed testing of an output component. I have some experience with Javascript so I plan on possibly taking advantage of some of the test utilities when I do.
Next up on the list is test driven development. This concept seems to me to be an effective testing technique. If you can come up with tests for what you want to build it can make it easier to actually build in a sense. I have barely scratched the surface of this methodology, but am looking forward to learning more about it. In the introduction the writer described two rules. 1. Write a failing automated test before writing any code. 2. Remove duplication. How to use those two rules is the narative of the book and I cannot wait to dig in farther and keep you updated as I progress through the book, Test Driven Development: By Example.
A Haiku by Amanda Shankle-Knowlton I thought was pretty good that to me makes sense.
I will work through lunch
Stay late, tracking down a bug
Just to hear “good catch”
The last testing strategy I would like to learn more about is Oblique Testing. Apparently the concept was used by a music producer to make artists try something new. The testing method provides a set of cards that are based on fictional reviews for the application. The method is mainly using mobile apps, but can be used in other applications as well. The full software dev team is also involved and not just the testers. This seems like an interesting take on testing that I will definitely be gaining more insight on in the future.
The following are links to the blogs or titles of books.
Pair Testing:
Javascript Unit Testing:
Test Driven Development:
Test Driven Development: by example, by Kent Beck.
ISBN: 0-321-14653-30
Haiku:
Oblique Testing:

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

Serverless Architectures

Serverless architectures: game-changer or a recycled fad? by Gojko Adzic.

This article discusses something that i had not necessarily heard of before this point, or at least not in a formal sense, “serverless architectures”. Much like noSQL databases the name can be a bit misleading, meaning that there are in fact servers involved, perhaps even more than a normal “server architecture”. Serverless actually refers to the fact that you do not have to maintain your own server hardware, nor do you have to rent racks at a traditional data center.

In order to understand why this new idea is such a big deal i will attempt to explain the more traditional architecture, from there i can elaborate on the incentives of going “serverless”. Gojko talks about the most important thing when considering server architecture is “keeping the hardware busy”. This was to get the most bang for their buck in a way. In order to accomplish this they would bundle a number of processes together to make the most out of the hardware. Of course this meant at some points bundling things that shouldn’t necessarily be bundled for purely financial reasons. He goes on to discuss how the introduction of cloud computing did not address this issue and the need to bundle remained the same. This caused situations where you could have a bug in a rarely used process that was bundled with more important ones, and that bug caused every one to be held up.

The “serverless” architecture changed all of that. The idea is based on the “container farm idea”. Although i am still working to completely understand the implementation the financial aspects are quite obvious. Instead of reserving computing capacity you only need to pay for the time that a process spends executing. This means that it doesn’t matter if a process is rarely executed since we only pay when it does, instead of having to allocate space for that process regardless. Which then means that there is no need top bundle eliminating a large deal of the headaches that go along with that.

It was quite an interesting article and i suggest it to anyone who may even be slightly interested, the author does an amazing job of explaining the technical details.

Other Interesting Articles:

Correcting Load Testing Errors

Testing Microservices with Citrus

http://qahiccupps.blogspot.com/2016/09/giving-back.html

From jUnit to Mutation-Testing

 


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

Test Automation and the Internet of Things

More and more devices are now having the ability to connect to the Internet. With all of these devices testing is becoming more and more abundant. In order to test all these applications coming from all of these new devices, test automation is something that should try to be implemented as quickly as possible. With test automation on these devices, users will potentially experience less bugs and down time.

https://www.utest.com/articles/test-automation-is-challenged-by-the-internet-of-things

From the blog CS@Worcester – Software Testing by kyleottblog and used with permission of the author. All other rights reserved by the author.

Management Vs. Reality

While looking through a few blogs and websites I came across an interesting post. This post discusses the idea that there is not a specific way to analyze the amount of time the testing process takes, and tries to elaborate on some helpful tactics. The post is written by Lee Copeland and Matthew Heusser.

introducing-timeshiftx

Within every company there are thousands of variables that can possibly change the necessary amount of time testing will take. Estimating this time is a big challenge for the team because management will always want a finite time. But not many people can look into the future and see  what will go wrong. For all of the rest of us we have estimations. In the article they detail some of the big factors that can influence this estimation.

In the blog post they elaborate on some of the techniques that can help narrow the window of estimation time. Some techniques listed include:

  • Gathering more data
  • Getting to know the team you are working with
  • Knowing the stability of the requirements
  • Knowing the size and complexity of the system

The more data of past projects you have the easier your estimation will be. Knowing your team will make it easier to know the realities of the effort to time ratio. Knowing the stability of the requirements and the size of the system will allow a more accurate estimation of bugs in the project. In the post they mention an evidence-based scheduling method by Joel Spolsky.

My favorite part of the post is the closing line stating “perhaps we would be better off investing the time we would spend estimating, in doing the testing instead”. I think this is a very interesting way to say that estimation is sometimes pointless.

For more information click here to read the full post.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Pros of Platform-led Testing

Platform-led Testing by Lakshminarasimhan Rajabather

In this article, Rajabather goes over the positives of using platform-led testing to help with automation across all the stages of the software development life cycle. The first advantage that he lists for using this approach is that it cuts down on the cost and time to use assurance across the development’s life cycle. This is also positive to businesses since their goal is to minimize cost and time, and maximize quality.

Rajabather points out is that platform-led testing makes sure that the software is constantly being checked and validated at every stage of development. This is able to be done because, as previously stated, it is now possible to have software assurance constantly being implemented through the entire life cycle. Platform-led testing also works well with Agile development because it “promises quick sprints, rapid sign-offs and a measurable transfer of value from one sprint to the next.”

The last two advantages of platforms that Rajabather lists show that they are beneficial to businesses. He states that platforms allow businesses to build upon both industry and third party analytical tools which makes it so that the tools can be customized to fit a certain need. The last benefit is that platforms are not “restricted only to the requirements, design or execution stage of the lifecycle.”

Please read the full article for more information on this subject.

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

Git

This week I was reading a book call Learn Git in a Month of Lunches by Umali. The book was very good in explaining how Git works and is written in a very easy to understand way. My understanding of Git has improved by a lot after reading this book. I would recommend this book to anyone who wants to understand Git.

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