Fuse blown

After 3 years you got used to things and you just aren't surprised every week by something strange (to you). But recently I've seen two things worth sharing.

First thing

What's this?

For almost 2 years, I haven't noticed this small red bin in each restroom next to the washbasins having a bio-hazard label on it. This little container is for people suffering with diabetes. If they need to administer insulin during the day, they can safely dispose the used needles and syringes. And in each restroom I've been to on this campus, this thing was never empty. Now, there's either no policy in Europe regulating such medical waste at workplaces, or there's really a lot of people here dealing with diabetes! I vote for the second one. It's frightening. Maybe it's time to lift quotas on cane sugar and ban high fructose corn syrup?

Second thing 

 

This is just something I couldn't go by. Why would you want to take such a picture wearing a pink women's scarf around your waist on the beach in front of dozens of people?! Americans are really extrovert.

End of a journey

My 2 year long journey in quality engineering is about to be over. Finally I will do development work again. But this outlook made me learn some valuable lessons and made me a more seasoned engineer.

I have mixed feelings.

I think every software engineer should take a journey on the QE/QA side. It makes you learn to look at things from a different perspective. It makes you appreciate QE folks better, too. I certainly felt like being treated as a second class engineer multiple times. I saw how QE is not appreciated. But when it comes dohúztálwn to deliver a working enterprise class application suite, it's essential. It's just not appreciated, and treated as a pain in the butt.

I've seen better setups for dev-qa cooperation than what I've experience just now. I think when a developer has a direct QE counterpart, and the two departments are not separated hierarchically, the cooperation and efficiency is way better. I also observed what problems can it cause if someone forgets that agile over waterfall model shouldn't mean lack of design and not thinking through things..

I think

• developers should respect QA folks. Their job is not that interesting, they spend most of their times gathering logs and creating bugs, filling out excel sheets and chasing developers to get some information on the thing they are supposed to be testing. And theirs no break really, it's the same story every day, week or month.
• hiring managers for QE should not lie to candidates saying that this is like a development position. Sure you'll develop testcases and design tests, but that is far not the majority of your time spent on the job.
• usability of a product should play a much higher priority. Maybe you're the market leader today, but there's no guarantee that someone will not develop a better solution based on your products. Then you can go and acquire that start-up, and mess up your product line, to make the investment return somehow.
• once managers apply tools for reporting, they should spend their managing time acquiring the metrics from the tools instead of making engineers do the same and put it in the Excel sheet. Nobody went to engineering school and got an engineering degree to run reports on a tool and put the numbers in the Excel sheet.
• just because a QA person didn't fill out the 100 entry form for filing your bug, you shouldn't close it with won't fix or user error. Not just QA should have the sense of ownership in the team. Have you heard about needinfo?
• once you invest millions in certain tools don't save hundreds of thousands of dollars not integrating it completely into your environment. Let's say you're using HP Quality Center, then integrate the test runner as well, so QA doesn't have to spend days or weeks every month on running the tests in a separate environment, convert the results XML into CSV, fill out the opened bug number in the CSV and upload it into the tool, from which manager can't/won't run reports but ask QA to export back into the Excel sheet. The same can be achieved with just Excel and SharePoint or a simple wiki. Way cheaper, but much more expensive in the long run.
• documentation should not be treated as an unwanted child or a nagging distant relative. It's an overhead, but saves dollars, pain and time!
• if you join a big company with big and/or complex product line, in QA you will learn much more about the products and will undertsand them better than any developer. Most of the time developers know only about the module/feature they're working on it, and not even able to see its connections and interactions to other parts in the system correctly.
• H1B system is somewhat like modern slavery, but I'm not complaining; I'm the one who wants to work in this country anyway, so I just suck it up.

Once my LinkedIn inbox started to receive exclusively QA/QE/automation (all synonyms) offers, I knew that I must make my move. Thanks to my (e-)smoking habits, I finally found my way out.

Why I took a QE position in the first place? My trust towards my previous employer and the way my immigration was handled suffered a major hit, in despair I took the first position offered to me. It paid off though. QE is less stressful then development, so I could enjoy a strictly 8hr workday environment for years.

Employers: if you employ people on H1B, then live up to your commitments. Handle their immigration status with extra care. Their life depends on it. Nobody would like to move back to the other side of the planet within days. People like to plan, leaving your people in uncertainty is disrespectful and just plain wrong. If you're not willing to, or unable to achieve something, don't promise it. If you're facing difficulties communicate it clearly without any bullsh*tting.