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