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.

Let's Test 2015: Final Day 3

Software Talks by Julian Harty (@julianharty)


Photo from Let's Test Conference Flickr
Security Testing talk by Jari Laakso was replaced by this one. Julian Harty talked about mobile software, customers feedback and statistics. Some facts about Google: about 75% of bugs are not being fixed (usually it's minor bugs that are closed or postponed); GoogleAnalytics doesn't know data of one particular user, it aggregates all data into one big picture; there is not so much manual testers in Google – basically they collect data from users, which helps to find problems.

One very interesting thing about mobile testing: if your mobile application connects to the internet then you should test its traffic – it shouldn't send or receive more data than needed, because users pay for each byte.

And one lesson about customers service: developers (or somebody in product developing team) should follow users comments on store page. First of all, it's good source of problems and bugs. Secondly, if there is a reported problem without an answer, users are likely to report more negative comments and reduce the rating. If developers team answers that they are dealing with reported problem users are more likely to trust.

Coders To The Left by Jan Eumann (@JanEumann) and Philip Quinn


Photo from Let's Test Conference Flickr
Workshop about how to find bugs using the source code and how to fix them. Very useful workshop for me, because 5 days earlier I did something similar in our company internal conference. So it was interesting experience to see how other people doing same stuff as I did (especially, taking into account that it was my first workshop that I ever did).

During the session we worked in groups and had to find bugs and fix them. I discovered some new functionality in DevTool for myself and had a couple of ideas how I can improve application for my own workshop.


Me working in pair with Kadri-Annagret Petersen (@kadriannagret).
Photo from Let's Test Conference Flickr
Closing keynote Detecting the Heartbleed Vulnerability by Tuomo Untinen


Photo from Let's Test Conference Flickr
Seems like the presenter was not very experienced (which was a big contrast with the whole conference), so it was hard to listen to this keynote. Especially hard to focus after so intensive days. But topic was very interesting, so I even have written some interesting points: finding heartbleed bug wasn't a luck, more like a decision; vulnerability was made in 2012 in last day of December, which is just coincidence. They wanted to put some honeypots to find out does somebody exploit this vulnerability, but it went to public too fast (by OpenSSL fault), so it didn't succeed.

Main takeaway – if you notice something new and unclear – try to understand it.


Siim Sutrop (@SiimSutrop) is asking quite interesting question – was finding heartbleed bug a luck or good testing? The answer – it was a decision.
Photo from Let's Test Conference Flickr
Summary

In the first post I have already written that it was the best conference I have ever attended at. I've met there a lot of open, smart and inspired people, who give a lot of energy and ideas. You can talk about testing there in very different aspects, for example, I even participated in small talk about testing and religion. So, if you have and opportunity to participate in some conference and don't know which one to choose – I definitely suggest to choose Let's Test. Next date is already known – May 23rd-25th 2016!


Me thinking about the conference during the final keynote.
Photo from Let's Test Conference Flickr

See posts about other days:
Let's Test 2015: Day 1
Let's Test 2015: Day 2, Exploring Web App (In)Security

Let's Test 2015: Day 2, Exploring Web App (In)Security

Testability Features by Stefan Thelenius (@StefanThelenius)


Photo from Let's Test Conference Flickr
Good talk for morning session, which gave me a lot of ideas about making testability features in my project (for example, I really like the idea to have some tool, that chooses random document from the DB). Stefan Thelenius showed us testing-application that their developers have made for testing real-application. Interesting thing, that testing-application appears thank to developers, who decided to test more (by them self, not by managers order) and found out that only setup and configurations take half a time. So developers decided to create some application that allows to spend more time on actual testing. A little bit sad, that testers still don't implement new features by them self, but asks developers for that. I think testers should strive to do their tools by them self.

But you should be very careful while implementing testability features – first of all, it shouldn't relate to production anyhow; secondly – usually testability features are not being tested (because of the lack of time), so more complex they are – more chance to get false results.

Exploring Web App (In)Security by Bill Matthews (@Bill_Matthews) and Dan Billing (@TheTestDoctor)


I am interested in security for about a year now. I remember great session of Dan Billing about New Adventures In Security Testing on previous Nordic Testing Days 2014. So, when I saw this workshop and Dan's name I immediately knew that want to join it. And my knowing didn't let me down – it was really useful and interesting full-day workshop.

Thanks to this workshop I have a long backlog of security things (test cases and tools), that I'm going to try at my work. I heard about them quite a long time ago, but now I have an idea about how actually use them.

During this workshop we had a lunch, where Baldvin Gislason Bern said interesting thing: statistics works only once, because further data begins to adjust to the metrics.

Cynefin Sensemaking Surgery by Duncan Nisbet (@DuncNisbet)


Photo from Let's Test Conference Flickr
Duncan Nisbet told us about interesting framework Cynefin (kʌnɨvɪn) and we even did some exercises, but I'm not still sure how to use it in real life. Agree, that it can add some sense in some hard situations, but its implementation is still quite vague to me. Or maybe I was still thinking about security and didn't hear important explanations.


One interesting (in some sense even philosophical) thing about transactions between different domains. There are 5 domains in Cynefin framework: Complex, Complicated, Chaotic, Obvious and something between them all. You can move through these domains, but there is one special boundary between Chaotic and Obvious – if you believe that all things are simple you can crush into chaos and it's nearly impossible to go back to Obvious domain (usually from Chaos you move to Complex). Other boundaries allow transactions.

TestLab

After all workshops open bar and TestLab again.


Photo from Let's Test Conference Flickr


See posts about other days:
Let's Test 2015: Day 1
Let's Test 2015: Final Day 3

Let's Test 2015: Day 1

Here is another post about Let's Test conference. You can read at least two more detailed opinions about it by Hannes Lindblom (@HannesLindblom) or Dan Billing (@TheTestDoctor). Also hashtag #LetsTest in Twitter is quite interesting reading.

Shortly – it's the best conference I have ever attended. Longly – it's not quite conference, but some kind of community meeting. The slogan on badge – "By Testers For Testers – Because People Matter" – is absolutely true.

I arrived at Runo a day before official start, so I also write a little bit about Day 0. Venue is very beautiful and it's a good place for knowledge and thinking. The level of all services (room, bed, food, wi-fi, number of outlets etc) was quite hight, so there were no distractions at all.

Every participant got a little bear, who suggest to test (see title on his shirt), nice notebook and badge. I liked, that every one should write their name (or whatever they want) on badge by them self, so they are all individual and unique. There were also 3 k-cards (red, green, yellow) for questions.

A lot of people also arrived on Sunday, so socialization part started immediately. Han Toan Lim (@MIndfulTester), who was doing a workshop What I Learned From Juggling, brought devil sticks and taught willings to deal with them.

Kristjan Uba (@kristjanuba), Henrik Andersson (@henkeandersson), me, Siim Sutrop (@SiimSutrop) and Han Toan Lim. Photo from Let's Test Conference Flickr.
Day 1 started with keynote There Was Not a Breach; There Was a Blog by Ben Simo (@QualityFrog).

Photo from Let's Test Conference Flickr
This is actually the same keynote as in CAST last year and you can see it on Youtube – CAST 2014 Keynote . It was slightly modified, but mainly the same. Very good keynote, especially for those, who haven't seen CAST version. Ben Simo told very interesting true story combined with educational parts.
Main takeaway – if you find security bug don't do harm and don't publish info, that somebody may use to do harm.

Equipping You For the Unexpected Challenges of Testing by Emma Armstrong (@EmmaATester)
We needed to do some exercises in pairs and here comes a challenge – Michael Bolton (@michaelbolton) decided to join our pair for couple of minutes. I was in pair with Christina Ohanian (@ctohanian) (who did a workshop A Note on Notetaking Using Mindmaps and who draws beautiful mindmaps) and we needed to test prototype according to Shneiderman's Eight Golden Rules of Interface Design. Mr Bolton a little bit chided us about not making notes while we were exploring the application and shows as example which notes he would take in this case. Also he told us, that Jonathan Bach once told him, that he doesn't usually look for bugs during the exploring, but he looks for people, who can take advantage of application, which makes it easier to find important vulnerabilities, that can be exploited (it's not a quotation, it's how I remember it).
Main takeaways from workshop itself – be aware of time, complexity, skills and external factors, and you can use at least 5 tactics to deal with them: cheat sheets, heuristics, rubber duck, visualization and practice.

A Journey Towards Self-Learning by John Stevenson (@steveo1967)

Photo from Let's Test Conference Flickr
I really liked his book The Psychology of Software #Testing and even wrote a post about it.
All participants were randomly divided into 3 groups (and I randomly got into one group with my 2 colleagues) where we did a lot of exercises using ARCS model of John Keller (Attention, Relevance, Confidence, Satisfaction). Main takeaway – if you want to learn something try to write about it or teach it. Also interesting blog post was mentioned – Oracles Are About Problems, Not Correctness by Michael Bolton.


Me explaining to Siim Sutrop my values and priorities. Photo from Let's Test Conference Flickr
A tester's Walk in the Park by Ilari Henrik Aegerter (@ilarihenrik)
Unusual format of the session – we just walked and talked about testing. I liked it, despite the fact, that I expected more philosophy from Ilari Henrik. Venue is very beautiful and walking there is a great pleasure.


In the evening there was an open bar, TestLab and socialization.

Photo from Let's Test Conference Flickr
I really liked TestLab – it was great opportunity to test with great testers. For example, I tested a little bit some planning application with Rikard Edgren, who talked about serendipity on Nordic Testing Days 2014 and managed to crash the application by some random action.



At the end of the first day I was in some kind of cultural shock. It's a magical place for tester to be.



See posts about other days:
Let's Test 2015: Day 2, Exploring Web App (In)Security
Let's Test 2015: Final Day 3

Hackers: Heroes of the Computer Revolution by Steven Levy

Hackers: Heroes of the Computer Revolution by Steven Levy – very interesting book, which is not about testing, but about hardware and software history.

By sheer dint of hacking, the TX-0 no, the PDP-1 hackers had turned out a program in a weekend that it would have taken the computer industry weeks, maybe even months to pull off. It was a project that would probably not be undertaken by the computer industry without a long and tedious process of requisitions, studies, meetings, and executive vacillating, most likely with considerable compromise along the way. It might never have been done at all. The project was a triumph for the Hacker Ethic.

It is full of charming stories about how some things were invented and how hackers were dealing with problems.

One of Minsky's contributions to the growing canon of interesting hacks was a display program on the PDP-1 called the Circle Algorithm. It was discovered by mistake, actually while trying to bum an instruction out of a short program to make straight lines into curves or spirals, Minsky inadvertently mistook a "Y" character for a "Y prime," and instead of the display squiggling into inchoate spirals as expected, it drew a circle: an incredible discovery, which was later found to have profound mathematical implications.

He would help develop a program called "The Dictionary," which corrects an Apple user's spelling, but then would place a magazine advertisement for the product which contained ten spelling errors, including a misspelling of the word "misspell."

The joke is, if Draper were writing math routines for addition and he came up with the answer 2 + 2 = 5, he would put a clause in the program, if 2 + 2 = 5, then that answer is 4. That's generally the way he writes programs."

The book describes in great detail the Hacker Ethic and raises a lot of philosophical questions.

He'd [Ricky Greenblatt] twist back in his chair, looking not as rumpled as he did back as an undergraduate, when he was cherub-faced and dark-haired and painfully awkward of speech; the question, he figured, came down to whether hackers were born or made, and out came one of the notorious non sequiturs which came to be known as Blattisms: "If hackers are bom, then they're going to get made, and if they're made into it, they were bom."

The perfect algorithm. You'd have hacked right into the sweet spot, and anyone with half a brain would see that the straight line between two points had been drawn, and there was no sense trying to top it. "The Right Thing," Gosper would later explain, "very specifically meant the unique, correct, elegant solution ... the thing that satisfied all the constraints at the same time, which everyone seemed to believe existed for most problems."

"The technology has to be considered as larger than just the inanimate pieces of hardware," said Felsenstein. "The technology represents inanimate ways of thinking, objectified ways of thinking.

"To me, the best teachers tell me what I know is already right," Lee would later explain

Reading this book you may understand better why today's world is such as it is.

BASIC had spread all over the country, all over the world. And it helped Gates the fact that everybody had Altair BASIC and knew how it worked and how to fix it meant that when other computer companies came on line and needed a BASIC, they went to Gates' company. It became a de facto standard."

This book is filled with love for computers. If you ask yourself not only how, but also why – you may like it.

Les Solomon would speak in hushed terms of the project he was about to introduce to his readers: "The computer is a magic box. It's a tool. It's an art form. It's the ultimate martial art... There's no bullshit in there. Without truth, the computer won't work. You can't bullshit a computer, God damn it, the bit is there or the bit ain't there." He knew of the act of creation that is a natural outgrowth of working with the computer with a hacker's obsessive passion. "It's where every man can be a god," Les Solomon would say.

Perfect Software And Other Illusions About Testing by Gerald Weinberg

Perfect Software And Other Illusions About Testing – I am a little bit confused by this book and can't decide did I like it or not. Some chapters are good, some are too obvious. Obvious, of course, for me, maybe not for others, but I value books according to what new they can give to me.

First of all – version for Kindle on the Ebay is awful. All content is in one chapter (actually there are several chapters, but they are not formatted properly), which makes navigation harder:

There are some concrete characters in the book, with whom are made some examples. A lot of them are quite trivial and overdone, so they seemed pointless for me:

Some claims are doubtful. For example, claim, that the most important value of review is learning – for me it sounds like learning is the very last excuse why you should do review, because all other reasons doesn't fit. Usually (and I think in that case also) learning is a good side effect, not the purpose.
Update: see discussion in the comments about this item.

Another example – author categorically thinks that tester should not answer the question "Is the software ready to ship?" – I think that good tester definitely should answer this question and in modern projects roles are not so strictly divided:

But some claims are good and interesting:




Seems like this book is good for developers, who want to test and for testers, who are involved in testing for many-many years and they need to learn again how to test (with up-to-date tools and approaches). But for young testers, who are learning to test from scratch there are too many obvious and out-of-date recipes.

And beautiful parallel in the end:

The Psychology of Software #Testing by John Stevenson

The Psychology of Software #Testing by John Stevenson – great book for all testers. It's useful for beginners, full of resources for further advanced study and full of great quotations.


"Creativity is just connecting things. When you ask creative people how they did something, they feel a little guilty because they didn't really do it, they just saw something. It seemed obvious to them after a while." Steve Jobs – Wired Magazine
Basically the book is collection of references to interesting articles and books and brief analysis of them. At the same time it contains all necessary information, so themes are developed and there is no need to look into referenced articles for explanations.


As one of my previous post stated I think to be creative we need to think about finding problems than trying to solve them. Continuing on the path of our focus being only to solve problems restricts our creative thinking.
I was looking for this kind of book for a while. A book about testing, but not about techniques, methodologies, reports and other skills. There are psychology books and articles that are useful for testers, but there aren't many books, which connects psychology with concrete testing cases and possible situations.


Testing is not just about finding defects it is about asking questions and forming theories based on the answers (evidence) given while experiencing the software.
<...>
Finding defects is a side effect of this approach, a very useful side effect, however, it is not the sole purpose of testing.
Book asks not only psychological but also philosophical questions.

if testers should be problem solvers or problem finders

They like to know that, say, a dog will bite a man. That is what dogs do. They don't want to know that man bites a dog, because the world is not suppose to happen like that. In short, what people think they want is news, but what they really crave is olds.

"I would like to remind people involved in testing that – after and engaged brain – one of our most useful testing tools is... the pause..." Michael Bolton
The book is quite small and you can read it in one evening.

The Cartoon Tester Vol. I by Andy Glover

The Cartoon Tester – pretty good book of Andy Glover's cartoons about software testing. All cartoons can be found in his blog, but book is cooler: more organized and more pleasant to read.


"I've checked every square foot in this house. I can confidently say there are no mice here."
Making fun of serious things is always healthy and good for the field, so I am glad, that there exists such book about testing. Sad, that there is no paperback version – it would be a great gift for tester.


It's very nice to have this book on my e-reader, so I can always read/see some comics when I don't have much time for reading, but need to somehow entertain myself.


"Look! They've got it all wrong. Mice can get into the house in many ways. Through windows, drains, the cellar, need I go on?"
You can buy book at LeanPub or Amazon, download free sample there or read comics at Andy Glover's blog Cartoon Tester.

FF Add-On FoxReplace

Very nice add-on for FireFox - FoxReplace, which replaces text in web pages.

You can define a substitution list and apply it automatically or at your own discretion, or make individual substitutions. You can use this as a filter, or just for fun :)

My blog without add-on:

With add-on:

I work in international project and we have different applications in different languages. And I need to provide a support in this applications. I use this add-on to translate some basic texts (like menu items) before resources are translated by developers or in applications where I can not change the language. It speeds up my support and ability to find the right component in application with unknown language. You can also possibly use it in demo's: with this add-on your application doesn't need to support different languages, you can add translations just for demonstration.

And the whole beauty of this add-on is flexibility - you can configure different patterns for different domains, disable\enable some patterns and even export\import settings (which makes very easy to share them with colleges).

So, if you have an international application - it's good to know about existence of this add-on. Maybe it can help to speed up some of your tasks.

Secrets of a Buccaneer-Schoolar by James Marcus Bach

The complete title of the book is Secrets of a Buccaneer-Schoolar: How Self-Education and the Pursuit of Passion Can Lead to a Lifetime of Success. The book is not about the testing or even software, but about self-education. However there are a lot of examples from testing area.


Shortly - I really-really liked it. First of all, as we all know, the author dropped high school - me too. So the philosophy about schools and universities is very familiar to me. I want to give this book to all people who make surprised face about that fact in my biography. In my case, I was very successful in middle school (graduated with honors) and people just don't understand why I don't want to get a paper about high education. Answer is actually very simple - because there isn't such profession as tester or even software engineer, there is only IT (which is much wider). So I want to go deeper, not wider. And this book proofs that this is a normal decision (sometimes I wasn't sure about how smart this decision was).


"Perhaps the secret to happiness is finding the games we love to play, instead of learning how to win a games we hate."
The book is full of very bright and simple statements, that I understand intuitively, but was never able to put them in words. So it sorts some thoughts and puts them in right places.


"Intelligence is just a tool. Love is the point."
Great metaphor: you should encourage your mind to wander - like keeping dog on a long leash:

The text itself is very simple, but it's full of weird words - I was looking for definitions in dictionary all the time. And this is actually quite fun, because all these strange words are understandable through context, so the meaning of text is not lost, but English is improved.

In this case I wanted to look up a word in dictionary from explanation itself (unfortunately you can't do that in Kindle)
Sometimes even dictionary didn't know the word. For example, unjammed:

So, I strongly recommend read this book to all testers (actually all people). It makes your mind wider and more open.

One more magic idea that I really liked - "the most wonderful thing I do in my entire life may happen in the next ten seconds."