This article was previously published at cobeisfresh.com.

If you work in an agile environment, you’re aware that every software life cycle includes testing as a big part of it. The way you introduce testing to development phases of a project is called a process. Or more specifically, a QA process.

Imagine the following situation: A new project just kicked off and the client requests a Quality assurance engineer on the team. Neither he nor his development team have ever worked with a QA before, so reasonably, many questions appear — both from the team and the client. And guess what? You, as the QA engineer who’s joining the team, will have to answer them:

• How do we work from now on? Will QA block my progress and what happens with our velocity; does QA slow us down?
• What’s with all the bug tickets, do I really have to fix them?
• Why should I let someone else test the app? I was doing just fine without them.

‍ First things first, keep in mind that it’s completely normal for them to have all these doubts. Being in QA for 5+ years myself, and having worked on numerous projects over the years, I’ve answered all of these questions multiple times. But, let me start by saying this: Introducing QA to the project team will not negatively influence the team’s work. Repeat after me — you are a much needed addition to the project team, not a burden.

Got it? Good, now let’s move on to developing the QA process.

Creating the QA process

1. Introduce the Quality Assurance role to the project team

Your first step is to explain the QA engineer’s responsibilities and how he/she will contribute to the project. This is when you’ll have to make it clear that the role of a QA engineer is to help improve the process, stories, requirements and most importantly, the quality of the mobile or web application. Important notice: developers will still be very much involved in testing the app’s quality. ‍

a) To support these arguments, first you have to have the knowledge — that means learning everything you need to know about testing principles, levels, and types of testing. Without mastering the basics, you won’t be able to educate others about what you do and prove the importance of your work. In the end, it could make it harder to introduce the QA process to the team — and this is something we want to avoid.
b) Secondly, you want to get involved in all team activities, as much as possible, and right from the start. That means participating in all scrum meetings, from the beginning until the end. I have to warn you — in the beginning, there will probably be situations when the team doesn’t invite you to certain meetings. Don’t let this discourage you. Stay persistent, ask questions, and offer solutions — soon, they’ll see all the wonderful benefits of having you on the team.

2. Get to know the project team

If you’re familiar with the agile methodology, you know that every team has its own dynamic and approach to work. And the key to success? You know it already, it’s adaptation.

From what I’ve gathered over the years, there are no general rules of getting familiar with your team — it all depends on your teammates. New project usually means a new team, so every time you start a project, you’ll probably have to come up with a fresh set of rules to define the type of the relationship you want to have with them. My advice is to always go with a friendly approach — it was proven to give the best results, at least in my case. This means building a relationship with the developers where you can openly tell them you found a bug and they’ll react positively to it. It also means reaching a level of comfort with the Product owners that allows you to openly discuss any issues and improvements. The Product owner should be your best friend on the project and believe in your approach — if you, for example, say it’s time for a release, they should trust your decision. The same goes with the designers. I always include them in the implementation part of the project and if I see that some part of the design doesn’t make sense, I’ll challenge them. Don’t be afraid to speak up, it’s all part of the job. But as I said, always do it in a friendly way.

When it comes to the team dynamics, it’s also important to recognize the velocity of your team. This will affect the QA process you’re trying to build with them, but also, the number of releases you have. For example, if your team works fast, it makes complete sense to have everyday releases. If not, once a week might be just enough.

3. Start reporting!

Every bug you report, you need to document in the tracking tool you’re using on the project, for multiple reasons:

• You don’t want to lose any bugs,
• You want to know the status of every bug,
• You want a visible trace of your work; I like to call this no bugs under the table.

Until the team resolves all bugs, I suggest keeping the stories open. If resolving all of them is not a possibility, make sure at least all the major and critical ones are resolved. To help developers know what’s a priority, use prioritization. Here’s how we do it at COBE. Educate developers about the importance of having regular builds and small chunks which you can test fast.

Another important thing is to adapt the tracking tool you’re using to the project. When you open the tracking tool, you should be able to see what’s ready for testing right away. So feel free to add an additional column or a simple label that will tell you when something’s done. Occasionally, a developer might say that something’s done because it works on their computer.

