Comments 79
интересно написано, не согласен с пунктом 6, немного непонятно описан пункт 7, абсолютно согласен с пунктом 1
Кстати, несколько человек из Portnov Computer School (из Кремниевой, а не Силиконовой долины) ко мне приходили на интервью — пока никто из них не прошел даже первое собеседование (без выводов, просто факт)
Кстати, несколько человек из Portnov Computer School (из Кремниевой, а не Силиконовой долины) ко мне приходили на интервью — пока никто из них не прошел даже первое собеседование (без выводов, просто факт)
А в чём именно не согласны с п.6?
Выскажу, в чем я не согласен с п.6, пока коллега молчит:
Сказать «Я эксперт» — можно в разном контексте (см. пункт 7). Например, когда в борьбе за тендер нужна оценка какого-то специалиста два года занимавшегося тестированием биллинговых систем — мы, да и сам специалист, может назвать себя экспертом в данной области.
Просто потому что нам нужна «экспертная оценка в данной области».
***
А в целом же, я понимаю, что суть 6 пункта в том, что говорить «Я настолько крутой тестировщик, что аж дальше некуда» — мягко говоря глупо. (:
Сказать «Я эксперт» — можно в разном контексте (см. пункт 7). Например, когда в борьбе за тендер нужна оценка какого-то специалиста два года занимавшегося тестированием биллинговых систем — мы, да и сам специалист, может назвать себя экспертом в данной области.
Просто потому что нам нужна «экспертная оценка в данной области».
***
А в целом же, я понимаю, что суть 6 пункта в том, что говорить «Я настолько крутой тестировщик, что аж дальше некуда» — мягко говоря глупо. (:
Поняла, согласна.
Ваша формулировка «Я настолько крутой тестировщик, что аж дальше некуда» значительно лучше передаёт смысл того, что я пыталась передать словами «нельзя быть экспертом». ;)
Ваша формулировка «Я настолько крутой тестировщик, что аж дальше некуда» значительно лучше передаёт смысл того, что я пыталась передать словами «нельзя быть экспертом». ;)
«Супер-дупер Крутой» и Эксперт — разные вещи. Если у вас проект с очень сжатыми сроками (как это обычно бывает) — вам необходим действительно эксперт в данной области, а не «настоящий тестировщик», который будет и готов развиваться.
Всё-таки там зачастую продвинутые пользователи ПК с непрофильным образованием (или без него вовсе), которые надеются найти в тестировании свою золотую жилу, с помощью которой свершится их американская мечта. (Сам там не был, но периодически почитываю ресурс где Портнов выступает не хуже Шахиджаняна).
Про выпускников, которые к вам на интервью приходили. Из чистого любопытства — они сразу к вам после школы приходили и не прошли, или уже после какой-то работы?
Простите, а вы сами давно тестированием занимаетесь?
> Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко.
и так же легко получать при таком подходе на уровне грузчика или дворника.
а вот в тех местах, где тестировщики получают эээ адекватно — и подход другой, и фиг устроишься…
и так же легко получать при таком подходе на уровне грузчика или дворника.
а вот в тех местах, где тестировщики получают эээ адекватно — и подход другой, и фиг устроишься…
Пункт 5. Настоящие тестировщики прекрасно разбираются в прикладной области.
должен быть первым. Иначе это все просто не имеет смысла.
должен быть первым. Иначе это все просто не имеет смысла.
А если прикладную область знают, но целей проекта не понимают, тесты проектировать не умеют и делают то, что «интересно», а не то, что полезно?
Врядли в таком случае потенциал полученных знаний будет раскрыт.
Врядли в таком случае потенциал полученных знаний будет раскрыт.
Заявление логично, но часто наблюдаю обратное.
нравится работать в командах, где бизнес-аналитики занимаются еще и тестированием, а тестировщики еще и анализом.
Это же приятно «сломать продукт», после чего ехидно потирать ладоши. Как вы без этого живёте?
Спасибо за статью, но когда я читаю подобные заметки про тестирование, единственная мысль, которая приходит в голову: «Вы занимайтесь тестированием, ну не отчаивайтесь!».
Я сам в тестирование больше 3 лет и сменил несколько направлений и компаний, но отношусь к этому как к работе. Да, тестирование достаточно новая и значимая часть процесса производста IT продукта, но создается впечатление, что тут просто пытаются возвести тестера в титул «Короля» IT индустрии.
Извините, но подобные статьи, как мне кажется, вносят еще большее непонимание между разработчиками и тестерами.
Я сам в тестирование больше 3 лет и сменил несколько направлений и компаний, но отношусь к этому как к работе. Да, тестирование достаточно новая и значимая часть процесса производста IT продукта, но создается впечатление, что тут просто пытаются возвести тестера в титул «Короля» IT индустрии.
Извините, но подобные статьи, как мне кажется, вносят еще большее непонимание между разработчиками и тестерами.
> Я сам в тестирование больше 3 лет и сменил несколько направлений и компаний,
> но отношусь к этому как к работе.
А я до тестирования была сисадмином, разработчиком, аналитиком, «техподдержцем» и внедренцем. И то же самое думала про каждую из отраслей, в которой работала от силы год, а потом терпение заканчивалось. Тогда мне казалось, что для интереса в работе нужно «что-то новое».
А потом я просто нечаянно нашла то, что мне интересно — тестирование. И я ни в коем случае не хочу сказать, что тестирование — интереснее других областей.
Каждому своё, надо искать и не насиловать себя.
«Найдите себе работу по душе, и вам не придётся работать ни дня в своей жизни» — Конфуций.
> но отношусь к этому как к работе.
А я до тестирования была сисадмином, разработчиком, аналитиком, «техподдержцем» и внедренцем. И то же самое думала про каждую из отраслей, в которой работала от силы год, а потом терпение заканчивалось. Тогда мне казалось, что для интереса в работе нужно «что-то новое».
А потом я просто нечаянно нашла то, что мне интересно — тестирование. И я ни в коем случае не хочу сказать, что тестирование — интереснее других областей.
Каждому своё, надо искать и не насиловать себя.
«Найдите себе работу по душе, и вам не придётся работать ни дня в своей жизни» — Конфуций.
Я никак не хочу сказать, что мне не нравится тестирование. До него я тоже кем только не был. Просто, я встречал людей, которые ничего не знают кроме «пасс» или «файлед», но отчетливо думают, что они профессионалы. Я считаю, что хороший тестер, просто обязан пытаться расти либо в программисты, либо в управление, так как те навыки, которые он будет приобретать в процессе роста, дадут пользу всей компании.
Зачем быть тестировщиком чтобы стать программистом?
Если тестировщик работает для того что-бы стать программистом, то значит он зря тратит своё и чужое время :)
Статья отличная!!!
Если тестировщик работает для того что-бы стать программистом, то значит он зря тратит своё и чужое время :)
Статья отличная!!!
Например, чтобы очень хорошо автоматизировать тестирование.
Что-бы хорошо автоматизировать тестирование, нужно быть в первую очередь тестировщиком, но конечно же в автоматизации скилы программирования используются крайне мощно, но это не значит что тестировщик программист.
Если нужно стать программистом, так нужно взять и стать им, тестирование не является естественным этапом роста к программированию.
Вообще тестирование и программирование две параллельно идущие ветки, нельзя работая программистом статья хорошим тестировщиком, а работая тестировщиком статья хорошим программистом. Данный рост не естественен.
Если нужно стать программистом, так нужно взять и стать им, тестирование не является естественным этапом роста к программированию.
Вообще тестирование и программирование две параллельно идущие ветки, нельзя работая программистом статья хорошим тестировщиком, а работая тестировщиком статья хорошим программистом. Данный рост не естественен.
Согласен.
Просто понятие «программист» — несколько шире, чем «разработчик». Я хотел указать именно на это: хороший тестировщик должен уметь программировать.
Просто понятие «программист» — несколько шире, чем «разработчик». Я хотел указать именно на это: хороший тестировщик должен уметь программировать.
Удивительно. Понятие «селедка» шире чем понятие «рыба» — если перефразировать ваше предложение.
По мне так программист — это разработчик. Тестировщик — тоже разработчик. И аналитик, и архитектор и релиз инженер.
По мне так программист — это разработчик. Тестировщик — тоже разработчик. И аналитик, и архитектор и релиз инженер.
Разные взгляды. Меня учили, что разработчик — то кто занимается непосредственно разработкой, программист — разработчик + тот кто выполняет смежные задачи разработки (например, специалист занимающийся юнит-тестированием).
Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.
Думаю, все равно мысль я свою донес: хороший тестировщик должен уметь программировать.
Зачем? В каких именно ситуациях это необходимо?
Кейсов много, во многом они зависят от контекста проекта.
В моей практике, например, был случай, когда ошибка возникала в многопоточной обработке некоторой сущности. То есть в реальных условиях проявлялась в одном случае на (боюсь соврать, но...) миллион.
Это вскрылось во время пристального изучения кода тестировщиками (специфика проекта позволяла и во многом одобряла белый ящик), и соответственно верифицировалась через код ревью ими же.
***
Случай, конечно, нетривиальный, но много багов было найдено подобным образом в рамках проекта (анализ кода там был неотъемлемой составляющей для понимания работы системы вцелом).
Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).
В моей практике, например, был случай, когда ошибка возникала в многопоточной обработке некоторой сущности. То есть в реальных условиях проявлялась в одном случае на (боюсь соврать, но...) миллион.
Это вскрылось во время пристального изучения кода тестировщиками (специфика проекта позволяла и во многом одобряла белый ящик), и соответственно верифицировалась через код ревью ими же.
***
Случай, конечно, нетривиальный, но много багов было найдено подобным образом в рамках проекта (анализ кода там был неотъемлемой составляющей для понимания работы системы вцелом).
Обобщая, в каких ситуациях это нужно: когда у нас в системе используются сложные составные сущности, взаимодейсвтие которых раскрывается в многостраничных талмудах архитектуры или раскрывается скупо в тестовой документации — разумно использовать анализ кода (эту идею я выдвигал в своем докладе на SQA8, но, к сожалению, так и не выступил с ним вживую — не позволил проект вырваться в Харьков).
Да, возможно я смотрю с другой точки зрения и она подкреплена такими фактами:
1) В большинстве случаев одного лишь программирования недостаточно для разработки продукта, которым будет пользоваться конечный пользователь. И я не говорю, что тут обязано тестирование участвовать, вовсе нет, хотя, конечно, желательно.
2) Во многих западных компаниях (средних и крупных), все кто создает ПО обычно сосредоточены под названием R&D (Research&Development) или Product Development, куда включают и программистов и тестеров и писателей и много кого еще. (Development=разработка)
3) В совьет-стайл предприятиях (мне довелость поработать на ЛОМО) быть программистом — значит быть кодером. Программисты там (это должность, записанная в трудовой) пишут код по уже предоставленным и разработанным спецификациям. В рамках заданной архитектуры. От себя ничего не придумывают. И хотя их работа несомненно важна, но продукт, на самом деле, разработан людьми, писавшими требования.
1) В большинстве случаев одного лишь программирования недостаточно для разработки продукта, которым будет пользоваться конечный пользователь. И я не говорю, что тут обязано тестирование участвовать, вовсе нет, хотя, конечно, желательно.
2) Во многих западных компаниях (средних и крупных), все кто создает ПО обычно сосредоточены под названием R&D (Research&Development) или Product Development, куда включают и программистов и тестеров и писателей и много кого еще. (Development=разработка)
3) В совьет-стайл предприятиях (мне довелость поработать на ЛОМО) быть программистом — значит быть кодером. Программисты там (это должность, записанная в трудовой) пишут код по уже предоставленным и разработанным спецификациям. В рамках заданной архитектуры. От себя ничего не придумывают. И хотя их работа несомненно важна, но продукт, на самом деле, разработан людьми, писавшими требования.
>Я считаю, что хороший тестер, просто обязан пытаться расти либо в программисты,
>либо в управление, так как те навыки, которые он будет приобретать в процессе роста,
>дадут пользу всей компании.
Тестирование тоже не ограничивается знанием слов passed и failed!
И рости нужно не обязательно в разработку/управление. Хорошо
>либо в управление, так как те навыки, которые он будет приобретать в процессе роста,
>дадут пользу всей компании.
Тестирование тоже не ограничивается знанием слов passed и failed!
И рости нужно не обязательно в разработку/управление. Хорошо
Что то сразу вспомнилось: «Не стремись знать все, что бы не стать во всем невеждой.» :)
Я в настоящий момент ищу подрядчика на тестирование. Наверное к этот список можно соотнести и к компаниям.
Хорошая статья и очень интересные ссылки. Я бы еще добавил про управление качеством статистическими методами…
«Я эксперт!» = «Я больше не буду развиваться»эксперт это, прежде всего, — специалист. и в этом термине нет ничего, что говорит о том, меняется он или нет :) здесь я с тобой не согласен!
Я согласен с тем, что настоящий специалист должен постоянно развиваться. но это отновится не только к тестировщикам
Извините, не удержался…
Чем отличаются настоящие программисты от ненастоящих?
1. Настоящие программисты с проектом заодно.
А для этого нужно:
* учитывать цели проекта
* адаптироваться под внешние условия (приоритеты, сроки, цели, верхнеуровневые задачи)
* уметь выяснять: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достигнуть цели?
2. Настоящие программисты умеют проектировать.
Никакого кодманкинга и быдлокодинга!
Настоящие программисты умеют проектировать ПО.
3. Настоящие программисты понимают архитектуру разрабатываемого ПО.
… для понимания того, как эффективно разрабатывать ваше приложение, вы просто обязаны знать его архитектуру!
4. Настоящие программисты — мастера коммуникаций.
Кому, как не программистам приходится нести плохую весть? Самое худшее, что можно сделать, обнаружив отсутствующий функционал — сказать проджект-менеджеру «Ну ты и напланировал!».
А еще, нам надо не просто реализовать фичу. Нам надо сделать всё для того, чтобы ее было легко и приятно тестировать.
Каждый покрытый тестами код — это классно, и любой тестер это понимает.
5. Настоящие программисты прекрасно разбираются в прикладной области.
6. Настоящие программисты не бывают экспертами.
Если вы слышите слова «я настоящий эксперт!», значит, перед вами ненастоящий программисты. Потому что быть экспертом в едва складывающейся отрасли невозможно. Потому что методологическая база ничтожно маленькая, и даже она меняется непрерывно.
7. Настоящие программисты выбирают цели, а не средства.
Как часто НЕ покрываются юнит-тестами проекты с отрицательным ROI? Как часто код НЕ документируются, превращаясь в ворох бесполезных и неповоротливых классов и функций просто потому, что это «накладно» и код якобы уже «самодокументированный»?
8,9,10. Настоящие программисты любят свою работу, любят свои продукты и непрерывно развиваются.
Чем отличаются настоящие программисты от ненастоящих?
1. Настоящие программисты с проектом заодно.
А для этого нужно:
* учитывать цели проекта
* адаптироваться под внешние условия (приоритеты, сроки, цели, верхнеуровневые задачи)
* уметь выяснять: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достигнуть цели?
2. Настоящие программисты умеют проектировать.
Никакого кодманкинга и быдлокодинга!
Настоящие программисты умеют проектировать ПО.
3. Настоящие программисты понимают архитектуру разрабатываемого ПО.
… для понимания того, как эффективно разрабатывать ваше приложение, вы просто обязаны знать его архитектуру!
4. Настоящие программисты — мастера коммуникаций.
Кому, как не программистам приходится нести плохую весть? Самое худшее, что можно сделать, обнаружив отсутствующий функционал — сказать проджект-менеджеру «Ну ты и напланировал!».
А еще, нам надо не просто реализовать фичу. Нам надо сделать всё для того, чтобы ее было легко и приятно тестировать.
Каждый покрытый тестами код — это классно, и любой тестер это понимает.
5. Настоящие программисты прекрасно разбираются в прикладной области.
6. Настоящие программисты не бывают экспертами.
Если вы слышите слова «я настоящий эксперт!», значит, перед вами ненастоящий программисты. Потому что быть экспертом в едва складывающейся отрасли невозможно. Потому что методологическая база ничтожно маленькая, и даже она меняется непрерывно.
7. Настоящие программисты выбирают цели, а не средства.
Как часто НЕ покрываются юнит-тестами проекты с отрицательным ROI? Как часто код НЕ документируются, превращаясь в ворох бесполезных и неповоротливых классов и функций просто потому, что это «накладно» и код якобы уже «самодокументированный»?
8,9,10. Настоящие программисты любят свою работу, любят свои продукты и непрерывно развиваются.
Большое спасибо за стоящую статью. На предыдущем проекте мне необходимо было собеседовать тестировщиков. В ходе беседы было выяснено, что люди могут безупречно знать материал и оперировать терминами, но на поле быть полными нулями. Я разработал тестовое задание, которое включало в себя все основные активности тестировщиков, и раздал группе претендентов. Через сутки мне прислали выполненные задания. Я выбрал несколько лучших и провел с ними обычную беседу об их предыдущем опыте. И в итоге оказалось, что эти люди показывали лучшие результаты по сравнению со старичками. Тестируйте тестировщиков перед приемом на работу.
Поделитесь заданием? Я думаю, многим будет интересно и полезно.
Задание выкладывать я не буду так как оно относилось к той специфике и закрытости проекта, но я опишу что оно в себе содержало:
1. Список требований (из десяти) к мнимому продукту и краткое описание архитектуры проекта — эту секцию я готовил на основе разрабатываемого продукта;
2. Задание 1: написать тест кейсы по существующим требованиям и краткому описанию продукта в волном стиле — здесь я хотел увидеть, насколько ответственно и качественно подойдут к составлению тест кейсов когда дают свободу выбора;
3. Задание 2: написать несколько баг отчетов на их усмотрение, какие ошибки могли возникнуть и т.д. — здесь меня интересовал именно аналитический подход к проблеме, и как ясно и четко будет выполнена работа (некоторые рисовали мок скрин шоты, и как раз эти люди показывали хорошие результаты);
4. Задание 3: подготовить отчет о проведенном тестировании;
5. Задание 4: написать несколько рисков, которые могут возникнуть в ходе работы.
1. Список требований (из десяти) к мнимому продукту и краткое описание архитектуры проекта — эту секцию я готовил на основе разрабатываемого продукта;
2. Задание 1: написать тест кейсы по существующим требованиям и краткому описанию продукта в волном стиле — здесь я хотел увидеть, насколько ответственно и качественно подойдут к составлению тест кейсов когда дают свободу выбора;
3. Задание 2: написать несколько баг отчетов на их усмотрение, какие ошибки могли возникнуть и т.д. — здесь меня интересовал именно аналитический подход к проблеме, и как ясно и четко будет выполнена работа (некоторые рисовали мок скрин шоты, и как раз эти люди показывали хорошие результаты);
4. Задание 3: подготовить отчет о проведенном тестировании;
5. Задание 4: написать несколько рисков, которые могут возникнуть в ходе работы.
>>Тестируйте тестировщиков
разоблачить разоблачителей?
разоблачить разоблачителей?
Зачем вешать ярлыки «настоящий»/«не настоящий»?
Чесно, мысль полезная как для развития впринципе любого специалиста, но стиль изложения похож на заметки про Чака Норриса.
Всеравно для тестировщика его резюме, что для фотографа портфолио.
Чесно, мысль полезная как для развития впринципе любого специалиста, но стиль изложения похож на заметки про Чака Норриса.
Всеравно для тестировщика его резюме, что для фотографа портфолио.
Резюме из нескольких страничек еще ничего не говорит о качествах и навыках человека в реальности. Я в них не верю.
Если в резюме тестировщика имеются орфографические ошибки, то это говорит о навыках человека ;)
Ну, и в целом умение структурировать излагаемую информацию очень важно не только для тестировщиков но и для многих других специальностей.
Чтоб небыло такого (из реально полученного нами резюме):
я желаю работать в создании игр, я не програмист, я творческий ручей желающий слиться с другими в реку. я хотел бы прислать идеи, продуманные или просто мысль, или рисунки. может вы укажете адрес. честно не в курсе работает ли почта, которую я укажу. оставлю и номер-можно смс.
Ну, и в целом умение структурировать излагаемую информацию очень важно не только для тестировщиков но и для многих других специальностей.
Чтоб небыло такого (из реально полученного нами резюме):
я желаю работать в создании игр, я не програмист, я творческий ручей желающий слиться с другими в реку. я хотел бы прислать идеи, продуманные или просто мысль, или рисунки. может вы укажете адрес. честно не в курсе работает ли почта, которую я укажу. оставлю и номер-можно смс.
Все нужно проверять. Резюме не исключение.
Резюме не главное, главное тот опыт который получил с прошлых мест работы. Да и еще как у человека голова работает, способен ли он создавать извращенные тест кейсы или работать как робот, проверяя все по спеке и все.
UFO just landed and posted this here
UFO just landed and posted this here
Мне тоже несколько непонятна тенденция сделать из тестера «царя и бога», возложить на него те обязанности и ту ответственность, которые никоим образом его касаться не должны.
1. давайте различать Testing Manager-а и рядовых тестеров (если тестеров 3 и больше, то обязательно нужно выделять Manager). Тест-кейсы рядовой тестер писать не должен, он должен заниматься тестированием.
2. TM действительно должен обладать квалификацией на уровне хорошего программиста и четко представлять себе архитектуру продукта. Без этого действительно никак. Рядовые тестеры могут не обладать такой квалификацией. Если продукт многофункциональный, то обучить каждого тестера будет нереально. Пока рядовые тестеры тестируют, TM общается с командой разработчиков и корректирует тест-лист. Учить всех — никакого времени не хватит. И вот как раз на позицию TM надо именно эксперта подыскивать.
3. если программеры обижаются на тестеров, то разумнее не учить тестеров коммуникабельности, а по шапке программерам надавать, дабы фигнёй не страдали. А для коммуникации лучше использовать Bug Tracker — никаких обид и всё перед глазами.
4. (или даже больше 1) Если команда воспринимает кого-либо из своих членов как врага, то тут уже виноват Project Manager или руководитель проекта. Разъяснительная работа вкупе с тимбилдингом — всё на совести руководства.
5. По приоритезации тестирования функций — этим тоже не должен заниматься TM. Точнее говоря, вместе с продуктом для тестов TM должен получать описательные документы по продукту, и, в частности, подробный перечень Сценариев Использования продукта с расставленными в нем приоритетами. Вот по этим приоритетам сценариев и должны расставляться приоритеты для Testing Cases. Если в проекте не используются Сценарии, то тут уже действительно TM приходится становиться суперменом и заниматься всей той не свойственной ему деятельностью, что описана в данной публикации.
Еще раз. Я не пытаюсь принизить роль Тестирования в общем вкладе в проект. Но и расписывать его в качестве «Супер-мозга» не стоит. Каждый должен заниматься своим делом. Роль личности, особенно в малых проектах, очень велика. А вот в больших, отлаженных проектах, такая вот супер-личность может принести больше проблем, чем пользы.
1. давайте различать Testing Manager-а и рядовых тестеров (если тестеров 3 и больше, то обязательно нужно выделять Manager). Тест-кейсы рядовой тестер писать не должен, он должен заниматься тестированием.
2. TM действительно должен обладать квалификацией на уровне хорошего программиста и четко представлять себе архитектуру продукта. Без этого действительно никак. Рядовые тестеры могут не обладать такой квалификацией. Если продукт многофункциональный, то обучить каждого тестера будет нереально. Пока рядовые тестеры тестируют, TM общается с командой разработчиков и корректирует тест-лист. Учить всех — никакого времени не хватит. И вот как раз на позицию TM надо именно эксперта подыскивать.
3. если программеры обижаются на тестеров, то разумнее не учить тестеров коммуникабельности, а по шапке программерам надавать, дабы фигнёй не страдали. А для коммуникации лучше использовать Bug Tracker — никаких обид и всё перед глазами.
4. (или даже больше 1) Если команда воспринимает кого-либо из своих членов как врага, то тут уже виноват Project Manager или руководитель проекта. Разъяснительная работа вкупе с тимбилдингом — всё на совести руководства.
5. По приоритезации тестирования функций — этим тоже не должен заниматься TM. Точнее говоря, вместе с продуктом для тестов TM должен получать описательные документы по продукту, и, в частности, подробный перечень Сценариев Использования продукта с расставленными в нем приоритетами. Вот по этим приоритетам сценариев и должны расставляться приоритеты для Testing Cases. Если в проекте не используются Сценарии, то тут уже действительно TM приходится становиться суперменом и заниматься всей той не свойственной ему деятельностью, что описана в данной публикации.
Еще раз. Я не пытаюсь принизить роль Тестирования в общем вкладе в проект. Но и расписывать его в качестве «Супер-мозга» не стоит. Каждый должен заниматься своим делом. Роль личности, особенно в малых проектах, очень велика. А вот в больших, отлаженных проектах, такая вот супер-личность может принести больше проблем, чем пользы.
А вам не кажется, что вы не учли простого факта: что из тестеров должны расти ТМы?
По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.
Попробуйте прочитать статью как «Сферический тестировщик в вакууме, каким он должен быть?» — тогда позиция Натальи вам станет ближе.
P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.
По вашему описанию — есть мозг (ТМ), есть руки (тестеры). Мозг руководит — руки делают.
Теперь вклбчим человеческий фактор — как долго руки останутся руками? Если долго — насколько они будут эффективны спустя полгода?
Описанная вами схема на моих глазах работает только с новичками. Получив некоторые опыт — они загораются идеями и простым тестированием и валидацией дефектов от них не отделаешься.
Попробуйте прочитать статью как «Сферический тестировщик в вакууме, каким он должен быть?» — тогда позиция Натальи вам станет ближе.
P.S. Извините, наболело. По-крайней мере меня всегда удивляли люди, которые чтобы внести дефект с повышенным приоритето — звонили ТМу, который вышел пообедать. Даже не смотря на то, что функционал имеет особую важность в продукте.
Кто сказал «должны»? Кому это нужно? Самому тестеру? — Да, хочется вырасти. Нужно ли это PM-у и TM-у — вопрос. Бывает, что и не нужно. Все зависит от общей линии руководства и сложившихся правил к команде. Ну и от поведения самого тестера. Рядовой тестер, генерящий кучу идей и предложений по делу и без дела — это головная боль для всего менеджмента проекта, ибо то, что должно быть сделано в срок, скорее всего будет не сделано, ибо у этого тестера свои идеи, своё видение проекта и продукта и он уже мнит себя PM-ом и т.п. В результате то, что должно быть сделано — не делается, сроки уходят, проект тормозится. Результат — чел вылетает с работы со скоростью пробки из бутылки.
Поэтому давайте сперва определимся с тем, о каком масштабе мы говорим. Если это разовый стартапный проект — тут важна полная отдача от каждого «и еще немного». Но если речь идет о производственном процессе, отлаженном и выстроенном, то надо быть готовым, что всякие идеи по «улучшайзингу» могут быть просто не приняты или даже приняты в штыки. Приходя в такую команду, надо прежде всего выполнять то, что требуется от работника на данной позиции. Если просто «быть руками» — значит, надо просто быть руками.
Поэтому давайте сперва определимся с тем, о каком масштабе мы говорим. Если это разовый стартапный проект — тут важна полная отдача от каждого «и еще немного». Но если речь идет о производственном процессе, отлаженном и выстроенном, то надо быть готовым, что всякие идеи по «улучшайзингу» могут быть просто не приняты или даже приняты в штыки. Приходя в такую команду, надо прежде всего выполнять то, что требуется от работника на данной позиции. Если просто «быть руками» — значит, надо просто быть руками.
У Вас очень распространённый управленческий паттерн «без начальства никуда». Команда, в которой тестеры ничего не могут без ТМ-ов, ТМ-ы без РМ-ов и т.д.
Так можно делать (и более того, не меньше половины компаний так и делают), но получается ерунда. Об этом Демарко в «Deadline» классно написал, поэтому здесь подробно вдаваться не буду.
А по пунктам:
А если тестов нет (а бывают ситуации, когда исходя из контекста их НЕ ДОЛЖНО БЫТЬ)? А если в тестах ошибка? А если тесты сегодня утром устарели?
А наш тестировщик сам проектировать проверки не может, как работает продукт понимает не до конца, и тупо нажимает на кнопочки?
Хорошее решение для неуверенного в себе ТМ-а, который боится продвинутой команды. Но плохое решение для проекта и результатов тестирования.
И так, вместо менеджера, который мог бы развивать процесс, нивелировать риски, взращивать команду и выполнять другие не менее важные менеджерские задачи, мы получаем редактора таблиц. Круто!
И впрямь! Мы уже получили команду тестеров-зомби, кликающих на кнопки, давайте ещё демотивируем разработчиков и получим абсолютно нерабочий проект. И что самое главное — руководителю с таким подходом будет не скучно! Везде он будет видеть проблемы, всё будет валить на сотрудников, а в своём глазу не заметит бревна.
Так и делают многие руководители, и вполне логично зачем.
О да!
Представим, что у нас небольшой проект: полгода, 3 разработчика, 1 РМ, 1 ведущий тестировщик. Почему бы нам вместо нескольких совместных обсуждений не потратить первые из 4х месяцев на документирование? Неважно, что после прототипирования многое изменится — поменяем все бумажки ещё раз.
Я за, за, всеми руками за документацию. Но давайте не забывать про контекст — иногда она НЕ оправдана.
Так можно делать (и более того, не меньше половины компаний так и делают), но получается ерунда. Об этом Демарко в «Deadline» классно написал, поэтому здесь подробно вдаваться не буду.
А по пунктам:
1. Тест-кейсы рядовой тестер писать не должен, он должен заниматься тестированием.
А если тестов нет (а бывают ситуации, когда исходя из контекста их НЕ ДОЛЖНО БЫТЬ)? А если в тестах ошибка? А если тесты сегодня утром устарели?
А наш тестировщик сам проектировать проверки не может, как работает продукт понимает не до конца, и тупо нажимает на кнопочки?
Хорошее решение для неуверенного в себе ТМ-а, который боится продвинутой команды. Но плохое решение для проекта и результатов тестирования.
2. Пока рядовые тестеры тестируют, TM общается с командой разработчиков и корректирует тест-лист. Учить всех — никакого времени не хватит.
И так, вместо менеджера, который мог бы развивать процесс, нивелировать риски, взращивать команду и выполнять другие не менее важные менеджерские задачи, мы получаем редактора таблиц. Круто!
3. если программеры обижаются на тестеров, то разумнее не учить тестеров коммуникабельности, а по шапке программерам надавать, дабы фигнёй не страдали.
И впрямь! Мы уже получили команду тестеров-зомби, кликающих на кнопки, давайте ещё демотивируем разработчиков и получим абсолютно нерабочий проект. И что самое главное — руководителю с таким подходом будет не скучно! Везде он будет видеть проблемы, всё будет валить на сотрудников, а в своём глазу не заметит бревна.
Так и делают многие руководители, и вполне логично зачем.
5. вместе с продуктом для тестов TM должен получать описательные документы по продукту, и, в частности, подробный перечень Сценариев Использования продукта с расставленными в нем приоритетами. Вот по этим приоритетам сценариев и должны расставляться приоритеты для Testing Cases
О да!
Представим, что у нас небольшой проект: полгода, 3 разработчика, 1 РМ, 1 ведущий тестировщик. Почему бы нам вместо нескольких совместных обсуждений не потратить первые из 4х месяцев на документирование? Неважно, что после прототипирования многое изменится — поменяем все бумажки ещё раз.
Я за, за, всеми руками за документацию. Но давайте не забывать про контекст — иногда она НЕ оправдана.
Еще раз предлагаю прежде всего определиться с исходными данными:
1. О проекте какого масштаба мы говорим: о маленьком стартапе или об отлаженном производственном процессе?
2. С позиции кого из участников проекта мы рассматриваем вопрос: с позиции рядового тестера или руководителя проекта?
Если молодой специалист собирается попробовать себя в качестве тестера в стартапе — это один расклад. Если вопросом отладки процесса тестирования озаботился PM в проекте, который уже набрал силу и собирается развиваться и дальше — расклад будет совсем другой. И уж тем более будет совсем другой расклад, если TL наконец-то задумался, как навести порядок в нескольких параллельно разрабатываемых проектах, дабы проекты, которые уже на подходе, были отработаны быстрее и принесли больше прибыли.
Моя точка зрения описывает точку зрения скорее TL. Когда надо с максимальной эффективностью использовать имеющиеся ресурсы. Когда надо чтобы тестировщик быстро и эффективно тестировал, когда надо чтобы программист не отвлекаясь на всякие дополнительные вещи программировал и т.п. В этом случае маркетинговая и организационная составляющая должны быть максимально отделены от основной работы. Маркетингом (проработкой Сценариев и т.п.) должен заниматься отдел маркетинга; составлением тест-кейсов — лидер комманды тестеров. В выстраивании четко регламентированных и документированных маркетинговых процессов и процессов разработки должен быть заинтересован прежде всего менеджмент, если он хочет снизить накладные затраты на разработку ПО и отдалить сам процесс (кстати говоря, как и в налаживании взаимоотношений внутри коллектива, что является его — менеджмента — прямой обязанностью). Рядовому работнику зачастую подобная регламентация может ограничивать свободу действий, но и позволяет больше сосредоточится на самом процессе. Действительно, подобное документирование на своем начальном этапе требует определенных дополнительных усилий и затрат, но зато делает процесс разработки максимально прозрачным и эффективным. Когда с уходом даже очень хорошего специалиста проект не рушится, а продолжает жить и развиваться.
1. О проекте какого масштаба мы говорим: о маленьком стартапе или об отлаженном производственном процессе?
2. С позиции кого из участников проекта мы рассматриваем вопрос: с позиции рядового тестера или руководителя проекта?
Если молодой специалист собирается попробовать себя в качестве тестера в стартапе — это один расклад. Если вопросом отладки процесса тестирования озаботился PM в проекте, который уже набрал силу и собирается развиваться и дальше — расклад будет совсем другой. И уж тем более будет совсем другой расклад, если TL наконец-то задумался, как навести порядок в нескольких параллельно разрабатываемых проектах, дабы проекты, которые уже на подходе, были отработаны быстрее и принесли больше прибыли.
Моя точка зрения описывает точку зрения скорее TL. Когда надо с максимальной эффективностью использовать имеющиеся ресурсы. Когда надо чтобы тестировщик быстро и эффективно тестировал, когда надо чтобы программист не отвлекаясь на всякие дополнительные вещи программировал и т.п. В этом случае маркетинговая и организационная составляющая должны быть максимально отделены от основной работы. Маркетингом (проработкой Сценариев и т.п.) должен заниматься отдел маркетинга; составлением тест-кейсов — лидер комманды тестеров. В выстраивании четко регламентированных и документированных маркетинговых процессов и процессов разработки должен быть заинтересован прежде всего менеджмент, если он хочет снизить накладные затраты на разработку ПО и отдалить сам процесс (кстати говоря, как и в налаживании взаимоотношений внутри коллектива, что является его — менеджмента — прямой обязанностью). Рядовому работнику зачастую подобная регламентация может ограничивать свободу действий, но и позволяет больше сосредоточится на самом процессе. Действительно, подобное документирование на своем начальном этапе требует определенных дополнительных усилий и затрат, но зато делает процесс разработки максимально прозрачным и эффективным. Когда с уходом даже очень хорошего специалиста проект не рушится, а продолжает жить и развиваться.
Проект не рушится, если в команде нет «узких горлышек». Если Вы предлагаете делить команду на мозги и руки, то уход мозга — это всегда большая попа. Поэтому диверсификация знаний в коллективе лишь повышает стабильность такой команды.
1) Если где-то нужны просто руки, то там нужна автоматизация, а не микроменеджмент мартышками.
2) Неполнота — одно из фундаментальных свойств человеческого знания, поэтому и полной документации быть не может.
Я руководила группой из 40 тестировщиков при чётко построенном процессе и группой из 0,5 тестировщика в стартапе. Расскажите, на что это по-Вашему влияет в данном контексте. Я пока что не поняла, какой должна быть разница в квалификации и почему.
1) Если где-то нужны просто руки, то там нужна автоматизация, а не микроменеджмент мартышками.
2) Неполнота — одно из фундаментальных свойств человеческого знания, поэтому и полной документации быть не может.
Я руководила группой из 40 тестировщиков при чётко построенном процессе и группой из 0,5 тестировщика в стартапе. Расскажите, на что это по-Вашему влияет в данном контексте. Я пока что не поняла, какой должна быть разница в квалификации и почему.
И что, все эти 40 человек «генерили» идеи и занимались налаживанием взаимоотношений, писали тест-кейсы, разбирались в алгоритмах и т.п.?
Я не предлагаю делить на «мозги — руки». Я предлагаю четко разделить прежде всего зоны ответственности в коллективе. Это важно и для стартапа, и для большого отлаженного производственного процесса. В зависимости от проекта и его объёма зоны ответственности могут меняться очень значительно. При этом главное — чтобы каждый человек в команде четко понимал, чего от него ждут.
И еще раз прошу определиться по вышеуказанным двум пунктам: о каком варианте проекта и о какой точке зрения мы говорим.
Я не предлагаю делить на «мозги — руки». Я предлагаю четко разделить прежде всего зоны ответственности в коллективе. Это важно и для стартапа, и для большого отлаженного производственного процесса. В зависимости от проекта и его объёма зоны ответственности могут меняться очень значительно. При этом главное — чтобы каждый человек в команде четко понимал, чего от него ждут.
И еще раз прошу определиться по вышеуказанным двум пунктам: о каком варианте проекта и о какой точке зрения мы говорим.
И еще раз прошу определиться по вышеуказанным двум пунктам: о каком варианте проекта и о какой точке зрения мы говорим.
Не поняла что такое точка зрения в данном контексте.
Размер команды — пока что любой, потому что, как я уже указала выше, я не вижу в данном контексте разницы и прошу Вас её объяснить.
Я не предлагаю делить на «мозги — руки». Я предлагаю четко разделить прежде всего зоны ответственности в коллективе.
Зоны ответственности можно делить по-разному. По типу деятельности, по функционалу, за который человек несёт ответственность.
И что, все эти 40 человек «генерили» идеи и занимались налаживанием взаимоотношений, писали тест-кейсы, разбирались в алгоритмах и т.п.?
1. Откуда дровишки про идеи, написание тест-кейсов и налаживание взаимоотношений? В моём понимании, грамотные коммуникации — это ещё не налаживание взаимоотношений, а проектирование тестов (анализ и определение необходимых проверок) — это ещё не написание тест-кейсов (документирование последовательности действий, основанной на проектировании).
2. Даже при наличии кем-то написанных тест-кейсов, тестировщик должен хорошо знать продукт, прикладную область и архитектуру для грамотного заведения дефектов. Не знает область — может пропустить ошибку. Не понимает архитектуру — не сможет качественно локализовать проблему. А в итоге это всё сводится к проблемам проекта и срывам сроков.
3. Покрыть всё тестами априори невозможно. Всегда будет необходимость что-то проверить без тестов. И если эта проверка превратится в кликанье, вместо предварительного анализа и проектирования (которое гуру-тестер и в голове сделать может), то результаты те же — плохое покрытие и срывы сроков.
Я согласна, что в крупных командах должно быть деление задач. Но я не согласна, что даже в очень крупных командах есть место для неквалифицированных исполнителей, которые могут только выполнять чёткие инструкции. Первое время это кажется решением, а потом всплывает слишком много проблем.
Очень странно, что Вы с вашим опытом работы не понимаете таких очевидных вещей.
Все люди разные. Каждый преследует свои собственные цели. Большинство людей ходят на работу чтобы заработать денег. Это их цель. Еще одна цель — узнать что-либо интересное. Третья — реализовать свои амбиции. При этом большинство хочет зарабатывать как можно больше, но при этом работать как можно меньше. И уж тем более никто не хочет выполнять чужую работу. Человек, занимающий позицию ответственного менеджера наоборот заинтересован заставить людей работать, но при этом сэкономить как можно больше средств. Так вот о каком именно «тестере» вы говорите? О рядовом, который приходит на работу за деньгами, ему не очень-то интересно выполнять рутинную работу и хочется поскорее выбиться «в начальники», или о начальнике — TM, который ищет пути, как наиболее продуктивно организовать рабочий процесс с теми работниками, которые уже есть? Даже если эти люди работают в одной команде, интересы у них в общем случае разные. Да, есть «глобальный интерес» — успешное завершение проекта, но у каждого конкретного человека могут быть и другие цели.
Поэтому и возник этот спор: Вы говорите об «идеальном» тестере, не конкретизируя условий. Я же пытаюсь подвести Вас к мысли, что в разных условиях требования к «идеальному» тестеру будут разными. И то, что хорошо и будет приветствоваться в маленьком стартапе, в крупной компании с уже отлаженными процессами производства может вызвать негативную реакцию. Вы пытаетесь убедить, что надо все время выходить на привычные рамки, проявлять инициативу, а я говорю про то, что это хорошо только в маленьком коллективе, где еще только идет разграничение зон ответственности, и то только в том случае, если проект появился стихийно, без нормальной подготовки.
И я нигде не говорил, что на работу надо набирать даунов и других низкоквалифицированных людей. Высокая квалификация нужна и при работе «руками». Нужна и приветствуется, вопрос только в том, захочет ли работник, достигший высокой квалификации, сидеть на одном и том же месте и делать руками одно и то же? Конечно хорошо, когда фирма приветствует карьерный рост своих работников и всячески его поощряет, но такое бывает очень редко (и уж тем более редко в отрасли разработки ПО). Поэтому я пишу, что надо быть готовым к тому, что рвения и самые благие желания могут разбиться о Должностную инструкцию.
А про документацию я убежден, что она должна быть в каждом проекте в необходимом и адекватном объеме. Чем больше проект, чем больше людей в нем взаимодействуют, тем более четко должна быть выполнена регламентация и тем ответственней нужно подходить к документированию рабочего процесса.
Все люди разные. Каждый преследует свои собственные цели. Большинство людей ходят на работу чтобы заработать денег. Это их цель. Еще одна цель — узнать что-либо интересное. Третья — реализовать свои амбиции. При этом большинство хочет зарабатывать как можно больше, но при этом работать как можно меньше. И уж тем более никто не хочет выполнять чужую работу. Человек, занимающий позицию ответственного менеджера наоборот заинтересован заставить людей работать, но при этом сэкономить как можно больше средств. Так вот о каком именно «тестере» вы говорите? О рядовом, который приходит на работу за деньгами, ему не очень-то интересно выполнять рутинную работу и хочется поскорее выбиться «в начальники», или о начальнике — TM, который ищет пути, как наиболее продуктивно организовать рабочий процесс с теми работниками, которые уже есть? Даже если эти люди работают в одной команде, интересы у них в общем случае разные. Да, есть «глобальный интерес» — успешное завершение проекта, но у каждого конкретного человека могут быть и другие цели.
Поэтому и возник этот спор: Вы говорите об «идеальном» тестере, не конкретизируя условий. Я же пытаюсь подвести Вас к мысли, что в разных условиях требования к «идеальному» тестеру будут разными. И то, что хорошо и будет приветствоваться в маленьком стартапе, в крупной компании с уже отлаженными процессами производства может вызвать негативную реакцию. Вы пытаетесь убедить, что надо все время выходить на привычные рамки, проявлять инициативу, а я говорю про то, что это хорошо только в маленьком коллективе, где еще только идет разграничение зон ответственности, и то только в том случае, если проект появился стихийно, без нормальной подготовки.
И я нигде не говорил, что на работу надо набирать даунов и других низкоквалифицированных людей. Высокая квалификация нужна и при работе «руками». Нужна и приветствуется, вопрос только в том, захочет ли работник, достигший высокой квалификации, сидеть на одном и том же месте и делать руками одно и то же? Конечно хорошо, когда фирма приветствует карьерный рост своих работников и всячески его поощряет, но такое бывает очень редко (и уж тем более редко в отрасли разработки ПО). Поэтому я пишу, что надо быть готовым к тому, что рвения и самые благие желания могут разбиться о Должностную инструкцию.
А про документацию я убежден, что она должна быть в каждом проекте в необходимом и адекватном объеме. Чем больше проект, чем больше людей в нем взаимодействуют, тем более четко должна быть выполнена регламентация и тем ответственней нужно подходить к документированию рабочего процесса.
1) «Почти все люди ходят на работу за баблом, им неинтересно работать и они хотят стать бааальшими начальниками» — проекция Вашего восприятия.
Согласна, что все люди разные, поэтому говорить про «большинство» некорректно, бабло, амбиции и интерес — лишь одни из двух сотен ключевых мотиваторов.
2) «Документация должна быть на каждом проекте в необходимом объёме» — согласна. Зачастую, необходимый объём равен нулю. Алистер Кокбёрн проводил глубокое исследование проектов, и не мог догнать, почему иногда неформальные проекты без документации значительно успешнее формальных. У него получилось вывести неплохую модель, советую познакомиться.
А вообще, проблемы обычно возникают там, где слышится «очевидные вещи». Не надо додумывать, додумки — корень зла :)
Мне кажется, что мы хорошо поняли друг друга и дискуссию можем закончить, обогатившись мнениями друг друга. С наступающим!
Согласна, что все люди разные, поэтому говорить про «большинство» некорректно, бабло, амбиции и интерес — лишь одни из двух сотен ключевых мотиваторов.
2) «Документация должна быть на каждом проекте в необходимом объёме» — согласна. Зачастую, необходимый объём равен нулю. Алистер Кокбёрн проводил глубокое исследование проектов, и не мог догнать, почему иногда неформальные проекты без документации значительно успешнее формальных. У него получилось вывести неплохую модель, советую познакомиться.
А вообще, проблемы обычно возникают там, где слышится «очевидные вещи». Не надо додумывать, додумки — корень зла :)
Мне кажется, что мы хорошо поняли друг друга и дискуссию можем закончить, обогатившись мнениями друг друга. С наступающим!
Устроиться тестировщиком легко
не соглашусь с этим утверждением, не так то уж и легко. С каждым годом требования к тестировщику растут. Одно из основных требований которое просто скачет — это знание английского, как письменного так и устного. Умение свободно общаться будет огромным плюсом на собеседовании.
Как говорил одни человек, что если ты супер-классный спец знаешь очень много и умеешь схватываешь всё лету, но если ты не можешь связать 2-х слов по-английский, не можешь рассказать о себе и выразить свою мысль — то ты никому не нужен. И это к сожалению правда.
Если отбросить тот факт, что английский нужен любому, кто занят в ИТ, то применительно к тестированию: много инструментов, описаний, хороших практик, да и нормальных книг существуют только в английском варианте. Чтобы человеку, занятому в тестировании, расти надо хотя бы свободно читать на английском — факт. Даже если кто-то работает в абсолютно российской конторе и имеет дело только с русскоязычным документооборотом.
Еще только начиная читать статью я сразу заподозрил какую-то откровенную попоболь на тему того, что тестировщиком может быть и обезьяна за компьютером. Да, безусловно, то что вы описали это крутой и настоящий тестировщик, с, безусловно, такими же крутыми запросами к оплате своего труда, но кому такой нужен тестеровщик то, возможно крупной компании, но и то 1, ну максимум 2 на проект, остальное же «стадо», по вашей терминологии, являются не крутые и плохие тестеры.
Зачем вообще нужно 10 человек пишущих сами себе тесткейсы, устанавливающих приоритеты, совершенно знающие предметную область, это все повергнет в хаос процесс тестирования. Всем этим должен будет кто-то руководить, тот кто будет 1 писать, устанавливать приоритеты, общаться с ПМ и тимлидами. А следовательно, все это стадо крутых и правильных тестеров, просящих за свои услуги как 2 или 3 «быдлотестера», вообще не нужны на производстве, а с учетом того, что в средних и особенно мелких фирмах, эту центральную играет в основном ПМ или ТЛ, то вообще трудно сказать нужен ли такой человек действительно предприятию, и пойдет ли он на него на условиях обычного тестера.
Зачем вообще нужно 10 человек пишущих сами себе тесткейсы, устанавливающих приоритеты, совершенно знающие предметную область, это все повергнет в хаос процесс тестирования. Всем этим должен будет кто-то руководить, тот кто будет 1 писать, устанавливать приоритеты, общаться с ПМ и тимлидами. А следовательно, все это стадо крутых и правильных тестеров, просящих за свои услуги как 2 или 3 «быдлотестера», вообще не нужны на производстве, а с учетом того, что в средних и особенно мелких фирмах, эту центральную играет в основном ПМ или ТЛ, то вообще трудно сказать нужен ли такой человек действительно предприятию, и пойдет ли он на него на условиях обычного тестера.
>Black-box testing — это тестирование в чёрном ящике без окон и с закрытыми глазами.
Black-box testing — это тестирования программы, воспринимая ее как черный ящик без какого-либо понимания, что там внутри (если поправить очки, как я).
Black-box testing — это тестирования программы, воспринимая ее как черный ящик без какого-либо понимания, что там внутри (если поправить очки, как я).
Sign up to leave a comment.
Чем отличаются настоящие тестировщики от поддельных?