All Participants Work For The Benefits Of The Project

Most people hate to work in support, because they are tired of all these stupid clients, who doesn't understand at all how things work.
Some people even hate to explain something to their colleges: they think that colleges wasting their time by asking questions that they probably could just google. I've found a quiet simple solution for myself to reduce this kind of feeling:
All participants work for the benefits of the project
Basically, every time I feel "oh, that stupid question again" I remember, that it isn't about me, it's about the project. And the project definitely benefits if I answer on this question reasonably and exhaustively.

It helps even in the tester-developer situations: there are some developers who don't take testers seriously. And only reasonable thing that you can do in this situation is to show that testers are useful too. And one way to show it is to help developers (for example, testers can help to update versions, update/write manuals, create test data etc).
Help your developers!
It also helps in situations, when you feel "it's not my work, I don't want to do that". In the scope of project it doesn't matter who did something - it matters that something is done.

Lessons Learned in Software Testing by Cem Kaner, James Bach, Bret Pettichord (2002)

I like it.
It's a long-play book, that you can (and want) to read from time to time. It is designed for coming back: it has 293 lessons with very clear topic and with some thoughts about this topic. So, if you want to read something about specific problem, then it is quite easy to find thoughts about it.

I like that authors don't afraid of short explanations - for example, lesson 4 have only 5 rows and it's nice, because there is no unnecessary information in it. There is a lot of big books with big chapters where concentration of useful information is actually very low. Not in this book.
I am agree with Tim Lister, who said (on page XVIII of this book): "If you have never participated in a serious software effort, this book will be too heady for you." This book is for experienced testers, not for juniors. It can be useful for those who have already encountered with some problems in testing and have been already thought about them.

But I am not quite agree with further "rule of using" this book (also from Tim Lister on same page): "Don't drink the entire bottle" Meaning "don't read this book in one sitting". I've read it in one sitting for the first time, which gave me general overview of it's content. For me it is not very important to understand all things in first time, it is more important to know what sort of information you can find there so you can return to it later.

So I think every tester should have their own copy of "Lessons Learned in Software Testing" - it is not that kind of book that you can borrow. It is very useful when you can come back to it whenever you want.

To Worry About All Things

Three problems that need to be worried about in the context of other problems.
A couple years ago, being a junior specialist, I was involved in resolving one big problem with senior analytic and senior developer. And I remember very clearly our talk with analytic:
[A] We should think about this.
[Me] Developer is fixing it now.
[A] OK, we also should resolve that thing.
[Me] Developer has already fixed it.
[A] Good. Also we need to figure out how to resolve this issue.
[Me] Developer already has some plan about it.
[A] Good. That's what I call senior developer.

And at moment I understood what does it mean to be a good at your work - it means to worry about big picture and see all things that are connected to your area, even if you are not required to worry about it.

Even today I think about it from time to time - it helps me to find time for stepping back and try to see a big picture. It is much easier to see picture than to find time for that, and remembering this dialogue is a very good trigger for me (because I also want the other senior analytics and developers talk about me "that's what I call good tester").

More Bugs, More Testers Mistakes

Tester makes more mistakes if developer makes more mistakes.
On this week I noticed that if I - a tester - check some functionality with a lot of bugs in it and ping-ponging these bugs to developer several times (some developers can't fix bugs with one version), then with another "fix" I am more likely to be critical on code, not on myself. That means that I am more likely to report every suspicious thing about that functionality, even if it is not a bug.

Testers mistakes in that case are mistakes, that developer can't fix in code: wrong settings, for example; or wrong data; or misinterpretation of documentation.

If developer produces relatively clean code, I assume that if I find suspicious behavior it more likely to be my mistake (because I know, that this developer makes few mistakes). Or, in another words, the cleaner code usually is - the higher probability that founded bug is caused by tester.

This kind of prejudice is not productive, so every time I try to "reset default settings" and don't think about developer, who implemented the task, but think only about code and implementation. I even preferred to check anonymous tasks (without developer's or analytic's name), but unfortunately I can't do it in JIRA.

Testing Applications on the Web by Hung Q. Nguyen, Bob Johnson, Michael Hackett (2003)

I've just finished to read this book and decided to write an opinion about it.

In short - I didn't like it. It's too obvious, too direct, too general and too big.

Examples of why obvious:
There are multiple browsers and browser versions available for PCs, Macintosh computers, and UNIX computers. (page 130)
Remember, for any valid condition, there is always an invalid condition. (page 259)

Examples of why direct:
In testing for DLL-related errors, do the following: ... (page 143)
In a server-side installation, the user (usually an administrator) must, at a minimum, be able to specify the following: ... (page 374)

Example of why general:
Simply put, an effective UI design is one that provides the highest usability to the users. (page 247)

Why big? I think, all information that is written on 644 pages could be shortened to 100 pages, or even less.

So, I can't suggest this book for experienced testers, because I don't think they find anything that expands their knowledge or makes them think in a new way. And I also can't suggest this book for new unexperienced testers, because normal person can't keep in mind 644 pages of todo lists and document templates and, again, because it doesn't make reader to think.

Also some things are not valid nowadays: for example, chapter about response time (internet is way more faster now); or some suggested tools; or some links are broken now (and there are lots of links in the book).

But there are a few things that I liked. First of all, it's a first book where I've read about The Combinatorial Method (page 78, Chapter 3).
Basically, with that method you can extract from, for example, 27 unique combinations 9 that are worth testing (I've even thought about using that algorithm in my next extension).

Also chapter 18 "Web Security Testing" is not bad. It is very long chapter (maybe that's why it seems to be quite thorough). And I think that it's introduction explains quite well why this topic is interesting:
Security issues are becoming the gravest concern of many companies. Despite this fact, security testing often remains the least understood and least well-defined testing activity.

In conclusion, I would like to tell that this book is not worth the time that it requires.

spanD v1.1

New version of spanD is now with new dev design too!

• Google Store
• Extension Page
• Extension Repo at GitLab

 
In latest version

• New dev design
• New icon
• Shows result only if it is not NULL (difference between 0 and NULL)
• Smart focusing: when You focusing on span calculation, the bottom part of date addition is shadowed. And vice versa

stringG v3.2

New version of stringG is available with new dev design!

• Chrome Store
• GitLab
• Blogger Page

 
There is no new functionality - only design. I am reading Testing Applications on the Web (by Hung Q. Nguyen, Bob Johnson and Michael Hackett) and the chapter about design and performance made me think about software target users. So I decided that testers (and all IT users) will like so called terminal design with dark background and monospace font.
Also I am using now new text editor Atom. I'll write about it later when I get enough experience with it.

Bad and Good Humor in IT

Here are some video sketches which are somehow related to IT.

Lets start with bad humor. I don't like this kind of attitude to customers: yes, they often don't know what they want; yes, they often don't know how to properly name things - but the mission of IT guy in this situation is to understand what is actually needed, not to prove, that customer is stupid and doesn't understand the topic.
This sketch shows how unprofessional IT "expert" actually is, not how stupid requirements customers order.

This one is better. Not very funny but at least accurate and not offensive:

And these are really good: 2 parts of If Google Was a Guy: