Agile Saturday XI

Summary of Agile Saturday XI conference.

Keynote The Soul of a Developer by Jaan Pullerits (MYJAR)

All pictures are taken from Agile Saturday XI Facebook album
I liked it. I can't say that it was very useful (does keynote should be useful?), but it was well told presentation with ideal structure.
Phrase of the talk – you should analyze yourself before others do.

Hope management in web applications from pentester's point of view by Elar Lang (Clarified Security)

Nive and useful talk. Some notes from it:

• It was interesting to hear statistics about popular passwords in Estonia (not in the world or in USA). For example, a lot of passwords are some kind of modification of username. The most popular pattern in Estonia is first capital letter and number at the end (for example, User1).
• In Estonia if authentication is done only with username and password it's the first vulnerability.
• If you trust your password to the server you actually blindly trust it to the sysadmin (unknown man).
• If sysadmin creates rules for passwords, it makes users to create weak passwords (with patterns).
• If you build the team of juniors you can't expect quality (such as security).

And Elar Lang explained with one gif how people test their own code (as a tester who writes a code from time to time I confirm that it is true independently of you testing skills):

MVP-s At TransferWise - How To Build As Much As Needed And As Little As Possible by Peep Pullerits (TransferWise)
I didn't like it at all. The description of the talk was absolutely wrong. Basically speaker just made some simple prototype with Angular in front of the whole auditory. And it was meant to show how easy and quickly we can create prototypes. First of all – yea, actually you shouldn't always even code prototype, you can just draw it. Secondly, if you code something the most difficult part is to think up the logic of the application – he already did it at home. The second time-taking part is to create design (css styles) – he already had it as well. Thirdly, while he was coding (for n time) he had some bugs and answers how to fix them came from the audience, so you can't say how long does they take when you are alone.
And speaker did no summary or no analysis – just code, which supposed to be the proof.

Teaching Young Hackers by Peeter Marvet

Nice talk (looks like keynote).

• Many teachers now are trying to teach kids to code in some language (python). This is wrong way, because language is just a tool. If teachers want to develop a thinking skill (which programming can help to develop), then they must to teach programming itself (not language) and to teach it with fun (so kids wanted to code to achieve some goal).
• Making your application with copied parts of code from StackOverflow doesn't make you a programmer (or at least makes you very bad/pour programmer).
• Speaker advised some interesting game for "learning to hack": https://hackerexperience.com.

Keynote Agile Is A Bad Strategy Or 5 Things Every Agile Practitioner Should Know About Strategy by Hanno Jarvet (Jarvet Consulting)

Basically I liked it – the speaker was very good with clear message and beautiful language, but it wasn't useful, again – nothing new. But, actually, perfect talk for keynote.

Lunch

One of the disadvantages of the conference was badly organized lunch (we waited in the queue for 40 minutes).

Briefing

One of the big advantages – briefing of the talks at the beginning of the conference. Each (or almost each) speakers briefly present their talks, so you can choose which one you want to visit not only by reading the description but also by seeing how speaker speaks (which is important). They do it at the every Agile Saturday conference – very good tradition.


Previous Agile Saturday conferences were held at the hotels, this one – at the university. So this time I had feeling that it's not conference, but some regular lectures at the university. Weird feeling.

Microsoft TechDay Estonia 2014

I visited Microsoft TechDay Estonia conference for the second time. And last year I liked better, than this year.

Two complaints about organization:
1. There was 5 tracks and usually talks about similar topics are in one track. This year they put 2 security talks to parallel tracks, so I had to choose between them.
2. The language of the talk was not specified in the program. Some talks were in English and some in Estonian. For me it's not a problem, but there were people who doesn't talk in Estonian and they couldn't plan their program because of this.

Opening video speech by Rain Laane (Microsoft Baltics region manager)

All pictures are taken from TechDay Estonia OneDrive album
Standard general speech, but I wanted to mention about it only because of one quote, that I heard there. The idea of the speech was that they showed a bunch of kinds in the meeting room, who are tend to be mobile experts and talked what they like about mobile and cloud. And one girl said, that she likes to draw on computer, because it is easier to erase things there. And that sentence is some kind of bias: on the one hand, how can you like to draw if you like to erase on the first place; on the other hand, the erasing is the essential part of the creating.

