Life changing steps, but not really

   Working in environment where everything more or less is in good process, documented and planned correctly. It makes hard to think about new topics for blog. The best working environment I have ever been, but it doesn't scratch that parts of brain which generates ideas and sarcasm about work, things to improve, or horrible things I sow working with people. This is not perfect, but not horrible enough to write something about. And writing about writing is not my thing. Enough of weeping about how bad is work in good work, first world problem... 

   Back to testing.

   Remember last post video - which changed Your life? No? Well I still remember it. Talking about it - how it changed my life it is not enough, I should use that thing. Not just should, actually first steps where done. Imagine situation - about 30min whole development team  watched video, and now everyone is sitting in conference room and had to give feedback, pros and cons. And You start to imagine that 'shit just got real', but actually no. Meeting was productive and not as bad as I expected. But still long way to go to have decent results.

   First steps were done, now real things needs to be started. And about that I will post later.

   Kinda short post, and after long time. Winter and another stuff affected my normal schedule, but maybe I will be back to normal soon.

Yours friendly neighborhood Tester

Everything changed then fire nation attacked. Wrong universe... but still everything will change after this post

   Before main post - to the person who didn't add history saving to blogger - Thanks for blogger, but fck You for not adding history saving.

   OK, now back to topic.

   My whole life was a lie. Trying to be dramatic, but really I sow video about QA job which made me rethink all my work I'm doing, all of that is just a waist of time. And again "Drama queen". Of course my work isn't worthless, I just need to work differently. Well not just me, whole team.

   Idea behind my dramatic begging is that I sow process which can change how I and whole team is working. First thing is that team don't need so much tester. Or don't even need tester as position at all. Everything can be done by developers. Developing, reviewing, testing. Whole process. And "what I going to do in that process?" You are asking. Short answer is - watch this video.



   Done? Not yet? Watch it.

   So, life looks little bit different now, huh? Mine too. Next step, reaching goals. Will see how it will unroll. For now that's all. And again, add history saving to blogger!!!

Yours friendly neighborhood Tester

