• Главная
  • О сайте
  • Архив

Normal testing

From the programmer's worst friend

Feeds:
Записи
Комментарии
« Каждое дело должно заниматься своим делом
Когда требования «никакие», когда спасает психология »

Тыкайте проекты в свободном режиме

05.05.2015 Автор: Alexei Lupan

Тыщу лет назад.

Осень.

Я, безработный, «словно птица на сносях», иду собеседоваться в большую компанию.

А там на входе две анкеты «на адекватность».

Дадада, давайт сюдайт, адекватность — это же моё второе имя!

Первая анкета скучна, как радио «Шансон» в киевском варианте. Сто насущнейших вопросов из области программирования.

Что такое ООП, а вот предположим, что мы намазываем на бутерброд наследуемый полиморфизм, а в чем же насущная суть абстрактной сущности, а вот найди неправильный тэг в предлагаемом html-коде, а что б ты сделал, если б ты увидел молдавских коммунистов в церкви (ничего, это же неправильные коммунисты, они делают неправильный мёд),  а кто такой тов. Стучка (один из организаторов коммунистической партии в Латвии с 1919 г.), а где теперь живет Карл Маркс (в сердцах пролетариата), и прочее…

Я отвечал этой занудной анкете честно, обстоятельно и неторопливо, мол, не брал я на душу покойников, и не испытывал судьбу, и не знаю я никаких ваших ООП, а вот этот тэг на html надо безусловно закрывать вот здесь, а тут тоже не знаю, и это пропущу, и тут я хз, а тут я вообще хз, и я начальник, спал спокойненько, и весь ваш МУР видал в гробу…

Вторая анкета поживее — сто вопросов про тестирование ПО. Там я тоже отвечал честно, обстоятельно и неторопливо, но тут уже, в отличе от первой, незаполненным не оставил ни одно поле.

Итого странная ситуация: коньдидатЪ продемонстрировал исчезающе мало знаний в программировании, но ВНЕЗАПНО оказался невероятно хорош в тестировании, набрал ~90% правильных ответов, каг же таг?

Разбираться со феноменом явилось двое тест-манагеров. Мое сопротивление было смелым, как атака кавалерии Келлермана под Ватерлоо, но таким же ненужным. Не суть, конечно, дело прошлое, но по итогу беседы мне был нанесён самый мощный coup de grâce в моей тестировщицкой жизни, о котором не забывается. Речь пошла про тестирование проекта, который вот-вот надо сдавать.

А именно: «А вот у вас проект, который вот-вот надо сдавать. Что вы предложите делать тестировщикам: проверять по тест-кейсам, или в свободном режиме потыкать проект, может и найдутся какие-нибудь баги?»

Я крепко подумал.

И ты подумай.

Саспенс же, ёпта.

Если проект уже надо сдавать, это означает, что времени — с гулькин, мгм, нос.

Будет ли возможность выпуска следующей версии ПО, в которой будут исправлены все баги, которые будут обнаружены после выхода на продакшн? Не знаю, молчат, не говорят.

Да, и непонятно, что в данном случае означает «выход на продакшн», бо я ж ни здоб ни здуб о том, какого рода проект происходит — он на сервере появится, или будет передан в разные офисы и установлен на разном оборудовании, а я ж хз, тестировались ли варианты «разного оборудования», и…

Ок, считаем, что другого шанса «сдать адекватный проект» не будет.

Можно заняться аналитикой: ещё раз пройтись по проекту и выяснить, все ли возможные сценарии работы приложения были продуманы и протестированы? Наверняка же не все… Но заниматься аналитикой перед финалом работы по проекту вобще?…

А если проект уже «надо сдавать» — это означает, что времени на багфиксы не будет?! Если в свободном поиске тестировщик найдёт что-то СТРАШНОЕ, то его свои же манагеры закопают у озера на Скулянке, лишь бы не сообщать в последний момент о том, что  выходить в прод опасно…