Opening speech by Symon Perriman (Senior Technical Evangelist, Microsoft)

Perriman said a lot of suspicious things. For example, he said that Microsoft is very passionate about cloud technology and before they make some product they think first how it would work with cloud. I am not sure that it's advantage – not all products should work with cloud and this one-side approach may kill some good ideas.

Symon Perriman said, that some other guy said, that every single company is now software company, because all have their pages and provide services through internet. I can't agree with this – every single company is also cleaning their offices every day, that doesn't mean that they are cleaning companies. Software is just a tool to achieve some goal and goal is what makes the company, not tools. If hotel have rooms reservation system most likely it just bought or ordered this system from so called "software company" and that doesn't make the hotel "software company" itself.

Also he showed some new functionality of Windows 10 and there was a moment where he called 3 available options of frequency (5 sec, 5 min, 15 min) "a lot of flexibility".

Opening speech by Simon May (Enterprise Device Infrastructuralist, Microsoft)

Simon May was mainly talking about Windows 10. The purpose of it – one platform for all devices (notebooks, smartphones, xbox, tablets...), which is pretty nice. Also Microsoft do software for competitor's devices such as iPads and iPhones (for example, Office for iPad), which is also nice.

The Microsoft Web Platform – Today and Tomorrow by Jon Galloway (Technical Evangelist, Microsoft)

Jon Galloway showed some interesting features in Visual Studio. I don't use Visual Studio, but it was quite interesting for me – looks like ASP.NET programmers are pretty lucky.

Crash Course to the Magic of Universal Apps by Iris Classon (Software Developer, In Love With Code)

I didn't like it. It supposed to be technical talk in developers track, but it was very general and without any interesting
specific new information.

Windows PCs Can Be Hacked! It's Time to Use Bitlocker by Heiki Tähis (Windows Expert - IT Pro MVP)

It was very interesting talk about platform security itself and with specific hacks that you can try at home. Some point from this talk:

• There isn't any reason why user should have administrator's account in Windows.
• If user have administrator's account in Windows there is no way to secure data on this computer.
• If you need to steal data from hard drive, but you don't know Windows username's password you can just physically attach hard drive to your computer, where you have username.
• With Bitlocker it is possible to encrypt only taken space, but in free space are located deleted files.
• In most cases TPM (Trusted Platform Module) is enough to secure your data.

Any Size of Data Visualization with Power BI by Henn Sarv (Technical lector, trainer, consultant)

Very interesting talk. Henn Sarv showed how you can make beautiful and dynamical diagrams and graphs with Office tools (mostly with Excel), how you can visualize a big amount of data, how you can import and analyze data from your Facebook (about your friends, for example) etc.
After this talk I updated my Office (from 2010 version) to try all these features that Henn Sarv showed.

Unknown talk about Office 365 by unknown speaker (replaced talk)

Too general. I had the impression, that speaker is trying to sell me some product, which he is not using by himself. I din't learn anything new about Office – just pretty presentation about nothing.

Security and Microsoft Azure Iaas by Tarmo Tikerpäe (SSP Datacenter at Microsoft)

I liked it. Speaker was talking about backstage things. One thing that I want to mention from this talk – Tarmo Tikerpäe told, that usually Microsoft doesn't have direct access to your data. They get access only if you have some incident and ask them to resolve it.

Sponsors' Boxes

I am on the rightSponsors and their boxes are mostly the same as in previous year (even located at the same corners). I liked Microsoft box the most, where I tried tablets and different devices for them (such as covers with keyboards).


Another Microsoft's box with 3D printing was also interesting.


Almost all sponsors gave some prizes for visiting their boxes and this guy wins 3 prizes, which statistically is pretty amazing.

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.

My First Steps in Using MindMap

At the conferences a lot of speakers talk about using MindMap in testing. So I tried to use it in my work.

