Comments 30
А можно спрятать часть текста под «читать дальше»?
Спасибо.
Спасибо.
Автоматизация программного обеспечения требует дополнительных инвестиций, хотя позволяет повысить качество продукта. По сути, автоматизация начинает приносить пользу только на продуктах, разработка и сопровождение которых достаточно длительны.
Длительных, да. А ещё обязательно достаточно стабильных. Я сейчас участвую на одном проекте, который разрабатывается уже более полутора лет, срок для окупаемости автотестов предостаточный. Но каждую неделю проводится обработка пожеланий пользователей, которая вызывает серьёзные изменения в продукте. В итоге автотесты с третьей космической скоростью устаревают, в продукте нет ничего старше 2-х месяцев.
Весь НОВЫЙ функционал нужно тестировать вручную. Потому что при тестировании такого функционала 50% затрат уходит на анализ «как правильно» и «как тестировать», а 40% — на регистрацию дефектов. Автотесты позволяют сэкономить 10% на тыкание на кнопочки, но этого недостаточно.
Получается, автоматизация оправдана только в случаях, когда основные затраты приходятся на клики (стабильный, работающий функционал, который уже понятно как тестировать и в котором не находится колоссальное количество ошибок).
Весь НОВЫЙ функционал нужно тестировать вручную. Потому что при тестировании такого функционала 50% затрат уходит на анализ «как правильно» и «как тестировать», а 40% — на регистрацию дефектов. Автотесты позволяют сэкономить 10% на тыкание на кнопочки, но этого недостаточно.
Получается, автоматизация оправдана только в случаях, когда основные затраты приходятся на клики (стабильный, работающий функционал, который уже понятно как тестировать и в котором не находится колоссальное количество ошибок).
автоматизация позволяет сократить расходы;
автоматизация решает проблему с нехваткой ресурсов;
чем больше автотестов, тем лучше;
Это — не мифы. Конечно, автоматизированное тестирование не заменит живых разработчиков. Но эти три фразы безусловно истинны в большинстве случаев.
s/живых разработчиков/живых тестеров/
Да все ок. Тестеры тоже разработчики, хотя, конечно, не программисты.
А чем отличается программист от разработчика?
programmer can be used to refer to a software developer
В моем понятии у софта есть разработчики(те, кто его делает) и пользователи. Просто понятие разработчик более широкое, чем программист. Я тестировщик и я вношу посильный вклад в разработку ПО.
Поэтому ваш вопрос для меня звучит как «чем отличается каменщик от строителя».
Поэтому ваш вопрос для меня звучит как «чем отличается каменщик от строителя».
Подпишусь под каждым словом. Просто на личном опыте.
Но не тестировщики улучшают качество программного обеспечения.
А вот это откомменчу особенно.
Количество моих нововведений чуть меньше, чем заявок от кастомеров. Ну как-то так сложилось. Самые простые делают сразу, сложные — после еще пары просьб о том же.
Но в целом — коллега, целую руку :)
А вот это откомменчу особенно.
Количество моих нововведений чуть меньше, чем заявок от кастомеров. Ну как-то так сложилось. Самые простые делают сразу, сложные — после еще пары просьб о том же.
Но в целом — коллега, целую руку :)
Да сделайте уже хабракат, наконец-то! Раздражает. Сколько раз листаю — разражает.
Хочу добавить в список мифов: слышала такой миф от программистов, что тестировщики ищут баги только путем нажимания всех кнопок подряд, даже не задумываясь о входных и выходных параметрах.
Monkey testing – это неотъемлемая часть проверок. Вы отдадите продукт пользователю, который, поверьте, будет тоже нажимать на все кнопки не задумываясь о входных и выходных данных. Задача разработчиков – сделать так, чтобы пользователь не мог навредить самому себе и чтобы ответ приложения был всегда корректным. Если я могу нажать на все кнопки и приложение выдает непонятную ошибку, разве это нормально? Конечно же, не стоит ограничиваться лишь обезьяним тестированием, и в будущем стоит его автоматизировать, но сейчас, подумайте, если кнопка не работает – то я не смогу завершить свой самый сложный и самый продуманный сценарий. Так почему бы не убедиться в готовности приложения, проводя вначале сессию обезьяньего тестирования?
автоматизация позволяет сократить расходы;
Тут вопрос в том, что вы подразумеваете под автоматизацией. Если я, как мануальный тестировщик, использую инструменты для генерации тестовых данных, скрипты автоматизированого деплоймента базы данных, компиляции приложения из исходников, анализаторы логов, автоматизированную выкачку и установку билда перед мои приходом на работу, то это не автоматизация тестирования?
Многие люди думают, что автоматизация тестирования — это тесты на Селениуме. Вот вам еще один миф :)
автоматизация решает проблему с нехваткой ресурсов;
Ресурсов или кадров?
Если ресурсов, то да, автоматизация тестирования не заменит мне винт на 500 Гб.
Если кадров — то каких именно? Если вам нужен человек, который перегоняет данные из ворда в ексель, то я бы мог попробывать написать для этого скрипт.
чем больше автотестов, тем лучше;
Два теста лучше чем один, три теста лучше чем два, двадцать тестов лучше чем девятнадцать.
Вы — несогласны?
После какого числа это станет мифом.
> Два теста лучше чем один, три теста лучше чем два, двадцать тестов лучше чем девятнадцать.
Вы — несогласны?
Я — не согласен. Точнее так. Существуют проекты и системы разработки для которых два теста лучше, чем один. Но существуют и другие. Не знаю точно, как там дела у вирусологов, но допускаю мысль, что тест сканирующего приложения у них всего один — с разными наборами данных для сканирования.
Вы — несогласны?
Я — не согласен. Точнее так. Существуют проекты и системы разработки для которых два теста лучше, чем один. Но существуют и другие. Не знаю точно, как там дела у вирусологов, но допускаю мысль, что тест сканирующего приложения у них всего один — с разными наборами данных для сканирования.
Самый страшный миф на моей памяти: Разработчики и издатели прислушиваются к тестировщикам.
Очень часто также путают: Quality Assurance, Quality Control, Quality Check (в принципе все это процедулы входящие в процесс контроля качества, но частенько нам дают грызть готовый продукт, добавляя «Через неделю релиз — поищите косяки.» И ладно если ты один и тестишь калькулятор, а если это клиент-серверное приложение управления контентом и вас 15 человек?).
Хотелось бы чтобы это было реальностью, но это миф: Тестирование продукта начинается на этапе проектирования и продолжается в течении всего его жизненного цикла.
Чем то разаработка и тестирование напоминает Мытье слона. Его нельзя помыть всего целиком и чистенько, пока одно ухо помоем — второе уже чемто заляпалось :) Можно конечно окатить целиком штормовым тестированием, но тогда дотошный клиент найдет какуюто дрянь по всей поверхности слона… а целиком в кислоте не вымочить — умрет ведь :)
Вот такой вот сумбурный текст. За статью громадное спасибо. Вдруг вернусь к истокам.
Очень часто также путают: Quality Assurance, Quality Control, Quality Check (в принципе все это процедулы входящие в процесс контроля качества, но частенько нам дают грызть готовый продукт, добавляя «Через неделю релиз — поищите косяки.» И ладно если ты один и тестишь калькулятор, а если это клиент-серверное приложение управления контентом и вас 15 человек?).
Хотелось бы чтобы это было реальностью, но это миф: Тестирование продукта начинается на этапе проектирования и продолжается в течении всего его жизненного цикла.
Чем то разаработка и тестирование напоминает Мытье слона. Его нельзя помыть всего целиком и чистенько, пока одно ухо помоем — второе уже чемто заляпалось :) Можно конечно окатить целиком штормовым тестированием, но тогда дотошный клиент найдет какуюто дрянь по всей поверхности слона… а целиком в кислоте не вымочить — умрет ведь :)
Вот такой вот сумбурный текст. За статью громадное спасибо. Вдруг вернусь к истокам.
Mythbusters рулят :)
А никто не заметил, что это на самом деле универсальные мифы? Можно применить к любой профессии, так же как «тебя недооценивают на работе. а ждет тебя, милок, дальняя дорога и казенный дом». Вот, например,
(disclaimer: это НЕ наезд на тестировщиков и не оспаривание мифов, а только замечания об общности их формулировок)
А теперь можете перечитать статью, и она заиграет перед вами новыми красками…
(disclaimer: это НЕ наезд на тестировщиков и не оспаривание мифов, а только замечания об общности их формулировок)
Миф первый: уборка помещений — это скучно.
Миф об уборке помещений как о скучной и монотонной активности распространяется в средствах массовой информации, в которых уборщицы рассматриваются как чернорабочие офисной деятельности. На самом деле в уборке приходится решать много новых и интересных задач ежедневно. [прим. перев. например, жевательная резинка на стуле]
Миф второй: уборка — это просто.
Часто говорят также, что уборка не может быть ТАК сложна, так как обычные
люди постоянно убирают в своих квартирах…
Миф третий: уборщицы всего лишь подбирают мусор.
Уборщицы действительно занимаются подбиранием мусора, но это далеко не единственная цель их деятельности…
Миф четвертый: машины заменят уборщиц, и они станут ненужными.
С развитием компьютерных технологий все более распространенным становится мнение, согласно которому уборка помещений людьми скоро вообще исчезнет…
Миф пятый: уборщицы не ладят с офисными сотрудниками.
Вполне понятно, почему этот миф так распространен… Не все знают, что многие уборщицы являются бывшими офисными сотрудниками…
А теперь можете перечитать статью, и она заиграет перед вами новыми красками…
Факт первый: тестирование — это скучно.
Не всё конечно, но примерно 3/4 всех тестеров это мануальщики тестирующие UI и его работу. Остальных да, эти факты не касаются.
Факт второй: тестирование — это просто.
Нет никакой особой склонности к тестированию. Лучше тругих тестируют люди потратившие на это больше времени (трудоголики) или обладающие лучшей квалификацией по определенным технологиям. Про проблемы сложнее чем у программистов это просто бред. Ну есть штучные специалисты по нагрузочному тестированию в сложных системах например но их реально единицы.
Факт третий: тестировщики всего лишь ищут ошибки.
Ответственность это к лидам и прочим манагерам. На больших продуктах у тестера ровно столько же влияния на дизайн решения, сколько у анонимуса в интернете. 99% времени тестировщики ищут ошибки.
Не всё конечно, но примерно 3/4 всех тестеров это мануальщики тестирующие UI и его работу. Остальных да, эти факты не касаются.
Факт второй: тестирование — это просто.
Нет никакой особой склонности к тестированию. Лучше тругих тестируют люди потратившие на это больше времени (трудоголики) или обладающие лучшей квалификацией по определенным технологиям. Про проблемы сложнее чем у программистов это просто бред. Ну есть штучные специалисты по нагрузочному тестированию в сложных системах например но их реально единицы.
Факт третий: тестировщики всего лишь ищут ошибки.
Ответственность это к лидам и прочим манагерам. На больших продуктах у тестера ровно столько же влияния на дизайн решения, сколько у анонимуса в интернете. 99% времени тестировщики ищут ошибки.
Ещё покину один «миф»: я пишу на haskell и мне не приходится тестировать мой код, всё и так работает.
Это полумиф. Безусловно, если Haskell-программа скомилилась, — значит, работает. Но она может работать не правильно. Ошибки логики там тоже можно допустить… Хотя сам дизайн языка и программ отсекает львиную долю ошибок, возможных в императивных языках. Так что тестировать все же придется, — на то есть GHCI и QuickCheck. Опять же, от регрессий язык полностью страхует…
Вы-то, конечно же, это знаете, но чтобы другие чего про Haskell не думали.
Кстати, в Лаборатории Касперского есть должность SDET — Software Design Engineer in Test. В моем отделе два SDET'а занимаются очень интересными и любопытными вещами (Load Testing, Performance Testing, другие автоматические тесты...). У них есть куча инженерной работы. Есть и инструменты красивые. И графики там тоже рисуются очень-очень. :) В общем, работа — интересная и не простая.
Вы-то, конечно же, это знаете, но чтобы другие чего про Haskell не думали.
Кстати, в Лаборатории Касперского есть должность SDET — Software Design Engineer in Test. В моем отделе два SDET'а занимаются очень интересными и любопытными вещами (Load Testing, Performance Testing, другие автоматические тесты...). У них есть куча инженерной работы. Есть и инструменты красивые. И графики там тоже рисуются очень-очень. :) В общем, работа — интересная и не простая.
Честно говоря статья мне и в оригинале не понравилась. В целом ниочем. Плюс выдранные из контекста высказывания тех или иных товарищей. По-моему такие мифы и придумывают авторы таких статей.
Почитайте лучше упомянутого в статье Виттейкера,
цикл 7 plagues of Software Testing, перевод jnechaeva
И the future of software testing, коллективный перевод
Почитайте лучше упомянутого в статье Виттейкера,
цикл 7 plagues of Software Testing, перевод jnechaeva
И the future of software testing, коллективный перевод
Sign up to leave a comment.
5 мифов о тестировании