DEV Community: Artur Mikłasewicz

Dear recruiter, Dear candidate.

Artur Mikłasewicz — Thu, 16 Feb 2023 20:11:51 +0000

As a QA I took part in many recruitments, both as the recruiter and candidate, this led me to the point, where I worked out my recruitment style and developed some expectations related to these. Below I’d like to go over different approaches to interview, this article has no point in defining which way is wrong or right, please treat it as some perspective you can agree or disagree with. I hope you will find it useful.

Dear recruiter

The interview itself is a vast and very complex process. Companies worked out different approaches, starting from very long and detailed recruitment processes consisting of many steps on the one hand and processes that consist of one step on the other hand. All of these have some pros and cons. I will not dive deeper into the process, instead, I will focus on the key points that I find very important.

The right mentality, it’s the most essential value/feature for me, I always repeat that you can teach anyone technical skills, but changing character and attitude is beyond the capabilities of both the candidate and the company. What exactly hides behind this right mentality term? I would divide it into something you can measure and something you can feel, both of these factors matter because silver tongue or the right preparation of a candidate might mislead you. Let’s start with something you can “measure”, there are plenty of open questions which could be asked to understand the reaction of candidates in different situations, not to extend this article I will put a list of questions I like to ask during the interview in the following article. The second part, the feeling, is something, you just understand on the level of your subconscious, so things like the first impressions, if you are having a good time discussing different matters with the candidate, and so on.
Red flags, if there is anything that triggers my internal warning system I consider that, trusting my intuition was always important.
For the technical part, instead of putting a list of questions related to theory, I like to put a candidate in a situation, where he extends his creation and approach. What I mean here is: I do prefer to send very short challenges, up to 2 hours long, that the candidate creates in advance, then during the interview, I can ask the candidate to expand it or ask questions related to that. I’ve seen candidates that could answer every single question related to theory, but when asked to apply this knowledge in practice, all you could get was silence.

Dear candidate

I still remember my first interviews when I was very stressed. I made mistakes I still feel cringed about. I went through all the stages, starting from, I know nothing, then, I know everything, to the point where I understand I need to learn constantly. Like above, I would like to share with you what I expect from myself during the interview.

Be yourself and be true to yourself, I could not imagine a situation where I put some masks just to pass the interview, this would lead to frustration for all the parties involved, if you don’t know something admit it openly, there is a high probability that one day you will receive a question that you don’t know the answer to. Showing your ability to assess your strengths and weaknesses is very important.
Don't forget that you aren’t one man army, usually what you have achieved wasn’t only your merit, most likely there were other people involved. Don’t get me wrong, being proud and voicing your accomplishments is something important, although, there is a very thin line between showing achievements and being cocky, even ignorant.
Choose your strengths over the desire to impress, When you get some kind of challenge and you can present it either in a framework that the company you are applying to is using or the framework you know the most, choosing the one you feel good at, could be a better option, you also show the level of understanding the tools you know the most.
Understand yourself, this is the hardest part of everyone's career. What is the reality? What are the true levels of my skills? What did I learn over the last year? What did I do to improve the way I work? How fast do I learn new things? all of these are very important questions I always ask myself.

These points I have realized after many years of trial and error. Every recruitment process adds, removes, or modifies something on my list. I would like to hear your thoughts and approaches related to that matter, maybe together we can create some book of knowledge that can help all of us :)

The end is near (the end of the failed project, again!)

Artur Mikłasewicz — Wed, 15 Feb 2023 21:13:24 +0000

Within dozens of projects, I had the pleasure to work on, only a very small amount of them could be claimed successful. Did you have the same feeling, that during the development phase of the projects, you could instinctively know which one of them would be a success and which will become a failure? What is the difference between winning and losing? Can we prevent it?
I have a very strong feeling that this is kind of cliche, everyone knows what good projects should look like, so why are we still failing?
I’ve put some thought into this topic and here I’d like to present 4 significant factors, that differ hooray! from dammit!

Wishful thinking
This is something I’ve explicitly put in the first place as the main factor of failing projects from my perspective, what does it mean then? There is an idea of a project, usually quite ambitious, but from my observation, the more ambitious the project, the less time is to finish it, not to mention the resources which tend to be scarce, does it look familiar? I will be completely honest with you, super ambitious projects with scarce resources tend to be successful, although the fact that no one takes into the equation is that chances are meager. All that expectations combined, lead only to frustration and anger. To avoid that, plan it, and include all the parties' Business, Development, QA, DevOps, etc. at the very beginning of the project, not during the implementation phase. The results might surprise you.

One side communication
Every company is saying, we are a team, we are together, etc. But what is the rate of companies that actually mean it and not just repeat that cliche stuff we have heard thousands of times? Often I faced a situation when a business had been communicating the expectations, and setting timeliness then that was it, no feedback expected, no cooperation before, and no review. When teams get only two choices, adapt or fail, unfortunately, the second option would be more likely. The more effort we will put in during the phase of creating the requirements the better output we will receive. Review and feedback are sufficient to deliver good-quality tasks into the work pipeline. This pyramid known for ages already indicates that it costs 10 times more to fix problems and issues once they hit production. Just have that in mind every time you decide to cut corners and skip communication to speed up things.