Shortly – I didn't like it (or didn't understand). I guess it is useful for describing some system and relations in it system, but I don't understand why testers should do that – usually analysts describe relations. Of course, there are projects with poor analysis where testers should do some extra work to understand the whole system or to explain it to someone else, but it is not testing – it's tester doing analyst's job. So I can't say, that MindMap is a testing tool.

One more purpose of MindMap, that I heard about – is writing notes during exploratory testing session. In that case I don't understand why you should connect these notes with each other? I use simple checklist for that purpose: before (and during) test session write down chapters that I need to check; during the session under these chapters write bugs or functionalities that need to be clarified; after session read the list, report or clarify the problems and strike out the lines. Lists are more readable (in MindMap there is no start and end), lists suits more for screens and papers (MindMap can very easily go beyond the screen or, worst, beyond the paper, checklist can be just continued on second page), in lists it is more convenient to strike the line out, when it's done.

There is one more usage of MindMap, which is not connected to testing – note-taking during the lecture, tutorial or conference. Again, don't understand why you need connections in these notes – usually I write down a thought or an idea, that need to be processed later. So after conference I need to read all notes and do something about them – checklist is more convenient for that purpose.

I agree, that in some cases (mostly for analysts) MindMap is pretty useful tool, but I think that it is overrated in testing world.

Support Of Inner Application, Part 2

In one of the previous posts Support Of Inner Application I wrote about six major features for this kind of support and some principles according to these features.

In this post I would like to continue the list of principles which are also comply with those features.

• If user reports you some case, where problem is in invalid data and you decide to fix data, then you should also check are there more similar cases to fix. Of course, first of all, you should understand why the data is invalid, if the problem is in application then fix this problem and after that fix all the wrong data, that were caused by this problem. The point is, that you shouldn't wait when user reports you cases one by one, but should find similar cases on your own and fix them all in one time (with user permission).
• Different forced users often ask same questions. So it's good to make some sort of FAQ (Frequently Asked Questions) document for them. Especially if you have some tricky functionality with codes or formulas that doesn't need to be memorized. It's good practice when users are complementing and maintaining the FAQ documentation by themselves (because they know better how tricky functionality should be described to be useful for them in years) and you only moderate and validate the content, but usually users don't do it. I don't know why.
• If you know particular user who is testing particular functionality, that you have already been tested – share extensions and tips that you were using. You have already tested it, you have already found some solutions for some problems – don't make other people find same solutions for same problems. You can say here, that may be they find better solution, but my experience says, that people who are capable of finding good solutions find them anyway – whether they have yours or not. So this principle helps people, who are not able to improve processes by themselves.
• Answer on all messages even if it wasn't a question. Sometimes people write some message just to inform about something and if you red it but didn't answered anything (because there was't anything to answer) then they don't know did you get the message or not. You can always just answer "ok".
• If user reports you a problem he must know its fate. If problem cause is in application – report it to developer and tell the user that its reported. If the problem was in invalid data – tell it, don't just silently fix it.
  Bad example[User]: I have the problem X
  [Support]: Thank you for reporting the problem, we'll see what we can do.
  
  Another bad example[User]: I have the problem X
  [Support]: I fixed some data, please check is problem reproducible.
  
  Good example[User]: I have the problem X
  [Support]: It's the bug of application, I reported it to developer, we try to fix it in next cycle.

Support paradoxes
And two more problems in support which I have not been answered yet to myself.

• When I investigate the cause of the problem should I ask every time obvious things such as "were you logged in in two browsers at the same time" and thereby spend some minutes for this in every problem? Or should I assume, that users know that they can't save data in two browsers without corrupting it and when it is the case, spend 30 minutes before clearing the obvious cause? Tester may say here, that we shouldn't assume anything, but very often assuming saves our and other peoples time.
• In support often when things are too good and calm it seems like everything is wrong. In my experience there was a case when live update was so smooth that inner support team thought that error sending system was broken and users can't send their regular errors.
  There is a nice story about similar situation, but with Light Pollution.