Portfolio

Marcelo Costa

Unsplashed background img 1

QA Automation Engineer


personal-picture

Hi!

I'm a QA tester in which I have been working for the last 5 years in companies like Cognizant (for S Project) and EA as a manual and automation tester. I have been working with many test scenarios, mainly with iOS and validating test outputs through blackbox testing. I've also done regression, smoke test, user acceptance and UI testing.

Also acted as the Team Lead for my locale (pt-BR) in which I trained and formed 3 people in the team, always providing constant feedback. In my QA role at the S project, I tested the specific AI and fixed pipeline issues of the 23 localised languages that the product supports. In automation I've mainly worked with Swift language, with Xcode (IDE) in a framework designed by my client.

My project also includes Git commands, in which we add new fixes through a CI/CD environment and understanding Machine Learning: Natural Languge (NLP), Speech Recognition (ASR), Flow, Dialog and Text to Speech.




My Programming Languages

Unsplashed background img 2

laptop

Python

code

JavaScript

data_object

Swift

developer_mode

Ruby

adb

Gherkin

data_array

Cucumber

terminal

HTML and CSS

Three pillars of a QA

Unsplashed background img 2

zoom_in

Attention to detail

As in every project that I work, I have great attention to detail in order to identify even the smallest defects in a product. This includes being able to carefully review and test every aspect of the product to ensure that it meets the required specifications and standards.

developer_mode

Problem-solving skills

In order to be a good professional in this area, it's essential to be able to troubleshoot problems and find creative solutions to issues that may arise during the testing process. This requires strong analytical skills and the ability to think critically.

call

Communication skills

The best QA is the one that communicates effectively with different teams and stakeholders, including developers, project managers, and customers. This may involve writing detailed bug reports, giving presentations, or providing feedback and recommendations.

Test Fundamentals

Unsplashed background img 2


Why is the test pyramid a pyramid?


The test pyramid is a visual metaphor that represents the recommended balance between different types of tests in an application. It is called a "pyramid" because the base of the pyramid represents the tests that should be the most numerous, while the top of the pyramid represents the tests that should be the least numerous. The idea behind the test pyramid is that you should have a large number of low-level unit tests, a smaller number of integration tests, and an even smaller number of end-to-end (E2E) tests. This is represented by the shape of the pyramid, with unit tests at the bottom (the widest part), integration tests in the middle, and E2E tests at the top (the narrowest part). The rationale behind this recommendation is that unit tests are typically faster and easier to write than integration or E2E tests, and they provide a solid foundation for testing the individual units or components of an application. Integration tests come next and provide a way to test how different units or components work together. Finally, E2E tests are the most expensive and time-consuming to write, but they provide the highest level of confidence that the application is working as expected in a real-world scenario.



Does the Software Development Life Cycle (SDLC) end?


The Software Development Life Cycle (SDLC) does not necessarily end, as software often requires ongoing maintenance and updates even after it has been deployed. However, the formal SDLC process may be considered complete once the software has been deployed and is in use by the intended audience. After the software has been deployed, it may enter a phase of maintenance and support, during which bugs are fixed, updates are made, and new features are added. This maintenance phase may continue indefinitely, as long as the software is being used and supported. In some cases, the software may reach the end of its useful life and be retired, at which point the SDLC process may be considered fully complete. However, in many cases, software is continuously updated and maintained, and the SDLC process may continue in some form even after the initial release of the software.




How to prevent bugs into production


Write clean, well-structured code: This can help to reduce the likelihood of bugs occurring in the first place.

Use a version control system: This will allow you to track changes to your code and easily revert to a previous version if a bug is introduced.

Use automated testing: Automated testing can help to catch bugs before they make it into production.

Review code changes: Having other developers review your code changes can help to catch bugs that may have been missed during testing.

Use error logging and monitoring: Tools such as error logs and application performance monitoring can help to identify and fix bugs that may occur in production.

Implement a robust QA process: A thorough quality assurance (QA) process can help to catch bugs before they make it into production.

While it is not possible to completely eliminate the risk of bugs occurring in production, following these best practices can help to minimize the likelihood of bugs occurring and make it easier to identify and fix them when they do occur.



Thanks for the visit! ☺

Feel free to send me an e-mail or connect with me in any social media on top.

Marcelo Costa