Comments 14
Вот он, кровавый капитализм — пусть за вас тестируют пользователи, все равно они никуда не денутся :)
Причём здесь кровавый капитализм?
Насколько я понял статью после прочитки по диагонали, Антон Олиевский поднимает довольно щепитильный в некоторых кругах вопрос: «А нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»
Насколько я понял статью после прочитки по диагонали, Антон Олиевский поднимает довольно щепитильный в некоторых кругах вопрос: «А нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»
«Причём здесь кровавый капитализм?»
Ну, во-первых, там смайл. Во-вторых, капитализм там при том, что компания экономит деньги на тестировании, по сути, перекладывая его на плечи пользователей.
«нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»
Вообще-то, нет. В конце концов они перестали тестировать фичи вообще, типа как-то работает, ну и ладно.
Ну, во-первых, там смайл. Во-вторых, капитализм там при том, что компания экономит деньги на тестировании, по сути, перекладывая его на плечи пользователей.
«нужно ли тратить гигантское количество времени (а следовательно и денег), чтобы найти вообще все баги, если от одного МЕЛКОГО бага урона не будет?»
Вообще-то, нет. В конце концов они перестали тестировать фичи вообще, типа как-то работает, ну и ладно.
Сейчас прочитал подробнее… вы правы, тестируют только критичные функции.
В таком случае, чтобы давать оценку таком решению, нужно знать статистику о количестве багов в новых фичах, может их действительно очень мало и связаны они с очень специфическими ситуациями у пользователя.
В любом случае обе крайности «Нафиг тесты» и «Тестируем даже функцию c одним return 1;» плохи, везде нужен баланс.
В таком случае, чтобы давать оценку таком решению, нужно знать статистику о количестве багов в новых фичах, может их действительно очень мало и связаны они с очень специфическими ситуациями у пользователя.
В любом случае обе крайности «Нафиг тесты» и «Тестируем даже функцию c одним return 1;» плохи, везде нужен баланс.
на хорошее.it его
переименуйте статью и измените вводную — очень хочется минусануть до того, как прочитаются аргументы: слишком провоцирующее начало, вызывает кучу негативных эмоций в вводной
А так куча негативных эмоций становится меньше?
Если рассмотреть гипотетическую ситуацию, в которой компания требует полный цикл тестирования на каждую небольшую фичу, не умеет оптимизировать процесс тестирования и автоматизировать тестирование — то тестирование для этой компании зло: приносит мало пользы, но потребляет много ресурсов. Насколько я понял, в этой компании именно такая ситуация. И здорово, что они осознали это, озаботились тем, чтобы решить эту проблему, выделить критичные направления и всё ещё тестируют (основные user-case) для минорных фич. Да, меньше становится негативных эмоций.
Освободившиеся ресурсы они теперь могут направить на автоматизацию тестирования, например, и в итоге будут тестировать в перспективе качественнее, чем до «отказа от тестирования» и меньшими ресурсами.
Освободившиеся ресурсы они теперь могут направить на автоматизацию тестирования, например, и в итоге будут тестировать в перспективе качественнее, чем до «отказа от тестирования» и меньшими ресурсами.
Что имеем в итоге: «Продакт Дима совсем перестал заходить к Антону.»
А вообще обидно смотреть на современные тенденции, когда качество уходит всё дальше и дальше на задний план.
А вообще обидно смотреть на современные тенденции, когда качество уходит всё дальше и дальше на задний план.
История полна фейспалмов. В книжках не написано, что тестировать надо всё — это называется exhaustive testing. И надо быть полным дятлом чтобы фиксить абсолютно все баги. 60 багов/задач ожидающие проверки? Вы бы лучше больше функционала автоматизировали и наняли больше QA. А вместо того, чтобы релизить как вы называете хотфиксы каждый день стоит лучше планировать. Про стоимость исправления ошибки на разных этапах разработки я вообще молчу — тут наглядно видно http://www.karlgroves.com/wp-content/uploads/2016/01/boehm-curve.jpg
На самом деле поиск QA вёлся параллельно всем нововведениям. Однако найти хорошего тестировщика оказалось задачей не быстрой — за последний год мы набрали 3 человека. Да и аппетит растёт во время еды, разработчиков тоже набирали и сейчас отношение 8 к 60.
Насчет планирования "хотфиксов" — Вы правы, в этом направлении тоже ведётся работа, но к данной статье она не относится.
надо быть полным дятлом чтобы фиксить абсолютно все баги
а какие баги фиксите Вы?
Вобщем подход вполне разумный. Тестировать то, что важно и срочно — сейчас, а то, что важно, но не срочно — потом.
matvey_travkin Тут немного не понял:
matvey_travkin Тут немного не понял:
Потом к Антону пришла тестировщик Юля и сказала, что задолбалась. Типа, делай, что хочешь, но она не может больше каждый день проводить приёмочное, учитывая тот факт, что по основному функционалу редко что-то меняется и багов она не находит. Поэтому Юля предложила проводить приёмочное раз в неделю.Почему тесты по основному функционалу не автоматизированы? Это те которые тяжело автоматизируются? Ведь тест базового функционала не дает вам тестировать новое и срочное. Даже если это раз в неделю. Еще если новый функционал при тестировании захватывает базовый функционал можно было бы отказаться от тестирования базового функционала так как он был бы и так протестирован. Может переписать сценарии так чтобы каждый тест нового подхватывал немного старого? Каждый тест станет на 1-3 шага длиннее, но зато у вас будет что-то вроде интеграционного теста, и небходимость отдельного тестирования базового функционала отпадет совсем.
Спасибо за коммент!
Совершенно верно, не автоматизированны остались сложные для автоматизации кейсы (получение СМС/E-mail, шаринги и админка). В этом направлении ведутся работы — разработчики обещали помочь с частью «сложных» кейсов.
Насчет проверки базового функционала параллельно с тестированием задач — интересная идея, спасибо. Сейчас у нас не очень прозрачно — тот, кто проводит приёмочное не знает, что из него было уже проверено в рамках тестирования других задач. Ну и конечно же всегда есть риск, что последняя задача всё переломает (мыж тестировщики суеверные :))
Совершенно верно, не автоматизированны остались сложные для автоматизации кейсы (получение СМС/E-mail, шаринги и админка). В этом направлении ведутся работы — разработчики обещали помочь с частью «сложных» кейсов.
Насчет проверки базового функционала параллельно с тестированием задач — интересная идея, спасибо. Сейчас у нас не очень прозрачно — тот, кто проводит приёмочное не знает, что из него было уже проверено в рамках тестирования других задач. Ну и конечно же всегда есть риск, что последняя задача всё переломает (мыж тестировщики суеверные :))
Sign up to leave a comment.
Тестировщики против тестирования