JuniorLearnsToCode

Here are the three things that have helped my testing career: Building good relations with people I work with - from personal experience, is what has helped me the most in my career. People remember if they enjoyed having you as their team member and working alongside you. I always advocate that you should be polite and considerate towards everyone you work with, and never burn bridges behind you, as you never know when a previous co-worker can be your future co-worker as well, when you change companies. I got quite a few referrals from previous co-workers when they moved to new companies, and I recommended people who I worked with, so it goes both ways! Learning Continuously - about 5-6 years ago I tried hard to make a habit of trying my best to learn something new (almost) every day, the reason for this is because I'm lazy, and on the other hand people say consistency is the key to learn new things. If you spend 30 minutes daily learning test automation, in a year you will know...

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