JuniorLearnsToCode

For most testers, designing, executing, and maintaining test cases are regular activities, this is especially true for new testers and those in the early stages of their career. This post is inspired by some documentation I worked on, in an effort to standardize the testing process in one of my previous jobs. Bear in mind that in each company the approach to handling test cases can differ significantly, old-school (Waterfall-like) enterprises might favor very long and detailed test cases, where each step required to execute the test cases is described in great detail, to more Agile environment where testing is moving at a faster pace, so test cases in Agile are shorter and more concise. There is a great course at the MoT on this topic called  Optimising Manual Test Scripts For An Agile Environment , by Match Archer, the course is not too long and it's full of useful info, I'd highly recommend it. There is also a third alternative - no test cases at all! This has been a trend in...

Most of the time, when people hear the term "software testing" the first thing that comes to mind is just that - testing some software, which usually involves reporting a lot of bugs, designing test cases, doing exploratory testing sessions, working on automated checks, etc. But, there are a lot of other ways in which a tester can contribute to the overall quality of the product. So what exactly would proactive thinking be, from a tester's perspective? A tester does not have to be just a bearer of bad news, as a tester sees the system as a whole and gets plenty of chance to interact with it, the said tester can also gain a lot of useful insight into the system. One of the most important aspects of our job is to provide information, sometimes that information needs to be distilled down into more succinct formats, but also, a tester should proactively act on the information he/she gains.  Just because you might not find any obvious bugs in a feature you're testing it do...

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...