If I would need new colleague

   If I would be QA team manager, and I would need to find some people to my team, what would I do? Yes, of course, I would need to go through CV and have interviews. CV part is not very interesting, but interview - that is totally other thing.

   Testing tester about what he (she, it or any other thing, I'm trying not to be sexist, but it is hard to use abstract word) knows and understands about testing. That is not just simple task with several question about Agile and how to register bug, it can be fun and challenging for interviewer and interviewee (had to Google these names). Over my experience had some of them. Some were interesting others were boring, and after couple minutes I knew I will not work here, but still spend my time for knowledge and experience. Without knowing which interview is bad, You can't know which was good, or how good.

   While thinking about previews interviews, I starting to remember some questions I got there which in my opinion I would use in my interviews. And got some I would not use, "why?" You ask, because they are stupid, sexist or impropriety for interviews. Good example would be "where You see yourself in five years?" well here if you pay me enough.

   But back to good ones. If QA does not have imagination, that person (this time sounds OK, but how often I can use person?) will not be the best for this role. Sometimes any person is better than nothing, but I am not talking about it now. For imagination:
We have medicine scale and eight coins. One of them are fake, lither then other seven. How least number of weighting we need to have to find fake coin?

   And if You thing about three, remember this is not about knowledge of math, imagination.

   Person needs to understand situations. It is not easy to understand that you fucked up, but who understands, it is really useful person.

    When incorrectly used word can postpone release? For example in Microsoft office packet?

Didn't expect that, didn't You? Now think, and yes everybody can guess about brand name, but think little bit deeper, I'm talking about user experience, not grammar Nazis.

   Then You have imagination and You are smart enough to know then time to stop. It is time for shit to get real. Understand testing is the biggest part of testers life. So:
A simple gaming system has been specified as a set of use cases. It has been tested by the supplier and is assessed as low risk and there is pressure to release the software into the market as soon as possible. Which test techniques would be most appropriate for this testing?

   This could make You feel that You seen this somewhere, and it is, I used it from external sources, thanks for that!

   And I would finish my interview with open question:
Which testing approach You prefer? And why?

For example me - I love exploratory testing, because searching for an issue or a bug just to find it is the reason I do this work.

   Expected to finish this couple weeks ago, but life is life, nana na nana.

Your friendly neighborhood Tester.


P.S.
Doesn't feel as decent post, but to lazy to rewrite, so let it be as it is.

These robots - taking over our jobs

   From last post so much happened, didn't even had time or energy to write about something. I don't even know is somebody reading this, but any way I want to keep writing, maybe some good idea will come up one day in this blog, and I will be able to use it.

   So now, after so much time without writing or thinking anything related with testing, I'll try to jump in, for me not very much explored, waters. Automatic testing or test automation or any other name You would like to call it. I will not create any test here, or write about frameworks or tools for testing, just ideas and other crap I can think of automation.

   Main task of test automation is same as in other areas where automation is used. Remove manual work and do work more efficient. And yes, this is achievable even in testing. But not always. And I will try to explain pros and cons of this, and it wouldn't be easy.

   Thinking about automation, people image, that robots will take away their jobs, and they are right, manual work often can be replaced with automated machine which will work day and night, will not have breaks, wouldn't complain, and if something happens - will not inform other about problem. Last part can be even updated to inform personal about issues, but again exhausting testing is impossible (what again, you never mentioned that before. Well I'm not, but I'm using this in real life almost weekly). And even human errors can be made, because still robots don't create robots with already programed stuff without human interception, and even more automated tests (as much as I know right know) are written by humans only.

   There are bunch of tools for test automation, companies are creating specific things for other companies for automation, companies by them self are creating things related to automation testing, and even random citizens creating things to automate testing for websites/software they created. But how often automation is needed in testing? Very often, but not always. There are ideologies that every test needs to be automated. But this is not true. Don't agree? Well, maybe You are write, but I think differently.

   There are bunch of cases where automation will take to long, or will not be so efficient or accurate as human. Automatic test can't decide that gray text on white background is hard to read - text is there, no errors in text, so it is correct, but user cannot see a shitty message You are showing to him. So automatic test passed, but manual test not. Other example can be testing website and searching elements by ID's - automatic test can find element with correct ID, it can make actions and report result, but user cannot find this element, because it is overlapped with table or something else. I can think of bunch similar test that will give on some level correct results while they are incorrect in human perception.

   But believe me - automatic tests are like a water to thirsty tester in a week of regressions with thousands of test cases, after months of repetitive work. Regressions period can be so boring and repetitive that at least part of test automated, even with bugs and required overview is better, then no automation.

   I think that You shouldn't trust person who says that automation is everything, and same way - who says manual testing is life. There should be equilibrium, balance in life. Eating only cake is not healthy, but not eating cake - huge part of joy of eating can be missed.

Your friendly neighborhood Tester

Life cycle of the bug

no eggs for this time

   Bug is like a butterfly (this sentence sounds silly, butterflies are bugs, but still software testing here, not biology). I can think of three simple stages for a bug lifetime - larva, cocoon and spreading wings butterfly. And it is hard to imagine smashing butterfly with shoe as soon as You see it, but cockroach doesn't fit for this example in my head.

   I will try to focus in three different bugs and three different stages for each of them. While everything is still in my head everything seems good, but we will see how it will unroll.

   First one seems simple - error in code. Something like misspelled element name, incorrect variable used, too much variables sent to function, exception handling missed or something similar, I hope You got right idea. Some of them can be caught early and simple, and I'm focusing on them (no hard thinking for today).

   First stage - larva. If Your editor didn't catch error, it will be caught in compilation stage or if code is compiling correctly - still it can appear easily somewhere. But it could not end here, it could slip though all checking, be wrapped in some kind code cocoon, and survive till next stage.

   Sitting quietly until next stage is coming - sounds really like cocoon. And in next stage, then code is delivered somewhere, doesn't matter where, tester, customer, machine, that non-malicious cocoon - will be seen. Cocoon will become butterfly. That butterfly will flying around place. Would not let focus on work, until it will be removed from the room.

   Now we are walking to gray area. Bug is not a bug, if tested didn't say so. "In this case code is written correctly, but in "decision table" testing one case was left not checked." Now I have example of bug and from here I start to build my example about stages.

   As a larva, this bug, started in head of tester - as missed case, as not expected scenario, ate it's way to some place where it can easily stay as a cocoon. Test cases where prepared, all functionality seems working as expected, seems, everything is ready for release. But there, somewhere is cocoon, which will sooner or later will become butterfly. And we are releasing. Seems everything is great. Cases didn't failed, functionality working, customer is happy. Until. That cocoon - missing test case from "decision table", edge case, which was not thought through - becomes butterfly. With big wings, that makes hard to focus on full picture, which is working correctly, only to the bug, which is messing all the picture.

   From gray area - to even grayer one. What if in the begging of something, bug already was there. It is not code issue, not a missing test case, what if larva starts eating its way in description of project/feature/enchantment. Starts on first document, or even at the idea. Finds a nice and cozy place and sits there as cocoon through development, testing, till the end.

   Having that product in hands - you can't find bug, no missing edge cases, but it just feels not right. Cocoon become butterfly only when final product is ready. No issue in code, no issues in testing, bug was there all the time, bug in project/feature/enchantment design. No bug, but still not usable.

   Enough horror stories for today.  But more will come, more stories, more bugs, more problems, and I or we will try to discuss them.

Your friendly neighborhood Tester

Human vs. Machine (man would sounded better, but sexism...)

   Last week I caught virus. I spend 4 days in bed. It made me thinking - human body and mind is such a vulnerable things. It can catch a virus, bones can be broken, can be tricked by magician, can be used by social engineer, and more things which can affect body or mind negatively or positively. I don't even need to go to addictions section.

   How much we are different from shitty software? If your source code is bad, it affects your vulnerability to outside attacks and internal crashes and bugs. Or makes You some kind special, for example like me, having rare blood antigen. Maybe core stuff at the moment can't be changed from what You got, but a lot of stuff can be hacked, overwrite and used.

   Crazy thing is social engineering. If You don't know what it is check "Social Engineering: The Art of Human Hacking" book. Using Your best personal character sides, like friendliness, urge to help, unreasonable truthful, it will use You, will take all needed info, and left You proud of Yourself of being a good person and hacked shit out of You. That's the reason why I use quote "Everybody lies" in my life.

   One day I would like to use my testing skills in social engineering, but I think I am to good person, and lying while looking directly into persons eyes would be extremely difficult task for me. And I lack of other skills required for this job. But maybe one day. Someday.

   With the people is hard, understanding systems is quite easy task. If shitty database is used - why not to look for a problem there? If software is developed by easily distracted person - issue will definitely will be somewhere there. If project lack of documentation, well You can guess, if tester would not find bug, customer will. If You think that hardware seems little bit odd, why not to try performance tests, it would be fun to melt core or two.

   Why not to use software testing knowledge on people? Well no, I wouldn't do that, at least not know. Maybe later, who knows? Not You, I guess.

Your friendly neighborhood Tester.

Forgot to add title...

   Started writhing three different blog posts, but can't finish them. So why the hell not to write fourth about how I can't deliver... Well this happens from time to time, and this time I planing to finish about how not to finish.

   Delivering something sometimes is a pain in the ass, and You can do nothing about it. Some time ago I had to write automation tests for website, where they were using so much on-live generated popups and other elements, that with my skills, for that time, I just couldn't write normally looking tests with expected behavior. I was struggling for couple days, at some point I was even thinking about just quitting that task.

   And in the end - I did that. Wrote horrible, unusable tests, which didn't reach expectations. Give them and never looked back.

   Now in my work I come to this very rarely, most of projects are delivered, sometimes on time, sometimes to late, but final product is prepared. In my blog writing experience – I often write same post over and over again, until I found equilibrium, and often I write myself to the corner, and then I just left several paragraph to sink in to the depths of drafts.

   Before I had and some different experiences – like I mentioned several posts ago about Why release should be postponed. And that is not bad experience. Sooner I know I'll fail, sooner I can start to take an action. After several not finished posts, I can just leave that idea, and took other one, or sooner I see that my project is going to fail, I can inform everybody that some actions need to be taken, or if I see I'm failing in my work, sooner I can leave and find new one with still good looking CV.

   I guess everybody hates failing, not finishing or loosing. Even seems the best ones fails, like my country swimmer in Olympics, everyone were expecting medal from her, but she finished second from the end. Well, last example doesn't go with my main idea, not finishing race and running away from upcoming fail can't be compared. I wanted to finish with great, uplifting example about finishing, but failed to do that. Ideas in the head didn't aligned correctly.

   Didn't want to post this crap, but skipping this one would lead for not delivering by my schedule,  so heck, who cares, maybe next time I wouldn't fail again....

Yours friendly neighborhood Tester

I don't know, but I'll do it

   Working with systems with a lot of stuff, sometimes puts You in a corner, where You don't know what to do, or how it works or why You even working with it. But any way, while You are in the corner and You need to deal with stuff, there are one way - do it. Or be fired, I don't know.

   But to do stuff, not always the best way to do it. If You don't know a thing and start doing stuff, well it can get very nasty. Situation is very simple - I took bug from not tested bugs list, don't know how to test it, and not much info in bug description. For me everything seemed simple - 15 min of testing and bug is verified. Seem YAY, all done. I have good name in team, so everybody believes me, and bug goes to production. And then nasty things starts to happen - corner cases, which happens often, not tested, they are not fixed, and whole thing starts to going down the hill like avalanche. And that is just one bug. Imagine if system architect designs new feature without knowing that he(or she, or it, if this done by some AI, it is hard to guess where we will be in near future) doing.

   It is hard to imagine, I know, but in this case everything from beginning to the end can be just falling from the cliff - You can struggle in the air, but then it reaches customer - it just hits so hard that explodes into rocks, splashing parts and good name all around place.

   Enough of negativity - doing stuff which You don't know, makes You think, understand new things, find corner cases which were not checked before. And of course how I will not use example... So I never worked before with (now imagination kicks in), hmm, I don't, hmm, I can't find good example, so I will use - fiscal printer (if don't know what it is, check it, what a piece of sh... technology). Had to spend some time reading about fiscal laws, taxes and even more horrible stuff. So now I know that printer through and through. In implementation was some ups and downs, but now it works. And I know things.


   Without downs, there are not ups, so not knowing, does not means that You wouldn't do it right, or left (I hate then right is right, but now about turn, and lead is leading, but not metal), just some time need to be spent.


   Your friendly neighborhood Tester

