Let us introduce Jelena, a member of our DevOps team in Novi Sad! She started her career in this field almost three years ago, and, as she likes to say, it started by accident when she got a laptop as a present, but with Linux on it. The curiosity took the lead as she wanted to figure out more about what is happening behind the machine’s pretty colors. Step by step, Jelena became a Development and Operations engineer, which means that she is now supporting her development teams by providing an automated infrastructure that is stable for deploying their applications.

“In the beginning, there was this System Administrator role whose main purpose was to dictate the infrastructure that developers needed to fit into; but over time, the role of connecting System Administrators with developers emerged - DevOps. Today, this role represents finding clever and inventive ways to provide and automate the infrastructure supporting what our Software Engineers create. I also believe that my role carries the responsibility of educating the development part of the team to understand how the system functions for them to be aware of how the code changes affect the bigger picture.”

Automation - Good Cop, Bad Cop

“We always strive towards automation. Automated processes enable us to easily detect defects, increase release frequency, and reduce the time to recover if a failure occurs - not to mention the shorter development cycle. In other words, automating your processes will give you the power of figuring out what’s wrong in just a couple of clicks - of course, if the automation is done right.” Jelena added that deployment to production is a critical moment for things to potentially crash and admitted that she likes to keep a close track of this step of the process by making sure everything deploys according to the standards. “Ideally, continuous deployment means that everything is automated, but I believe that the whole team needs to be very mature and well-coordinated, as well as the product itself, in order to work within that kind of a system set-up. Implementing fully automated processes is both a goal and a process of its own.”

What Are The Risks? Well, We Could Break Everything.

Another bright side of deployment automation is that you can always return to the latest stable solution you had. “I remember one time our Scrum Master asked what the risks of making a certain change within the system are. The answer was, we could break EVERYTHING,” Jelena said through laughter and added: “Those who don’t back up - will.” We assume that having a good recovery base is what helps DevOps Engineers sleep peacefully. “Being aware of the consequences certain changes may bring is a result of transparent communication within us as a team, where sharing concerns and coming up with solutions that serve as a compromise between the code and the structure is a goal we all share,” she added.

Jelena also mentioned that changes and updates of tools, infrastructure, or approaches are pretty standard in today’s industry and that building agile solutions terminate lots of risks.

DevOps as an Integral Part of the Development Team

In Symphony, every team has their dedicated DevOps Engineer, “which allows us to understand the product as a whole and work directly with the development team. I find that beneficial since working together means educating each other about what is feasible from both sides. This way, we are all transparent about what the other side can expect as support.” - says Jelena emphasizing the importance of direct cooperation with the team.“When it comes to continuous deployment, DevOps needs to get familiar with the system first, and developers are the ones who help us get the right perspective on the needs of a product they are building. On the other hand, we build deployment pipelines for developers to use regularly, so we must introduce those pipelines’ functionality and structure to the developers. Therefore, naturally, being in the same team eases the process and helps us bond by working on the same mission of building great software.”

Keep It Slow Until You Reach The Happy Flow

Continuous deployment is the primary goal of every Scrum team, and DevOps engineers give their contribution by providing a clean structure of deployment pipelines, lowering the risks of errors which results in achieving a so-called Happy Flow. “Building your process on automated pipelines and just tracking logs is an ideal scenario every DevOps engineer pursues. Pulling off a Happy Flow is never easy since the processes depend on one another as well as on the teammates, but it is not impossible. We are always striving towards optimizing our resources, which is one of the reasons I chose to speak about Jenkins at our Meetup in March. I see many benefits regarding this tool in my everyday work - it’s open-source, which is a huge deal when it comes to the DevOps community, it’s free, has innovative plug-ins that follow the trends, and it’s easy to use.”

Our DevOps team in Novi Sad consists of 4 engineers, led by a Principal DevOps, and they are looking to welcome new teammates in the future.

Are you one of them? There’s always an opportunity to join our team in Novi Sad, so check out our openings!

Visit the company profile.

Whether you’re an entrepreneur launching a service or a developer working on an application, one thing is for sure: your front end needs to impress and it needs to do it fast. In other words, if you want to succeed, the quality of the product you deliver needs to be impeccable and there’s little room for bugs. That’s why I do my best to include tests and make them mandatory on all front-end projects I work on in Symphony.

