We are looking for an experienced Server-side QA Engineer, to join our growing testing team . The job includes deep-testing of a Complex financial service and its corresponding application. The work is a combination of analyzing large log files to verify processing correctness, and testing a complex UI application.
Desired Skills & Experience
— At least 5 years experience of QA, of which at least 2 years as server-side QA
— Familiar with the following technologies : SQL, Linux/Unix, regular expressions
— Bug detection abilities and good analysis to root cause detection
— Financial background : Forex, equities, trading, algo trading
— Experience in writing automation tests for applications in unix and windows environments
— Experience with scripting languages — python, bash, perl, php or equivalent
— B.SC in Computer Sofware or equivalent
Fluent is an exclusive global boutique fintech software firm l that provides the world’s largest global banks and hedge funds with state-of-the-art technology. Fluent is comprised of highly talented senior software engineers who have built and maintain Fluent’s proprietary revolutionary and disruptive technology.
Please visit us at www.fluenttech.net
Responsibilities will include:
— Digging the system for missing requirements
— Going over specifications documents thoroughly to find special cases and scenarios
— Doing full coverage for Configuration files to find problematic values and combinations
— Becoming the house-expert of the application.
— Be a part of rapid testing cycles to deliver high quality products
A day in the life of a Fluent QA engineer
The QA is told he has a new version waiting for him (her). he gets a revision number and a few Jira tickets that were supposed to be resolved.
The QA then pulls the version from the SVN onto his testing environment, and compiles it (it’s a C++ code of an engine system). He configures all the environment‘s parts (using vi editor) according to what is needed for this version:
● Simulator and it’s data
● Liquidity source’s (i.e. the bank’s) test account
● The examined product which he just compiled, and it’s configuration
● test databases
● test clients, to drive the test
● adjacent processes, e.g. GUI, Risk engine etc.
● Connections between all the above
● Logs as required
The QA then runs test according to his testing plan. Some of these tests are manual but most of the time it’s a script. The QA needs to understand the script and be able to edit and manipulate it.
The QA looks at the monitor GUI, and notices that although the application seems to function viably, the data does not make financial sense (i.e. he needs to know enough about trading to understand that “this can’t be right...” )
he then digs into the logs (which are in FIX format, so he needs to learn to read it, and search it with regular expressions in Linux), and finds out that the Bank’s testing environment sent some messages that were not according to the bank’s own spec (i.e. he needs to be able to read a protocol’s spec). He informs the IT dept. to speak to the bank about it.
He then continues to dig, realizing that the engine reacted to the bad input in a way that doesn’t make business sense to a trader. There is nothing in the requirements about this kind of wrong input, and yet...
After consulting with a developer, he finds out that there is an undocumented configuration option that could have caused the engine to react better. He tries it, and then informs DevOps and TechWriter about it. And adds it to the knowledge base.
Meanwhile, he tries to configure the simulator so he can advance until the bank fixes their bug.
Please specify in email’s subject: your full name in English and position for which you’re applying.