Этот дайджест создан совместно с телеграм-каналом QA Live ? тестирование ПО. Подпишитесь, чтобы получать дайджесты прямо в телеграм!
? Почитать:
«Нестабильные тесты всегда были и будут. Раз уж они существуют, мы должны научиться работать с ними.» Опыт QA-команды Slack.
Краткий рассказ о двенадцати языках программирования, их особенностях и подводных камнях.
На других русскоязычных платформах:
Как-то раз к нам пришли с прома со следующей ошибкой: «Наименование ЮЛ имеет лимит 140 символов в теге <имя>». Начали разбираться, выяснилось, что одна из наших систем принимает названия юрлица не длиннее 140 символов. Это очень старая настройка, просто за полгода работы с момента релиза никто не регистрировал такие названия, как: «Местная Религиозная Организация Православный Приход Троице-Сергиева Храма, Подворья Заволжского Мужского Монастыря в Честь Честного и Животворящего Креста Господня г.о. Самара Самарской Епархии Русской Православной Церкви (Московский Патриархат)»
Хоть и немногие в это верят, QA всегда было отдельной специальностью: этот безусловный факт только подтверждается с годами. Даже самые лучшие разработчики не способны тестировать – они или забывают про критические сценарии, или оставляют интеграционное тестирование тестировщикам. QA – неотъемлемое требование для продукта, оно поддерживает все процессы и борется за качество. Во всем мире QA специализировано, и дабы это доказать, посмотрим, сколько проблем вызовет проверка, что чатбот хорошо работает: это требует глубокого понимания работы чатбота, его внутренней кухни, инструментария, алгоритмов, а также генерации сценариев, чтобы все это проверить.
В обязанности QA инженера входит локализация дефекта — процесс, направленный на анализ проблемы, с целью максимально‑возможной детализации причины ее возникновения. Чем больше информации о проблеме — тем быстрее ее решит команда. Ни в коем случае не стоит перекладывать эту работу на разработчика или аналитика. Обращение к команде идет только после анализа проблемы со стороны тестировщика.
При автоматизации нагрузочных тестов специалисты рано или поздно приходят к мысли о том, как сравнивать результаты проводимых тестов. И не только сравнивать, но и демонстрировать результаты команде и бизнесу. Часто сравнение результатов нагрузочных тестов напоминает игру «найди 10 отличий» на почти одинаковых картинках. И если для специалистов в тестировании производительности это не проблема, то для коллег, не погруженных в теорию, это может стать таковой. Тут необходим какой-то простой и наглядный индикатор, который легко позволит определить — показатели стали лучше или хуже в процессе работы над проектом.
«Работаю тестировщиком в «Афише» и наставником на курсе «Инженер по тестированию» в Яндекс Практикуме. Много лет назад я попал в тестирование без каких-либо курсов и практикуясь самостоятельно — и с этим я собираюсь помочь и вам.»
Для того, чтобы убрать препоны между бизнесом, DEV, OPS, SEC, QA и обеспечить прозрачность процессов можно разрабатывать свою автоматизацию для Jira, либо использовать инструменты от сторонних разработчиков.
Есть, как минимум, 3 способа, с помощью которых можно получить логи при краше приложения: По USB из Android Studio.; По USB через утилиту adb.; Через приложение Crash Log Viewer — Show App Cr.
В мире QA на других платформах (англоязычных):
The concept of “internal-facing engineering” generally in the tech industry can encompass an exceptionally broad range of roles. In this article I’m focusing on Developer Experience (DevX) engineers who provide platforms and tools to accelerate engineering teams and Quality Assurance (QA) engineers who play a pivotal role in ensuring software quality during the development of new features.
Understand the Business, Be a Problem Solver, Always keep an open mind and be willing to learn new things, etc.
“We, developers build stuff, QAs build nothing”, “I hate QAs and PMs”, “Why are QAs so annoying?”, “Anyone can be a QA”… and the list continues, although maybe I agree with the PMs stuff (just kidding). By the way, I am not offended, or at least not anymore. The truth is the QA Engineer position, or how a developer one day minimized to me to just “Tester”, tends to be underrated in some companies, especially when developers spend a significant amount of time building a feature or implementing a fix or improvement and it only takes a “few” minutes to be validated, let’s be real here, sometimes that could happen, however, I think most of the reason a team member minimize the QA work is because of the following reasons:
When you come across the terms ‘Software Quality Assurance’ or ‘Application Tester’, what immediately comes to mind is probably someone who is responsible for ensuring there are no bugs in an application. While this is true, but have you ever wondered about the ins and outs of their goals? What specific targets do they need to achieve? How they measure it?
How do you manage the expectations of others in a similar situation when you need, or feel you need, hours of time to investigate and report on it but others feel that the thing will be in production in 2 hours?
The Cupcake Antipattern: The Cupcake antipattern occurs when tests are duplicated across multiple layers, leading to disorganization and inefficiency. This can result in longer release cycles, blame games, and redundant efforts.
This article delves into the transformative journey of empowering diverse teams with open-source tools and knowledge to seamlessly integrate test automation into their workflows. From breaking down technical barriers to fostering collaboration, this article explores the multifaceted impact of democratization of test automation. We will see how efficiency, reliability and innovation work hand-in-hand within the realm of software testing in ING. So read along with me as we unravel the dynamics of this paradigm shifting revolution, where quality assurance meets excellence.
Martin Fowler, in his article, distinguishes two main types of unit tests: solitary tests and sociable tests. He describes solitary tests as those that test a unit of code in isolation, usually using mocks to simulate interactions with other parts of the system. On the other hand, sociable tests are those that allow the unit of code under test to interact with real implementations of its dependencies.
The problem with mocks is that the test needs to know how a dependency gets called, in order to mock calls. This leads to coupling between the test and the code, something we’d like to avoid, as changes to implementation details may require to changes in the test. Testing is hard. Mocks are not the only way to make tests more coupled, and therefore more fragile. Let’s talk about that, but first, a moment of distinction.
Scalable and simple way to test your jobs, services or applications via data generation and validation.
How did we end up with this 1:1 relationship between tests/classes? It is easy and obvious. Orientating around behaviour necessitates deeper insight and deliberation, similar to packaging code by concern as opposed to type does. It’s easy to throw all views one package, but much harder to group them by their rate of change (cohesion).
JUnit, TestNG, Cucumber, Allure, Mocha.
I am a developer QA and I spend a lot of time fiddling with selectors to exactly select the element I want. I created automize which is a completely free chrome extension that will automatically create the best* selector for you or in the event it’s not the best, you can pick and choose the way you want it selected. It will automatically export the selector to whatever language you need ex: cypress, playwright, selenium, puppeteer, javascript, xpath, css. It has some additional features such as network stubbing and a small script runner. It recently launched and I’m really looking for feedback.
Questions of that nature might reasonable if the interviewer’s goal is to hire a Java programmer, and to sift out the novices from the veterans. They might be reasonable if the intereviewer wants a toolsmith — someone is going to write Java code to support testers. But such questions are very poor ways to assess testing skills. If you’re a tester, beware of them; your prospective employer may be have a trivialized model of testers and testing work. The interview question may be revealing that you won’t be a good fit if you’re ambitious to test software.
Many people have asked for an AI to help them with “edge” testing. Edge test cases try inputs or actions that are uncommon — that are ‘on the edge’ of expectations. Edge tests push the limits of expected user behavior, and test things that the developers likely hadn’t even thought of during design and implementation — or their own testing.
Testability. What Our Tests Don’t Like About Our Code
We show how a piece of code evolves as we write tests for it. Tests don’t just check correctness; they push us toward code with less coupling and more cohesion.
? Посмотреть:
Как использовать Dev Tools (Network tab) для анализа бага. Посмотрим на запросы (request) и ответы (response) и разберем, какая информация может быть полезна для анализа.
- Should we just automate everything? The RPT formula (en) ⏱50 минут
If test automation is the solution to all our problems, shouldn’t we just automatate everything and get it over with? In this episode, we discuss whether automation really is the be-all and end-all remedy to all QA challenges we may encounter. You will learn a simple formula allowing you to assess whether a given test type is a good fit for automation, what kind of overhead automation actually adds to the project as a byproduct and how to distinguish what can be automated from what should be automated.
- Собеседование QA в ГосУслуги ⏱30 минут
В данном ролике проводится мое собеседование на позицию тестировщика в одну из крупнейших российских компаний – ГосУслуги.
Jira, Confluence, Zephyr Scale, Insomnia, Postman.
Как мы внедрили автоматизацию тестирования в компании без автоматизаторов. Ранее у нас были только manual QA, но мы решили автоматизировать тестирование и начали работать над этим вместе с разработчиками. В процессе мы научились выбирать подходящий масштаб автотестов, обучать manual QA и использовать автоматизацию для повышения эффективности разработки и обеспечения высокого качества продукта. Я расскажу, сколько времени ушло на проект, как мы изменяли процесс разработки, и как мы передали автоматизацию в руки тестировщиков. Этот доклад будет полезен для команд, которые хотят начать автоматизацию тестирования, но не имеют автоматизаторов в своей команде.
- Опыт Contract Testing (PACT) в Viber ⏱50 минут
Многие команды сталкивались с тестированием приложений, которые имеют зависимости от других сервисов. В своем докладе я расскажу, как можно тестировать такие интеграции без QA и быть уверенными, что коммуникация со сторонними API работает.
«Я уволился в никуда неделю назад. Полтора года без отпуска в QA в качестве SDET (автотестером). Провалены все планы. И в этом виноват только я.»
Хорошей недели!