First and most obviously, testing saves money and time. The software development lifecycle includes many phases and if bugs are discovered early on, it costs much less to fix them. However, solid testing will ensure the best product quality that keeps customers coming back.

I never met a React developer who is really comfortable with writing tests.

Yet, tests are often omitted. Entrepreneurs, especially when just starting out, are already barely making ends meet, so it’s no surprise that they try to cut down the hours and workforce needed to ship the product. Some developers, on the other hand, keep pushing to work on new features, which can seem more exciting.

I get it, you want to get down to the fun part. But, considering the cost of fixing a bug found after product release can be 6-7x higher than for the one discovered in the testing phase, I always prefer to spend the extra time and effort on writing tests for each product we work on. While it may sound counterintuitive, this way I actually get to spend less time fixing bugs in the long run. Win!

Adopting the testing mindset within a team

When defining the project scope, it’s a common practice to define the testing strategy as well. However, if rules and procedures are not clearly defined by the client, our team as a whole discusses and defines the strategy for writing tests for the React app. This is to avoid common excuses such as certain features being seen as more important than test coverage, tests not being a requirement from the client-side, developers not having the time to write tests, or considering them difficult.

Once these obstacles have been removed, the team agrees on the testing library or framework, and then the discussion moves to test types.

Unit or integration tests

Unit tests are usually the first step of testing because they are simple, have a few dependencies, fast execution, and are easy to write. Even though they are so simple, unit tests are tremendously helpful and reliable when written correctly. Writing them correctly means not touching the internal state ( if testing component ) and testing all edge cases.

When a unit test is written, the behavior must stay the same and the same test scenarios should pass. So, we’re testing user perspective instead of implementation.

For example, we had to display an error banner on the top of the UI, and we used a React Context API, but later on, we found it can be better implemented with an observable pattern. We changed implementation but error banner tests remained the same since we didn’t test the internal state and implementation, but inputs and UI outputs.

While unit tests are a better choice for standalone components, integration tests are more complex and have a dependency on other components, data, services, etc. They include multiple components or modules and require more time to write them. With more complexity comes more value too. Integration tests will ensure that the application works correctly. With years of experience in writing tests, I found integration tests most useful in the early detection of bugs.

But, where is the line between unit and integration testing? The difference can be blurry, but if we test standalone components and mock all dependencies ( isolation mode ) then we have a unit test. On the other hand, integration tests include the interaction of multiple components, without mocking all data.

Tip: We shouldn’t test an internal state because the test will break if we change how we handle the state internally. This is where the react-testing-library is good.

What and how much should you test

One of the challenges is what and how much we should test. A team should choose a library that follows best practices and is the best match for the application. Good documentation and test examples are also important since developers usually need some time to get comfortable with testing and a good source of information speeds up everything.

High code coverage is not a guarantee we have a stable application in and of itself, but it’s an important factor if achieved correctly. We could simply reach high test coverage by writing snapshot tests and testing only happy path scenarios, which doesn’t get the product far. Instead, we should write tests that are meaningful and follow both the basic and edge-case scenarios.

Which testing libraries/frameworks we should use?

Well, whatever you agree with your team. In the end, tests can be written with any popular framework or library. There are two most popular frameworks/libraries:

• React Testing Library - https://testing-library.com/docs/react-testing-library/intro
• Enzyme - https://enzymejs.github.io/enzyme/

I used both and I have had a great experience. It’s up to you to check documentation, experiences, and make a decision that makes the most sense to you. But, I will mention that lately, I use react-testing-library since it doesn’t let me access the component state and mess with it. I just test user perspective, not thinking about implementation details.

Tips and tricks

• Think about user perspective - as developers, we usually think about implementation, but this time we should think like users.
• Test application stability instead of implementation.
• Think about edge case scenarios since they are hard to catch.
• Do not mock everything - writing integration tests with mocked dependencies can be tricky. It could, again, lead to testing a happy path scenario.
• Write render tests for small components to ensure the component is not broken.
• Write unit tests for standalone components and helper functions that you don’t expect to change very often and want to be sure they are not broken accidentally.

Test component behavior based on props passed to it. Be sure props are used as requested and the user will see the correct output.

