Nicky Tests Software: June 2013

Wednesday, June 26, 2013

Interview with Michael Larsen

Michael Larsen retired from a career as a rock and roll singer to pursue software testing full time at Cisco Systems in 1992. Larsen has worked for/with a broad array of technologies and industries including virtual machine software, capacitance touch devices, video game development and distributed database and web applications.

For the better part of his career spanning 18 years, Larsen has found himself in the role of being the "Army of One" or "The Lone Tester" more often than not. This unique view point, along with ideas and advocacy regarding continuous education and learning/re-learning for testers, is frequently the grist of the mill for TESTHEAD


Sunday, June 23, 2013

Getting Feedback as a Software Tester

To start with, I think getting feedback as a Software Tester is very important.

In general, I think it's great to solicit feedback to see what you're doing well, what you're not doing so well and what you could just stop doing altogether.

A man from our office gave us a presentation on personal radars and how to be awesomer, then asked specifically for feedback after the presentation and then again in an email the next day- thanking us for our time. Good stuff. No ambiguity involved. If there was anything that I think he could've done better, I had a green light to let him know. And what he did well? I made sure to tell him what I thought regarding that too. And you know what?! I did it Toastmaster Stylz! That's right. The CRC approach- Commendation, Recommendation, Commendation.

Monday, June 17, 2013

8 Questions I ask myself when Testing Software

Questions I ask myself when Testing Software


So I'm working on a project, am given a project brief and then find some questions floating in my head.

Now aside from the obvious where I want to help detect any bugs before the system goes live I also find myself thinking the following things....



What's the point of this new system?

OK so we would've already been told this. But really, in simple-man's terms - what the point of this new piece of software? How does this add value to the users/business etc?

Sunday, June 16, 2013

Wednesday, June 5, 2013

How would I Promote the Software Testing profession?

How would I Promote the Software Testing profession?

I ask myself this so that I can try and explore how I would go about promoting Testing as a Profession.

To see how this came about, go here

Now, I have a theory and I do think it's fairly plausible so bear with me :)

You know despite the fact a lot of people seem to end up in careers that are not only unrelated to their education (whether that be teritary, polytech etc), I also think a lot of people end up doing something 40 hours a week- that they had not heard of as a career in high school. Or scratch that- even university!

Therefore, I propose a national Software Testing Competition for high school students and a separate competition for those in Tertiary study. 

In New Zealand there are similar competitions for Maths, English, Science, Economics and Debating (sponsored by a law firm)- so why not do the same with testing? It'd be a great way to get the word out there of software testing existing as a career and to get young people interested in exploring this possible career path.

So to focus on a specific example: The Monetary Policy Challenge. This is an Economics competition aimed at high school students. The long and short of it is that it is organised by the Reserve Bank of New Zealand (New Zealand's central bank) and participants need to come up with an Official Cash Rate then justify it. (BTW the Official Cash Rate is like the interest rate at which the central bank lends money to the other banks- i.e. OCR goes up, interest rates go up --> mortgages are more expensive, saving is encouraged etc etc).

Anywho. Enough of that. I don't want to lose you just yet. Let's get straight into it shall we!

So what I'm going to do is outline, in bullet points, what this competition would involve, and then draw attention to some possible benefits that could be reaped from such an idea.


Here's a Bullet Point format of what it would involve:

  • You need to be in a team of 2-6 people to enter
  • A few companies collaborate to run the competition and write requirements, build a piece of test software, change their minds with what they want etc etc to make it more 'real-life'
  • The competition is promoted to those studying IT in high school and uni through lecture bashes and newsletters- but NOT limited to those studying IT. 
  • Potential prize could be an internship for members of the winning team
  • Judges' criteria will include creativity, effectiveness, ability to justify, accuracy etc
  • Networking event after the prizegiving ceremony takes place

Possible Advantages:

  • Students have more career choices, they now know what software testing as a career path could look like
  • Potential Employers are able to meet students and listen to their viewpoints from a fresh perspective
  • More exposure to software testing as a career
  • Student get a better idea of what it's like to work on an IT project and can relate it back to websites they are familiar with like Facebook, Tumbler, Twitter, ZMonline etc
  • Friends and family of participants also gain awareness of the software testing industry
  • Sponsors will be exposed to students and perhaps students will see that as a more desirable work location
  • Sponsors can build important networks among themselves
  • Sponsors can see this as a step towards building strong relationships with tertiary institutions and secondary schools


Tuesday, June 4, 2013

Interview with Nadine Henderson

Nadine is responsible for Assurity's HR, recruitment and graduate recruitment. She plays a key role in helping to drive the company into its next stage of growth.
Her strong background in IT recruitment - she worked as HR Manager at Intergen for three years - gives her the knowledge and know-how to recruit the best people in New Zealand

Monday, June 3, 2013

More ISTQB Tips and Explanations of Sample ISTQB Foundation Questions

Hope you guys liked my previous blog post on tips for the ISTQB exam :)

