Release contraband

    “You were in silence for almost two years, and coming back with this shit?” You may be asking this question, but reality is – I need to start from somewhere again. And bunch of ideas come up and died in that period, but some left, and one of them is this one.

    So back to contraband, and not just any contraband, but to “release contraband”. What the f… this shit is? In shot – this is code or functionality which is released and client (depending on situation - manager, pm, etc.) does not know about it. And I can talk about this because I don’t need to deal with it daily.

    I’m not sure if I’m the first one, who come up with this term. Or it is already used, but 5min google search didn’t show much results, except sold out painting, project in GitHub and some movie from 2012 with Mark Wahlberg (had to double check surname, why to have ‘h’ in it, which is not pronounced?). So conclusion it is – I’m the first one.

    With this moved from my shoulders, back to real things. Small intro to situation – with constant push from client and management, continues failing and no proper plans, sometimes we had to hide problems without anyone except dev team knowing about it. So we started to put some stuff to application which may be beneficial to everyone, but informing about this problem would cost more problems, then just solving in without everyone knowing about it.

    On the first instances of this, I was extremely against it. ““Extremely”, wtf that means?” Was pushing back as any self-critical QA should do. Tried to convince team not to do it, understood possibilities of us failing and showing even more problems then we had at the time. But, (well, I should put it more like) BUT after tireless work, constant regression testing, and not willing to hear from manager, started agree to team tactic to solve some problems. Hell, I was even embracing it.

    So what we did – had a list of problems, sometimes on the board, sometimes in heads of team members. Tried to use same methods as fixing normally registered stuff, with code reviews, testing and regression coverage, but without mentioning anything in tracible tools, like Jira. And merges and code reviews, as much as I know, was covered with existing functionality which is introduced/fixed on same sprint (if you can call it that shit what we were working in, mhm, sprints my ass).

    Now I am really happy that I don’t need to do this kind of stuff again. Not sure if company learned something from that, I think not, I hope it did. But if management didn’t even knew about it, team at least have way how to deal shit storms.

Would I do it again? Yes.

Was it good approach? Yes.

And both questions have big butts (pun intended).

    

    I would do it, if would not see any other reason how to solve situation like I was in. If there is other more sophisticated and mature strategies (and definitely there is – such as proper communication without rising voice in meetings, You two motherfu…s, I still cannot believe You had balls to do it, well at least one was fired), certainly would use those. But having management who is only want to be good to client, without overseeing employees, it is kind a clear who it ends.

    So removing some stuff from my shoulders and from my heart – I’m happy that I was able to participate in such interesting situations which teaches a lot, for example – how properly do contraband in development. This is like trying to smack nail to wall with pliers, heck, not with pliers, maybe more like with shoe which does not even had steel toe, and you had it on Your head. So it teaches something.

Your friendly neighborhood Tester

Before release do regression testing

   Ah, regression, my worst friend, the biggest foe. Rarely there is a product in production without having occasional or regular regressions. Believe me or not, I did several regression testings over my career as tester. If You are thinking - "oh, he had just several, lucky bastard", well, You are wrong, had a lot, can't even remember all shit I have tested, and how many times...

   For those who doesn't know what regressions are (You are lucky) - this is written down test cases with steps and expected result, and most of time there is one test case for every action, event or stuff which is important to applications work, and it's need to be performed before product release. So there are a lot, hundreds, of tests which needs to be run over in specific period of time, before new version of application can be released in production. Definitely You can find different descriptions, but overall everything ends kinda similarly.

   How to deal with regression? If possible outsource it, pay for other companies to do monotonic work for You, and You can focus on more interesting stuff, like.. I don't know, video games or something. Other possibility - automation. If You can, automate everything. Add every new bug and story to automated cases and forgot about it until You find it crashing, fix it and forget about it again. And of course, funniest part - DIY.

   Did Your knife ever become dull?

   Knife is working - cutting through stuff, scratching, carving on doing other things which is designed or not to do. Some small bends appears on edge, it becomes dull, and maybe other things were not finished from last release. And one day comes, when it needs to be sharp again for putting it back to work. Same as software before release. Bugs where found, stuff needs to be updated, new features implemented, so knife needs to be sharpened.

   And you need to do it Yourself, because You are cheep and don't want to pay to other company to do it, and You don't have some kind of fancy electric hone. Doing it at least one time with our own hands will open Your eyes for stuff which were missed, skipped last time, and how poorly implemented this time.

   I have nice fancy water stone, it is not simple rock, it is designed to be used for honing. You shouldn't be using stuff which is not designed to it, You can, for example, have all Your test cases in excel spread sheet, but there is better tools precisely for that. If You aren't making it automated, at least make it easier do it manually. 

   Doing it once it will increase You understanding. Doing it ten times, You will get good at it. And after couple of years, You will want automation or outsource it as hell. Well this is my experience, maybe Yours are different, would be nice to know. Or not, Your choice.

   No funny image this time, because regressions aren't funny.


Your friendly neighborhood Tester

Long time no see

 
   Long time no see. I can't even remember what last post was about. And still don't know what this post will be. I'm in some kind of crisis at the moment, and this is going like this for couple month now. Can't write something meaningful, can't even think of something to write about.

   I really enjoy testers job, but maybe something need to change to go back to previews shape. Now can't even think of new issues, or I'm skipping something what I observe, but because this is not a part of story I'm working on. Feel like I am lying to myself, maybe I need vocations, maybe new job. Don't know, but something needs to change.

   Before I was "That's a bug, this a bug, bugs everywhere", but now I don't care. Blindly working on stories and that's all. It is sad and depressing, and I am already in bad shape.

   Couple days ago was "Alpha" release on project I'm working. It was really successful. Got a lot of feedback, stuff to improve, fix. And now after several weeks of hard teamwork, huge amount of testing, I don't know what to do now. Grinding my ass to chair, thinking of stuff to do. But I can't think of something. So last resort was to come back to this blog, and write something. At least something. Maybe it will kick me and I will came back to decent schedule.

   Now it would be good to plan next topics I would like to write about. Promises on internet need to be kept. Maybe little bit more depths on regressions, "agile', and product demos. Yes, that will be topics for next blog posts. So even if no one is reading, please stay tuned, new thing will come, someday.

Your friendly neighborhood Tester

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