• Write integration tests for a set of components to test the business logic.

This is usually done for higher-order components, lists, and components that have some external dependencies, like buttons that will trigger data fetching, show loader, and then load data.

• When mocking service response, think about undefined or empty data.
• Create a mock folder with all the data from API calls that you need for tests. That way you can easily find and import any mock data. If some API response changes, you can change the mock in a single place and run tests again.
• Once a bug is found, make sure you write the test so it’s not repeated.

In the end, I find that the QA team is really important and helpful since they are responsible for writing end-2-end tests to test the whole application flow. That means they catch everything that the developer missed to test.

Software engineer with 7 years of professional experience

Almina's strong suit is Android and JavaScript development, using ReactJS and the latest versions of other popular JS libraries. She’s recently been focusing on full-stack development and has been involved in all stages of software development including analysis, architecture design, implementation, and testing, working closely with clients to bring the best of technologies and solutions to each project.

Almina Haskic

Visit the company profile.

Jasmina’s story is a true example of how self-discipline and commitment can forge a great career path. During a decade and a half in the industry, Jasmina has managed to find new challenges, explore new areas and domains, and expand personal boundaries — from starting as a testing trainee, over the first lead roles, to today’s position as a Service Delivery Manager in our development center in Skopje. Moderate, at first sight, Jasmina leaves an impression that she manages to do everything with incredible ease. From her daily routine — starting with a continental breakfast and making sure the kids are up and running — to daily team meetings. She follows the “light approach” to facilitate the process of “bringing value while getting the job done.”

Living the Agile Adaptability and Focusing on the Essence

“Being able to adapt is crucial, as things don’t always go according to plan, both at work and in private life,” Jasmina explains as she dives into the methodology that shaped her career path. "The agile context allows you to adapt to all circumstances against encountered changes. Whether we focus on the essence or the form, it is up to us,” she adds. For that reason, Jasmina tends to favor a joint effort approach, where all team members share the same feeling that the team works and delivers value as a whole. “We might have a different star in each sprint, but the whole success is a real team effort.” Along with all the practical advantages, this is the charm she finds in the agile contexts.

“It is the same with our culture,” she adds. In general, “Symphony creates an enabling environment where everyone can speak up, and where clients accept and recognize our ideas and thoughts. As real partners, we bring essence and value to clients, and they encourage our improvement and creativity.” “Such cooperation allows a more significant involvement of all team members, resulting in the shared feeling that we equally contribute to shaping the product. For every new requirement, the entire team gathers, brainstorms, and discusses how we can address this new requirement. By putting ideas into practice, we determine whether the projected outcome can be more effective or the path more accessible. Our team is long past the individual egos, and we love that. I have been a part of the Symphony community for over a year now, and from day one, it was only natural that everyone contributes towards a successful joint delivery, and that’s the beauty of my current team and the entire Symphony community.” She explains how the team adapts and focuses on the problem’s essence rather than the form itself — from brainstorming to final delivery phases. The agile philosophy is based on open and transparent communication, similar to the transparency culture we nurture at Symphony.

Healthy and Positive Environment Enables Successful Delivery

Being a part of the team instead of just working in a group of people is the foundation for every success. “I always tend to adapt to a team's dynamic, and my experience probably makes it easier.” A healthy environment stimulates growth, and there is always space for improvement. Previously, Jasmina assumed the roles of a Test Lead, Project Lead, and Project Manager, in all of which her technical background was one of the greatest assets. Still, she always strives to work on her soft skills, as her role involves communication and cooperation with various stakeholders.

“I love Symphony's supportive approach, open-mindedness, and culture of continuous learning and development. Compared to my previous experiences, I feel more heard and stimulated to act through many joint activities with colleagues in service delivery and the entire community. Such dedicated career development creates an environment that stimulates growth. Even my March IT Up experience was an exceptional (and a bit stressful) milestone. A perfectionist strives to deliver the best presentation, and the Symphony community is always there to provide support.”

Always Test the Assumptions