Living through time

 

   Thing which never change is changes. All the time, everywhere, everything is changing. About hundred year ago just first planes started to take off and now days basic travel can't be imagined without flying (technically You can imagine or travel different ways, but it is not the point). In my childhood computer, even a console, was rare thing, but now consoles, tablets and other stuff is daily basis, and it is hard to imagine a day without it (and again, You can, but still not the point). And Yesterday I had phone with old Android version and now I have with new, and I had to adopt to changes. Extra amazing features!

    Adopting to changes is like drinking water, you can live without it, but how long until sugar will brake You?
 

   Maybe my personality is helping me or maybe I just don't care much, because seems like I quite easily adopt to changes. Going from slow boring and repetitive work to fast and challenging, was the best thing. From Windows to Apple (still work related stuff), from Jira to Bugzilla. Every change is fight for survival. Live or die. Or better – finish project on time or postpone release, get the newest  updates or live with crappy old version.
 

    Then I had job interview for current job, I got a question – "It wouldn't be a problem to you to work with Apple products?" and in that moment this question was strange for me, and my answer was similar to this – "of course not a problem, I could work with anything, just give me some time to learn". At that time I didn't know how people sometimes stuck in one place.
 

    At conferences, other blogs and books (at least which was recommended to me) often topic about "changes" comes up. And seeing all the things around me, I sow that. That strange thing. Even in my self. How changes are not accepted, struggling in same environment, with same issue without doing something. And I see myself, with broken screen, several years old phone. Which is lagging and crashing, often restarting without any reason. And problem is not money, it is avoiding changes.

