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

Normal testing

From the programmer's worst friend

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

А теперь ситуация изменилась

19.11.2012 Автор: Alexei Lupan

Махмуд, поджигай!

Ведь это же прекрасно, ящетаю:

Еще лет пять назад, когда мы нанимали тестировщиков, мы делали это в предположении, что вообще работа эта не очень квалифицированная (то есть большого ума не требует), но хороший старт в компании. Человек потестирует годик, а потом мы его (ну, чаще всего, ее:) переквалифицируем в аналитики или в менеджмент какой-нибудь. Ну, или в декрет проводим 🙂 И, в общем-то, это устраивало обе стороны.

А теперь ситуация изменилась. Тестировщики стали хотеть заниматься тестированием и QA. В эту профессию приходят очень неглупые люди. С амбициями. Они активно учатся. У них получается. Они достигают в этом деле очень неплохого уровня в среднем, а кое-кто уже считает себя гуру 🙂

Теперь вопрос: а готова ли компания вообще и руководители разработки в частности к такому развитию событий?

Alexander Chernin ©

Ваша оценка:

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

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

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

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

Похожее

Опубликовано в Радости, Соображения | Отмечено Александр Чернин, Red Hot Chilli Peppers | 7 комментариев

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

  1. на 28.11.2012 в 10:22 Nikita Knysh

    Степень «готовности» может сильно отличаться и внутри одной компании. Мой заказчик одним депертментом набирает только сильных тестировщиков, требует высокой продуктивности и ставит серъёзные задачи (автотесты, CI, technical tests), а другим департментом — не берёт тестировщиков совсем, аргументируя тем, что и без них никакой катастрофы не происходит.

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


  2. на 23.11.2012 в 02:09 Roman Podolyan

    > Теперь вопрос: а готова ли компания вообще и руководители разработки в частности к такому развитию событий?

    Это зависит от заказчика/компании/команды. Есть готовые. Есть не готовые.

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


    • на 23.11.2012 в 02:10 Roman Podolyan

      Вернее даже, не столько не готовые, сколько не желающие / не заказывающие / имеющие другие приоритеты.

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


  3. на 21.11.2012 в 13:35 Рина

    Согласна с Димой.
    На работе таже ситуация.
    Не готовы. совсем.
    а то что начинают тестировать иногда очень даже раздражает. (меня лично)
    я же не лезу править сама баги в их код? Даже если знаю как и имею доступ?
    нипарядок(

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


    • на 23.11.2012 в 02:31 Roman Podolyan

      Кого раздражает, а кого и не раздражает 🙂

      Меня вот больше раздражает, когда после коммита и билда эта задача помечена как fixed, а она не работает, а потом «Ой, я не то закоммитил». Закоммитил — вот возьми и проверь сразу, меньше новых билдов надо будет делать.

      А если нерабочий код будет закоммичен в транк, и билд не собирается, то зла будет вся команда, и в случае рецидивов такого разработчика могут довольно скоро уволить.

      Или вот раздражает э-ле-мен-тар-ное отсутствие проверки ввода пустой строки для поиска. Блин, программеры, это ж первое, что я сделаю.

      Или вот вспоминается, как на проекте N разработчику выделили время и дали задачу написать автотесты для сервера, потому что чем быстрее выявляются большие проблемы в новой сборке сервера, тем меньше времени теряется впустую (если без автотестов, то проблема может быть выявлена минут через 40, а не через 10, и все по новой).

      Крооооооме того, если так широко посмотреть, то даже code review это white box testing, а оно-то уж точно является рекомендованной на ряде проектов практикой.

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


  4. на 20.11.2012 в 01:55 dzhariy (@dzhariy)

    Мало того, и разработчики начинают все больше и больше тестировать. Вот и получается, что разработчики пишут программы, в которых все меньше и меньше багов. Тестировщики хотят управлять процессами. Что же остается руководителям проектов? – Только идти и кликать на кнопки по екселю 🙂

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


    • на 23.11.2012 в 02:21 Roman Podolyan

      There’s so many different worlds,
      So many different suns
      And we have just one world,
      But we live in different ones.
      (c) Dire Straits, «Brothers in arms»

      Видел разных заказчиков, видел разные проекты, разные приоритеты, разных разработчиков и разный код.

      — Заказчик может навешать на разрабочиков столько, что им будет вообще не до тестирования
      — Разработчики очень даже могут считать, что не их («касты» 🙂 ) это дело
      — Заказчик может не выделять времени/денег на какие-то виды тестирования вообще (автотесты, тестирование серверной части, да что угодно).
      — Приоритетом проекта может быть выкладывание приложения в appstore еще до того, как оно будет хорошо протестировано
      — Наконец, в заказе-«доработке» первая версия может прийти страшно глючное приложение на говнокоде — непонятно, что за *люди* это разрабатывали и как оно тестировалось, блин (если вообще тестировалось).

      Проекты бывают очень разные, и далеко не во всех картина сколь-нибудь близка к райской.

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



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

  • Aut bene

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

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

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

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

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

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

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

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

  • Темы

    • Без рубрики (6)
    • Документация (18)
      • Тест-план (2)
    • Изображения (149)
      • Видео (49)
      • Комиксы (20)
      • Скриншоты (48)
      • Фотографии (46)
    • Инструменты (53)
      • Debian (13)
      • Макросы (1)
      • Трекеры (15)
        • Баг-трекер (8)
        • Тест-трекер (5)
      • LibreOffice (4)
    • Книги (19)
    • Конференции (138)
      • Подкасты (12)
      • Презентации (50)
        • Слайдкасты (10)
      • Семинары (19)
    • Обзоры (1)
    • Постановка мозгов (246)
      • Банальное (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 Александр Александров Александр Орлов Алексей Баранцев Наталья Руколь Хватит тупить Юля Нечаева
  • Самое читаемое

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

    • Alexei Lupan к записи S3E13: Про Тест планы и тест стратегии в 2020 году
    • esculapandreevgmailcom к записи S3E13: Про Тест планы и тест стратегии в 2020 году
    • Alexei Lupan к записи Сетап для преподавания в сети
    • Сергей к записи Сетап для преподавания в сети
    • Alexei Lupan к записи Сетап для преподавания в сети
    • Дмитрий к записи Сетап для преподавания в сети
    • Сетап для преподавания в сети | Normal testing к записи Оценка времени на тестирование: неочевидные надводные камни
  • Блоги о тестировании

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

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

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

WPThemes.


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