Equal Experts Geek Conference 2023

Hey guys, 4 months ago I had a 5 minutes lightning talk about How the QA will look like in the future at the Equal Experts Conference.

We went through the evolution of the role and how it is right now, then we quickly talk about the trends that are coming so you can already prepare yourself to be up to date 🙂


In this 5-minute talk, we will quickly talk about the future of Quality Assurance (QA) position and discuss the evolution of the QA role in response to emerging trends.

The QA role has come a long way from its traditional focus on manual testing and bug detection. As technology advances, QA professionals are adapting to new demands and becoming integral contributors to the software development process.

The  future of QA position will be marked by AI Tests,  Tests in the Cloud, Web3 Tests, Alerting and Monitoring, along with strong soft skills. By embracing these trends and developing the necessary skills, QA professionals will be well-equipped to drive quality and innovation in the ever-changing software development industry.

Brazilian QA’s around the world series – Walmyr Lima

Walmyr Lima is software engineer who loves testing. He is also a clean coder, blogger, YouTuber,

online instructor, mentor, speaker, an active member of the testing automation and JavaScript communities, and a fan of good music, tattoos, vegan food, and skateboarding.

Be sure to follow Walmyr on LinkedIn.

TL;DR;

Walmyr Lima’s decision to immigrate to Spain was sparked by their ability to understand and read Spanish content. They found a job opportunity at Typeform in Barcelona and relocated with the company’s assistance. Cultural differences were noticed, with Spanish people being warmer and the language being a significant change. Adapting to QA practices in Spain was not challenging for Walmyr as they had previous experience in a similar role. The perception and importance of quality assurance varied between companies rather than being country-specific. Walmyr discovered new methodologies and tools in their role as a Quality Assistant. Professionalism was deemed valuable regardless of the country. Work-life balance was generally seen as better in Europe compared to Brazil.

What were your reasons for choosing to immigrate to Spain? How did you prepare for finding a job and planning your move?

It was almost accidentally. My wife and I were actually planning moving to London, when one day, while preparing for a Live Stream on YouTube, I read a content in Spanish, which was related to the content I was going to present. I was able to read and understand everything, which made me think we (my wife and I) could live in Spain.

Then I searched for the coolest startups to work in Barcelona, since we would like to live close to the sea, and then I found Typeform. I applied for the job, went through the whole interview process, and got an offer (with relocation help and everything else). The rest is history.

What are some of the cultural differences you’ve encountered in the new workplace ? 

As a person who had been living in Europe for 6 years before moving to Spain, the main difference was cultural, since before that, I had lived in Norway and The Netherlands 😯. The Spanish people are more similar to Brazilians. They’re “warmer” ❤️. The language was a big difference too, and one of the main reasons for the move. In terms of workplace, nothing changed much, since I came to work remotely, which is something I was already used to before the move.

Are there any specific challenges you faced when adapting to the QA practices and standards in Spain? How did you overcome them? 

No really. I was hired to work as a Software Engineer Quality Assistant, which is something I was already used to do, but never had the exact title.

Have you noticed any variations in the perception or importance placed on quality assurance compared to Brazil? If so, in what ways? 

I think every country has companies that practice software engineering with excellence while others don’t care about it. That said, I don’t think the differences are related to the country you are in, but the company you choose to work for.

Are there any new unique methodologies or tools that you’ve come across that have improved your QA processes? 

Well, maybe yes. I mean, it was the first time I was hired as Quality Assistant, but the company was still discovering what such a role really meant.

We (the Quality Assistance team) were there to help teams become autonomous in terms of everything quality-related. We were helping them with their quality bottlenecsk, but for a short periods of time. After that, they should be able to “walk with the own legs”. We were also helping them with tooling (testing frameworks, visual regression testing, testing management systems, etc). Finally, we were helping the company to reduce cost, replacing paid SaaS for open-source alternatives.

Are there any specific lessons or skills you learned in Brazil that you find particularly valuable in Spain?

Again, I don’t think it’s a country thing. In my opinion, it’s all about professionalism. If you are a professional, we’re it independent of where you live.

Have you noticed any differences in the work-life balance or professional expectations ?

Yes, not only in Spain, but in Europe in general. My impression is that europeans care more about a good work-life balance than Brazilians, but it’s probably because they had more time to develop, their currencies are (usually) more valued than Brazilian Reais, and their economies have (in general) less inflation.

Thanks Walmyr for sharing your adventures around Europe, great insights and experiences 🚀

Web3 Test Series: Lewis Prescott

Lewis Prescott

QA Lead at Cera Care (one of Europe’s fastest-growing companies). He talks about Contract API Testing: 99 minute workshops with Ministry of Testing, on Testers Island Discs and many meetups.

He provides services on how to get started with API Contract Testing, Contract Testing for Microservices, End to End Testing, Acceptance Test Driven Development!