And while I am writing it, looking around and I see all the stuff which should be changed. Adopting changes is hard, even harder then it affects Your life, like - start to make coffee from different beans, or buying new clothes because old ones was taken away (hope You are getting idea... that this is not about what it is). 

   And now Your are thinking I will gave life changing suggestion what to do. Well... No. I don't know what to do, somebody sometimes say they know and they do stuff, and I will leave it to them. I love to have eggs and bacon every morning, have same phone and same job and no changes in my daily problems. But I also love to get new projects, challenges to defeat, dragons to kill or pokemons to catch. Not much about testing, not much about life (this is not that I thought in the beginning and not such end i wanted). Well... hope next time more about testing.

Your friendly neighborhood Tester

Working Your ass off?

 

(Meaningless graph representing nothing)

If I don't work – how to know if I am not doing my job? Got similar question couple days ago, and we started small discussion about tester and how to check their progress.
Imagine situation – there are 100 bugs and release is in a week. Till release date – 25% of bugs was reopened and 30% had to be tested in release period. Developers starts to fixing reopened bugs, merging them in release branch. Release is going on, everybody working their asses off. And finally regressions are done and release is sill not fully tested. More bugs are merged there. There was so much things to do in a week, that correctly test expected bugs amount was to difficult task.
So did I done my work or not?
Two weeks before release – there was 80 bugs fixed, but not tested. In next week 20 more appeared, was fixed, but not tested. And then I jump to work. In this situation I have one question – what I did last three weeks?
It doesn't matter what, but definitely not my job.
If in this case my manager would have looked to amount of new code lines in release, I think I would be fired. To check progress is not hard, but this need to be done, and even if I don't have manager, I should check my progress just to know if I could sleep next couple days, or I will be working as horse to catch up.
To make your whole team sweat – just do Your job late. It definitely will make every one enjoy extra stress.
This case is just theoretical idea we discussed, and most of thoughts was not even mine. But using both approaches can be useful – for example if You hate Your job and coworkers, well just do what You wouldn't do if You appreciate Your job. Or just extra stress before Christmas is useful for every one.

