Monday, September 26, 2016

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:



No comments:

Post a Comment