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.