В конце концов, можно же просто выпустить продукт, а потом исправить баги, на которые наткнутся пользователи. Да?
А теперь представьте, что вы делаете приложение для нефтяной вышки — как выкачивать нефть, распределять по бакам итд. Если обнаружится неисправность, придется брать вертолет и лететь на место происшествия искать и чинить ошибку. Никаких тебе «прислал фикс по email», там даже wi-fi нет.
Это, между прочим, реальная ситуация. Просто вряд ли вы будете тестировать именно такой софт и поэтому ситуация кажется надуманной. Хорошо, помните, на каком примере мы обсуждали, что такое программы? На примере смартфона и всего того хлама, что там установлен! А теперь попробуйте погуглить историю «Samsung Galaxy Note 7», если вы о ней раньше не слышали. В поисковую строку можно добавить слово «самолет».
А представьте, если в машине обнаружится массовый брак? Телефон то хоть стоит 20-30, ну даже если 100 тысяч. А машина? Представляете, какие убытки несет производитель, если надо отозвать модель?
А ведь сейчас вовсю разрабатывают машины, которые катаются без водителей. Что, если в их систему закрадется баг? Одно дело — когда ты сам виноват в аварии, совсем другое, когда это сделал робот.
Ну хорошо, хорошо, вернемся к тем реалиям, в которые вы попадете. В ближайшие лет 5, по крайней мере. Скорее всего, это будет разработка ПО. Сайта в интернете, игрушки для мобильного телефона, десктопное приложение типа ворда…
См также:
Стоимость исправления ошибки на разных этапах разработки ПО
Да, конечно, можно обойтись вообще без тестировщиков. Сам придумал, сам сделал, сам проверил. Но ведь намного проще заметить соринку в чужом глазу, чем бревно в своем, не так ли?
Но маляр покрасит стену лучше, чем разнорабочий. Тяжело быть супер-крутым сразу во всем, ведь мастерство требует времени. Поэтому мы будем учиться быть хорошими тестировщиками. Которые придут на проект и сэкономят кучу времени остальной команде, которая до этого пыталась тестировать самостоятельно, не особо понимания, как это делается.
А теперь представьте, что вы делаете приложение для нефтяной вышки — как выкачивать нефть, распределять по бакам итд. Если обнаружится неисправность, придется брать вертолет и лететь на место происшествия искать и чинить ошибку. Никаких тебе «прислал фикс по email», там даже wi-fi нет.
Это, между прочим, реальная ситуация. Просто вряд ли вы будете тестировать именно такой софт и поэтому ситуация кажется надуманной. Хорошо, помните, на каком примере мы обсуждали, что такое программы? На примере смартфона и всего того хлама, что там установлен! А теперь попробуйте погуглить историю «Samsung Galaxy Note 7», если вы о ней раньше не слышали. В поисковую строку можно добавить слово «самолет».
История Samsung Galaxy Note 7
Компания Samsung выпустила очередной «новый клевый телефон», Galaxy Note 7, который на тот момент был самым крутым в цепочке. Пользователи радостно побежали его покупать, а потом… Телефоны начали взрываться! Все происходит по однотипному сценарию: телефон перестает работать, не включается и взрыв.
 |
| Взрывной телефон |
В итоге Samsung пришлось отзывать все телефоны назад. Это убытки на возврате денег и транспортировке (они отправляли пользователям огнеупорную коробку) + потери на репутации и цене акций.
По официальным данным, их подвел производитель аккумулятора. На тестирование прислал один, а в общей поставке другой. В любом случае, это был провал.
А представьте, если в машине обнаружится массовый брак? Телефон то хоть стоит 20-30, ну даже если 100 тысяч. А машина? Представляете, какие убытки несет производитель, если надо отозвать модель?
А ведь сейчас вовсю разрабатывают машины, которые катаются без водителей. Что, если в их систему закрадется баг? Одно дело — когда ты сам виноват в аварии, совсем другое, когда это сделал робот.
Ну хорошо, хорошо, вернемся к тем реалиям, в которые вы попадете. В ближайшие лет 5, по крайней мере. Скорее всего, это будет разработка ПО. Сайта в интернете, игрушки для мобильного телефона, десктопное приложение типа ворда…
См также:
Стоимость исправления ошибки на разных этапах разработки ПО
Да, конечно, можно обойтись вообще без тестировщиков. Сам придумал, сам сделал, сам проверил. Но ведь намного проще заметить соринку в чужом глазу, чем бревно в своем, не так ли?
Но маляр покрасит стену лучше, чем разнорабочий. Тяжело быть супер-крутым сразу во всем, ведь мастерство требует времени. Поэтому мы будем учиться быть хорошими тестировщиками. Которые придут на проект и сэкономят кучу времени остальной команде, которая до этого пыталась тестировать самостоятельно, не особо понимания, как это делается.
PS — это выдержка из моей книги для начинающих тестировщиков, написана в помощь студентам моей школы для тестировщиков
Эта картинка с стоимостью бага на разных стадиях, самый большой миф, который постоянно тиражируется. Даже специально считали, по большому счету на уровне погрешности. Мы даже, сейчас, когда собеседуем тестировщиков, даем им вот эту картинку и просим ее протестировать.
ОтветитьУдалитьОльга, вы можете выполнить офигенный интересный квест и найти откуда Копланд взял эту картину и почему она именно такая.
Он вроде писал откуда, хотя я сейчас уже не помню. А в чем огромность мифа то? Неужели правда исправлять код проще, чем исправить требования до начала реализации? Вполне адекватная картинка, которую действительность подтверждает (в моем опыте)
УдалитьЭто не очень сложный квест, модель популярная и даже именная, называется "модель Боэма". Опровергают её достаточно часто. Действительно ли она является мифом? Вовсе нет! Просто, как любая модель, она имеет ограниченную область применимости. Люди находят ситуацию, которая этой моделью не описывается, и делают из этого вывод, что модель неправильная. Но на самом деле просто эти люди не в ладах с логикой. Так же как и те люди, которые считают, что модель Боэма универсальна и применима во всех ситуациях, и у них с логикой не всё в порядке.
УдалитьДа да!
УдалитьЯ не считаю модель применимой во всех ситуациях)) Мои случаи ее подтверждают, но я осознаю, что мой опыт ≠ весь мир :)
Хотя интересно, как именно тестировщик должен протестировать картинку. Какой ответ вы ждете от него? Ответ как у Алексея или что это "самый большой миф"?
Алексей, привел другой пример, спиральную модель. У нее как и у картинки есть границы применимости.
ОтветитьУдалитьОльга, поверьте зачастую дешевле выпустить пробную версию, послушать стоны, и начать править требования. Чем собирать фокус группы и прочее. Весь вопрос в t2m
Тестировщик должен подвергнуть сомнению картинку и выявить для каких условий она применима ну или, при каких условиях она возникла. Первое очень просто. Второе, сложнее, надо садиться и гуглить.
На мой взгляд, надо помнить.
1. Границы применимости моделей или методов.
2. Что есть общие и особые вариации системы.
А как он на собеседовании будет гуглить? Пробная версия — хм, да, такое тоже делают. Но ведь это не отменяет того факта, что исправить что-то в архитектуре сильно проще на этапе требований.
УдалитьПросто иногда не заморачиваются и делают первую версию. Но все, кто пишет про прототипы, говорят о проблеме — в идеале надо прототип выкинуть, так как он сделан "из говна и палок". Но Ж — жадность. В итоге его оставляют и правят как исходную версию. И получают костыли на костылях, в которых потом что-то исправить еще сложнее
Зависит от того сколько времени выделено на собеседование, если достаточно, то мы предоставляем ноутбук или же у кандидата, свой с собой.
УдалитьПо архитектуре, да, согласен если выполнено тестирование на этапе написания требований, это офигенно круто. Но! Но! Специалистов могущих это выполнить единицы и исходя из текущей ситуации, это практическая утопия. Поэтому, только через продакшен.
Да, прототип должен быть выкинут, в большинстве случаев, доработка прототипа очень дорого. Но как ты правильно сказала, Жадность и не желание считать полной стоимости приводит к вполне очевидным последствиям.
А при слове ГОСТ на качество, народ просто впадает в ярость :) :)
"Только через продакшен" — ну тоже неправда же, не надо всех под одну гребенку :)
УдалитьА вот последствия жадности я вижу в чатике выпускников, да... Когда новичков ищут строить процессы с нуля и это вот все)