Exuses vs Reasons in Software Testing

Interesting article 8 Common Excuses in Software Testing by Mike Brown, who blames testers for did not found bugs. In comments you can find another article Why would I need excuses? by Tony Bruce, who said that testers don't need excuses for missed bugs, they have reasons.

Of course both of them are right: the first one is talking about lazy testers and the second one - about I-will-do-my-best testers. But I think that actually there is point to decide should you blame yourself for missed bugs or not. And the answers depends on personal nature - does blaming helps you to be more attentive next time? If does - so let it be excuses.

As for me, excuses are more productive than reasons: I'll better believe in that I am capable to do better testing, than that I did my best and there are missed bugs in the result. So if you consider for example lack of time for regression testing as excuse, you will try to use your time more productively.

ATM Interresting Behavior

Interesting behavior of ATM I discovered today. I wanted to put cash on my bank account using ATM.

Procedures:
* I inserted card
* I entered PIN code
* I inserted the cash
* ATM counted the cash
* I chose "Transfer money to account"
* ATM said "Wrong PIN"
* I entered the right PIN
* ATM transfers money to my account

Why the PIN verification procedures at this stage? What if I enter the wrong PIN 3 times? Does it give me my cash back?

The Sience Of Debugging by Matt Telles and Yuan Hsieh

I strongly recommend to read this book - The Science Of Debugging by Matt Telles and Yuan Hsieh. I really like how and what authors are writing about bugs. Especially I liked the Chapter 2: Case Studies of Famous (and Not So Famous) Bugs with summaries and points what we should learn from the others' mistakes. Don't be confused with the "debugging" word in the title - book is also interesting and useful for the testers who just find the bugs, not reduce them.

Also I recommend to read a short article History's Worst Software Bugs by Simson Garfinkel, which shortly describes some of the cases.

Introduction To Load Testing by Kristo Kuusküll

On this week I participated in the course Introduction To Load Testing by Kristo Kuusküll. Here are some interesting notes (not quotations) from this course. I emphasize that I am not a load tester, so this area is new for me.

* It is necessary to know the frequency of clicking and typing of end-users. If client can not define these requirements you can take this information from live logs.

* Load testing software does not simulate the browser.

* Load testing takes a couple of days even among professionals.

* You need tests and sometimes even a load tests for load tests.

* Before overloading the application always run the tests for 1 user (thread). If it is ok only then you can run it for 1000.

* Load testing software and the application never should work on the same machine, because load testing software increasing the CPU%.

* If CPU usage is grater than 75%, then you can not trust the results.

* It is necessary during the testing to browse the application in the browser - only that you can see the whole picture.

* You should check not only test status (fail\ok) but the response data itself. There might be successful response (code 200) with text of error (sorry, the server is overloaded, please contact the administrator).

* The best software for beginning is JMeter. But it takes a lot of memory, so you can not use it for sizable projects (more than 300 users).

* In JMeter different reports take different amount of memory, so you can increase the number of threads by disabling some result reports (Summary Report is the best).

TED's Set About The Security

Here is a set of good TED's videos about security and hacking. I recommend to watch them in given order.

How to Make Software Fail by John Regehr and Sean Bennett

There is a pretty good online course about software testing in Udacity, called How to Make Software Fail by John Regehr and Sean Bennett.

This course is for programmers, but testers can also find some useful thing in it, especially the automation testers.

There are some brief quizzes and answers with explanations. They are not necessary of course, so you may just listen the theoretical part, which takes a few hours. In the some exercises you should program a code in python, others are just theoretical questions.

As always in Udacity there are a discussion and a wiki sections - in the wiki you can find the whole written text of the course.

Technical part: Auto-Next function does not perfectly work in Safari browser - sometimes it doesn't switch to the next video automatically. In Chrome works perfectly.
Answers' submitting works only if you're signed in, otherwise it just "working" a long while (Safari, Chrome). But you can watch videos without submitting answers, so it is not really necessary to sign up.

And here is the interesting example of one video:

About Planning