Nothing relaited with testing

Was writing post on my way to EuroStar Software testing conference, didn't finished it on my way there, and now I am going home, and full of ideas and new knowledge. So skipping that post, to write this one, and that one will be not forgotten, will finish it later.
Some topics was just add extra info to already existing knowledge or refreshed memories. Other ones was unexpected good ones. Conference was in Poland, so some topics was in Polish, so stayed in one presentation because it was in English, and left it quite amazed(hope to write something about it later). "Never judge book by its cover" it is suitable to this situation. Overall conference was great. Would love to come back.
I understood one thing, there were more things that I got better view of, but this one is clear and hope it going to stuck in my head for some time. People who gives speeches in these conferences are same people like everybody, they have their struggles, stories, good and bad examples from experience, and experience. After having a chat with them I got little bit inspired to present some topic about testing myself, sometime in the future, when my experience will be relevant.
Other good thing was to stay little bit after presentations ended and chat with people. Almost all attenders left in 20-30 minutes after event. But not me, I stayed little bit longer. I had very good opportunity to listen and talk with four presenters in neutral environment with a drink in hand. Got interesting options on testing and overall things that is happening around in this area.
So, how correctly end this post without sounding dumb – didn't expected that conference will be that good, it not perfect, but if I will have possibility to go to other conferences I will try to do that. And I should apply at least several thing I learned there. Hope that didn't sounded dumb, at least not in my head today.

Your friendly neighborhood Tester

Just don't believe me

Training helps to achieve better results in sports. It helps to get better in math, write better stories. It's like - more You do, better You become in it. So testing shouldn't be exception. Testing muscle should be trained. And this muscle is not a single continuous mass, but it is made from bigger and smaller parts. Which should be trained in different ways. And training must go all the time.

Sometimes when testing huge things, small bugs starting fade out in in whole picture and they are missed. Like double 'in' in previews sentence. Other times if to much focus is putted in details, huge things are missed. Grammar is checked in text, but incorrect font is missed. Or there are better examples, but idea is the same.

This perspective thing always affects work, and often is helpful to step back from that You are doing, and after brake come back to it and new things will come up. At least for me it helps. If I work on something for a longer time I start to ignore some issues, which are not directly related to my project. But if I take a brake, for example weekend, then I start to work again with same things, I see everything more clearly and register more not related issues, which should be fixed not in my project scope.

Same thing happens with regressions. Huge scope, a lot of things to test. Starting to work carelessly. Miss some things. And it went to client, and later, this should be fixed and tested anyway. But often my conscience doesn't let to leave not registered issues. It is better to register and close it later, than see how people are struggling with this bug in productions.

Started with training, now writing about brakes. Not that I was thinking in the begging. Back to training - I like watch and comment on movies, my fiance hates it, so I doing it in my head. I started to like reading, and writing. Trying my skills there. Like to check grammar, which is hardest thing for me. Reading test related books and found flaws there. Listen to people and how much crap sometimes they are talking. Playing Sudoku. Seems like not important things, but they help in testing.
See patterns, questioning everything, and don't believe anybody are the keys, which keeps mind straight. Like a nice quote from the MD. House poster which is hanging on my wall - 'It's basic truth of the human condition that everybody lies. The only variable is about what.' And it helps. Never believe in developer who is saying that the issue is fixed. Test it. Otherwise it is not fixed, if not tested.
So about everything and nothing at the same time. Hope ideas was not to much messed, if it was just don't believe me! Find it out Yourself.

Your friendly neighborhood Tester.

Sanity is needed everywhere

I was reading about different test approaches and come up to keyword 'Sanity testing', it is similar thing as 'Smoke testing' but it sounds little bit fancier. And talking about fancy things in testing should be my daily basis. 

If we go deeper sanity and smoke testing - it splits in different approach. First is about to test if system, website, server, app, nuclear plant, jet engine or any other thing is turning on, or doing or has other things it should do to start working with it. For example if we are testing pencil - sanity testing would be if it has graphite hart and wood body. If not – sanity test fails. Everything else like – is it sharp, writing, has or not eraser would be smoke tests. View can be different, but overall it comes fairly close to this.

Why I started with 'Sanity testing' - this type of testing comes really close to real word situations. All test types are close to real world situations, but this one has even a good name. 

For example interview for new job - in the beginning there are one or two meetings before You can talk to real people You will work with. Often first one is phone call - to check if that person is real, and second is with human resources person, to check if You are sane enough to talk with people which can actually test you. And this raise a question for me, how much people who works human resources was attacked or even worst happened in jobs interviews? Going to check that later.

Sanity testing I try to use every day before going to real work. Very good example is to check is server is running and last update was successful. If any of this doesn't passes my overview - I get up and go to make extra cup of coffee and read some news until everything is back to normal. I'm check is situation is sane enough for work. Often it is, but if it is not then work can't be started. This applies in almost all situation, if You walk in burger restaurant and see that chef is coughing better to leave now (food testing is a real thing, and if you testing it, better test good one, not with saliva in it), if You try to start jet engine and spark isn't working - so performance tests can't be applied to it. Sanity testing can be used in a lot real life situations, and I hope it is.

This testing helps with new projects or features - sometimes if enough just to look at basic stuff and see that everybody is insane and it is better to leave now, and not to sink with the ship. Otherwise just register bug that stuff isn't working (error is raised, crash appears or etc.) and get back to reading articles or view cat videos.

Your friendly neighborhood Tester

Cutting corner over parking lot

Sitting in the bus, it's traffic jam. And now I'm looking throw the window in shop parking lot. Parking lot is between two roads, to reach one road from another you need to drive at least two kilometers in various ways and roads. So drivers is using it as short cut. Parking lot is with barrier you need to pay for leaving car longer than 1hour. So if you drive thru it in a minute or less, barrier will opens and you just saved 10-15 min of your life and used system design flaw.
This situation got me thinking - does planner thought about possibilities how to break the system, this case cutting corner over parking lot. I can bet for 100 euros that tester wasn't involved in planning. Actually in my previous job and current one testers aren't involved in planning of projects. So often we(I mean I or my tester colleagues) need to deal with projects that already have design issue, flawless logic or other crap, with which we need to deal, and it can't be changed easily or at all.
Books about testing writes - as soon as tester is involved in developing project, issues are found and can be fixed sooner and cheaper. This sounds great - issues are founded faster, cost less to fix, project developed with better quality, because tester is closest thing to client and could see a problem which client will or may have.
Actual situation is - testing need to be done by company policy, so it is left until project is fully developed or to have little bit more time for fixing - tester is involved while project is still in developing process. If company or team policy doesn't involve testing as a must thing to do, it is skipped and consequences hits hard.
I would like to be involved in project development as soon as I could be useful, but I am not that lucky. At least I am not working with other team which are fixing issue directly in production. That would be thought thing to deal with, maybe in the future about this.
And I'm still thinking - does architects use testers in planing and building thinks, or this is just new area where I could find place to test my skills.

Your friendly neighborhood Tester