I got some great feedback on LinkedIn when I posted it on a discussion there that I thought I'd follow it up with a few more tips and Part 1 of explanations of some sample ISTQB Questions.
(Source: http://www.istqb.org/downloads/viewcategory/41.html)

More Useful Tips for the ISTQB Foundation Exam

Process of Elimination

As the ISTQB Foundation Exam is multi-choice, process of elimination is a pretty good idea. The good thing is you can get rid of the trash quickly and then focus on the 'realistic' possible answers when you read the question or when you come back to it later

Highlight the key words

Especially words like "not" and "most" that change the entire meaning of the sentence but can be easy to miss.

Watch out for questions that contain the word "MOST"

I'd like to draw attention to this because chances are all of the options will be correct if you're asked something along the lines of: "Which goal is the MOST valid to try and achieve?" At least 2 of your options will definitely be valid, so don't just circle the first correct answer you see as you go through your options

Learn the different ways to say the same thing

For example: Confirmation Testing and Retesting --> They're the same thing. You don't want to be thrown by a question that you should know the answer to because you didn't know about different ways of saying the same thing.

Learn the different types of Coverage

You're guaranteed a few questions that will check you actually know the difference between Decision coverage, path coverage, branch coverage etc. I've written a blog post on the difference between Branch and Path coverage here.

Make sure you learn the 7 Key principles of Software Testing

Here they are:

(Source: http://www.universalexams.com/iseb-istqb-certification/the-7-key-principles-of-the-isebistqb-foundation-level-exam)

Principle 1: Testing shows the presence of bugs (but a failure to find bugs does not necessarily mean that none exist). Tests must be designed to find as many bugs as possible, and since it is assumed that every product initially has bugs, a test that identifies bugs is better than one that finds none.

Principle 2: Exhaustive testing is impossible because there are usually too many variables that come into play. Therefore, testers must focus efforts on only the most critical priorities and risks.

Principle 3: Testing should be done as early as possible after the product or application has been created, in order to fix issues as fast as possible. Errors identified later in the process tend to be more expensive to mitigate.

Principle 4: Use defect clustering, as software problems tend to cluster around narrow areas or functions. By identifying and focusing on these clusters, testers can efficiently test the sensitive areas while concurrently testing the remaining “non-sensitive” areas.

Principle 5: Use a variety of tests and techniques to expose a range of defects across different areas of the product. Avoid using the same set of tests over and over on the same product or application, because this will reduce the range of bugs you will find.

Principle 6: The same tests should not be applied across the board because different software products have varying requirements, functions and purposes. For example, a website should be tested differently than a company Intranet site.

Principle 7: Don’t buy into the absence of errors fallacy. In other words, a test that finds no errors is different than concluding that the software is error-free. It should be assumed that all software contains some faults, even if said faults are hidden.

Confirm answers

Not only should you make sure that your answer is correct but that the other answers (that you did not select) are definitely wrong. This is a great way to stop yourself from being caught out.


Explanations of Sample ISTQB Foundation Questions




Which of the following statements BEST describes one of the 7 key principles of software testing?
a) Automated tests are better than manual tests for avoiding the Exhaustive Testing
b) Exhaustive Testing is, with sufficient effort and tool support, feasible for all software.
c) It is normally impossible to test all input/output combinations of a software system
d) The purpose of testing is to demonstrate the absense of defects


Ok let's start from the top.
a) This doesn't make any sense. How does automation help avoid exhaustive testing?
b) Exhaustive testing (note this is also known as complete testing) is not feasible for all software. The keywords here are ALL software. Even with the addition of the words "sufficient effort and tool support" makes that option seem possible, the "all software" part cancels it out.
c)Yep this looks good. Since software systems are so complicated, testing all input/output combinations of a software system would indeed be very difficult and "normally possible". Let's hold on to this one for now but check the last one just to make sure.
d) Nope. It is to demonstrate the presense of defects. BUT say you didn't learn this particular key principle of software testing. Then you could also ask yourself, how exactly would testing a piece of software prove that there is nothing wrong with it (i.e. there are no defects).

Answer: C




Which of the following statements are TRUE?


A. Software testing may be required to meet legal or contractual
requirements.
B. Software testing is mainly needed to improve the quality of the
developer’s work.
C. Rigorous testing and fixing of defects found can help reduce the risk of
problems occurring in an operational environment.
D. Rigorous testing is sometimes used to prove that all failures have been
found

a) B and  C are true. A and D are false.
b) A and D are true. B and C are false.
c) A and C are true. B and D are false.
d) C and D are true. A and B are false.

With these sort of questions I like to use the process of elimination technique and figure out which sentence out of the ones above is true so that I can eliminate 1 or more options as soon as possible.
Let's start with A.
Yes- A is true. It's feasible that software testing may be required to meet legal/contractual requirements (e.g. for peace of mind for people 'above' and to know that the software is of a certain quality)
Now that we know that sentence A is true. Let's eliminate options a) and d)
Let's read sentence C. Yep definitely- rigorous testing and defect fixing can reduce the risk of problems occuring in an operational environment. Let's put this one on hold and check sentence D.
D- nope you can't prove all failures have been found. It's not feasible. Similar to the idea of Exhaustive Testing is impossible.

Answer: c)