Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть
Шериф в Нуар-сити
  • Тестирование. Фундаментальная теория

  • Суровая реальность начинающих тестировщиков. Пособие: что и как учить

    На самом деле, где-то четверть (по личным наблюдениям) практикуются.
    Но, зачастую, так получается, что человек берет софтину и начинает активно искать баги, а не тестировать, чем потом неистово хвастается на собеседованиях.
    Тут желательно присутствие некого подобия ментора, который даст стартовый пинок и покажет, как надо.

  • Тестировщик vs программист

    Когда я шел в тестирование, у меня были точно такие же мысли (а-ля «пару лет потестить, набраться опыта, и программеры»). Всё от поверхностного понимания процесса и перспектив карьерного роста. Но, ничего, понимание пришло после первого же собеседования.
    Хотя, по сути, если тестер переквалифицируется в дева с течением времени — в этом страшного нет ничего, дело ведь в понимании своей работы и отношению к ней.
    Такие «недо-программисты-тестировщики» преимущественно в любой сфере будут партачить и халатно относиться к своим обязанностям.

    Поддержал: Mark Neramik
  • Тестировщик vs программист

    Вообще замечаю, что у многих подобное представление о работе QA.
    Скорее всего, ноги растут от печального опыта работы с некорректно поставленным процессом. Ну и сложившихся, в связи с этим, стереотипов.

  • Тестировщик vs программист

  • Кому звонят HR’ы

    Всем ТС-мужчинам на тему «хочу в IT» можно советовать пол сменить? :)
    По сути — подтверждаю, тоже сталкивался с прецедентами, когда брали людей, руководствуясь непонятно какой логикой. Но... Хозяин-барин =\

  • Джун QA или что я делаю не так?

    Все зависит от того, как построен процесс разработки :)
    Иногда приходят задачи с заголовком типа «Реализовать функцию n», со статусом «готова к тестированию» и пустым телом.
    Когда задействованы сложные бизнес-процессы, и точно не знаешь, что затронула/не затронула реализация остается только втихую материться, идти выяснять подробности к постановщику/ разработчику, в сотый раз напоминать, чтобы описывали задачи более объемно и в итоге самому описывать логику, чтобы в дальнейшем хотя бы иметь возможность в этом разобраться.
    Само собой, в нормальных конторах такого наблюдаться не должно :)

    Поддержали: Yuliya Pasechnyk, Alex Fogol
  • Джун QA или что я делаю не так?

    Всё-таки, считаю, что при сферически правильном построении процесса выше будет стоять умение определить и хотя бы поверхностно спроектировать минимальный набор тестов на основании спецификации/ТЗ/юзкейсов.
    На практике часто приходится и без этого обходиться, опираясь лишь на логику и общее понимание конкретных бизнес-процессов :)

    Поддержали: Yuliya Pasechnyk, Alexey Sych
  • Джун QA или что я делаю не так?

    Погуглил нашел форум и стало интересно сколько же находили такие же тестировщики как и я. Некоторые писали 10, а другие 100.
    Что ж все акцентируют внимание на количестве найденных багов?
    Однажды тоже прислали тестовое (найти и описать ошибки). Так получилось, что времени на выполнение осталось всего-ничего — ночь и утро. Естественно, от проектирования и написания кейсов отказался, пошли в ход наиболее очевидные пользовательские сценарии.
    Какое-то время было уделено monkey testing.
    В итоге, на утро имел 20+ осмысленных репортов и короткое описание того, что было проверено.
    Получил замечания за сравнительно небольшое количество багов («некоторые кандидаты и по 70 присылали») и за «описание не как тестировщик, а как разработчик» (некоторый функционал при разных входных данных давал на выходе абсолютно разные некорректные результаты; не имея исходников на руках, посчитал, что целесообразнее предложить вариант правильной реализации, чем разбираться, как же оно всё-таки работает на данный момент).
    Удручает.
    Поддержал: Yuliya Pasechnyk