Чем отличаются настоящие тестировщики от поддельных?

    Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.

    Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.

    Первой праведной мыслью было: тестирование обидели!

    На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.

    Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!

    Кто они?
    Как отличить настоящих джедаев от поддельных тестировщиков?

    Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.


    1. Настоящие тестировщики с проектом заодно.


    Настоящие тестировщики не враги программистам. Настоящие тестировщики не ставят своей целью «сломать продукт», после чего ехидно потирать ладоши. Настоящие тестировщики вообще не радуются наличию проблем, багов, дефектов и ошибок!

    Чтобы приносить проекту пользу, тестирование должно выступать в роли сервиса. Баги — не продукт, который можно выпустить. Баги не приносят пользы. Пользу приносят только активности, нацеленные на достижение общих целей.

    А для этого нужно:
    * учитывать цели проекта
    * адаптироваться под внешние условия (приоритеты, сроки, цели, верхнеуровневые задачи)
    * уметь выяснять: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достигнуть цели?

    Если тестирование неэффективно, ошибки находятся поздно, а заводятся низкокачественно, то их будет больше и больше: плохая локализация дефектов отнимает время у разработчиков, а их заведение в неприоритетном порядке ведёт к трудностям в исправлении.

    Поэтому, вместо задачи «как бы мне найти кучу багов и заDDOSить разработчиков», настоящие тестировщики думают: «Что сейчас нужно проекту, в каком формате и с какими приоритетами?».

    2. Настоящие тестировщики умеют проектировать тесты.


    Никакого манкикликинга и быдлотестинга!
    Настоящие тестировщики умеют проектировать тесты. Для этого они как минимум зазубрили библию проектирования тестов от Lee Copeland'a, а как максимум — освоили контроль рисков качества.
    В зависимости от условий, тестирование может проводиться эксплоративно или по тест-кейсам, но тесты делаются не от балды «понажимаю-ка я кнопочки», а только по результатам анализа: что нужно тестировать, в каком приоритете и каким образом это можно сделать наиболее эффективно?
    Для этого любое тестирование начинается с исследования продукта, влияющих на его работу факторов, и их последующего разбиения на классы эквивалентности.

    Сначала — думать, потом — тестировать!

    3. Настоящие тестировщики понимают архитектуру тестируемого ПО.


    Чтобы быть настоящим тестировщиком, вовсе не обязательно быть продвинутым разработчиком. Но для понимания того, как эффективно тестировать ваше приложение, вы просто обязаны знать его архитектуру!
    Black-box testing не позволяет детально происследовать продукт, и тестирование только «со стороны пользователя» приводит к тому, что неучтёнными оказываются многие влияющие на работу ПО факторы.
    Black-box testing — это тестирование в чёрном ящике без окон и с закрытыми глазами. Вы идёте наощупь, натыкаетесь на какие-то шероховатости в продукте, и заводите на это ошибки «где-то в левом углу что-то не так».
    Откройте глаза и включите свет! Посмотрите, что вы тестируете!

    Узнав, как работает ПО, вы сможете:
    * эффективнее проектировать тесты
    * обеспечивать более высокое покрытие, зная влияющие на работу ПО факторы
    * точнее и грамотнее локализовывать ошибки — а значит, экономить время разработчиков и проекта в целом!

    4. Настоящие тестировщики — мастера коммуникаций.


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

    О том, как коммуницировать с разработчиками на предмет дефектов — запись выступления Алексея Баранцева на встрече Московского Клуба Тестировщиков.

    5. Настоящие тестировщики прекрасно разбираются в прикладной области.


    Как-то раз я проводила аудит процесса тестирования в московской компании, занимающейся разработкой бухгалтерского ПО. По мнению руководства компании, тестировщики пропускали слишком много дефектов. Причина оказалась простой: аналитики компании (2 шт.) писали тест-кейсы для тестировщиков компании (~15 шт.). Тестировщики проходили их и регистрировали все отклонения в поведении ПО от задокументированного в тест-кейсах.
    При этом они даже не понимали, что такое сальдо и по какому принципу формируются отчёты!

    Естественно, это не могло приносить высокого качества тестирования. Аналитики, не зная подходов к проектированию тестов (так как это не их работа), не могли оптимизировать тестовое покрытие. А горе-тестировщики лишь искали отличия между непрерывно устаревающими тестами и поведением программы. Если что-то шло «не так», и это «не так» не было задокументировано в тестах, то они даже не понимали, что перед ними дефект.

    Чтобы такого не происходило, настоящие тестировщики должны знать, как работает продукт. Они должны знать пользователя, его ментальную модель: как используется продукт? В каких условиях? Каким образом?

    6. Настоящие тестировщики не бывают экспертами.


    Если вы слышите слова «я настоящий эксперт!», значит, перед вами ненастоящий тестировщик. Потому что быть экспертом в едва складывающейся отрасли невозможно. Потому что методологическая база ничтожно маленькая, и даже она меняется непрерывно.

    С неумолимой скоростью появляются новые техники и подходы. Продвинутые тестировщики всех направлений создают её, создают прямо сейчас!

    А как можно быть экспертом в области, которая пока что не сформировалась? Которая слишком гибка, чтобы в ней можно было что-то назвать «правильным»?

    «Я эксперт!» = «Я больше не буду развиваться». А это НЕ про настоящих тестировщиков.

    7. Настоящие тестировщики выбирают цели, а не средства.


    Как часто автоматизируются тесты с отрицательным ROI просто потому, что автоматизация — это «круто», а ручное тестирование — это «скучно»? Как часто тесты документируются, превращаясь в ворох бесполезных и неповоротливых бумажек, просто потому, что это «солидно»?

    В тестировании (как, наверное, и в других областях?) многие решения принимаются исходя из «круто», «интересно» и «а давайте попробуем?».

    Но ведь понятие «крутости» не абсолютно! В каждом проекте, в каждой команде свои условия работы, и эффективное тестирование всегда определяется контекстом!

    Когда настоящие тестировщики принимают решение что-либо внедрить, они говорят: «Нашему проекту это будет полезно, потому что ...». И эти слова отличают настоящего тестировщика от поддельного больше, чем что бы то ни было ещё.

    8,9,10. Настоящие тестировщики любят свою работу, любят свои продукты и непрерывно развиваются.


    Для соответствия десяти задекларированным пунктам, вкратце освещу ещё три:
    * Настоящие тестировщики ЛЮБЯТ свою работу, всегда находят в ней творчество, и у них не может быть рутины! Потому что каждая новая задача выполняется лучше, качественнее, эффективнее — а значит, интереснее и интереснее!
    * Настоящие тестировщики любят свои продукты. Невозможно тестировать софт и быть деструктивистом. Задача настоящего тестировщика — сокращать количество дефектов, принимать превентивные меры, проводить тестирование на ранних стадиях, так чтобы серьёзные дефекты и не появлялись вовсе. А эти цели несовместимы с деструктивизимом, для их достижения продукт надо не ломать, а любить.
    * Настоящие тестировщики непрерывно развиваются. И развивают молодую неокрепшую отрасль!

    Выводы


    Настоящие Тестировщики сделают выводы сами :-)

    А я просто хочу сказать этим редчайшим людям, которых можно заносить в Красную Книгу: «СПАСИБО!».
    Спасибо, что не стоите на месте.
    Спасибо, что приносите пользу проектам.
    Спасибо, что развиваете отрасль!
    Поделиться публикацией
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 79
      0
      интересно написано, не согласен с пунктом 6, немного непонятно описан пункт 7, абсолютно согласен с пунктом 1
      Кстати, несколько человек из Portnov Computer School (из Кремниевой, а не Силиконовой долины) ко мне приходили на интервью — пока никто из них не прошел даже первое собеседование (без выводов, просто факт)
        +2
        А в чём именно не согласны с п.6?
          +1
          Выскажу, в чем я не согласен с п.6, пока коллега молчит:
          Сказать «Я эксперт» — можно в разном контексте (см. пункт 7). Например, когда в борьбе за тендер нужна оценка какого-то специалиста два года занимавшегося тестированием биллинговых систем — мы, да и сам специалист, может назвать себя экспертом в данной области.
          Просто потому что нам нужна «экспертная оценка в данной области».
          ***
          А в целом же, я понимаю, что суть 6 пункта в том, что говорить «Я настолько крутой тестировщик, что аж дальше некуда» — мягко говоря глупо. (:
            +2
            Поняла, согласна.

            Ваша формулировка «Я настолько крутой тестировщик, что аж дальше некуда» значительно лучше передаёт смысл того, что я пыталась передать словами «нельзя быть экспертом». ;)
              +1
              «Супер-дупер Крутой» и Эксперт — разные вещи. Если у вас проект с очень сжатыми сроками (как это обычно бывает) — вам необходим действительно эксперт в данной области, а не «настоящий тестировщик», который будет и готов развиваться.
                0
                Кажется именно это, но другими словами я и написал выше.
            0
            Всё-таки там зачастую продвинутые пользователи ПК с непрофильным образованием (или без него вовсе), которые надеются найти в тестировании свою золотую жилу, с помощью которой свершится их американская мечта. (Сам там не был, но периодически почитываю ресурс где Портнов выступает не хуже Шахиджаняна).
              0
              А что за ресурс? Govorimpro.us?
            0
            Про выпускников, которые к вам на интервью приходили. Из чистого любопытства — они сразу к вам после школы приходили и не прошли, или уже после какой-то работы?
              0
              уже с опытом работы
            –1
            Простите, а вы сами давно тестированием занимаетесь?
              +2
              Развейте свою мысль :)
                +4
                там нет мысли.там прямой вопрос.
                –1
                [gn]На ветру?[/gn]
              –1
              > Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко.

              и так же легко получать при таком подходе на уровне грузчика или дворника.

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

                  Врядли в таком случае потенциал полученных знаний будет раскрыт.
                    0
                    Обычно из знаний прикладной области все остальное следует. Но обратное — нет.
                      0
                      То есть по вашему из стремления правильно спроектировать тест не появится знание проекта?

                      Показательтный пример, когда правильный тестировщик первые дни\недели на проекте остается на пару часов дольше, чтобы лучше изучить проект.
                    +1
                    Заявление логично, но часто наблюдаю обратное.
                      0
                      нравится работать в командах, где бизнес-аналитики занимаются еще и тестированием, а тестировщики еще и анализом.
                      0
                      Это же приятно «сломать продукт», после чего ехидно потирать ладоши. Как вы без этого живёте?
                        +2
                        Успешный релиз, вовремя и сплачённой командой — куда приятнее!
                          +1
                          добавьте, что настоящий тестер не занимается замалчиванием. его задача находить баги и радоваться этому.
                          Я работая программистом подсказываю тестировщику, где искать баги, затем двоём радуемся, что нашли и заранее догадались где тонкое место.
                        0
                        Спасибо за статью, но когда я читаю подобные заметки про тестирование, единственная мысль, которая приходит в голову: «Вы занимайтесь тестированием, ну не отчаивайтесь!».

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

                        Извините, но подобные статьи, как мне кажется, вносят еще большее непонимание между разработчиками и тестерами.
                          +8
                          > Я сам в тестирование больше 3 лет и сменил несколько направлений и компаний,
                          > но отношусь к этому как к работе.

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

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

                          Каждому своё, надо искать и не насиловать себя.

                          «Найдите себе работу по душе, и вам не придётся работать ни дня в своей жизни» — Конфуций.
                            0
                            Я никак не хочу сказать, что мне не нравится тестирование. До него я тоже кем только не был. Просто, я встречал людей, которые ничего не знают кроме «пасс» или «файлед», но отчетливо думают, что они профессионалы. Я считаю, что хороший тестер, просто обязан пытаться расти либо в программисты, либо в управление, так как те навыки, которые он будет приобретать в процессе роста, дадут пользу всей компании.
                              +5
                              Зачем быть тестировщиком чтобы стать программистом?

                              Если тестировщик работает для того что-бы стать программистом, то значит он зря тратит своё и чужое время :)

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

                                  Если нужно стать программистом, так нужно взять и стать им, тестирование не является естественным этапом роста к программированию.

                                  Вообще тестирование и программирование две параллельно идущие ветки, нельзя работая программистом статья хорошим тестировщиком, а работая тестировщиком статья хорошим программистом. Данный рост не естественен.
                                    0
                                    Согласен.
                                    Просто понятие «программист» — несколько шире, чем «разработчик». Я хотел указать именно на это: хороший тестировщик должен уметь программировать.

                                      0
                                      Удивительно. Понятие «селедка» шире чем понятие «рыба» — если перефразировать ваше предложение.
                                      По мне так программист — это разработчик. Тестировщик — тоже разработчик. И аналитик, и архитектор и релиз инженер.
                                        0
                                        Разные взгляды. Меня учили, что разработчик — то кто занимается непосредственно разработкой, программист — разработчик + тот кто выполняет смежные задачи разработки (например, специалист занимающийся юнит-тестированием).

                                        Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.
                                          +1
                                          Зачем? В каких именно ситуациях это необходимо?
                                            0
                                            Кейсов много, во многом они зависят от контекста проекта.
                                            В моей практике, например, был случай, когда ошибка возникала в многопоточной обработке некоторой сущности. То есть в реальных условиях проявлялась в одном случае на (боюсь соврать, но...) миллион.
                                            Это вскрылось во время пристального изучения кода тестировщиками (специфика проекта позволяла и во многом одобряла белый ящик), и соответственно верифицировалась через код ревью ими же.
                                            ***
                                            Случай, конечно, нетривиальный, но много багов было найдено подобным образом в рамках проекта (анализ кода там был неотъемлемой составляющей для понимания работы системы вцелом).

                                            Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).

                                            0
                                            Да, возможно я смотрю с другой точки зрения и она подкреплена такими фактами:

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

                                            2) Во многих западных компаниях (средних и крупных), все кто создает ПО обычно сосредоточены под названием R&D (Research&Development) или Product Development, куда включают и программистов и тестеров и писателей и много кого еще. (Development=разработка)

                                            3) В совьет-стайл предприятиях (мне довелость поработать на ЛОМО) быть программистом — значит быть кодером. Программисты там (это должность, записанная в трудовой) пишут код по уже предоставленным и разработанным спецификациям. В рамках заданной архитектуры. От себя ничего не придумывают. И хотя их работа несомненно важна, но продукт, на самом деле, разработан людьми, писавшими требования.
                                              0
                                              Ваша точка зрения разумнее.
                                              Приму к сведению :)
                                  +4
                                  >Я считаю, что хороший тестер, просто обязан пытаться расти либо в программисты,
                                  >либо в управление, так как те навыки, которые он будет приобретать в процессе роста,
                                  >дадут пользу всей компании.

                                  Тестирование тоже не ограничивается знанием слов passed и failed!

                                  И рости нужно не обязательно в разработку/управление. Хорошо
                                    +4
                                    упс, поторопилась :)

                                    Хорошо ли вы знаете тестирование? Если надо расти куда-то ещё — значит ли это, что в тестировании вы уже знаете ВСЁ??
                                      +2
                                      никто, никогда и нигде не знает всего :) в таком виде вопрос неинтересен
                                  0
                                  Что то сразу вспомнилось: «Не стремись знать все, что бы не стать во всем невеждой.» :)
                                0
                                Я в настоящий момент ищу подрядчика на тестирование. Наверное к этот список можно соотнести и к компаниям.
                                  0
                                  Хорошая статья и очень интересные ссылки. Я бы еще добавил про управление качеством статистическими методами…
                                    +4
                                    «Я эксперт!» = «Я больше не буду развиваться»
                                    эксперт это, прежде всего, — специалист. и в этом термине нет ничего, что говорит о том, меняется он или нет :) здесь я с тобой не согласен!

                                    Я согласен с тем, что настоящий специалист должен постоянно развиваться. но это отновится не только к тестировщикам
                                      +11
                                      Извините, не удержался…

                                      Чем отличаются настоящие программисты от ненастоящих?

                                      1. Настоящие программисты с проектом заодно.
                                      А для этого нужно:
                                      * учитывать цели проекта
                                      * адаптироваться под внешние условия (приоритеты, сроки, цели, верхнеуровневые задачи)
                                      * уметь выяснять: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достигнуть цели?

                                      2. Настоящие программисты умеют проектировать.
                                      Никакого кодманкинга и быдлокодинга!
                                      Настоящие программисты умеют проектировать ПО.

                                      3. Настоящие программисты понимают архитектуру разрабатываемого ПО.
                                      … для понимания того, как эффективно разрабатывать ваше приложение, вы просто обязаны знать его архитектуру!

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

                                      5. Настоящие программисты прекрасно разбираются в прикладной области.

                                      6. Настоящие программисты не бывают экспертами.
                                      Если вы слышите слова «я настоящий эксперт!», значит, перед вами ненастоящий программисты. Потому что быть экспертом в едва складывающейся отрасли невозможно. Потому что методологическая база ничтожно маленькая, и даже она меняется непрерывно.

                                      7. Настоящие программисты выбирают цели, а не средства.
                                      Как часто НЕ покрываются юнит-тестами проекты с отрицательным ROI? Как часто код НЕ документируются, превращаясь в ворох бесполезных и неповоротливых классов и функций просто потому, что это «накладно» и код якобы уже «самодокументированный»?

                                      8,9,10. Настоящие программисты любят свою работу, любят свои продукты и непрерывно развиваются.
                                        +2
                                        главное не останавливаться, пишите руководства и к другим профессиям
                                        пару идей для творчества:
                                        Настоящий депутат, какой он?
                                        Сантехник, миф или реальность?
                                        Каким должен быть строитель в 21 веке?
                                          +1
                                          какой богатый выбор тем! но увы, оффтопик.
                                        +1
                                        Большое спасибо за стоящую статью. На предыдущем проекте мне необходимо было собеседовать тестировщиков. В ходе беседы было выяснено, что люди могут безупречно знать материал и оперировать терминами, но на поле быть полными нулями. Я разработал тестовое задание, которое включало в себя все основные активности тестировщиков, и раздал группе претендентов. Через сутки мне прислали выполненные задания. Я выбрал несколько лучших и провел с ними обычную беседу об их предыдущем опыте. И в итоге оказалось, что эти люди показывали лучшие результаты по сравнению со старичками. Тестируйте тестировщиков перед приемом на работу.
                                          +2
                                          Поделитесь заданием? Я думаю, многим будет интересно и полезно.
                                            0
                                            Задание выкладывать я не буду так как оно относилось к той специфике и закрытости проекта, но я опишу что оно в себе содержало:

                                            1. Список требований (из десяти) к мнимому продукту и краткое описание архитектуры проекта — эту секцию я готовил на основе разрабатываемого продукта;
                                            2. Задание 1: написать тест кейсы по существующим требованиям и краткому описанию продукта в волном стиле — здесь я хотел увидеть, насколько ответственно и качественно подойдут к составлению тест кейсов когда дают свободу выбора;
                                            3. Задание 2: написать несколько баг отчетов на их усмотрение, какие ошибки могли возникнуть и т.д. — здесь меня интересовал именно аналитический подход к проблеме, и как ясно и четко будет выполнена работа (некоторые рисовали мок скрин шоты, и как раз эти люди показывали хорошие результаты);
                                            4. Задание 3: подготовить отчет о проведенном тестировании;
                                            5. Задание 4: написать несколько рисков, которые могут возникнуть в ходе работы.
                                            0
                                            >>Тестируйте тестировщиков
                                            разоблачить разоблачителей?
                                            0
                                            Зачем вешать ярлыки «настоящий»/«не настоящий»?
                                            Чесно, мысль полезная как для развития впринципе любого специалиста, но стиль изложения похож на заметки про Чака Норриса.
                                            Всеравно для тестировщика его резюме, что для фотографа портфолио.
                                              0
                                              Резюме из нескольких страничек еще ничего не говорит о качествах и навыках человека в реальности. Я в них не верю.
                                                +2
                                                Если в резюме тестировщика имеются орфографические ошибки, то это говорит о навыках человека ;)
                                                Ну, и в целом умение структурировать излагаемую информацию очень важно не только для тестировщиков но и для многих других специальностей.

                                                Чтоб небыло такого (из реально полученного нами резюме):

                                                я желаю работать в создании игр, я не програмист, я творческий ручей желающий слиться с другими в реку. я хотел бы прислать идеи, продуманные или просто мысль, или рисунки. может вы укажете адрес. честно не в курсе работает ли почта, которую я укажу. оставлю и номер-можно смс.
                                                  0
                                                  Надеюсь после такого резюме вы его взяли (а не убили отказом) на работу? :)
                                                    +1
                                                    Увы. Может быть, он и слился в реку, но не в нашу…
                                                    0
                                                    Проникся.
                                                    Человек, похоже, действительно крайне творческий.
                                                      +1
                                                      !!!
                                                      если это не фейк, то это вау! :)

                                                      Взяли бы на работу — весело было бы :)
                                                      0
                                                      Все нужно проверять. Резюме не исключение.
                                                      0
                                                      Резюме не главное, главное тот опыт который получил с прошлых мест работы. Да и еще как у человека голова работает, способен ли он создавать извращенные тест кейсы или работать как робот, проверяя все по спеке и все.
                                                      0
                                                      Если вдруг кто не читал: www.rsdn.ru/article/humor/tester.xml
                                                      По теме — имхо, но сколько я работал с тестерами — больше всего нравились б\у программисты. Они хотя бы понимали что делают :)
                                                      • НЛО прилетело и опубликовало эту надпись здесь
                                                          –2
                                                          Мне тоже несколько непонятна тенденция сделать из тестера «царя и бога», возложить на него те обязанности и ту ответственность, которые никоим образом его касаться не должны.
                                                          1. давайте различать Testing Manager-а и рядовых тестеров (если тестеров 3 и больше, то обязательно нужно выделять Manager). Тест-кейсы рядовой тестер писать не должен, он должен заниматься тестированием.
                                                          2. TM действительно должен обладать квалификацией на уровне хорошего программиста и четко представлять себе архитектуру продукта. Без этого действительно никак. Рядовые тестеры могут не обладать такой квалификацией. Если продукт многофункциональный, то обучить каждого тестера будет нереально. Пока рядовые тестеры тестируют, TM общается с командой разработчиков и корректирует тест-лист. Учить всех — никакого времени не хватит. И вот как раз на позицию TM надо именно эксперта подыскивать.
                                                          3. если программеры обижаются на тестеров, то разумнее не учить тестеров коммуникабельности, а по шапке программерам надавать, дабы фигнёй не страдали. А для коммуникации лучше использовать Bug Tracker — никаких обид и всё перед глазами.
                                                          4. (или даже больше 1) Если команда воспринимает кого-либо из своих членов как врага, то тут уже виноват Project Manager или руководитель проекта. Разъяснительная работа вкупе с тимбилдингом — всё на совести руководства.
                                                          5. По приоритезации тестирования функций — этим тоже не должен заниматься TM. Точнее говоря, вместе с продуктом для тестов TM должен получать описательные документы по продукту, и, в частности, подробный перечень Сценариев Использования продукта с расставленными в нем приоритетами. Вот по этим приоритетам сценариев и должны расставляться приоритеты для Testing Cases. Если в проекте не используются Сценарии, то тут уже действительно TM приходится становиться суперменом и заниматься всей той не свойственной ему деятельностью, что описана в данной публикации.

                                                          Еще раз. Я не пытаюсь принизить роль Тестирования в общем вкладе в проект. Но и расписывать его в качестве «Супер-мозга» не стоит. Каждый должен заниматься своим делом. Роль личности, особенно в малых проектах, очень велика. А вот в больших, отлаженных проектах, такая вот супер-личность может принести больше проблем, чем пользы.
                                                            0
                                                            А вам не кажется, что вы не учли простого факта: что из тестеров должны расти ТМы?

                                                            По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
                                                            Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
                                                            Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.

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

                                                            P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.

                                                              0
                                                              Кто сказал «должны»? Кому это нужно? Самому тестеру? — Да, хочется вырасти. Нужно ли это PM-у и TM-у — вопрос. Бывает, что и не нужно. Все зависит от общей линии руководства и сложившихся правил к команде. Ну и от поведения самого тестера. Рядовой тестер, генерящий кучу идей и предложений по делу и без дела — это головная боль для всего менеджмента проекта, ибо то, что должно быть сделано в срок, скорее всего будет не сделано, ибо у этого тестера свои идеи, своё видение проекта и продукта и он уже мнит себя PM-ом и т.п. В результате то, что должно быть сделано — не делается, сроки уходят, проект тормозится. Результат — чел вылетает с работы со скоростью пробки из бутылки.
                                                              Поэтому давайте сперва определимся с тем, о каком масштабе мы говорим. Если это разовый стартапный проект — тут важна полная отдача от каждого «и еще немного». Но если речь идет о производственном процессе, отлаженном и выстроенном, то надо быть готовым, что всякие идеи по «улучшайзингу» могут быть просто не приняты или даже приняты в штыки. Приходя в такую команду, надо прежде всего выполнять то, что требуется от работника на данной позиции. Если просто «быть руками» — значит, надо просто быть руками.
                                                              +1
                                                              У Вас очень распространённый управленческий паттерн «без начальства никуда». Команда, в которой тестеры ничего не могут без ТМ-ов, ТМ-ы без РМ-ов и т.д.

                                                              Так можно делать (и более того, не меньше половины компаний так и делают), но получается ерунда. Об этом Демарко в «Deadline» классно написал, поэтому здесь подробно вдаваться не буду.

                                                              А по пунктам:

                                                              1. Тест-кейсы рядовой тестер писать не должен, он должен заниматься тестированием.


                                                              А если тестов нет (а бывают ситуации, когда исходя из контекста их НЕ ДОЛЖНО БЫТЬ)? А если в тестах ошибка? А если тесты сегодня утром устарели?

                                                              А наш тестировщик сам проектировать проверки не может, как работает продукт понимает не до конца, и тупо нажимает на кнопочки?

                                                              Хорошее решение для неуверенного в себе ТМ-а, который боится продвинутой команды. Но плохое решение для проекта и результатов тестирования.

                                                              2. Пока рядовые тестеры тестируют, TM общается с командой разработчиков и корректирует тест-лист. Учить всех — никакого времени не хватит.


                                                              И так, вместо менеджера, который мог бы развивать процесс, нивелировать риски, взращивать команду и выполнять другие не менее важные менеджерские задачи, мы получаем редактора таблиц. Круто!

                                                              3. если программеры обижаются на тестеров, то разумнее не учить тестеров коммуникабельности, а по шапке программерам надавать, дабы фигнёй не страдали.


                                                              И впрямь! Мы уже получили команду тестеров-зомби, кликающих на кнопки, давайте ещё демотивируем разработчиков и получим абсолютно нерабочий проект. И что самое главное — руководителю с таким подходом будет не скучно! Везде он будет видеть проблемы, всё будет валить на сотрудников, а в своём глазу не заметит бревна.

                                                              Так и делают многие руководители, и вполне логично зачем.

                                                              5. вместе с продуктом для тестов TM должен получать описательные документы по продукту, и, в частности, подробный перечень Сценариев Использования продукта с расставленными в нем приоритетами. Вот по этим приоритетам сценариев и должны расставляться приоритеты для Testing Cases


                                                              О да!
                                                              Представим, что у нас небольшой проект: полгода, 3 разработчика, 1 РМ, 1 ведущий тестировщик. Почему бы нам вместо нескольких совместных обсуждений не потратить первые из 4х месяцев на документирование? Неважно, что после прототипирования многое изменится — поменяем все бумажки ещё раз.

                                                              Я за, за, всеми руками за документацию. Но давайте не забывать про контекст — иногда она НЕ оправдана.
                                                                0
                                                                Еще раз предлагаю прежде всего определиться с исходными данными:
                                                                1. О проекте какого масштаба мы говорим: о маленьком стартапе или об отлаженном производственном процессе?
                                                                2. С позиции кого из участников проекта мы рассматриваем вопрос: с позиции рядового тестера или руководителя проекта?

                                                                Если молодой специалист собирается попробовать себя в качестве тестера в стартапе — это один расклад. Если вопросом отладки процесса тестирования озаботился PM в проекте, который уже набрал силу и собирается развиваться и дальше — расклад будет совсем другой. И уж тем более будет совсем другой расклад, если TL наконец-то задумался, как навести порядок в нескольких параллельно разрабатываемых проектах, дабы проекты, которые уже на подходе, были отработаны быстрее и принесли больше прибыли.

                                                                Моя точка зрения описывает точку зрения скорее TL. Когда надо с максимальной эффективностью использовать имеющиеся ресурсы. Когда надо чтобы тестировщик быстро и эффективно тестировал, когда надо чтобы программист не отвлекаясь на всякие дополнительные вещи программировал и т.п. В этом случае маркетинговая и организационная составляющая должны быть максимально отделены от основной работы. Маркетингом (проработкой Сценариев и т.п.) должен заниматься отдел маркетинга; составлением тест-кейсов — лидер комманды тестеров. В выстраивании четко регламентированных и документированных маркетинговых процессов и процессов разработки должен быть заинтересован прежде всего менеджмент, если он хочет снизить накладные затраты на разработку ПО и отдалить сам процесс (кстати говоря, как и в налаживании взаимоотношений внутри коллектива, что является его — менеджмента — прямой обязанностью). Рядовому работнику зачастую подобная регламентация может ограничивать свободу действий, но и позволяет больше сосредоточится на самом процессе. Действительно, подобное документирование на своем начальном этапе требует определенных дополнительных усилий и затрат, но зато делает процесс разработки максимально прозрачным и эффективным. Когда с уходом даже очень хорошего специалиста проект не рушится, а продолжает жить и развиваться.
                                                                  0
                                                                  Проект не рушится, если в команде нет «узких горлышек». Если Вы предлагаете делить команду на мозги и руки, то уход мозга — это всегда большая попа. Поэтому диверсификация знаний в коллективе лишь повышает стабильность такой команды.

                                                                  1) Если где-то нужны просто руки, то там нужна автоматизация, а не микроменеджмент мартышками.
                                                                  2) Неполнота — одно из фундаментальных свойств человеческого знания, поэтому и полной документации быть не может.

                                                                  Я руководила группой из 40 тестировщиков при чётко построенном процессе и группой из 0,5 тестировщика в стартапе. Расскажите, на что это по-Вашему влияет в данном контексте. Я пока что не поняла, какой должна быть разница в квалификации и почему.
                                                                    0
                                                                    И что, все эти 40 человек «генерили» идеи и занимались налаживанием взаимоотношений, писали тест-кейсы, разбирались в алгоритмах и т.п.?

                                                                    Я не предлагаю делить на «мозги — руки». Я предлагаю четко разделить прежде всего зоны ответственности в коллективе. Это важно и для стартапа, и для большого отлаженного производственного процесса. В зависимости от проекта и его объёма зоны ответственности могут меняться очень значительно. При этом главное — чтобы каждый человек в команде четко понимал, чего от него ждут.

                                                                    И еще раз прошу определиться по вышеуказанным двум пунктам: о каком варианте проекта и о какой точке зрения мы говорим.
                                                                      0
                                                                      И еще раз прошу определиться по вышеуказанным двум пунктам: о каком варианте проекта и о какой точке зрения мы говорим.

                                                                      Не поняла что такое точка зрения в данном контексте.
                                                                      Размер команды — пока что любой, потому что, как я уже указала выше, я не вижу в данном контексте разницы и прошу Вас её объяснить.

                                                                      Я не предлагаю делить на «мозги — руки». Я предлагаю четко разделить прежде всего зоны ответственности в коллективе.

                                                                      Зоны ответственности можно делить по-разному. По типу деятельности, по функционалу, за который человек несёт ответственность.

                                                                      И что, все эти 40 человек «генерили» идеи и занимались налаживанием взаимоотношений, писали тест-кейсы, разбирались в алгоритмах и т.п.?

                                                                      1. Откуда дровишки про идеи, написание тест-кейсов и налаживание взаимоотношений? В моём понимании, грамотные коммуникации — это ещё не налаживание взаимоотношений, а проектирование тестов (анализ и определение необходимых проверок) — это ещё не написание тест-кейсов (документирование последовательности действий, основанной на проектировании).

                                                                      2. Даже при наличии кем-то написанных тест-кейсов, тестировщик должен хорошо знать продукт, прикладную область и архитектуру для грамотного заведения дефектов. Не знает область — может пропустить ошибку. Не понимает архитектуру — не сможет качественно локализовать проблему. А в итоге это всё сводится к проблемам проекта и срывам сроков.

                                                                      3. Покрыть всё тестами априори невозможно. Всегда будет необходимость что-то проверить без тестов. И если эта проверка превратится в кликанье, вместо предварительного анализа и проектирования (которое гуру-тестер и в голове сделать может), то результаты те же — плохое покрытие и срывы сроков.

                                                                      Я согласна, что в крупных командах должно быть деление задач. Но я не согласна, что даже в очень крупных командах есть место для неквалифицированных исполнителей, которые могут только выполнять чёткие инструкции. Первое время это кажется решением, а потом всплывает слишком много проблем.
                                                                        0
                                                                        Очень странно, что Вы с вашим опытом работы не понимаете таких очевидных вещей.

                                                                        Все люди разные. Каждый преследует свои собственные цели. Большинство людей ходят на работу чтобы заработать денег. Это их цель. Еще одна цель — узнать что-либо интересное. Третья — реализовать свои амбиции. При этом большинство хочет зарабатывать как можно больше, но при этом работать как можно меньше. И уж тем более никто не хочет выполнять чужую работу. Человек, занимающий позицию ответственного менеджера наоборот заинтересован заставить людей работать, но при этом сэкономить как можно больше средств. Так вот о каком именно «тестере» вы говорите? О рядовом, который приходит на работу за деньгами, ему не очень-то интересно выполнять рутинную работу и хочется поскорее выбиться «в начальники», или о начальнике — TM, который ищет пути, как наиболее продуктивно организовать рабочий процесс с теми работниками, которые уже есть? Даже если эти люди работают в одной команде, интересы у них в общем случае разные. Да, есть «глобальный интерес» — успешное завершение проекта, но у каждого конкретного человека могут быть и другие цели.

                                                                        Поэтому и возник этот спор: Вы говорите об «идеальном» тестере, не конкретизируя условий. Я же пытаюсь подвести Вас к мысли, что в разных условиях требования к «идеальному» тестеру будут разными. И то, что хорошо и будет приветствоваться в маленьком стартапе, в крупной компании с уже отлаженными процессами производства может вызвать негативную реакцию. Вы пытаетесь убедить, что надо все время выходить на привычные рамки, проявлять инициативу, а я говорю про то, что это хорошо только в маленьком коллективе, где еще только идет разграничение зон ответственности, и то только в том случае, если проект появился стихийно, без нормальной подготовки.

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

                                                                        А про документацию я убежден, что она должна быть в каждом проекте в необходимом и адекватном объеме. Чем больше проект, чем больше людей в нем взаимодействуют, тем более четко должна быть выполнена регламентация и тем ответственней нужно подходить к документированию рабочего процесса.
                                                                          0
                                                                          1) «Почти все люди ходят на работу за баблом, им неинтересно работать и они хотят стать бааальшими начальниками» — проекция Вашего восприятия.
                                                                          Согласна, что все люди разные, поэтому говорить про «большинство» некорректно, бабло, амбиции и интерес — лишь одни из двух сотен ключевых мотиваторов.

                                                                          2) «Документация должна быть на каждом проекте в необходимом объёме» — согласна. Зачастую, необходимый объём равен нулю. Алистер Кокбёрн проводил глубокое исследование проектов, и не мог догнать, почему иногда неформальные проекты без документации значительно успешнее формальных. У него получилось вывести неплохую модель, советую познакомиться.

                                                                          А вообще, проблемы обычно возникают там, где слышится «очевидные вещи». Не надо додумывать, додумки — корень зла :)

                                                                          Мне кажется, что мы хорошо поняли друг друга и дискуссию можем закончить, обогатившись мнениями друг друга. С наступающим!
                                                              0
                                                              Устроиться тестировщиком легко


                                                              не соглашусь с этим утверждением, не так то уж и легко. С каждым годом требования к тестировщику растут. Одно из основных требований которое просто скачет — это знание английского, как письменного так и устного. Умение свободно общаться будет огромным плюсом на собеседовании.

                                                              Как говорил одни человек, что если ты супер-классный спец знаешь очень много и умеешь схватываешь всё лету, но если ты не можешь связать 2-х слов по-английский, не можешь рассказать о себе и выразить свою мысль — то ты никому не нужен. И это к сожалению правда.
                                                                0
                                                                Если отбросить тот факт, что английский нужен любому, кто занят в ИТ, то применительно к тестированию: много инструментов, описаний, хороших практик, да и нормальных книг существуют только в английском варианте. Чтобы человеку, занятому в тестировании, расти надо хотя бы свободно читать на английском — факт. Даже если кто-то работает в абсолютно российской конторе и имеет дело только с русскоязычным документооборотом.
                                                                0
                                                                Еще только начиная читать статью я сразу заподозрил какую-то откровенную попоболь на тему того, что тестировщиком может быть и обезьяна за компьютером. Да, безусловно, то что вы описали это крутой и настоящий тестировщик, с, безусловно, такими же крутыми запросами к оплате своего труда, но кому такой нужен тестеровщик то, возможно крупной компании, но и то 1, ну максимум 2 на проект, остальное же «стадо», по вашей терминологии, являются не крутые и плохие тестеры.
                                                                Зачем вообще нужно 10 человек пишущих сами себе тесткейсы, устанавливающих приоритеты, совершенно знающие предметную область, это все повергнет в хаос процесс тестирования. Всем этим должен будет кто-то руководить, тот кто будет 1 писать, устанавливать приоритеты, общаться с ПМ и тимлидами. А следовательно, все это стадо крутых и правильных тестеров, просящих за свои услуги как 2 или 3 «быдлотестера», вообще не нужны на производстве, а с учетом того, что в средних и особенно мелких фирмах, эту центральную играет в основном ПМ или ТЛ, то вообще трудно сказать нужен ли такой человек действительно предприятию, и пойдет ли он на него на условиях обычного тестера.
                                                                  0
                                                                  >Black-box testing — это тестирование в чёрном ящике без окон и с закрытыми глазами.
                                                                  Black-box testing — это тестирования программы, воспринимая ее как черный ящик без какого-либо понимания, что там внутри (если поправить очки, как я).
                                                                    0
                                                                    Вы дали определение black-box тестированию, а я дала ему оценку :)

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

                                                                  Самое читаемое