“My development path has taught me to ask, test, and improve.” Throughout the years, Jasmina has been part of what local stereotypes may call a minority — first by attending a technical high school where only 10% of students were females and then pursuing a career in engineering after obtaining a degree in electronics and telecommunications. Her professional life has only confirmed the focus on the skills. There is no room for testing any stereotypes in the software industry; the only tests are the challenges we set for ourselves. Jasmina’s decision to join Symphony’s community has also tested her capability to adapt to a different setting, as she was looking for a new challenge after 13 years and three lead roles. Her decision was based on Symphony’s detailed and skills-focused recruitment process.

In retrospect, after almost 15 years in the industry, the drive for improvement and life-long learning nature were the main motivating factors for Jasmina’s role shifts. “Every project, every position (even in the same domain), brings new development areas and enables you to feel useful and see that your work brings value and benefit. Repetitive processes and reporting are not boring tasks for me; on the contrary, being organized and analytical allows me to find creativity in each step of the work.”

“One of the most important lessons I have learned from my QA days is to always think about the bigger picture, set the scenario (before testing), and visualize the expected results. Even nowadays, I especially enjoy the QA aspects of each deployment. And (secretly) I always cheer for the QA engineers in the team! It all comes down to a good concept: planning, organizing, delivering, but with detailed scenarios and vision,” she continues. “Creating detailed concepts against given challenges and making a plan for delivering solutions is probably my go-to creativity trick.”

Visit the company profile.

This is the story of Anida Mumic - a Service Delivery Manager at Symphony who goes by the nickname "Sunshine." In this blog, you will learn how she went from getting her first internship to leading a cross-functional team of more than thirty people. Keep reading because this is a story about motivation, persistence, and drive to go forward!

Throughout the journey we are about to tell, Anida has encountered many opportunities and challenges. Years later, she looks back and shares the first career lesson that got her to where she is today: "Do opportunities exist? The answer is yes - you have to reach out and grab them. It doesn't matter how big or small they are. Focus your energy on the fact that they exist!"

We asked Anida to start from the beginning. She leaned back and began her story. "I graduated in the field of Telecommunications and received a working internship right after the University. The first year of my prospective career looked very much like this - I spent most of my days on the field, driving through different cities to solve problems that included fixing wires in clients' attics or basements. I remember I'd put on my Converse Superstars with some casual attire and hit the road! I was no stranger to coming home with some cobweb in my hair. But I never had an issue with this - even though I was an engineer, I had this constant need to learn things from their core - even when that meant starting from scratch covered in cobweb".

The vast world of Project Management

Very soon, Anida realized that her learning path had to expand. We asked her what her next steps were with this realization? "Well, in my usual free spirit, I started looking for job opportunities - and this is how I discovered the vast world of Project Management. The scary thought that kept me awake for four nights was that, with this decision, I am distancing myself from engineering and going into a new career direction.”

As she started diving deeper into this topic, Anida realized that this is where she found herself and her true potential. "In my earliest encounters with Project Management, I tried to optimize processes while leading teams - and I understood how important this is. But it is also important to remember that the projects you lead come first! As Project Managers, we often need to implement innovative approaches to processes that produce the best output and meet project needs. Once I understood the power of thinking outside the box - I was ready to make an impact."

After getting her PMI certification, Anida re-entered the IT business as a Project Manager and worked on global projects where she led teams based in ten different time zones at a time. Such a career jump required dedication, and we were curious what it took for her. "This type of commitment needed some around-the-clock work, but it was essential for me at that moment to make changes. Changes that were presented as knowledge-sharing lessons throughout the globe and made the whole experience even more worthwhile.

Leading cross-functional teams within Symphony

Next stop in Anida’s career: Symphony! As our first newcomer during the pandemic, she entered the Symphony community on April 1st, 2020. "Remote onboarding sounds scary, but the effort made from the very first day was extraordinary, and it did not take long to feel how much I belonged here. Accordingly, a positive challenge I faced was creating a stronger bond among people.”

"As a Service Delivery Manager, the easiest thing to say is that the client asked for something. However, in this new environment encountered within Symphony, I worked with my team to constantly discover requirements and develop solutions. As a part of our mutual collaboration, I always reached out to my team for ideas to improve the overall results. When it comes to the technical aspects of leading a team of thirty people, my goal was to inspire change from within. This approach may be slower and more stable, but one year later - my team knows that this is their success, and they are proud to stand behind it".