What are contract tests, and how do they differ from smart contract tests?

 Contract testing is a framework for testing integrations between two services, for example an API and a mobile app. The contract is defined by the mobile application who requests data, shares the request and expected response with the API service which verifies the implementation matches the expectations. Imagine when you start developing a feature that has frontend and backend components. They must communicate with each other perfectly, in happy path and negative scenarios. These details are usually detailed within some form of documentation, but who is verifying that both sides have implemented according to the documentation? That’s where contracts come in.

Smart contract tests are also focused on testing agreements with the terms between contracts written into code, but the difference is that the contract that is compared against to is a contract deployed to a Blockchain. Same concept as normal contract testing but this time focused on the decentralised applications (DApps) and blockchain ecosystems.

Why are contract tests important in software development, and how do they differ from smart contract tests in blockchain development? 

Contract tests offer the ability to scale integration tests by using mocks and act as unit level tests. Large applications with many integration points can be verified quickly and without significant maintenance of test environments. There is plenty of logic such as http codes, required fields and error contents which can be verified via contracts without the need for heavy duty integration environments.

Smart contracts are the backbone of decentralized applications (DApps) and business logic. They help ensure that the code deployed on a blockchain accurately represents the intended business logic, functions correctly in different scenarios, and is resistant to security vulnerabilities, specially given the irreversible and immutable nature of blockchain transactions.

What are some of the challenges developers face when writing contract tests versus smart contract tests?

Contract tests has a bit overhead on setup, with provisioning the broker to store the contracts. Deciding whether you want to self host or use a SaaS solution. As well as the process shift of teams changing how they go about testing integrations. Moving from the authors of the API service writing their own tests to the consumer such as the mobile app writing tests. Often when implementing contract tests you already have integration tests, so persuading people to duplicate the effort can be a hard sell as well.

Smart Contract tests same as the Contract tests are not straight forward when you are starting specially as you need to have special knowledge to setup test networks, wallets, and tools. Another important point is the costs associated when deploying and testing smart contracts, especially when running large-scale or repeated tests. On top of those there is the blockchain specific challenges and security.

How do contract tests and smart contract tests differ in terms of the tools and frameworks used to implement them?

Contract testing most commonly uses Pact & Pactflow which supports multiple languages and frameworks such as graphql. Offering matchers and the ability to compare results makes implementing contract testing much easier. Pactflow offers a SaaS solution to store contracts securely and additional features to visualise dependents.

Smart contract tests are often implemented using dedicated blockchain development tools and language such as Truffle, Hardhat, Solidity. These frameworks provide additional features like contract deployment management, fixture data handling, and integration with test networks. Tools like Ganache provide local blockchain test networks that developers can use to deploy and test smart contracts.

How do contract tests and smart contract tests differ in terms of their level of complexity and the skills required to write them?

Contract testing gets complicated when you need to setup different states before the tests can run, for example data needs to be available within the API in order to test the specific scenario. The key skill though required is good communication and collaboration. Due to the teams now relying on each other to deploy and make changes. It’s important to communicate effectively and support each other’s changes. Contract tests also live next to the code, requiring a decent level of programming skills and knowledge of the application under test.

Smart contracts tests need to consider factors such as consensus mechanisms, gas costs, and security vulnerabilities, blockchain network, deploying contracts, and handling transactions. Additionally, skills in testing blockchain-specific functionality, such as testing for gas usage optimization and handling different network environments, are essential for writing effective smart contract tests.

Thanks for the participation Lewis ! It is always a pleasure to learn from one of the biggest leaders in the area ! 🙌

Pros and Cons of Robotium

Hi guys, I am writing just a summary about Robotium, because maybe I will start to work with it. So, if you have any tips or suggestion, please feel free to comment here.

Robotium is a popular Android automation framework for testing native and hybrid Android apps using the black box method. Licensed under an Apache 2.0 license and first released in 2010.

To use Robotium, you need either the source code or apk file for the app, Eclipse for building a test project, ADT (Android Development Tools), SDK (Software Development Kit), JDK (Java Development Kit), and the Robotium.jar file.

Benefits:
• You can develop powerful test cases, with minimal knowledge of the application under test.
• Allows user to test more flexible and convenient for analyzing results.
• Robotium allows us to take screenshots anywhere in the test (both for Emulator and Device) and save it to device internal memory or SD Card or Emulator
• The framework handles multiple Android activities automatically.
• Minimal time needed to write solid test cases.
• Readability of test cases is greatly improved, compared to standard instrumentation tests.
• Test cases are more robust due to the run-time binding to GUI components.
• Blazing fast test case execution.
• Automatic timing and delays.

Limitations of Robotium:
• Tied to JUnit 3 Instrumentation on device.
• Tied to one app process.
• It can’t work with different Applications in on test – if your application call another one (like Camera) – Robotium can’t “see” it and press any buttons there.

Parallel tests:

I’ve found this API: https://github.com/square/spoon, but I believe that we can configure parallel tests with Jenkins too.

 

Thank you guys ! See you next week 🙂

 

Sources:

https://saucelabs.com/resources/articles/open-source-tools-robotium-android-appium

https://code.google.com/p/robotium/

https://www.linkedin.com/grp/post/3769150-5852687643892002817

http://blog.mobinius.com/robotium-best-testing-framework-for-android/