"Проблема" с пользовательскими сценариями, на мой взгляд тестировщика, в том, что они рассматривают атомарные последовательности действий. А ошибки случаются, как правило, на стыке сценариев.
"Кто сшил костюм?"
И если мы попытаемся учесть все возможные взаимодействия всех сценариев у нас опять случается "комбинаторный взрыв". Т.е. нужно вводить еще одно измерение в котором сценарии будут иметь свойство совместимости друг с другом, чтобы можно было как-то систематически учитывать, как сценарии могут влиять друг на друга. А это уже совсем другой подход. На уровне сигналов, входов и выходов. Тут нужна системная аналитика технического инженера и/или архитектора. И опять у нас конфликт. С одной стороны "мы же не ракеты строим", а с другой стремление к полному покрытию.
Именно по этой причине я при поиске промтоваров в интернете, не редко склоняюсь повысить бюджет, вместо того чтобы до умопомрачения копаться в низком ценовом сегменте в надежде найти что-то приличное. Просто стоимость поиска в какой-то момент может перекрыть всю выгоду. Т.е. условно ты выгадаешь 60 долларов, но потратишь на это четыре вечера по 4 часа, итого 16 часов, при зарплате 8 долларов в час. При таком раскладе такая экономия только во вред.
Еще нужно про мобильные телефоны рассказать. Раньше мне чтобы позвонить другу вообще не нужна была операционная система на телефоне. А теперь вот, андроид с двумя гигами оперативы после года-двух начинает подтормаживать. Беда, беда, огорчение.
Вообще, отчасти эта тенденция обусловлена стремлением сделать пользование приложением/системой более удобным для пользователя. Ведь приятно, например, когда операционка сама опознает железо и ставит драйвера. Раньше такого не было. И тому подобное.
Но вот соразмерен ли рост требований к производительности росту удобства пользования? ... Какой там фактор? 4 тысячи? Я не знаю что нужно сделать, чтобы улучшить удобство компьютерной системы или ПО в 4 тысячи раз. Хотя, если за удобство брать время для выполения типовой пользовательской задачи, то в некоторых задачах, возможно, оно и соответствует, а может даже и превосходит.
-- Ты не мог бы передать соль
...
-- Э, алло!
-- Да погоди ты, я же разрабатываю систему, которая сможет передавать любые приправы.
-- Чувак, я, жду уже 20 минут!
-- Но это же сэкономит нам кучу времени в долгосрочной перспективе!
Да, в Германии, например, есть такое. Наличие детей учитывается в декларации, и уменьшает налоговую базу. Но никак не влияет на взносы к социальному и медицинскому страхованию. За детей дают "детские". Но суммарный итоговый эффект этого всего не настолько сильный, чтобы все срочно побежали обзаводиться детьми. С детьми ты уже не сможешь ограничиться двухместной машиной, ты не заселишься в двухкомнатную квартиру, и прочее.
Но мое личное мнение, как женатого с двумя детьми - не все меряется деньгами. Эмоциональное удовлетворение от детей, если ты готов к этому - бесценно.
Samsung Wave был у меня. Покупал тогда "на вырост", т.к. ходили слухи, что они с Bada переедут на Tizen, но этого не случилось. Самое обидное нессответствие ПО и железа, которое никогда не было сбалансировано. Телефон был по техническим характеристикам очень крутой. Батарею держал как титан. Дисплей четкий, контрастный. И хаптика такая классная, что руки до сих пор помнят. Да, было время, не боялись экспериментировать.
Самый распространенный пока все еще. И будет в корпоративной среде так точно. Там где важен факт отправки и доставки сообщения. Вся официальная переписка с заказчиками происходит по электронной почте. Также множество инструментов и сервисов рассылают уведомления по электронной почте.
У среднестатистического домашнего пользователя, конечно, реалии совсем другие. Ему уведомления и сообщения приходят в основном через сервис мгновенных сообщений, смс, ватсапп, вк, фб, телега и прочее. А эл. почта второстепенна.
A бездеятельная критика разве не нытье? В таких постах как правило ничего не предлагают, а только выражают свое недовольство имеющимся status quo. Спасибо, это всем понятно, а делать-то что? Вот это и есть нытье. Когда ты со своей стороны ничем не помогаешь решению задачи. Даже порой не пытаешься понять истоки, и суть проблемы, а критикуешь ее проявления. Ну это как в багтрекер писать "у меня не работает", вместо обстоятельного подробного баг-репорта.
И есть как статьи с конструктивной критикой так и откровенное нытье. И когда я читаю нытье, у меня возникают сомнения в искренности автора, не чисто ли ради слушателей он старается? Поэтому вайн и не приветствуются.
На это сами "вайнеры" ответят "Мы даем проблеме резонанс!". Спасибо, не надо. Все и так знают про проблему, лучше предложите способы решения, или хотя бы мысли в этом направлении. Т.е., условно не писать очередную статью "Что мне не нравится на Хабре", а "5 изменений которые сделают Хабр еще лучше".
Самое ценное на Хабре, то что тут ты еще можешь получить по статье замечания по делу, и чему-то научиться. На западных ресурсах в лучшем случае ты получишь лайк. Или бесформенно-положительный комментарий с благодарностью. Никто как правило глубоких комментариев по существу давать не будет.
Исключение это пожалуй Reddit и Quora (хотя она-то ближе по смыслу к Stackoverflow). Tам можно найти мнения по существу и какое-то "мясо в бульоне".
Статьи на западных блог-площадках нередко имеют такой вид "5 <чего-то>, что поможет тебе <чего-то>". Чисто уровень Яндекс Дзена. Порой производители инструментов такие статейки пишут, псевдоумные. Где вoкруг рекламы сплетена якобы полезная статья с квази ценным опытом.
LinkedIn, там, если подписаться на группы по интересам и интересных людей можно изредка наткнуться на занимательные вопросы и мнения. Или даже общаться с профессионалами напрямую. Но развернуться там негде, там даже комментарий ограничен по количеству символов. Из положительных моментов, однако, все что ты там пишешь прочитает возможно рекрутер и составит о тебе мнение. А если ты оставляешь о себе высокопрофессиональное впечатление, то соответственно спрос на тебя как специалиста будет выше. Но по качеству коммуникации LinkedIn недалеко ушел от Фейсбука. Т.е можно вообще своим мнением никого не заинтересовать, все таки это больше площадка для пиара, а люди которые пиарятся заинтересованы только собой, а не другими. Т.е. там самое главное написать такой набор текста который вызовет максимальную положительнуж реакцию. Все.
Самый технически насыщенный англоязычный контент, такой прям, с рукоприкладством, а не языкоболтанием, я больше нахожу на ютубе.
Вот даже Stackoverlflow, казалось бы, тоже открыл свою блог площадку, но техническая насыщенность статеек там с самим SO даже рядом не стояла. Очередное УГ для пиара.
Ну да, издержки общения в интернете. У оппонента складывается ложное впечатление из-за того, что ему кроме написаного текста больше нечего оценить. Получается он вставляет полученый текст в контекст своей модели мира, без возможности оппонентом это сразу откорректировать. Хотя, во многих спорах, на самом деле, можно найти компромисс.
Такая же петрушка может происходить и в корпоративной переписке. Когда ты всю ночь не спишь, думая, что я такого ляпнул, что начальник так резко ответил. А там на самом деле, ему просто некогда было, дети вывели из себя, попугайчик лапки откинул, да что угодно. Действительно полезно в текстовом общении не вменять человеку злого умысла раньше времени. Ведь всякое бывает.
Ну а по итогу, да, получается, что карма отражает субьективную оценку пользователя сообществом, основаную на неполной информации. И, конечно, выражать оценку человека бинарным «нравится» или «не нравится» кажется примитивно, но несмотря на это, такие системы работают и в других областях. Например Youtube. Там по дизлайкам мы сразу оцениваем качество информации в видео. Это экономит кучу времени. Поэтому надо дорожить репутацией и быть осторожным в высказываниях, стараться никого не задеть.
Сегодня это еще актуальне чем когда либо, потому что присутствие в интернете социальных групп, которых можно ненароком задеть, постоянно разрастается. О необходимости «фильтровать базар», собственно, и в мануале Хабра написано:
Поэтому очень важно внимательно следить за словами и тщательно взвешивать всё написанное, перед его публикацией.
P.S.: Любопытная мысль. Если это экстраполировать на все общество, то оказывается никакой государственной цензуры не надо. Люди сами все «зацензурят» так, что родная мама не узнает. Все будут по струночке ходить, лишь бы не попасть в немилость «сообщества».
Да, все так. Часто тесты пишутся «в лоб», подгоняются под приложение, и реальные пользовательские сценарии не учитывают. Только вот это не проблема автоматизации как таковой. И имея отдел ручных тестировщиков можно иметь баги на проде, и тестировщики будучи людьми могут закрывать глаза на некоторые недочеты в приложении (по разным причинам) и тестовые сценарии для ручного прогона могут не покрывать всех пользовательских сценариев.
Потому что тестирование это борьба с комплексностью. Это решение задачи не как покрыть все (это невозможно на практике), а как с минимальными затратами покрыть наиболее критичные области приложения.
Поэтому хорошая метрика, не количество человекочасов в тестировании, или количество пройденых тесткейсов, а количество задокументированых багов. Нужно увеличивать выхлоп от тестирования, а не расширять тестировочные активности. Я бы еще ввел метрику соотношения найденых недочетов к задокументированым багам. У меня есть основания полагать, что далеко не все найденые недочеты попадают в беклог. Существенная их доля растворяется в дискуссиях. «Оно всегда так работало», «Давай не будем будить спящих собак», «У нас нет спецификации на это» и пр. и пр. Несгибаемых тестировщиков небывает, хоть к этому и надо стремиться.
Всё это компромиссы, компромиссики, которые потом боком выходят. Приведу тут еще раз тут эту поучительную историю:
При подготовке полета «Аполлона-8», первого пилотируемого космического корабля, добравшегося до орбиты Луны, Маргарет Гамильтон удалось обнаружить серьезную уязвимость, но никто не поверил, что она представляет реальную угрозу. Найти эту уязвимость помогла дочь Гамильтон, которая играла с симулятором компьютера «Аполлона-8», пока ее мать работала. В какой-то момент она включила последовательность P01, запускаемую перед стартом космического корабля, когда симулятор был уже в «полете». Запуск P01 в неподходящий момент привел к сбою; и хотя у космонавтов нет никаких причин допускать такую ошибку, Гамильтон решила добавить несколько строчек кода — сделать своего рода «защиту от дурака». В NASA воспротивились, сочтя, что прекрасно подготовленные астронавты никогда в жизни не смогут так ошибиться. Тогда Гамильтон включила строчку «Не запускайте P01 во время полета» в документацию, но и это показалось руководству излишней мерой предосторожности.
Вскоре после Рождества в 1968 году, когда «Аполлон-8» должен был покинуть орбиту Луны и отправиться на Землю, астронавт Джеймс Ловелл сделал именно то, чего от него никак не ждали — по ошибке запустил P01
Я бы не обобщал. Проекты разные бывают. Бизнес-модели разные.
Часто под разработкой люди понимают разработку своего продукта, но в айти на самом деле гораздо больше контрактной работы. Где ты предоставляешь заказчику работу/команду как сервис. А в контрактной работе тебе нужно предложить заказчику пакет услуг по приемлемой для него цене. И тут договориться об оплате выделеной роли не так просто. Конечно, подрядчик пытается увеличить чек, но конкуренция бешеная и это весьма и весьма сложно. Конкурренты демпингуют жестко, даже не имея необходимых компетенций, лишь бы получить контракт, а там хоть трава не расти. Поэтому работа айтишников сильно зависит от ловкости отдела продаж, смогут они охмурить заказчика или нет.
То, куда идет индустрия в конце концов решает рынок. Поэтому сервисные компании подбирают такой режим работы, чтобы во первых быть дешевле и получить заказ, а во вторых увеличить маржу, например, запихивая в проект джуниоров, и студентов.
А когда компания работает на себя, там другие мотивы. Они конкурируют продуктом.
Так что есть наше профессионально обусловленное представление о том как было бы лучше, и есть рынок, который все эти твои фантазии и мечты о лучшем мире жёстко херачит об асфальт и либо ты идешь на галеры, более или менее устроеные, либо ты идешь ко всем чертям (во фрилансеры).
Это может значить, что они просто не держат такую позицию. Но ведь и автоматизатор тестирования в первую очередь тестировщик. А может быть такое, что заказчик или группа ключевых пользователей сами частично проводят «приемку».
Вопрос же как стоит: как обеспечить нормальную скорость отгрузки, если тестировать по две недели после компоновки релиза? Чтобы настроить такой процесс, нужен тест-менеджер, тестировщики, нужно согласовывать и обновлять тестовые сценарии. На все это заказчик не хочеть тратить время и деньги. Поэтому он покупает автоматизацию тестирования, где ему показывают, что фича была покрыта автотестом, показывают репорты. И на это на все нужен всего один человек, а не целая команда, и тестирование происходит «постоянно». T.e. это скорее компромиссное решение в сторону снижения затрат, а не повышения качества.
Если сравнивать автотест с ручным тестовым сценарием то по моему опыту с автоматизацией ты можешь добиться удаления большего количества ошибок, чем ручной тестировщик. Ты просто можешь например сказать, что автоматизация из-за этого работает медленнее, или сыпется. Или из-за неконсистентного поведения ты не можешь написать вменяемый скрипт. А ручной тестировщик всегда проблему может «обойти». Автомат ничего «обойти» не может и в этом его прелесть. В этом отношении машине больше доверия.
Я на своем старом проекте будучи автоматизатором репортил в несколько раз больше багов чем ручные тестировщики с эксплоративным подходом.
Да и если коснуться вопроса сколько проекту нужно «качества», мы понимаем, что многие клиенты не ракеты в космос запускают, им там супер качество и не нужно. Так, чтобы очевидные вещи не сыпались и уже неплохо. А когда ты закрыл регресс автоматизацией у тебя появляется время/возможность «шерудить шваброй в темных углах» приложения. Смотреть на качество кода, делать QA Achitecture (работать над тем, чтобы встроить качество в архитектуру и процесс разработки)
Подводя итоги скажу:
Автоматизация не замена ручному тестированию, а производственная необходимость. Ее именно так нужно рассматривать. Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.
Нам преподавали WinGPSS, с графической оболочкой. Дискретная симуляция — интересно. Мы аэропорт моделировали в курсовой. Жаль только, что не настолько распространненая область в IT.
А мне кажется на тетрадном листе в клеточку тоже бы очень аутентично смотрелось. Урок биологии: - Петров, опять ты там в тетрадке рисуешь?! Лучше бы слушал внимательно, тема ведь про коронавирус! Это между прочим сейчас всех нас касается. - Марь Иванна, мне это в жизни не пригодится! - А то что ты там рисуешь, значит пригодится? - Во время пандемии, в некоторых ситуациях, вполне. - Не хочется тебя заранее огорчать Петров, но ни в каких ситуациях он тебе не пригодится. Помяни мое слово.
А еще можно взять тряпочку из грубой ткани и вышить на нем черной ниткой код, а потом как нашивку приделать на рукав - будет как "код прививки на рукаве, мой порядковый номер.."
Хотя, Вы правы, термин используется в словосочетаниях Устойчивость Окружающей Среды, и Устойчивое Сельское Хозяйство. Звучит для меня чужеродно, потому что я все эти языковые новообразования не застал, и мой словарный запас законсервировался 20 лет назад.
Но тогда ведь есть хорошее слово «гомеостаз». Способность сохранять равновесие.
Тоже подумал, что они сильно рискнули, запуская такую статью. Ведь тогда она сама должна быть образцом, а это практически невозможно.
"Проблема" с пользовательскими сценариями, на мой взгляд тестировщика, в том, что они рассматривают атомарные последовательности действий. А ошибки случаются, как правило, на стыке сценариев.
И если мы попытаемся учесть все возможные взаимодействия всех сценариев у нас опять случается "комбинаторный взрыв". Т.е. нужно вводить еще одно измерение в котором сценарии будут иметь свойство совместимости друг с другом, чтобы можно было как-то систематически учитывать, как сценарии могут влиять друг на друга. А это уже совсем другой подход. На уровне сигналов, входов и выходов. Тут нужна системная аналитика технического инженера и/или архитектора. И опять у нас конфликт. С одной стороны "мы же не ракеты строим", а с другой стремление к полному покрытию.
Именно по этой причине я при поиске промтоваров в интернете, не редко склоняюсь повысить бюджет, вместо того чтобы до умопомрачения копаться в низком ценовом сегменте в надежде найти что-то приличное. Просто стоимость поиска в какой-то момент может перекрыть всю выгоду. Т.е. условно ты выгадаешь 60 долларов, но потратишь на это четыре вечера по 4 часа, итого 16 часов, при зарплате 8 долларов в час. При таком раскладе такая экономия только во вред.
Еще нужно про мобильные телефоны рассказать. Раньше мне чтобы позвонить другу вообще не нужна была операционная система на телефоне. А теперь вот, андроид с двумя гигами оперативы после года-двух начинает подтормаживать. Беда, беда, огорчение.
Вообще, отчасти эта тенденция обусловлена стремлением сделать пользование приложением/системой более удобным для пользователя. Ведь приятно, например, когда операционка сама опознает железо и ставит драйвера. Раньше такого не было. И тому подобное.
Но вот соразмерен ли рост требований к производительности росту удобства пользования? ... Какой там фактор? 4 тысячи? Я не знаю что нужно сделать, чтобы улучшить удобство компьютерной системы или ПО в 4 тысячи раз. Хотя, если за удобство брать время для выполения типовой пользовательской задачи, то в некоторых задачах, возможно, оно и соответствует, а может даже и превосходит.
Так тройка встречается чаще всего, вот и ответ.
Да, в Германии, например, есть такое. Наличие детей учитывается в декларации, и уменьшает налоговую базу. Но никак не влияет на взносы к социальному и медицинскому страхованию. За детей дают "детские". Но суммарный итоговый эффект этого всего не настолько сильный, чтобы все срочно побежали обзаводиться детьми. С детьми ты уже не сможешь ограничиться двухместной машиной, ты не заселишься в двухкомнатную квартиру, и прочее.
Но мое личное мнение, как женатого с двумя детьми - не все меряется деньгами. Эмоциональное удовлетворение от детей, если ты готов к этому - бесценно.
Когда на меня под впечатлением от мировых событий накатывают антиутопические флешфорварды и прочие фантазии, я вспоминаю цитату Виктора Пелевина
А как тестировщику, повидавшему больше фейлов чем хотелось бы,
подобная картина мне кажется куда более реальной:
Samsung Wave был у меня. Покупал тогда "на вырост", т.к. ходили слухи, что они с Bada переедут на Tizen, но этого не случилось. Самое обидное нессответствие ПО и железа, которое никогда не было сбалансировано. Телефон был по техническим характеристикам очень крутой. Батарею держал как титан. Дисплей четкий, контрастный. И хаптика такая классная, что руки до сих пор помнят. Да, было время, не боялись экспериментировать.
Вы хоть бы это, салфеточку к посту прикрепили -- слезы ностальгии вытирать!
Самый распространенный пока все еще. И будет в корпоративной среде так точно. Там где важен факт отправки и доставки сообщения. Вся официальная переписка с заказчиками происходит по электронной почте. Также множество инструментов и сервисов рассылают уведомления по электронной почте.
У среднестатистического домашнего пользователя, конечно, реалии совсем другие. Ему уведомления и сообщения приходят в основном через сервис мгновенных сообщений, смс, ватсапп, вк, фб, телега и прочее. А эл. почта второстепенна.
A бездеятельная критика разве не нытье? В таких постах как правило ничего не предлагают, а только выражают свое недовольство имеющимся status quo. Спасибо, это всем понятно, а делать-то что? Вот это и есть нытье. Когда ты со своей стороны ничем не помогаешь решению задачи. Даже порой не пытаешься понять истоки, и суть проблемы, а критикуешь ее проявления. Ну это как в багтрекер писать "у меня не работает", вместо обстоятельного подробного баг-репорта.
И есть как статьи с конструктивной критикой так и откровенное нытье. И когда я читаю нытье, у меня возникают сомнения в искренности автора, не чисто ли ради слушателей он старается? Поэтому вайн и не приветствуются.
На это сами "вайнеры" ответят "Мы даем проблеме резонанс!". Спасибо, не надо. Все и так знают про проблему, лучше предложите способы решения, или хотя бы мысли в этом направлении. Т.е., условно не писать очередную статью "Что мне не нравится на Хабре", а "5 изменений которые сделают Хабр еще лучше".
Самое ценное на Хабре, то что тут ты еще можешь получить по статье замечания по делу, и чему-то научиться. На западных ресурсах в лучшем случае ты получишь лайк. Или бесформенно-положительный комментарий с благодарностью. Никто как правило глубоких комментариев по существу давать не будет.
Исключение это пожалуй Reddit и Quora (хотя она-то ближе по смыслу к Stackoverflow). Tам можно найти мнения по существу и какое-то "мясо в бульоне".
Статьи на западных блог-площадках нередко имеют такой вид "5 <чего-то>, что поможет тебе <чего-то>". Чисто уровень Яндекс Дзена. Порой производители инструментов такие статейки пишут, псевдоумные. Где вoкруг рекламы сплетена якобы полезная статья с квази ценным опытом.
LinkedIn, там, если подписаться на группы по интересам и интересных людей можно изредка наткнуться на занимательные вопросы и мнения. Или даже общаться с профессионалами напрямую. Но развернуться там негде, там даже комментарий ограничен по количеству символов. Из положительных моментов, однако, все что ты там пишешь прочитает возможно рекрутер и составит о тебе мнение. А если ты оставляешь о себе высокопрофессиональное впечатление, то соответственно спрос на тебя как специалиста будет выше. Но по качеству коммуникации LinkedIn недалеко ушел от Фейсбука. Т.е можно вообще своим мнением никого не заинтересовать, все таки это больше площадка для пиара, а люди которые пиарятся заинтересованы только собой, а не другими. Т.е. там самое главное написать такой набор текста который вызовет максимальную положительнуж реакцию. Все.
Самый технически насыщенный англоязычный контент, такой прям, с рукоприкладством, а не языкоболтанием, я больше нахожу на ютубе.
Вот даже Stackoverlflow, казалось бы, тоже открыл свою блог площадку, но техническая насыщенность статеек там с самим SO даже рядом не стояла. Очередное УГ для пиара.
Такая же петрушка может происходить и в корпоративной переписке. Когда ты всю ночь не спишь, думая, что я такого ляпнул, что начальник так резко ответил. А там на самом деле, ему просто некогда было, дети вывели из себя, попугайчик лапки откинул, да что угодно. Действительно полезно в текстовом общении не вменять человеку злого умысла раньше времени. Ведь всякое бывает.
Ну а по итогу, да, получается, что карма отражает субьективную оценку пользователя сообществом, основаную на неполной информации. И, конечно, выражать оценку человека бинарным «нравится» или «не нравится» кажется примитивно, но несмотря на это, такие системы работают и в других областях. Например Youtube. Там по дизлайкам мы сразу оцениваем качество информации в видео. Это экономит кучу времени. Поэтому надо дорожить репутацией и быть осторожным в высказываниях, стараться никого не задеть.
Сегодня это еще актуальне чем когда либо, потому что присутствие в интернете социальных групп, которых можно ненароком задеть, постоянно разрастается. О необходимости «фильтровать базар», собственно, и в мануале Хабра написано:
P.S.: Любопытная мысль. Если это экстраполировать на все общество, то оказывается никакой государственной цензуры не надо. Люди сами все «зацензурят» так, что родная мама не узнает. Все будут по струночке ходить, лишь бы не попасть в немилость «сообщества».
Потому что тестирование это борьба с комплексностью. Это решение задачи не как покрыть все (это невозможно на практике), а как с минимальными затратами покрыть наиболее критичные области приложения.
Поэтому хорошая метрика, не количество человекочасов в тестировании, или количество пройденых тесткейсов, а количество задокументированых багов. Нужно увеличивать выхлоп от тестирования, а не расширять тестировочные активности. Я бы еще ввел метрику соотношения найденых недочетов к задокументированым багам. У меня есть основания полагать, что далеко не все найденые недочеты попадают в беклог. Существенная их доля растворяется в дискуссиях. «Оно всегда так работало», «Давай не будем будить спящих собак», «У нас нет спецификации на это» и пр. и пр. Несгибаемых тестировщиков небывает, хоть к этому и надо стремиться.
Всё это компромиссы, компромиссики, которые потом боком выходят. Приведу тут еще раз тут эту поучительную историю:
— Маргарет Гамильтон: «Пацаны, я вас на Луну отправлю»
Часто под разработкой люди понимают разработку своего продукта, но в айти на самом деле гораздо больше контрактной работы. Где ты предоставляешь заказчику работу/команду как сервис. А в контрактной работе тебе нужно предложить заказчику пакет услуг по приемлемой для него цене. И тут договориться об оплате выделеной роли не так просто. Конечно, подрядчик пытается увеличить чек, но конкуренция бешеная и это весьма и весьма сложно. Конкурренты демпингуют жестко, даже не имея необходимых компетенций, лишь бы получить контракт, а там хоть трава не расти. Поэтому работа айтишников сильно зависит от ловкости отдела продаж, смогут они охмурить заказчика или нет.
То, куда идет индустрия в конце концов решает рынок. Поэтому сервисные компании подбирают такой режим работы, чтобы во первых быть дешевле и получить заказ, а во вторых увеличить маржу, например, запихивая в проект джуниоров, и студентов.
А когда компания работает на себя, там другие мотивы. Они конкурируют продуктом.
Так что есть наше профессионально обусловленное представление о том как было бы лучше, и есть рынок, который все эти твои фантазии и мечты о лучшем мире жёстко херачит об асфальт и либо ты идешь на галеры, более или менее устроеные, либо ты идешь ко всем чертям (во фрилансеры).
Вопрос же как стоит: как обеспечить нормальную скорость отгрузки, если тестировать по две недели после компоновки релиза? Чтобы настроить такой процесс, нужен тест-менеджер, тестировщики, нужно согласовывать и обновлять тестовые сценарии. На все это заказчик не хочеть тратить время и деньги. Поэтому он покупает автоматизацию тестирования, где ему показывают, что фича была покрыта автотестом, показывают репорты. И на это на все нужен всего один человек, а не целая команда, и тестирование происходит «постоянно». T.e. это скорее компромиссное решение в сторону снижения затрат, а не повышения качества.
Если сравнивать автотест с ручным тестовым сценарием то по моему опыту с автоматизацией ты можешь добиться удаления большего количества ошибок, чем ручной тестировщик. Ты просто можешь например сказать, что автоматизация из-за этого работает медленнее, или сыпется. Или из-за неконсистентного поведения ты не можешь написать вменяемый скрипт. А ручной тестировщик всегда проблему может «обойти». Автомат ничего «обойти» не может и в этом его прелесть. В этом отношении машине больше доверия.
Я на своем старом проекте будучи автоматизатором репортил в несколько раз больше багов чем ручные тестировщики с эксплоративным подходом.
Да и если коснуться вопроса сколько проекту нужно «качества», мы понимаем, что многие клиенты не ракеты в космос запускают, им там супер качество и не нужно. Так, чтобы очевидные вещи не сыпались и уже неплохо. А когда ты закрыл регресс автоматизацией у тебя появляется время/возможность «шерудить шваброй в темных углах» приложения. Смотреть на качество кода, делать QA Achitecture (работать над тем, чтобы встроить качество в архитектуру и процесс разработки)
Подводя итоги скажу:
Автоматизация не замена ручному тестированию, а производственная необходимость. Ее именно так нужно рассматривать. Ты без автоматизации будешь неконкурентноспособным, просто не сможешь держать темп.
А мне кажется на тетрадном листе в клеточку тоже бы очень аутентично смотрелось.
Урок биологии:
- Петров, опять ты там в тетрадке рисуешь?! Лучше бы слушал внимательно, тема ведь про коронавирус! Это между прочим сейчас всех нас касается.
- Марь Иванна, мне это в жизни не пригодится!
- А то что ты там рисуешь, значит пригодится?
- Во время пандемии, в некоторых ситуациях, вполне.
- Не хочется тебя заранее огорчать Петров, но ни в каких ситуациях он тебе не пригодится. Помяни мое слово.
А еще можно взять тряпочку из грубой ткани и вышить на нем черной ниткой код, а потом как нашивку приделать на рукав - будет как "код прививки на рукаве, мой порядковый номер.."
Но тогда ведь есть хорошее слово «гомеостаз». Способность сохранять равновесие.