Making Your Own Rules When There Isn’t Any.(Week 11 12/2/16)

There may come a time in your life as a software tester, where you do not know what to test. The guided path that your leader should have instructed you to base of your testing skills off of are completely blank and un-given. What do you do? The answer is simple, you do not take this moment as a stress-full event in your life where you may think one wrong, un-sure move is going to ruin your entire career, but take it as a opportunity so a blank slate with no requirements can turn into a free-style session and let your bug breaking mind run free!

Are you not given what to specifically test for and a strict deadline to go as the cherry? While, you could ask your supervisor for a list of requirements since they have not created them or misplaced the information to give you by accident, but chances are they do not have any and want you to go wild!

But how do you go wild when it comes to testing? Well, when the key phrase “oh i do not know what i am testing for” comes around, as a tester a familiar key term should pop in your head and that is the key term Black Box Testing! You can go crazy finding errors and bugs in a project and by the time the project is done, you have flexed your creativity muscles but enriching the curious experience of being a tester. The best of Black Box Testing can be found here.

Source: https://testzius.wordpress.com/2016/12/13/testing-without-requirements/

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.

On bug prevention

I really enjoyed this blog. The main theme more or less was
can bugs be prevented? He goes on to talk about how in testing we go at the
software from many different angles looks for bugs, but just how often is it
that we actually think about preventing them and are they actually inevitable
and can they even be prevented in the first place? While bugs are inevitable he
believes that they can be somewhat prevented and after reading his blog I
believe he is right.

He goes on to explain the general things we can do about
prevention such as better communication, trying to make less mistakes in the
code, understanding the platform that is being worked on and the list goes on.
The main question he asks is this; What can a tester do to help with bug
prevention? Testing happens usually after the bug is already in place and it is
the then too late to prevent the bug right? Well maybe not. He goes on to say
that the testing and the results report can actually influence the teams
thought in some areas or things. He says, “For
example, something as ‘innocent’ as an email saying: ‘I’m planning some testing
of feature X and I wanted to make sure I’m not duplicating work on this. What
kind of unit tests have you done on this?’ can gently nudge coders to think
about unit-testing their code (and the bug prevention benefits that come from
writing code that is unit-testable in the first place).”

I really enjoyed this blog as he
makes many good points and if I am ever in the tester role I will surely take
some of his points to heart.

You can read the full blog here:

https://offbeattesting.com/2016/12/13/preventing-bugs/