Keep in mind that until they’ve made a build with the included feature, something can’t be considered done.

4. Release

Since you, as a QA Engineer, are the person who’s testing the app the most, let’s face it: you’re the person who knows when it’s the right time to release it. That’s why you should be the one in charge of releases. If this doesn’t work for your team, for any reason whatsoever, try not to fight about it. Just make sure that you disclaim any blame if a release doesn’t go well. Remember, you can’t control something that you’re not responsible for.

What now?

Last thing: just start! At COBE, we like to say: Better done than perfect. Working is a learning curve, but so is developing a process. You will encounter problems on the way, but good news is — you’ll also find solutions. And please remember that reading and covering the theoretic part makes you so much more prepared for any situation. You got this! 💪

How to Introduce the QA Process Into an Agile Team was originally published in COBE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Try them out and see what happens next.

When I started working as a Scrum Master, the biggest challenge I’ve faced was creating a good retrospective. My first instincts were to try out some regular questions, such as:

1. What should the team start doing?

2. What should the team stop doing?

3. What should the team continue doing?

These questions were working just fine for a while, until I noticed the outcome of every retrospective started to look the same — and that became a problem. We were mostly just repeating ourselves without making any substantial changes and what made it even more interesting, we didn’t see anything wrong with that. We thought our communication was great and we should just continue doing what we were doing, but after some time, we decided to change the way we were doing the retrospective. That’s when we realized that most of our problems appeared due to bad communication — we were a team, but we weren’t acting like one.

Let’s start with a short story.

This year I was helping out with the organization of a sport event in Zagreb, Croatia. The work I did wasn’t related to COBE, it was just something I did on my own time. Now, the team that I was working with already had years of experience in this field and each person in the team was an expert in their own sector of work. Well, one of those sectors was in charge of the opening ceremony — which meant, after the ceremony was finished, everything needed to be properly cleaned up. If it was just up to those few people it would’ve taken them more than five hours to clean everything. Luckily, that wasn’t the case. Everyone, including the boss, stepped up and helped out, even though it wasn’t in their job description.

What I realized then and there was that that’s the kind of team spirit we, at COBE, were missing. At least when it came to working together on projects. When it came to setting up new desks or decorating the office for Christmas, we would all step in and help out and that never represented a problem. It’s just that sometimes we get so occupied by our own tasks that we forget others might be struggling too — and that’s the change we needed to make.

Ch-ch-ch-changes

The next logical step was to introduce changes and new possibilities where I could and the easiest way to do that was to improve the questions I mentioned at the beginning of the article. The main goal was to set some ground rules (because we were missing them), improve employee relationships while working together on projects and ultimately, build up the team spirit we were lacking.

Check out the new set of questions we came up with:

1. What’s the most important thing to have in your team?

First things first, you need to set expectations and team values. Since reading each other’s minds is not an option, everything needs to be said out loud because that’s the only way everybody can be on the same page.
For example, the most important thing for me is to trust the people I’m working with. In this case, trust represents a value that needs to be set up in order to grow a healthy working environment.

2. What are you missing in your team?

Yet another question reflecting your team cooperation. Maybe, at some point, you felt your teammates didn’t have enough sympathy for you. Maybe you even felt isolated or misunderstood. The goal of this question is to make your team rethink the values that were broken (if anything was broken). This one’s all about those feelings.

3. How can you help your teammates?

Trust me, there’s always a way you can help each other. People connect best in situations where someone shows compassion, especially when it’s without any obligation. The only “obstacle” here is that, in order to create an environment like that, you need to start with yourself.

4. What did you miss during the Sprint?

Maybe there wasn’t enough time, the design was missing or the client just wasn’t available — think about those kind of situations in order to prevent them in the future. Also, ask yourself did you stop doing something that was maybe working before? Reflect on the sprint and think about all those factors that had an impact on it, internally and externally.

5. Is there anything you’re doing during a Sprint even though you don’t know why?

Sometimes people give out opinions on things and they’re doing it not to be harmful — it’s just that they really want to help. But during a Scrum retrospective, no one outside your team should make any decisions for you. Discuss everything and if there’s anything you’re questioning or not quite understanding, say it out loud. Otherwise, chances for making changes are equal 0.