Что-то хорошее в этой ситуации тоже нашлось — если проект «уже надо сдавать», это значит, что до сих пор тестировщики что-то в этом проекте ковыряли, и вероятно, уже не первый день, и вероятно, уже знают его очень хорошо. Знают сильные места, знают слабые места, знают то, о чем никому не надо говорить, знают то, что хочется развидеть, но без армии психоаналитиков мистер Крюгер все равно будет каждую ночь посещать и несчастного тестировщика, и несчастного девелопера, который всё это надевелоперил…

Но в свободном поиске уже изрядно переспавшие с этим проектом тестировщики найдут, скорее всего, тот самый гулькин, мгм, нос, бо какие перлины можно найти, если начать перелопачивать всё ту же кучу навоза, которую сами наделали и сполна перелопатили?!

Подскажу бесплатно: или найдутся какие-то безумно идиотские экзотические сценарии перехода с одного экрана на другой, или какие-то безумно идиотские экзотические сценарии выполнения каких-то расчетов, которые закрэшат софтину, и тогда манагеры поедут на Скулянку выкапывать из благословенного молдавского чернозема тестировщика, который хотя бы что-то да знает о том, где у этой софтины слабое место, в которое НЕ НАДО тыкать…

Нехорошее соображение: программисты не рекомендуют тестировщикам находить экзотические баги под самый финал проекта.

Некстати подумалось, что если рискнуть, то можно дальше не читать, просто знайте, что убийца — не садовник…

Поэтому вариант «А давайте в режиме свободного падения покопаемся в программе, может быть, и найдём что-то…» мне не нравится КОТЭГОРИЧЕСКИ. Многовато экзотики. Потенциально можно доказать, что программа обладает страшными недостатками, но можно ли доказать, что она делает то, что…

А, кстати, программа уже делает то, что должна делать, без ошибок? Нет информации. Предположим, что я заказчик, который не врубается в градации экзотичности багов, и хочет, соппсно, получить софт, который будет делать то, что ему нужно… И как водится, предположим, что тестировщиков в проект пригласили просто потому, что кто-то убедил заказчика в том, что тестировщики — прекрасные эмуляторы «конечного пользователя». Следовательно, самая важная информация, которая должна приходить от тестировщиков — будет ли удовлетворён конечный пользователь, а он будет удовлетворён в принципе потому, что программа будет делать то, что она должна делать…

Вернёмся к исходникам:

  1. проект «вот-вот» надо сдавать,
  2. дальнейшая работа над проектом не объявлена,
  3. у тестировщиков есть ТОЛЬКО две возможности:
    1. или проверять проект по тест-кейсам,
    2. или «тыкать проект» в поисках ранее пропущенных багов.

Ваше решение, фельдмаршал?

Решение такое: проверять проект по тест-кейсам.

Если есть время, то следует методично и последовательно убедиться ЕЩЁ раз в том, что программа делает то, что она ДОЛЖНА делать.

Палюбасу эта информация важнее всего.

Итого: мне сказали, что в последний момент перед сдачей проекта надо тыкать в свободном режиме в надежде поймать какой-нибудь неведомый баг.

Я отказался.

Мне отказали.

big bang theory proved

Ваша оценка:

Поделиться ссылкой:

  • Tweet
  • по электронной почте
  • Печать

Понравилось это:

Нравится Загрузка...

Похожее

Опубликовано в Рекрутинг, Соображения, Учеба в бою | Отмечено Ватерлоо, Карл Маркс | 9 комментариев

