Игорь последние 7 лет занимается тестированием программного обеспечения и повышением качества. Начал свой путь в тестировании с веб приложений банковских систем. Затем вел бои за качество десктопных и браузерных расширений в компании AVG (Antivirus) и мобильного приложения в компании Gett (Gettaxi). Успел побывать в роли главы отдела тестирования в франко-израильского стартапа SweetInn. Сегодня Игорь является старшим инженером по обеспечению качества в компании Moovit (Израиль).
Как настоящий страстный фанат тестирования и качества, он увлекается исследованием методологий SQA, инноватор и архитектор тестовых решений. Игорь является чемпионом Израиля по тестированию программного обеспечения 2018-го года. Активист TestIL, крупнейшего сообщества тестирования в Израиле. Международный спикер и блогер (https://www.iggmaster.com/)
Agile: Quality Clean-Up in Development
Did you find yourself in a new company that switched to Agile? Or did your place of work decide to take up “agile development” and now you are part of the Scrum Team? And now you are the main on testing in the team, as the only tester. And most importantly, after implementing Agile, you test even more, but still, the quality of the product is not very good? And the manager, thinks to bring another tester to help you? But the quality of the issued product is still "not very good." What to do? Test even more and faster? But how? You are one, and there are many of them (developers). The short answer is to forget about testing and really tackle quality. How? I will talk about this in my talk.
Software QA Engineer Dreams. Automate everything!
With the existing dynamics in the "Agile" teams, the QA engineer faces many challenges. Most of which he would like to solve using automation tools. Fast feedback on the local version, effective setup of the test environment is only the beginning of the possible use of automation in testing and QA processes. QA engineers have long been dreaming of more! About what? I will tell you about this in my report.
Mission Impossible: QA Estimation Failed
Let's discuss the whole truth about Estimation (calculation of time) for the QA process in Agile. Here is how you can calculate how much time will be spent for analysis and testing (planning, writing, executing) when the business requirement may change or the technical solution is not yet fully thought out or something that will go wrong. Agile assumes be ready for the flexibility to change, how can you calculate the time for it for earlier? The team of the hero of my report also encountered this complex reality, but any impossible missions can be possible. How? I will tell you about it in my talk.
The true power of the tester is information
Big feature - small sprint
During last two years I've been working in Agile teams and quite often have come across the situation when the feature is pretty big, but they still want to release it at the end of the sprint. That is in spite of the fact, that there is a great risk of violation of the timing and poor product quality.
So what should we, quality guards, do when eventually everything depends on us?My report presents the analysis of the development stages from the testing point of view in such a difficult situation and provides tips for success.