QA
Factors described above lead to a point, where we start testing. Just to summarize, the project was created based on the wishful thinking of achieving something great and ambitious, everything was presented to the team as something carved in stone with the expectation of just doing it, then we estimated the stories, we develop them, and at the end, everyone is surprised that the sprint goal has not been achieved, when you go into the details you realize that 80% of tasks have been rejected, because requirements were poorly described and everyone was rushing to meet the deadlines. The problem only increases exponentially as the project becomes more complex and advanced.

Estimation
I still remember this joke that PM is a person that thinks 9 women can deliver a baby in 1 month. Jokes aside, this is unfortunately still true in many cases, the points above stacked together: wishful thinking, one side communication, and not taking QA into account, all of this together lead to the creation of roadmaps and estimations which are impossible to achieve from the very beginning.

Summary
This article pointed out some things from a very one-sided perspective, as all of these things I’ve been observing from a QA point of view. If I could shortly give a recipe for a successful project just in a few words that would be:

Engage everyone early
Provoke discussion
Be open to receiving and giving feedback
Balance the expectations and reality
Don’t only be a team, behave like one

7 sins of modern QA

Artur Mikłasewicz — Thu, 30 Jun 2022 10:10:46 +0000

My main motivation to become a QA was a role model of a renaissance man. In the past being a QA meant knowing everything about different technologies and approaches as well as becoming the most oriented member of the team.
This article is a consolidation of my loose thoughts and observations across different companies as well as hundreds of interviews I’ve been taking part in.
Please don’t treat it as an overview of the whole QA world but as some kind of trend, I start to observe. I would discuss shortly different problems in a very shallow manner, although each of the points would be a part of a separate article in the future, so stay tuned.

Quality advocacy

Being QA to me means that you need to become a quality advocate, in short, that means the following things:

Observe,
Analyze,
Conclude,

and the most important thing is to SPEAK UP, pretty often I have witnessed a situation when joining a new team where current QA members were concerned about things within the project but didn’t raise them because they weren’t feeling confident and knowledgeable enough, my advice here is trivial, be brave, you are the main source of raising red flags within the project, your input is the most important part of risk management.

Shallow wide became shallow narrow

The argument of not feeling knowledgeable enough to speak up leads us to another problem that I observe, back in the days QA had to know at least about the following areas:
General QA
Technologies used in the project
Domain knowledge both within the project and the area it was allocated in
DevOps

The phenomenon I observe more and more nowadays is that QA has little knowledge about QA itself as well as very shallow domain knowledge, more and more of them focus mainly on just testing the tickets and filling acceptance criteria than exploring and being curious. You don’t need to be an expert in each of these areas, it’s enough that you at least know that something exists and where to look for the answers, it’s not that much.

Automation != page object pattern

Narrowing the skills range, leads us to another point which is automation, this holy grail longed for every single company in the hope of solving all the problems related to quality, it’s not a mystery that it is not a magical remedy it’s just a supportive tool that lets QA find more critical issues, that are usually hidden underneath, but this is another topic, we will discuss in future, let’s focus on the clue. During many interviews when I ask candidates “how do you imagine a perfect automation environment” I get the answer “oh you mean page object pattern”. It bugs me a lot that so many QAs desperately try to become automation engineers without the basic knowledge about the things from point 2 about wide and shallow knowledge. In terms of automation, you don’t need to rely only on page object pattern, I will tell you a secret here, you can adjust individually your approach to every project you are working on, the goal is the overall quality and maintainability not sticking to the stiff rules.

Testing doesn’t mean quality

Sticking to the stiff rules and not being flexible causes another problem that everyone knows but not so many follow, testing itself does not mean quality, of course, you will find bugs and problems within the app itself, although in my opinion discovering a bug should be a last resort, your role is to help with processes and take an active part in discussions so you can prevent issues to happen. You can do it with this so popular shifting left approach where you are involved from the very beginning of feature creation by pointing out possible scenarios and problems.

Trying new things

Insanity is doing the same thing over and over again and expecting a different result this quote so often misattributed to Einstein is very relevant for our next point so trying new things. Dozens if not hundreds of QA on the market have the following tech stack in their portfolio, selenium+cucumber, I have even encountered companies that create dedicated teams that solve problems caused by selenium, dear colleagues there are plenty of frameworks and solutions that will solve your problems without workarounds, just reach for them. The second part is the famous cucumber, whenever I ask people ok, why do you use cucumber, the typical answer is so non-technical people can understand what is in the code. In the vast majority of cases when I ask, ok, so who in your team finds it useful there is no answer.

Treating QA as a jumpstart to the IT world

Many of the above problems I see, were caused by this one single cause, people treat QA as a jumpstart to becoming programmers, they think that QA is easy because “it’s just testing tickets” after that, they got comfortable, and forget about their goal to become a programmer, as a result, they end up in being neither good QA and programmer, this saddens me a lot because it’s causing some prejudice that QA, in general, is non-technical and non-useful team members.

Digging deeper

Dig deeper is something that is core of QA in general, being curious, asking questions, and understanding why, is your key and main goal that will let you become an indispensable and valuable team member as well as skillful QA. Let’s make QA great again :)