комментариев 9

  1. на 18.10.2015 в 10:24 NazguaL

    А было подозрение, что тест-менеджерам просто поставили задачу подготовки (и может еще и проведения) презентации работающего продукта перед представителями заказчика?
    И что-бы не сфейлиться как в этом видео: https://www.youtube.com/watch?v=W0UaVwnOCmo# они, не долго думая, решили что потыкать в вободном поиске хорошая идея, вдруг чего-то да найдется…
    Хотя, даже при постановке задачи проведения презентации, если подольше подумать, то правильным будет выполнять тесты по тесткейсам: прогнать тесты на презентационном окружении и скомпилить презентацию из шагов и данных тест-кейсов.

    НравитсяНравится


  2. на 06.06.2015 в 09:40 testm0re

    наверное они имели в виду только Positive testing в свободном режиме.

    НравитсяНравится


    • на 06.06.2015 в 13:37 Алексей Лупан

      Имели бы ввиду, так и сказали бы, не?!

      НравитсяНравится


  3. на 06.05.2015 в 15:20 Vlad Pilipenko

    Хм. Я бы в первую очередь, наверное, сросил бы, а что от тестировщика, приглашенного к концу проекта, все-таки ожидают. Дальше старался бы попасть в ожидаение. Или отказался бы наотрез, если бы увидел, что по тем или иным причинам не потяну.
    Так что я бы ответил(сделав умный вид и надув щеки, хотя я ни разу формально такой деятельностью не занимался), наверное, что начал бы я с написания краткого тест-плана и согласования его с заинтересованными лицами. Чтоб потом не получить негатива из-за того, что ожидаемую работу я не выполнил.
    А то из такой постановки задачи вообще ничего не понятно. Тест-кейсов, допустим, вообще может не быть.

    НравитсяНравится


    • на 06.05.2015 в 16:20 Алексей Лупан

      Подобные вопросы (с ограничением по предоставляемой информации) хороши тем, что можно наблюдать за поведением кандидата практически в естественной среде. О чем подумает? О чем спросит? На чём будет настаивать? Что постарается предусмотреть? Почему?

      Тест-планы я в ту пору презирал 🙂

      НравитсяНравится


  4. на 05.05.2015 в 09:21 Anton Khayrutdinov

    Вопрос из серии «Стоят два стула: на одном пики точеные..». Если они ожидают на этот вопрос однозначный ответ, который они выбрали заранее, — то они «очень интересные люди», как любят выражаться англичане (наши обычно говорят «мудаки»).

    НравитсяНравится


    • на 05.05.2015 в 10:03 Алексей Лупан

      Есть разные ситуации и разные решения для ситуаций.

      Может, им мой нос не понравился. А может, суждение (оно не безусловно верное, хотя и сегодня мне оно кажется верным). А может, хз что ещё.

      Всё это не делает этих мудаков мудаками 🙂 Может, сегодня там уже другие тест-манагеры, другие подходы, и вопросы на собеседованиях другие.

      НравитсяНравится


  5. на 05.05.2015 в 04:55 Serhio

    А удалось таки узнать какой был ожидаемый ответ? 🙂

    НравитсяНравится


    • на 05.05.2015 в 06:55 Алексей Лупан

      Я не тот человек, которому сообщают причину отказа о найме ))

      Да и если бы было о чем говорить, я все равно предложил бы в указанных обстоятельствах проверять проект по тест-кейсам, а не как они там сказали, что «нет, надо в свободном режиме».

      НравитсяНравится



