Secure Logging Training by Clarified Security

This is my second training in Clarified Security, first one was Web Application Security. This one is shorter – only one day, – and trainer was Mait Peekma.

The most useful part for me was about what and how to log, but unfortunately it was the shortest one. As always, logging depends on the context of your application, so the only thing that public training can give you is the understanding of attacker's logic (like log evasion and tampering) and the sense of importance of logs in software security – both these things were done good.

In summary, good training to start. If you participated at Web Application Security before, then you already know some things, but in Secure Logging they were expanded. Also I had a chance to perform some attacks that I have heard about, but never succeed to do them by my self. I suggest it for those who should deal with incidents or just care about security.

Web Application Security Training by Clarified Security

You shouldn't find any EXIF data in this picture.

I've participated in the Web Application Security Training by Elar Lang from Clarified Security. It's very detailed and thorough hands-on 4 days training for web programmers, testers and all people, that are related to web development.

As for me, it's must-do for all web developers and testers. If you look at the content (especially client-side part), then it may seem to be too general and basic, but actually these well known things are explained in a quite deep and advanced level.

Organization is really nice feature of this training: first we had 2 days of client-side part and next week 2 days of server-side part, so between them I had 3 working days to work through client-side attacks on my application. Also, there can be maximum 12 participants, which makes the treaining more individual.

In summary – I really recommend it to people, who thinks that their software is safe or that there is nothing to wory about even if it's not.

Learn to use browsers' DevTools

Nowadays almost every browser has DevTools, which makes web testing way more easier. But, unfortunately not all testers are using it: some of them just don't know that DevTool exists, some of them don't know capabilities of DevTools, some of them don't know how to use it.

So I want to recommend a great CodeSchool tutorial about Chrome DevTools. It is very clear and simple and you can not just learn theory there, but do some real excercises. The great part is that DevTools of different browsers are very similar (especially Chrome and FireFox), so if you learn to use one you can easily use the other too.

Also I want to recommend a video Secrets of the Chrome Developer Tools from Oredev Conference, where Patrick Dubroy from Google Chromium team talks about some advanced stuff that you can do with Chrome DevTool.

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).

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:

The Six Thinking Hats by Edward de Bono

The Six Thinking Hats (or parallel thinking) approach is so classic that everyone knows it. Or at least have heart about it. But I was surprised that not all of people who like principles of this approach have seen this presentation. In the video Edward de Bono is talking by himself about the parallel thinking approach and the talk is very interesting and easy to perceive.

Just in case, here is the short summary about colors:

• White Hat Thinking focuses on data, facts, information known or needed.
• Red Hat Thinking focuses on feelings, hunches, gut instinct, and intuition.
• Yellow Hat Thinking focuses on values and benefits. Why something may work.
• Black Hat Thinking focuses on difficulties, potential problems. Why something may not work.
• Green Hat Thinking focuses on creativity: possibilities, alternatives, solutions, new ideas.
• Blue Hat Thinking focuses on manage the thinking process, focus, next steps, action plans.

And here is the video presentation in 6 parts:

The NULL Logic In The SQL

On today's course "Anatomy Of Database" by Targo Tennisberg among other things I have learned very simple thing about NULL in SQL:

I've always thought that NULL means nothing, but actually it means unknown.
And that is why we can not compare some value with NULL - we can not use expressions like value = NULL or value > NULL, because it basically means that we are askind "does value equals to unknown?" It is impossible to answer that question. So we need to use expression value IS NULL, which means "does value is unknown?" Yes, it can be unknown.

The thing that impresses me - that I've always knew, that I should use IS NULL, not = NULL, but I've never thought why (when I started to use PL/SQL Developer, for the first time I wrote = NULL in the querry).

The Audience Is Important As The Presenter

Today I participated in the course "Security And Unit Testing" by Erki Männiste. And the thing is, that I have been participated in it for the second time: first time the audience was the testing team, second time - developing team. The course and presentetion were the same, but for now on I decided to participate only with developers, if it is possible.

Reason number 1: usually the one target group, are they testers or developers, asks the same questions. If I am tester, so I can ask 90% of the questions, that will be performed in the testers' audience and that are interresting and useful for me. So being in the developers' audience I can ask testers' questions and hear developers' - kill two birds with one stone.

Reason number 2: if the course is about testing area, that means, that developers asks questions from the nontester position - I can see, how nontesters understand the topic, which gives me wide-angle overview about it and helps to delve into it.

Reason number 3: type of developers' questions helps me to imporove the comunication with them. I can understand their logic and see problems, that they are interesting in.

Unreason: there is 10% (subjective evaluation) of the questions in the testers' audience, that can encrease my testing experience. Especially they are likely to be asked if there is presenting a really good test master in the audience.

But, in most cases, the same course with the developers is much more useful, than the same course with testers.

And here is Erki Männiste - QA specialist at Nortal - presenting this course for the testers' audience and showing some example:

Short Summaries Of James Bach

Here are some notes, which I wrote down during the Rapid Software Testing course by James Bach. These are not the quotations and exact words of James Bach - these are short summaries of his speech.


* Tester proofs that it can work, not that it will work. Tester can only say, that it worked so far, not that it will work in the future.

* Tester don't brake the software, because it is already broken. Tester is just "lightning" the bugs.

* People will find more problems if they have less information.

* If you need to test something with data, then the data should move and go through all possible paths.

* All good formal testing is based on the informal testing.

* Test integrity - are you sure you did testing that you wanted to do and the way you are talking about it?

* If you don't need document template, then you can have it. If you do need - then you can't have it.

* Documentation should not be completely understandable for the outsiders. There are details, that should know only the insiders and there is no need to describe them completely.

* Test automation and documentation takes more and more time, so you do not actually have time to test.

Rapid Software Testing Course by James Bach

Today is the last day of the James Bach's (http://www.satisfice.com) course Rapid Software Testing which I was participating. I think a short remark about this course is a great start in blogging.



This course is the most important thing happened to me in software testing area. It gave me not only a bag of knowledge but also a feeling of tester (I suppose it might be related to the "testing muse" he reminded about).

UPD: all pictures from the 3rd day of the course are available in my Picasa album: Rapid Software Testing by James Bach (3rd day, 21.09.2011)