JuniorLearnsToCode

Reporting bugs is an unavoidable part of SDLC and it is an integral part of any tester's job. It's usually done using bug-tracking software such as Jira, Rally, Bugzilla, Mantis, Azure DevOps, etc. In this post, I will share a few general (common-sense) tips on writing a clear and useful bug report. Well-written and understandable bug reports save time and can be a significant contribution to the quality of the product - especially if we prioritize those bugs which negatively impact the user experience and block the core functionalities of the application under test. So let's see what we can do to make our bug reports better.  Root Cause Analysis  Before reporting we need to make sure our defect is valid, we should check for human errors such as an outdated (no longer support) app version, configuration settings, user or systems settings - checking the logs can help us a lot here. Root cause analysis can be added in the form of testing notes to the defect ticket. If the tes...

Domain-Driven Design is not a new concept - it has been around since 2003 when Eric Evans published the " Blue Book ". However, I did notice that there is not much material on the topic of testing within a DDD environment. This may be due to the fact that DDD is not some trendy hot fad, and from what I have noticed, there aren't that many companies using it. Using DDD for smaller projects, and projects where the business/domain logic is not overly complex is overkill - as DDD is meant to simplify a demanding project, on a small project applying DDD would have the opposite effect - it will just add more abstraction, which is not needed in this instance making a simple project a lot more complicated. Combined with the previously listed reasons, DDD shops usually use the  TDD approach, so there is a lot of testing involved (especially automated testing) but it's done by the developers and not dedicated testers - and we all know that testers can talk on and on about test...

Test oracles and heuristics can be considered as "meta" aspects in software testing, often we can be in a position where we are using them without being aware of the "official" definitions. In short, an oracle is a way of deciding whether our test has passed or failed - most commonly express by using terms such AR/ER, Actual Result, and Expected Result.  Heuristics can be viewed as a rule of a thumb, a guiding principle, the "official" description goes like this:  " A heuristic, or heuristic technique, is any approach to problem-solving or self-discovery that employs a practical method that is not guaranteed to be optimal, perfect, or rational, but is nevertheless sufficient for reaching an immediate, short-term goal or approximation. " Heuristics can be applied to various testing activities, but are especially useful in exploratory testing, as they are broad and generic enough to be applicable in a variety of different situations.  And lastly, M...

Change is always hard. Humans are creatures of habit, we feel comfortable and safe when we are operating within our established (predictable) patterns. That is why people resist changes, even the ones that are good for them! Getting someone to accept that a change is needed can be tricky, it will generally involve analyzing the situations and doing some persuading. If you can convince others that a certain change will bring them a certain kind of tangible benefit, people will be more open to accepting it. So let's see how would that look in terms of software testing!  As testers we often are arguing for more resources for testing, more time, trying to convince the management to give us the blessing to do more automation, to try out new approaches to testing, and to implement improvements to our testing process. So let's say we propose to change the testing process in our company, how would we go about implementing those changes? Assess the Situation First of all, get to know th...

Change can seem difficult and scary, first day on a new job will always impact you emotionally, to a certain extent - even if you changed many jobs before. In this blog post I will share a few tips to help you make the transition easier and how to beat the fear of the unknown!  Keep Your Ego in Check Important thing is to be humble and kind, and leaving a good first impression (of course also make sure that the good first impression is also the lasting impression) as this will affect how people on your team perceive you. Don't be a cocky show-off, be polite and nice to everyone. Naturally this does not mean that you should put up with any abuse. Meet Everyone  Taking time to meet your new teammates is very important, and not just meeting them, getting to know them as individuals. People who are already working at your new workplace will be a lot more busy than you are so they might not initiate these kind of things, instead, you should be the one inviting people to lunch to ge...

I had a rather bumpy relationship with Java, up to now I re-started learning Java three times - gave up in my first two attempts, due to various reasons and the third time is the charm, as they say! Learning to code is tough, it can take a long time and can can be frustrating at times, especially at the very early stages - you will be tempted to give up it. The First (Unsuccessful) Attempt The first time I tried to learn it was in 2014, I watched a few online tutorials from some university professor (I can't recall the name) and at first, on the theoretical side it seemed okay, even though, at the time I had no programming experience at all. But when the coding part started I felt so lost and confused like never before, I had honestly thought that something was wrong with my brain then. Back then (being a smart-ass) I thought I could learn coding with little effort since it was generally always easy for me to pick up new things. I had no idea at the time that learning to code...

Once you have been to a certain number of interviews, you will notice that there are a lot of common questions that you will be asked by different interviewers. Sometimes differently worded, but most of the time the similar knowledge check will be required of you. This is especially the case if you are applying for a tester role for the first time, it may be for your first job ever, or a career change in IT, or if you're coming from another background. The goal of this post is to help people ace their interviews, and also to stimulate them to learn more about testing. Simply memorizing answers by heart will do you no good in the long run - you might find yourself in a situation where you bit off more than you can chew, let's say you find online a bunch of common QA interview questions, just memorize them without any understanding of the topics, bluff your way through the interview and you start working - the employer things you know what you claimed and expects a certain level ...