Обсуждение закрыто.

  • Aut bene

    Спiвпрацювальник по підготувальні тестувальників.

    Автор [глоссария] терминологии тестирования (english).

    Неоднократный докладчик [SQA Days], [QA Fest] и других конференций по тестированию ПО.

    Неспешный езжун на «[Волга ГАЗ-21]» 1965 года выпуска.

    Игрун чего-то похожего на тяжелый блюз [на классической гитаре].

    И так [далее].

  • Присоединиться к ещё 1 338 подписчикам

  • Follow Normal testing on WordPress.com
  • Залежи

  • Темы

    • Без рубрики (6)
    • Документация (18)
      • Тест-план (2)
    • Изображения (148)
      • Видео (48)
      • Комиксы (20)
      • Скриншоты (48)
      • Фотографии (46)
    • Инструменты (53)
      • Debian (13)
      • Макросы (1)
      • Трекеры (15)
        • Баг-трекер (8)
        • Тест-трекер (5)
      • LibreOffice (4)
    • Книги (19)
    • Конференции (137)
      • Подкасты (12)
      • Презентации (50)
        • Слайдкасты (10)
      • Семинары (18)
    • Обзоры (1)
    • Постановка мозгов (245)
      • Банальное (168)
        • Не смешно (47)
        • Неприятно (14)
        • Печали (15)
        • Радости (57)
        • Смешно (35)
      • В гостях у психиатра (45)
        • Поросенок v2.0 (3)
        • Странности (12)
        • Удивительные баги (17)
      • Level 80 (2)
    • Соображения (206)
      • Балабольник (10)
      • Гипотезы (11)
      • Озарения (55)
      • Откровения (88)
    • Статьи (23)
      • Интервью (6)
      • Опросы (1)
      • Переводы (11)
    • Управляторское (56)
      • Agile (13)
      • Программисты (23)
      • Рекрутинг (8)
    • Учеба в бою (83)
      • Тренировка (13)
      • Фишки (28)
      • Читерство (9)
    • Testing like… (79)
      • Acceptance testing (5)
      • Business Driven Testing (2)
      • Context-driven testing (2)
      • Defect-based Test Design Technique (1)
      • Автоматизация (37)
        • Performance Testing (5)
      • Рецессионное тестирование (1)
      • Юзероиммитатор (15)
      • Exploratory testing (9)
      • тест-дизайн (8)
      • State Transition testing (1)
      • Unit testing (1)
      • Usability testing (2)
    • To Do (12)
      • Анонсы (7)
  • Тэги

    Calc Excel James Bach Jira Mantis SQA Days SQA Days 7 SQA Days 8 SQA Days 10 Александр Александров Александр Орлов Алексей Баранцев Наталья Руколь Хватит тупить Юля Нечаева
  • Самое читаемое

    • Тестируем поля логин/пароль
    • Priority & Severity на пальцах обезъянок
    • Группирование данных в Excel
    • Как в Excel отображать символ валюты перед цифрами
    • План тестирования должен быть внятным, четким, небольшим
    • Основные положения тестирования
    • Разница между ошибкой (багом) и дефектом (тоже багом)
    • Что такое перформанс-тестирование
    • Ссылки в Confluence. Mazafaka
    • Мелочь пузатая или Объем тест кейса против его содержательности
  • Комментарии

    • Alexei Lupan к записи Сетап для преподавания в сети
    • Дмитрий к записи Сетап для преподавания в сети
    • Сетап для преподавания в сети | Normal testing к записи Оценка времени на тестирование: неочевидные надводные камни
    • Мария к записи Выделить вкладку страницы в фокусе в Firefox
    • Alexei Lupan к записи Савин, Фолкнер и Нгуен…
    • Тимур Исхаков к записи Савин, Фолкнер и Нгуен…
    • Alexei Lupan к записи Кагбэ собеседования в паблике
  • Блоги о тестировании

    • 1) Блоги тестировщиков на software-testing.ru
    • Про тестинг
    • Selenium IDE — rulezzz!
  • Профессиональное

    • Удобный софт
    • Управление тестированием
    • IT Crowd wikiquotes
    • Testing History

На платформе WordPress.com.

WPThemes.


Отмена
loading Отмена
Сообщение не было отправлено — проверьте адреса электронной почты!
Проверка по электронной почте не удалась, попробуйте еще раз
К сожалению, ваш блог не может делиться ссылками на записи по электронной почте.
Политика конфиденциальности и использования файлов сookie: Этот сайт использует файлы cookie. Продолжая пользоваться сайтом, вы соглашаетесь с их использованием.
Дополнительную информацию, в том числе об управлении файлами cookie, можно найти здесь: Политика использования файлов cookie
%d такие блоггеры, как: