Как QA скажу, что действительно хорошо, правдиво описана тема Повезло, что с разработчиками у нас дружественная атмосфера, редко встречаются ситуации когда происходят конфликты из-за багов
Есть еще нагрузочное тестирование. И не всегда тестирование - это нажатие на кнопочки. Во-первых, не всегда будет webApp, а может быть commandLine (почти всегда будет так, используя cURL), может быть webSocker, gRPC и др. Я к тому, что тестировщик должен писать тестирующие скрипты (иерархия скриптов), переписывание на, допустим, Python (для этого необходимо знать язык) или js, допустим на Postman, ApiDog и др. И обязательно должна быть декларация. Например, CRUD для справочника. (На самом деле удаление для справочника не всегда подходит, то есть CRU). Это вставка POST, получение id, get - должны получить 200, update через PUT, get - должны получить 200 и новые значения. Удаление DELETE. Get - получение 404. А также листинг. Это как пример. И это надо все уметь прогать тестировщику. Не обязательно на гохе. На каком-либо языке, типа js И я еще не затронул нагрузочное тестирование. И мало его провести. Надо еще собрать статистику при разных условиях и проанализировать. А дело разработчика - это обеспечить то, что сервис выдержит 10k ps. Если не выдерживает, то надо что-то химичить в алгоритмах.
Программист может протестировать хороший и плохой случай теста только в том случае если они конкретно описаны, а по личному опыту бывало просто описание проблемы, без случаев теста и собственно сам придумай как затестить и быть уверенным
про почту плюс, пока работаю не в айти, но лет 15 назад усвоил, после прихода на работу сразу открываю почту и СРМ и читаю, бывают значительные изменения концепции, чаще всего неожиданно, и ты делаешь одно. а оказывается политика изменилась...
02:30 это не переоткрытие бага. Переоткрывают уже закрытый баг: т.е. когда баг был исправлен, и тестировщик проверил, что бага нет и закрыл баг. Но он через время опять появился. В данном случае баг не закрывался. Его просто вернут в Doing для фикса.
Спасибо. Интересно. Но создаётся ощущение, что вы тоже подверглись размытию понятий QA и QC. Тестирование - это Quality Control. А QA - это более общее понятие, включающее и QC и прочие методики достижения качества.
Приветствую. На 23 минуте шла речь о том что разработчик, в случае непонимания того, как должна работать фича идет к тестеру, но все же чаще разработчик идет к аналитику, так как проработкой требований занимался он, перевести с языка заказчика на человеческий-профессиональный сможет тоже он. Или же к дизайнеру, если вы фронтендер, потому что в компании может присутствовать строгая дизайн-система с четкими паттернами. Ну и в целом, не считайте своих тестеров обезьянками, которые тыкают по кнопкам, и они скорее всего не дадут вам повода разочароваться
Не зобов'язаний, звісно. Але це йому все одне потрібно - з'ясувати як на справді повинен працювати функціонал. А раз все одне дізнався, то чому не поділіться
Пошта, месенджер, і... саме головне Daily meeting 😂😂😂 Можна не до тестувальника йти чи відразу до замовника, якщо задачу не розумієш, а наприклад до ВА, вони як правило зі Scrum майстром і формують задачі в Jira чи Rally чи ще деінде 😂. Тому що якщо є тестувальник, то це повноцінна команда, а не тріо Мареничі, відповідно і BA є, і представник замовника, і TL, PL і т.д.
Странно, что ни слова про прекрасное мнение, что тестирование - это для тех, кто не сдюжил стать разработчиком) Постоянно встречаю, в т.ч. в описании разных курсов
До речі про тестування. Пане Нємчінський, сторінки з курсами рівня Start, які ви рекламуєте, відображаються через Ж. - тільки шапка, підвал та заголовки.
@@NemchinskyLive О! А тепер здається все норм. Браузер Firefox версії 126.0.1, ОС - Win 11. Можливо були якісь затупи з інтернет-з'єднанням, хоча проблеми помітив тільки з розділами про курси рівня Start.
В чём секрет хорошего тестировщика? Разработчик думает, как программист. Тестировщик думает, как идиот. На прошлой неделе тестер нашёл баг, что если пользователь кликает на кнопку с частотой быстрее 30 миллисекунд, то приложение останавливает работу, но UI продолжает показывать, что якобы работа продолжается. Как он об этом узнал? у него мышка с тройным кликом.
Выпуск айти новостей от 24.07 - ruclips.net/video/vG1E10W8gQQ/видео.htmlsi=29-O_Pl7p7-HQ0sR
Как QA скажу, что действительно хорошо, правдиво описана тема
Повезло, что с разработчиками у нас дружественная атмосфера, редко встречаются ситуации когда происходят конфликты из-за багов
Сергей и весь коллектив канала, традиционное спасибо за выпуск. Как всегда интересно и содержательно 👍👍👍
Это все еще Сергей Немчинский?
Нет, я Влад, а почему ты спрашиваешь?
да, 0:28
@@krivodeling7925 Так не у тебя же спрашиваю.
💯
Сергей, запишите про аналитиков еще пожалуйста: бизнес и системных (в отличии от DA, PA они все-таки ближе к Dev)
Есть еще нагрузочное тестирование.
И не всегда тестирование - это нажатие на кнопочки.
Во-первых, не всегда будет webApp, а может быть commandLine (почти всегда будет так, используя cURL), может быть webSocker, gRPC и др.
Я к тому, что тестировщик должен писать тестирующие скрипты (иерархия скриптов), переписывание на, допустим, Python (для этого необходимо знать язык) или js, допустим на Postman, ApiDog и др.
И обязательно должна быть декларация. Например, CRUD для справочника. (На самом деле удаление для справочника не всегда подходит, то есть CRU). Это вставка POST, получение id, get - должны получить 200, update через PUT, get - должны получить 200 и новые значения. Удаление DELETE. Get - получение 404. А также листинг. Это как пример. И это надо все уметь прогать тестировщику. Не обязательно на гохе. На каком-либо языке, типа js
И я еще не затронул нагрузочное тестирование. И мало его провести. Надо еще собрать статистику при разных условиях и проанализировать. А дело разработчика - это обеспечить то, что сервис выдержит 10k ps. Если не выдерживает, то надо что-то химичить в алгоритмах.
а кто проеверяет что вы сгенерировали 10k ps? Ведь если вы сгенерировали 9k и все ок, то вопрос к тому кто проводил нагрузочное тестирование?
@@Devishhike Надо оставлять скрипты в readme
Коммент для продвижения от тестировщика 😃👍
В какой стране вы работаете?)
@@LeeoNas В той же, что и автор канала)
Программист может протестировать хороший и плохой случай теста только в том случае если они конкретно описаны, а по личному опыту бывало просто описание проблемы, без случаев теста и собственно сам придумай как затестить и быть уверенным
про почту плюс, пока работаю не в айти, но лет 15 назад усвоил, после прихода на работу сразу открываю почту и СРМ и читаю, бывают значительные изменения концепции, чаще всего неожиданно, и ты делаешь одно. а оказывается политика изменилась...
Отличный образовательный выпуск!
Как же вовремя Немчинский с видосом залетел, а то еда почти кончилась
02:30 это не переоткрытие бага. Переоткрывают уже закрытый баг: т.е. когда баг был исправлен, и тестировщик проверил, что бага нет и закрыл баг. Но он через время опять появился. В данном случае баг не закрывался. Его просто вернут в Doing для фикса.
Спасибо. Интересно. Но создаётся ощущение, что вы тоже подверглись размытию понятий QA и QC. Тестирование - это Quality Control. А QA - это более общее понятие, включающее и QC и прочие методики достижения качества.
Приветствую. На 23 минуте шла речь о том что разработчик, в случае непонимания того, как должна работать фича идет к тестеру, но все же чаще разработчик идет к аналитику, так как проработкой требований занимался он, перевести с языка заказчика на человеческий-профессиональный сможет тоже он. Или же к дизайнеру, если вы фронтендер, потому что в компании может присутствовать строгая дизайн-система с четкими паттернами. Ну и в целом, не считайте своих тестеров обезьянками, которые тыкают по кнопкам, и они скорее всего не дадут вам повода разочароваться
Тестировщик НЕ отвечает за качество, доброе утро. За качествоо отвечает вся команда.
но за баг на проде вые..ут тестировщика
как тестировщик не согласен с одним.. тестировщик не должен ходить к заказчику и узнавать требования для того, чтобы описать ТЗ разработчику
Не зобов'язаний, звісно. Але це йому все одне потрібно - з'ясувати як на справді повинен працювати функціонал. А раз все одне дізнався, то чому не поділіться
Потому что это работа аналитика. Далее уже по доке аналитика составляются тест кейсы
Вітаю. Питаннячко: чим відрізняється TW від BA?
Надо до кучи традиционный анекдот про тестировщика, который заходит в бар, заказывает 999999 пива, ящерицу и т.д.
Что за анекдот?
Пошта, месенджер, і... саме головне Daily meeting 😂😂😂
Можна не до тестувальника йти чи відразу до замовника, якщо задачу не розумієш, а наприклад до ВА, вони як правило зі Scrum майстром і формують задачі в Jira чи Rally чи ще деінде 😂.
Тому що якщо є тестувальник, то це повноцінна команда, а не тріо Мареничі, відповідно і BA є, і представник замовника, і TL, PL і т.д.
насправді досить часто ВА немає навіть в ентерпрайзі
Будем честны, почту приходится везде читать)
"тракать систему" - это смешно. это же суть юриспруденции на самом деле 😁
Так может уже есть qa ai? Или ещё раноавто?
Есть. У Boing ;)
@@PrVladimir boEing :)
Странно, что ни слова про прекрасное мнение, что тестирование - это для тех, кто не сдюжил стать разработчиком) Постоянно встречаю, в т.ч. в описании разных курсов
Я не разделаю этого мнения. Я считаю, что обе профессии достаточно сложны и очень важны
На почте слишком много спама, я её даже не открываю. Всё нахожу в Teams 😂
заведите себе рабочую почту
Тестирование - очень скучная однообразная деятельность которая со временем становится просто невыносимой.
Программист пишет баги а тестировщик их ищет..
Ходят слухи, что после 70-ти тоже падает )
До речі про тестування. Пане Нємчінський, сторінки з курсами рівня Start, які ви рекламуєте, відображаються через Ж. - тільки шапка, підвал та заголовки.
Полагодимо. Якій браузер і ос?
@@NemchinskyLive О! А тепер здається все норм. Браузер Firefox версії 126.0.1, ОС - Win 11. Можливо були якісь затупи з інтернет-з'єднанням, хоча проблеми помітив тільки з розділами про курси рівня Start.
@@jorgesacristan9221 можливо просто CSS не прогрузився
Заменит ли ИИ тестировщиков?
Нет
ИИ заменит тестировщиков в тот же момент когда и разработчиков. По крайней мере сделает отсечку по уровню требуемых навыков
носяться як з пісною торбою - оце був топчик😅
отк
в общем да
taskA, bugA... Хоспаде этот айтишный surjik 🙉
на 3:25 это не тест-кейс, а steps to reproduce баг-репорта. в тест-кейсе описываются шаги проверок работы функциональности
далее всё рассказано правильно, видимо, оговорка просто
@@LejbaBransztejnоговорился, да
@@NemchinskyLive в любом случае спасибо, что удостоили нас вниманием, очень приятно 🙂
В чём секрет хорошего тестировщика? Разработчик думает, как программист. Тестировщик думает, как идиот.
На прошлой неделе тестер нашёл баг, что если пользователь кликает на кнопку с частотой быстрее 30 миллисекунд, то приложение останавливает работу, но UI продолжает показывать, что якобы работа продолжается. Как он об этом узнал? у него мышка с тройным кликом.
И что не так? Баг нашел, баг завел, работа проделана. Или надо было наткнуться на баг и промолчать?
@@user-cr2rt9uq4o а кто сказал, что что-то не так?
@@user-ib1kw2ip7cтак ты же сам написал о том что тестировщик нашел баг
Баги нужно исправлять не?:/
А это ты потом пользователя спросишь, у которого мышка с тройным кликом)
@@user-ib1kw2ip7c ну как минимум, ты сказал, что тестировщик думает, как идиот. Но ему и надо так думать, юзеры творят полную дичь.