1. Can you tell me a little bit about yourself – two interesting things that people don’t know about you?
My name is Oren Rubin. I am the CEO & Founder of Testim.io. In the last 20 years I have been doing a lot of tech especially on the R&D and engineering side. After my graduation I started working at IBM as a distributed computing engineer. I worked on compilers at Cadence for a while. It was a language for hardware verification. It was my first step to the testing domain. After Cadence I got into the flash-based company called Wix who tried to move away from flash to HTML5. I was a web architect there. That’s where it hit me to think about software testing. There were so many unsolved things that could be improved. It was still nowhere to find information regarding software testing. Testing is so hard, people underestimate how hard it is, it is so not trivial.
There are some things people don’t know about me:
- I am a Bughouse chess player. That’s my fetish.
- I still play the guitar every day. I have the guitar next to the computer stand.
2. Can you tell us a little about your Organization? How are you different and what makes you great?
Everyone comes from this domain. We have people that actually worked on creating software tools: 2 guys came from HP. The nice thing is our people came from different areas – machine learning, hardware verification, general software. We try to solve difficult situations using different ways and not traditional ones.
We have three things people like:
- It is super interesting to build something that never being tried before.
- Building something that you would use yourself.
- Have fun. For example, one of the interviews is going with the team to a pub. We grew into it and it is working very well.
Going to every meet-up, talking about what you do. This is the nice part when you hear: “It’s amazing. Can I come to work with you?”
3. Let’s assume I am not using the system today. What are the things that I am missing?
First, We want to minimize the flakey tests – false positive cases when a test is failing because the application has been changed. That was the lead cause of what we are trying to do.
The second thing is helpful work – communication when there are three different tools working together.
We take challenges and we are trying to solve them. We try to find the best way for companies’ QA teams and developers.
We need to make sure that the changes made in the app will change the test itself. That’s why we started from machine learning, observing UI.
The reason why you have to have automation today is if you want to deploy the system many times, you can’t just do manual testing. The knowledge (of what to test) will be always on the hands of the QA.
4. Ecosystem in 3-5 years . What will be different? How will development/ testing evolve ?
Five years is actually kinda futuristic, many cool things can happen in 5 years. I believe it could be different flows that connect – more test-driven development (TDD), more testing on the start in development and design, defining what can be tested.
It will be more sharing knowledge across different units: QA, design, product, DevOps. Everybody will be talking the same technical language using the same tool.
The thing we solved accidentally was Record/Playback. 20 years people have tried to solve this and failed.
We try to have more and more case studies that show that it now works. I recommend to everyone starting their new product always start from day zero with design partners and real customers – this is the way to success.