Your friendly neighborhood Tester.

I need to become architect (still issues with environment planning)

I still have issues with architects or environment planners – issue is very simple and common "path around buildings and in whole neighborhood". Then they were planning infrastructure did they walked in paths they draw? I think they didn't, because design and user experience is totally different.
After long and hard bug hunting day and evening in gym, I want to go home as fast as I could, so I am walking in the shortest distance, that means that I need go over paths that are not tiled (don't know correct term and to lazy to search more). My shoes gets dirty or dusty, depends on weather, and if I am correct, I am passing private property. But I am not only one like this, big part of neighborhood is using same path.
Same things can be seen in my work too. Sometimes feels like designs are engineered, not created for ordinary users to be used. So users if they must use software – they starts to find work around(s) or use products in unexpected ways. Good example from my experience – people better change error message text then registers bugs and waits for fix. Sounds strange, but I sow is at least several times, how 'must use' software becomes people imagination drawing board to make life easier. Like a path I walking daily. I wasn't first who walked there, but I am one of users.

I put away this post for a day, tried to give some time to sink in, maybe I could think for solution to this stuff, but I can't. Can I register bug for neighborhood flows? I don't thinks so. I can walk on paths which are designed for it, but doing so will cause me wasting my time of relaxing...
So I will keep struggling on same issues and will do nothing about it, like most of us. And I will try to get most of it – come back home faster, even if my shoes are dirty...

Yours friendly neighborhood Tester.

View of the bug - project manager

These are waters where I have not much knowledge. Worked just with several project managers and I have just abstract understanding about they perspective to the bug. Just only of they face expression changes then they hear about issue. And I have seen some not happy faces than in the end of project there is some major issue, or even better, when issue appears after some time then project is in production and no money left to fix it.
(I feel joy seeing other people struggling.)
That project managers don't like bug late in the project is understandable, because later bug appears it cost more to fix. And than You are managing money, people and time to deliver project - everything that affects project, burns money, nobody is happy with it.

It is kinda boring to write about managers. What I am planning to write - I end up in money issue. Then there are money - no problems, no money - problems. Just basic. 

Yours friendly neighborhood Tester

Why release should be postponed

Now I am living in monthly release schedule. Every month we have regressions and all other processes for release. Not very often but sometimes happens that release needs to be postponed. Last time I had this situation was about six months ago. It was because of project I worked with. I am not proud of it, but happened what had has to happen.

Situation was very simple - developer underestimated development time and amount of bug registered for this feature. And everything ended even worse then just postponing release. Whole feature had to be removed from release, all affected areas had to be retested.
Having monthly releases and one of them postponing for two weeks affects whole company schedules, other releases, time to market, and I don't even know what more, but 100% sure it was affected.
Other interesting thing about that feature was that it was required by customers, I don't know details, but a lot of people were pissed because of this situation.

OK, enough of my experience.

Postponing release is not one man job (of course if company is not from one person) and it affects a lot of people even from outside the company(in my example). And then I start to think about all work - the line of issue criticality starts to blur out. How critical issue needs to be to stop whole process and push or stop everything for a period of time.
Image situation - Microsoft releasing new office packet, and for some reason there aren't "Save" button, just only two "Open" buttons and one of then works as save other as open. Do this bug is reason to postpone the release? Or other example - new FPS game has one level where just half of enemies are generated, this would be reason to postpone game release date? I wouldn't talk about military or medicine, there are different rules.
So both times I would suggest to release product and after release hot fix, but who I am to make such decisions. But these was small things, but if for example, product from office package crashes if document is with picture, or game has level without exit, these would be reasonable to postpone release. It could make huge impact on trust from users of these products. But line sometimes is so blurred out that it is hard to decide what to do.
In such situations clear head is needed, because of pressure from project manager or other management can make things even worse and bad decisions can be made. Always watch Your ass and what must need to be done - released on time, no matter what.

Yours friendly neighborhood Tester

Today I need to find a bug

Today is Wednesday, nothing very specific about this day, day like any other. But there will be one different - I will try to specify that I am doing to find bug. This week regressions are ongoing, I will step away from that for a little bit to find unrelated bug for the system.
While still on the way to work I need to think about place which is critical or highly important to whole system. "Product" is one of the main things for system. A lot of changes can be done to it, it is used for sales, reports, inventory management. Whole product depends on "product" to work properly (strange sentence, but self explaining). So I will focus on that.
One new setting was implemented for "product", to make it non-returnable if disabled. New stuff maybe more vulnerable so this maybe one of area's to focus. Now I am trying to use my knowledge and error guessing technique. This is my most used techniques then I am testing stuff.

I worked with this feature from front-end part, so I will try to find issue on part I wasn't involved in testing, back-end.

Founded issue faster then I expected. Bug was in "product" import. For easier management "product" has import, to deal with huge amount of them. For importing xls file is used, most of fields have possibility to use three states - with data, empty field and no column. With having all this knowledge I just need to check it. 

So if field is imported as empty(null value) - importer is unable to handle this case and incorrect error message is shown. Bug is registered, required info, file and log is added.

It was to damn easy. I fulfilled my task, but it wasn't challenging. Need to find other bug. Same target - "product". I should use other approach, not error guessing. 

Well everything went not as expected. Now is week later from previous paragraph - where I wanted to find another bug. That day I started with my ordinary tasks and founded myself week later without bug I wanted to find. So nothing to share about that and I want to touch other topic. So closing this post with defect, which will be founded later.

Your friendly neighborhood Tester

View of the bug - Support

First person who receives all the hate from customer about system issues is customer support employee. First line of defense who handles all the issues and complaints about software and all systems overall. I don't even need to guess, I know how they hate bugs from customers.
Not so long ago our company started hire support in my country and office. Quite fast office became full of people. Just couple of month passed and I started to see faces of disappointment and eyes full of sadness. Yeap, I am trying to sound more dramatic, but this is really close to reality. Hours of taking with crazy customers, dealing with they lack of knowledge and ignorance. And they also had to handle bugs. All this work makes this job tough.
Not so long ago I was witnessed of horrible accident. I am not sure about roots of issue, but I will try to explain as it was explained to me. Front-end application had its end of expiration date. And just couple of company heads knew about it. And one evening app stopped working for hundreds of clients. What I heard about situation, that there was about 45 customers for every support employee waiting in line to be connected. Hundreds of angry customers were that day (or night, depending on region, for me was night). And workaround was not that easy – time had to be turn back for 24 hours, clients database saved, app deleted, new app installed and database uploaded to new app. And it took some time ti figure this out, and to do this procedure for every calling customer.

Then I came to the work next morning – I felt like I was responsible for this issue, eyes full of anger and faces totally exhausted looking at me, and asking crazy question in which I didn't had answers. Later, after several chats I started to understand horrors of that night.

So back to view – it is easy to guess that they do not like bugs. They had to deal with same bug over and over again. All design issues and things that was not thought through making they work even harder and time consuming. But they had to deal with that, it is they work and if everything would work perfectly, they would not be needed. Sometimes I feel responsible for some issues I left not tested, but it is not about me. (Part 2 of N/A)

Your friendly neighborhood Tester.

View of the bug - customer

Back to "view of the bug" topic. I will try to fix previews post. This time I will try to look from different perspectives of more people who are affected by bugs of system. I will focus on my experience, so in couple month or years everything can change and this info will be not relevant or I will have more knowledge. But today I hope it is.
Starting from the bottom. Customer.
Now I will try to split customers in two groups. I will call them beta tester and working customers.
First group are actual customers who decided to work with product which is still in development stage. Sometimes this decision is for training or acceptance purposes, in other cases this is way to get product cheaper or get knowledge from that area where product is focused.
When customer knows that product is still in development for him to find a bug is not huge problem. Just to get fast response and hot fix is main requirement. This beta tester customer provides good info and feed back and gets updates and fixes faster. So this case finding bug is not such big deal for customer or company.
Funny part is working customers – they are people who wants to get the best and well working product. This time then bug appears – things can get crazy. Situation – customer decides to get rid off the old product and get new "my" product. "My" product have more features and other stuff which is not supported by previous product. Everything seems working fine, but after some time customer finds issue which for any reasons blocks customer from work or at least requires additional work to maintain working with this bug. From customer issue comes to support, later it is approved, fixed and tested, new release comes and only, only after some time fix will be introduced to customer.
Imagine how person or company should feel if they had to work with issue for month, maybe two or even a year. And how much customer is furious if he finds out that fix will come after two months or longer.
For this type of customers new bug can be unpleasant experience (softly saying).
This post doesn't seem very wrong for me. Two types of customer, it can be more, like something in between, customer which is same company, or something from specific area there bugs just can't occur. I didn't go to much left or right, tried to scratch surface, I hope I did what I wanted. Part 1 of unknown. 

Your friendly neighborhood Tester

Sitting together is good, sitting together is bad

Days like today I came up to the bugs which I can't reproduce and my colleague can't work because of this issue. We have one difference - I am sitting in same room with developer and he is sitting in other side of world. Does this situation makes me better or worse tester?
According ISTQB book independent tester or testing team provides better results (I think there was even a diagram of independence), because they aren't affected by developer or other same environment factors. I'm trying to think it through, and I see few pluses and minuses in this situation, regardless if I am independent or same environment player.
Pluses of sitting near developer would be that You get knowledge from first hands, and You can setup environments more "correctly" and easily, came to issue with more knowing about its roots than just from bug description. But pluses really soon becomes minuses. If You have developers knowledge about issue so in a way You see issue like developer who was fixing it. And like everybody he(or she, it doesn't matter, just for this situation leave it as he, next time maybe it will be she, I work with males and females developers) is protecting his work and can't truly see an issues clearly. And this confidence and don't believing affects me and I start to get careless. Loose my focus and can't work as that person who is miles away and is the closest to client point of view. Other minus I can think is eating lunch, joking or just chatting with same people, with whom You will need to work later and check their work, can make You irrational to decisions about founded issue.
To sit far away from developer, literally or theoretically, gives advantages of independent thinking. You aren't affected by developers sweet words, minds or his knowledge. You do what You must – testing. Project description mostly is available, bugs have reproduce steps. Seems everything can be fine and doing Your work goes to best result. But here comes disadvantages – lack of first hand knowledge, understanding, which sometimes goes to 1+1=3 is true and without knowing that You are working with things You don't know. This can lead to reopening same bug again and again until someone will provide information, or mentality differences will not make You see an issue, or maybe without small chat with developer You wouldn't be able to think test case which leads to issue. Or even more – sometimes testing projects that doesn't have much info, so without developer help – several bugs are founded and fixes, system kinda works, but without internal company or team knowledge,  final product isn't what is needed to be or it is, but lack of knowledge not all major issues was founded.

Now You are thinking – "this is what he is writing can be fixed with couple documents and calls". OK, yes it can, but knowing people helps, talking and knowing more than it is written helps too. But overall everything depends on Your (I am talking about myself mostly, so "my") attitude and view to work. Any body can be independent(now coming to theoretical part) or You are sitting in same room or miles away. But more knowledge You have about shit and fruits You are fertilizing, better they will grow.
Yes, independent tester or team is great, but situation not always allows that, independent must be mentality and view. So sitting close or sitting far can be just mental state, and by sitting in same room You can provide similar or greater results. 

Your friendly neighborhood Tester. 

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

View of the bug(test version 1.0)

Finding a bug is success not for everybody around me. Coworkers from different departments have different view to the bug of the system.

When I found issue, bug or defect - it's a good day for me. And more I found, better I feel that day.

And there are guys from fulfillment - for them bugs are problem why they can't send hardware for client, or something not that critical but still an issue. Other times just problem we discuss about, sometimes we find solution, or I just register their problems as defects or enhancements. But overall it is not such a big deal and can be managed easily.

But horror begins then issue is found by support, or to be more exact - by customer. Then ten same issues are registered, clients are angry, support are angry and exhausted. And I understand them, to deal with issues were everything is on your back and often fix doesn't come in week or two or even month. Like an issue exist at the moment for certain clients - in iPad footer appears red line with warning and it can be closed or turned off and under it hides buttons and it is really annoying while working with it. If app is killed it helps for several hours but after that red line appears again. And complains for this bug are coming and coming.

And with stuff like this and sometimes even worst, guys need to deal every day, and they aren't happy as I am then bug is founded.

After I read what crap I have written, I understood that this post need to be rewritten, because i just scratched surface of just couple of types of coworkers and how I see - how they see bugs. But I will not rewrite this post, i will expand it in couple posts with more details. Or even create series about "How other people see bugs", of course from my perspective. 

Your friendly neighborhood Tester

Everything need to be registered

Doing my everyday work I often came to the days when I can't find any bug or defect. Sometimes it is frustrating to do job without any success. But other days, mostly then starting new project, with joy I am registering new issues. And often i doesn't matter if it is actual bug or my misunderstood of what I am dealing with. But from my point of view is better to register everything and sleep peacefully at nights.

Yea- sometimes this bugs registration brings some confusion for developer or product manager, but it is easier to close it, then pay for man-hours for managing it. But in this method I see some pluses - first of all - a lot of bugs registered on your name. Deeper understanding of product - even closed bugs will have info why it is not actual bug or at least how to prevent it. To save your self from angry management, support or any body else how maybe affected of missed thing which was known about.
I'm trying to do job as good as I can. Register all the issues, defects and other stuff which looks important to me. But I am just a ordinary person - who makes mistakes, and a lot of them. 

I miss bugs very often, and sometimes very obvious ones. Very good example is from company I worked before. Situation seems very simple - on opening new account, fee is payed from money which are adding to account. Situation goes out of hand then accounts is opened in foreign currency. Because fee is in local currency, amount of fee need to be calculated with exchange rates from database. To check if amount is greater then fee, data is send to database, calculations done there and final amount and calculated fee is returned. From final amount fee is subtract and account with double fee taken is opened. I hope it was easily to fallow and understand how much shitload came to me - then every teller needed to write explanations for every account they open in foreign currency.

Every case should be registered, but not today. Today was boring day, and nothing new or interested happened. I hoping everybody has days like it. After they pass days with a lot of bugs will come, and day will be not boring.

Yours friendly neighborhood Tester.

Beginning

Who am I?
I'm tester, quality assurance engineer, QA analyst or anything I need to be at the moment - who I need to be at the moment.
To my self I'm person who is still a child playing and breaking all the toys all the time - and "I loving it". Just my toys are expensive and not always possible to touch. Sometimes it is printer, sometimes part of software, or just a string in description. Anything can be tested, and most of the times need to be tested. And I am doing it all the time.
I think I became tester long ago I came to testing area. While I was still kid and I don't remember I went to school jet or not, but I remember very clearly how I busted my toys and often checking that is in side and how they work. Even now I remember how I destroyed quite expensive toy train just to look how electronic motor is spinning its wheels, it was nice toy and still regretting I did that, but it is a part of me. I broken a lot of things in my life, but that helped me to understand how they work and sometimes how to fix them. But I am here writing not about fixing but about braking, destroying or simply testing. Fixing is a part of my job too, and maybe later i will write or include in posts about it.
I begin this journey couple years ago. Most of the stories still in my head, other almost fade away. But other are just coming to me. And i hope to share them all.

Yours friendly neighborhood Tester.