вторник, 4 октября 2011 г.

Так

Читая чужие резюме...
Стране нужны тестировщики, а в СНГ одни assurance`ы, их столько, что quality на всех не хватает.

8 комментариев:

  1. Как говорится, исторически сложилось)

    ОтветитьУдалить
  2. мы вот только сегодня обсуждали вопросы качества тестирования.
    у нас один из разработчиков уволился - уехал в Москву, к родственникам. он-то там без проблем работу найдёт, ибо человек с мозгами и неконфликтный. а вот нас всё меньше!
    и сегодня мы пытались "впихнуть невпихуемое": уложить в наш график работ и разработку, и тестирование. при том, что нас меньше, а работы - больше. я настаивала на том, что тестирование сокращать нельзя. но не все это понимают.

    ОтветитьУдалить
  3. Дык. Есть еще прикольный и почему-то не всем очевидный нюанс, на старой работе было. Меня спрашивали - а сколько надо времени чтоб проверить это. Я - дурак - отвечал на тот вопрос который и был задан. И перед самой сдачей - а куда еще помещать тестирование - оказывалось, что проверить - мало. Надо же еще исправить то, что я найду - а я найду. Не говоря уже о том, что исправления ломают продукт сильнее, чем фичи...

    ОтветитьУдалить
  4. меня прямо испугало желание некоторых разработчиков зарезать тестирование. я-то наоборот считаю, что тестирование надо ужесточить и развить как можно лучше, причём на всех уровнях. и не потому, что тестированием в основном я занимаюсь с точки зрения программирования (мне больше нравится писать прошивки и дрова, вообще говоря), а потому, что это совершенно необходимо. иначе потом дороже выходит: отлаживать и ловить баги в поле, у заказчика. ну и авторитет фирмы портится. а это немаловажный фактор.

    ОтветитьУдалить
  5. Ну так, quality нету на всех, не отчаивайся и не бери.

    ОтветитьУдалить
  6. Вот этот вопрос меня тоже периодически беспокоит.
    Например, я знаю, что один цикл тестирования займет 3 недели.
    Но ведь в процессе тестирования найдутся баги, которые
    а) тянут за собой время на исправление и перепроверку
    б) могут заблокировать проверку какой-то фичи
    в) создают при фиксинге новые баги
    и через три недели оказывается, что продукт сырой, багов много исправили, но еще больше внесли при исправлениях, состояние продукта неизвестно, надо тестить все снова.
    "Надо ускориться!" Ускоряемся, часть тестов с низким приоритетом не выполняем, укладываемся в 2 недели.
    и так может повториться и еще раз, и еще раз..

    Соответсвенно, сразу желательно закладывать надо время (как минимум): [testing_iteration_1_time] + [fixing_time] + [testing_iteration_2_time]. Но и этого часто недостаточно, а у менеджера будет вопрос "А почему так много - 2 месяца на тестирование?"

    ОтветитьУдалить
  7. Ну тестирование еще ж продать надо.

    Наверное, стоит постоянно уточнять формулировки. Не "два месяца на тестирование", а "две сессии тестов по 2 недели" (тоже невкусно, но полегче, и мы уже говорим о чистом времени).

    Или побить на микросервисы (у нас - именно так). То есть прогнать автотесты на клиенте стоит столько то часов, пробить это же руками - столько то, протестить фичу перед релизом, протестить весь жизненный путь фичи и так далее. Этакий прайс. И по отдельности - вполне допустимые трудо-и-времязатраты. И еще и объяснимые. Приемлимые.
    А потом наши ПМы хотят что-то сделать с клиентом - поставить фичу - подходят к прайсу и "покупают" набор того, чего им нужно. Какую-то фичу можно смотреть перед релизом. Какую-то надо сопровождать. А какая-то затрагивает слишком много.

    И в сумме набегают те же самые месяцы. Но они состоят из понятных - а главное самостоятельно купленных частей. Не будешь же спорить сам с собой.

    А то поди-ка складывается ощущение, что тестировщики и только тестровщики что то свое варят два месяца подряд.

    ОтветитьУдалить