6. Is there anything unexpected you got from a team member?

This doesn’t have to be anything big. Maybe one of your teammates made you coffee because you were super-busy or someone brought you chocolate because you had a bad day. Little things matter and they’re always worth mentioning.

7. Do you want to mention a situation that went unnoticed?

It happens more than often that during a sprint, people are occupied with their work and sometimes don’t even notice what’s going on around them. So, my advice is that if you notice someone doing something nice without anyone acknowledging it, say it out loud. Showing appreciation goes a long way.

8. Did you learn something new?

I think that each sprint or iteration teaches you something new. If there’s something cool you’ve learned and you want to share your knowledge — do it. It’s good to remind people that they are growing each day and that they’re always allowed to speak up.

To conclude

Coming up with these questions wasn’t the easiest, but we did it together, as a team. We finally figured out a solution to our problems and it became clear who was a part of the team and who wasn’t. Of course these questions won’t last forever — we’ll probably gonna get sick of them in some time or they’ll just become otiose. But as a Scrum Master, it’s your duty to constantly think of new ideas and iterations, all with an end goal in mind — having a successful retrospective with a happy client and an even happier team.

But, just like in life, after a retrospective ends most of the time people focus on the bad things. That’s when you need to step in and redirect your team to a “happier path”. Otherwise, you won’t be making any progress. And the most important thing to mention — when you finish the sprint, go get a beer. Because nothing connects people as alcohol. Just kidding. Or am I?

What questions would you add to our list? Is there something you would change? Let me know in the comments below!

Previously published on cobe.tech.

Nikolina is a master of math, QA engineer and a Scrum Master at COBE. While her responsibilities mostly focus on QA, she is strongly influencing and challenging the whole team, changing our process from scratch. As a former basketball player, she shows impeccable work habits and contagious energy that often reflects on the team.

• Prioritization in Quality Assurance — How we do it
• Product Ownership — Rights and Wrongs
• How Playing Sports Can Help Your Future Career

8 Questions You Need to Ask Your Team in Your Next Scrum Retrospective was originally published in COBE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Prioritization in Quality Assurance — How we do it

Five levels of prioritization in COBE

Catching all bugs as early as possible is a dream come true for the whole team. However, during the development phase it’s quite normal to have a few bugs at the same time.

Let’s say that a QA Engineer has found five bugs while testing a feature. How does he/she decide what to tackle first?
It can be overwhelming to add a few extra bugs to the pile of features you have to deliver, especially if you work in sprints or a release is right around the corner.

Luckily, there are different levels of prioritisation that can help you to decide what to tackle first!

Defining the different levels of priority might be a challenge for newly setup QA teams, since the internet is full of different and often contradicting information. We also did research before, and practically every page we’ve opened had its own definitions and explanations. That’s when we decided to create our own categorisation, explained in the following text.

5 types of prioritisation in COBE

By looking at the literature and online information, these two terms will probably show up: priority and severity. The definitions online say that:

• Severity stands for the impact that the bug has on the functionality of the app.
• Priority defines the order in which the bug should be fixed.

In our team, we use the combination of both and we call it prioritisation.

Bugs found (like we have them 🐛) in our projects are now being split into 5 categories: Trivial, Minor, Major, Critical, and Blocker.

The definition of each type is based on the way this bug impact on the functionality of the app. Let’s dive in!

1. TRIVIAL

Definition: Trivial bug doesn’t affect functionality and progress. It doesn’t affect the user usage of the app.

Example: In the Login screen there is a button for the Login. Text on the button is misspelled to ‘Logun’.

Explanation: Yes, this is definitely a bug. But it doesn’t affect the functionality. Users can log in to the app which is the main purpose of this feature. And this misspelling doesn’t affect the users’ understanding of the usage of that button.

These kind of bugs are lowest on the priority list. They will be fixed if there is enough time, or in the period of polishing the app.

2. MINOR

Definition: Minor bug has the potential to affect progress. The part of a feature is malfunctioning or is unable to function. There is a simple workaround to avoid this behavior.

Example: The user needs to click on the button to do some action. In order to trigger this action, the user needs to click 2 times on the button.

Explanation: As a user, if something is not working you will definitely click one more time to be sure that you have clicked. There is a simple workaround to avoid this problem. It won’t be a trivial bug, because it can be pretty annoying if this issue appears on the button that is ‘important’ in the app.

These kind of bugs should be resolved after all the serious bugs are fixed.

3. MAJOR

Definition: There is a workaround but it’s hard to go through it and there is a chance that this bug will affect the progress.

Example: One of the features in the app is deleting the item in the list. The item can be deleted from the list, but also it can be deleted from the details page of that item. Let’s say that deleting from the list is not working.

Explanation: This is the major bug because one of the features is not working at all so it’s affecting the progress. But, because there is more than one way of deleting the item, a user has a workaround and he can do this action.

The bugs with the highest prioritisation? This is it. It’s not a show-stopper, because there is a way for a user to finish the action. But this bug should be fixed because it’s not harmless.

4. CRITICAL

Definition: This type of bug affects the usage of the app and there’s no workaround. It’s a show stopper which means the functionality cannot be delivered unless that bug is cleared.

Example: In the application, there is a contact form. The user is able to send his data in order to apply for a job. After he has fulfilled the whole form, he clicked on the submit button. The form is not sent to the employer.

Explanation: The main function of this feature is not working. The user is able to fill out everything (that’s why it’s not a blocker), but he is not aware that his form has never been sent.

If the bug has the label critical, that means that something is seriously broken. Usually, the feature is unusable, so this should be fixed immediately.

5. BLOCKER

Definition: The entire app or just some of its features are broken and they aren’t usable. Users or testers are blocked.

Example: One of the features in the application is ‘Edit profile’ where the user can change his data. When he taps on the edit button, nothing happens.

Explanation: As it’s written in the definition, we are blocked. In the edit profile section can be more than one feature. For example, a user can edit his name, email, or image. None of these features can’t be tested because there is no path user can take to get there.

Same as the critical bug, this should be fixed immediately.

Please note! There are circumstances in which the same bug can jump up or down on the priority list. For example, the trivial bug above mentioned — the misspelled word “Logun”, during the production phase is only trivial. But if the team is one day away from the release point, this bug would become more important as it's quite embarrassing to go live with a mistake in the first steps of the app!

Two more factors affecting the priority

It is all about the context. If you are building an app where the most important thing is the look and feel of the app, then the UI bugs will get the highest priority. In this case, maybe the one-pixel difference will be enough to launch the bug into the major priority list. In some other cases, the one-pixel bug will be a trivial bug and the team might decide to leave it be.

The other thing that affects the priority of a bug is the personal opinion of the tester who is reporting the bug. There is a small difference between trivial and minor bugs, or critical and blockers. The examples that are stated are pretty straightforward, but sometimes the difference will be not that obvious and the priority will depend on the opinion of the person who is reporting it.

We didn’t forget severity but…

By looking at the prioritisation literature and online info, the term severity will probably show up. The definitions online say that:

Severity stands for the impact that the bug has on the functionality of the app.

Priority defines the order in which the bug should be fixed.

In our team, we use the combination of both and we call it prioritisation. Our projects are mostly done using Scrum or Kanban. The implementation is divided into 2 weeks iterations, with a mini-release after each of them.

Therefore, we are dealing with one set of bugs for one iteration. Our mindset is that most of the bugs need to be fixed anyway. First, the team needs to deal with the bugs that have the highest prioritisation, and if there is time they are going to fix the bugs that are not that much important (in an ideal world each bug is important, I know). At this point, labeling both severity and priority would be an overhead.

How do you handle priority in your company? Do you have the same categories as we do? Feel free to share your experience, we would like to hear it!

Nikolina is a master of math, QA Engineer and a Scrum Master at COBE. While her responsibilities mostly focus on QA, she is strongly influencing and challenging the whole team, changing our process from scratch. As a former basketball player, she shows impeccable work habits and contagious energy that often reflects on the team.

• How We Got the Whole Team to Practice QA for a Month
• It’s Test O’Clock!
• How I Fell in Love with the QA

Prioritization in Quality Assurance — How we do it was originally published in COBE on Medium, where people are continuing the conversation by highlighting and responding to this story.

How to do Quality Assurance in Agile Development

As a QA you are playing an important role, because — well, you are fixing bugs and trying to make the world a better place. And that is a big responsibility. When you think about it, your job is to actually question the product you are helping to develop. Interesting, right? Finding problem areas before the users do requires some pretty great skills and knowledge. How do to in Agile?

What’s it like to be a QA in an Agile environment?

Software Development Cycles usually have 5 phases: Requirement gathering and analysis, Design, Coding, Testing, Deployment and Maintenance. While in most traditional models testing comes at the end, in agile development, things are a bit different. Why?

In Agile, work is divided in phases called Sprints. Duration of one sprint is usually 2 weeks and the team has the responsibility to deliver certain tasks within this period. What makes sprints different is that during those 2 weeks, we go through all 5 phases of software development:

At the beginning of the sprint there is usually not much to test. Use that time to study the documentation and write test cases. Writing test cases may seem unnecessary at first, but it’s not! It’s actually very useful, because everything is now in one place, systematized and transparent. This document also allows you to see when a bug was created and can be therefore really helpful for the next person doing the testing, in case you switch to another project.

Testing during the sprint. At this point you test only what was newly created or bugs that have been fixed.

Testing at the end of the sprint. Now you have to test everything developers have done in this sprint.

Testing before release. Don’t forget to test the whole app to be sure that everything is okay.

And then we repeat it sprint after sprint.

Pretty cool, right? The problem is, this way of work also opens a lot of space for challenges. The biggest one is the fact that there is always so little time for everything, and QA is always the first one to be cut, which means that the product won’t be thoroughly tested. This could eventually lead to lower product quality. If developers don’t have enough time to fix all the bugs found at the end of the sprint, these bugs become part of the next sprint. How can you avoid that? Here are some tips and tricks.

What Bugs Me As a QA?

The most important thing for me as a QA is to feel like a part of the team. That means that all the other team members have to understand that testing takes time. Of course, it can sometimes be time consuming, but that doesn’t mean that we don’t have to do it. Here are my top 3 tips on how to improve your testing game in the agile development:

1. Include testing hours in planning. It’s important to calculate the time necessary for testing each feature of the sprint. Because of this, the scope of the sprint may become smaller, but we’ll get on quality. At least, developers will be sure that the product they delivered is bug free (as free as it can be, there are no applications without bugs) and ready to be used.
2. Test from day one. Testing should not be done only at the end of the sprint. As soon as developers are done with a bigger feature, they need to send it on testing. This allows the QA to catch bugs in the early phase of developing and can prevent smaller bugs from turning into a huge problem.
3. The last day of the sprint should be reserved only for testing. Developers will probably be mad about this, because that’s one day less for developing. But, in that way we will enter the next sprint without bugs! During that last day we have enough time to test everything, but also to fix all the bugs. Otherwise, bugs found in this sprint will go into the next one, because there won’t be enough time to fix everything before the end of the sprint. That means that we will lose the first day of the next sprint. In my opinion it’s better to lose the last day of the sprint and have a clean start in the next one.

Get involved!

But this is not all you can do. What has proven to be really helpful for me as a QA are daily meetings, where you can find out who is working on which task and when they will be done with that task.

It’s a great opportunity to self organize and learn what you can expect at a certain point. Communication and teamwork are essential if we want to accomplish our goals. In the end, as members of the team we all have the same goal — successful products!

So, do you find this tips useful? If you have your own insights, feel free to share it in the comments section, we would like to know more about it! While you are here, check some other COBE articles:

• How I Fell in Love with the QA
• Tips & Tricks on Becoming Successful in Software Development
• Developing Better Coding Practices Through Testing

It’s Test O’Clock! was originally published in COBE on Medium, where people are continuing the conversation by highlighting and responding to this story.

Before entering the world of programming, I wanted to become an Android developer. A year after, I’m a full time QA engineer, and a happy one. How did it happen?

It all started with my job application at the design&dev agency COBE. At that moment, I haven’t had any ideas about QA but my future boss asked me if I would like to try it out, as he finds QA the best way to start discovering Android functions and learn basic terminology.

First few weeks were all about reading and learning about platforms and company processes. Much of this reading was about the QA and its importance. Honestly, I thought that those were all just ‘empty’ words.

Later on, I’ve started testing manually, but whenever I had some free time, I used it to learn Java. My only goal was to learn Java as soon as possible and finally start with the ‘real’ programming.

The bug that changed it all

Then it happened. My first bug! When I found it, it was the first time that I felt like I’m contributing to the team — and it felt awesome. After a few days of testing I realized that manual testing is not all there is. There is a huge world of possibilities how to test and what to test.

That was a moment when I started to like what I do.

I realized that my job is actually really fun. You are the first person who gets to play with an app. You have complete freedom to do whatever you want in order to find bugs. Your job is to be creative and to predict what users will do when they are using your app.

I was told that dev team is glass which stands on the table. I’m the wind who is trying to knock that glass down.

Finding bugs became a game

What I enjoy the most in my job is the opportunity to communicate with the team. Together we are trying to find the best way to resolve whatever problem occurs. When it happens, we are working as one to fix it, and not as rivals, as it often happens. In COBE we support each other so when I report a bug, I’ll get a compliment, not a complaint. For me, this is the most important thing to achieve as a QA.

It seems that importance of a QA is quite big after all

Testing provides some dose of security to the whole team. Even if you have tested everything, you can never tell if an app is 100% bugs free, but you know that you’ve done everything that is in your power to deliver the most reliable version of it.

But the main goal is not really delivering an 100% bugs free app because most likely that kind of app wouldn’t be intuitive enough for users to like it. You are doing testing to ensure quality of your products and to be sure that you don’t have any omissions. We are all humans and it’s normal that we will make mistakes.

Importance and influence of technology today shouldn’t even be explained. Products such as airplane software or software in medical equipment are often in charge of human lives. It would be reckless not to test them, right?

But when it comes to other products like apps or websites, we often hear that there is no time or that this product is not of the same importance. But let’s say you want to buy a new car. I’m sure you wouldn’t buy it before you took it out for a test drive. You’ll first want to see if everything is okay with that car, are the brakes correct, do you have servo wheel, are tires faded… Why would it be different with apps?

Maybe you are not saving anyone’s life with it, but you definitely want to create smooth and enjoyable product that your users will love and come back to. If you approach every project like it’s the most important in the world, the quality of it will be unquestionable.

And you will feel much better about it, knowing that you are the one responsible for the seamless and awesome user experience. Also, it helps when you push the app and go for a beer with your colleagues, to celebrate and not worry! :)

Overcoming challenges

Of course, its not all fun and games. Every start is difficult and in my QA beginnings I’ve faced some obstacles too. It is important to imagine those obstacles as a challenge and understand that there is an existing solution for every problem — you just have to find it. The biggest race every QA has to run is against the lack of knowledge. As a QA, you have to be a t-shaped person. That means that you have to be good in your work, but you have to know a little bit of everything from other areas too. For example, great testers know how different mobile platforms react, understand frontend/backend concepts and recognize good and bad practices in design.

This versatility is exactly what I like about this job. There is always a new problem that you will encounter, new tool to test with. Sometimes it takes a lot of time but the feeling of finding a solution and seeing the progress every day is quite addictive!

Nikolina is a master of math and a QA engineer at COBE. While her responsibilities mostly focus on QA, she is strongly influencing and challenging the whole team, changing our process from the scratch. As a former basketball player, she shows impeccable work habits and contagious energy that often reflects on the team. In her free time, she is trying out different sports (currently yoga), plays DnD and enjoys life in general.

Liked this one? Check more articles from COBE team:

• Personas — If, Why and How to Use Them
• Developing Better Coding Practices Through Testing

How I Fell in Love with the QA was originally published in COBE on Medium, where people are continuing the conversation by highlighting and responding to this story.