With her new role at Symphony, the first thing Anida did was change the team setup. "We created three small cross-functional teams in which QA, Backend, and Frontend Engineers are part of one team. The teams are constant, and there is no shuffling from release to release, which brings more stability. We were delighted that we have established feature-based teams - which means that one team grooms a feature from the beginning and delivers it to the end. Another purposeful change we implemented was modifying processes and manual testing ownership, which raised the automation framework to almost 200 test cases and improved code quality overall.”

Besides introducing technical improvements, Anida makes sure to focus on every individual in her team. "As long as we have a common goal - I will do everything I can to help you reach your part of the goal. Whether it is a technology change (transition to full-stack or learning new technologies), or improving your communication and other soft skills - I will do anything that will make you feel better about your work!"

In a year, Anida and her team achieved outstanding results for the client. We asked what kind of motivation and drive it took to get there. "I have a mantra: every day, you can accomplish something. Even if your day was not spectacular - as long as you know you learned something from it, you will do better next time - I promise the result will set you always to go forward!

If Anida inspired you to reach out to Symphony and experience our community with fantastic opportunities, make sure to check out our Service Delivery Manager open position. We are excited to meet you!

Visit the company profile.

It's time to meet Anja Andric, a QA Engineer from our Belgrade development center! Besides the unmistakable fashion style and positive energy, Anja is famous for her constant desire to learn and grow. Before joining Symphony, she spent the first three years of her career solving problems and searching for why something is not working. "But, one day, I stopped and realized that while analyzing issues and bugs, I had found a new career path. That's precisely when I realized I should change the purpose of my programming and switch to automation testing," Anja started her story.

Experiment to find what you love the most – Journey from automation to manual testing

While upgrading her technical skills, Anja started working more closely with the clients. That opened a new perspective in her career, so she soon became a Technical Product Owner and spent two years working in an Agile team.

Anja explained in more detail: "To better understand automation, I had to better understand client requirements and deep dive into the implementation, which gave me a product owner perspective. That way, I had an opportunity to approach the problem from several sides, keeping in mind the job aspects of software and QA engineers."

Even though experimenting with roles helped broaden her perspective and scope, enabling her to progress rapidly, Anja returned to what she loved the most – QA.

Symphony's selection process: How I learned from it

"I was fascinated by my technical interview, as I didn't expect to learn from it but to be questioned. However, the discussion with my interviewer gave me a completely different perspective on things I was doing in the past and helped me realize that there is a whole new world in Quality Assurance I could grasp."

That was when Anja chose Symphony as her new destination and challenged herself by doing something she has never done before. Her team had supported her, and Symphony trusted her knowledge and previous experience, giving her space to learn, make mistakes, and do what was best for the team and the project. The key expectation was transparency and dedication, and everything else was part of the process and the joint journey.

"The company's attitude motivated me to do something I thought I would never do - manual testing besides automation. My team supported me, the company had my back, so I stopped thinking about how I am doing things and the tools I am using. Instead, I focused on better product delivery in each sprint. Also, not only have I upgraded my technical knowledge, but I also have an opportunity to work closely with clients and have a touch with the business side of the story."

Looking from this position in her life and career, Anja shared what she learned about Quality Assurance from her previous experience.

Understanding the QA role – What it takes to bring value

"To be a sound QA Engineer, you should be systematic. To be systematic, you need to be patient. There are no quick wins in Quality Assurance, and, of course, there are no tools and methods that can teach you to be analytical. A person should work on their testing skills each day and develop the mindset needed," Anja explained and continued: "QA is a quality assurance of the application - not ourselves. Sometimes it means that you will have to sit and write ten automated tests in three days, sit with software engineers and read things from tables, or sit with product owners and analyze each possible situation that the user can do. In the end, your only goal is to provide value by providing a quality product. Once you understand your role, you will realize your capacity for technical upgrades and learn to be better in everything you do."

"That should be your focus and not the tool you are going to use. To achieve all of that, you should pay attention to the quality of code, UI, usability - your app should be user-friendly, and still, you need to meet business requirements at the same time and think about what is essential for our users." Anja concluded with a smile.

Here in the Belgrade development center, we have a community of 9 excellent QA Engineers working together and helping each other develop all the necessary skills for their job. Will you be the 10th? There's always an opportunity to join our team in Belgrade, so check out our openings here.

Visit the company profile.