Сегодня я не смогла уснуть. Тяжкие думы не первый день омрачают моё бренное существование.
Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте SQA Testing School, находящейся в Силиконовой долине. В этом описании тестирование представляется как элементарная область, научиться которой можно очень быстро, знаний для этого нужно минимум, а зарабатывать в которой можно очень даже неплохо.
Первой праведной мыслью было: тестирование обидели!
На смену первой пришла вторая, более взвешенная: описанное вполне соответствует действительности. Устроиться тестировщиком легко. Быть плохим тестировщиком и при этом не быть уволенным — легко. Не приносить ни малейшей пользы проекту, и при этом зарабатывать нормальные деньги — легко.
Но ведь бывают, бывают истинные гении своего дела, которые приносят пользу, и, несмотря на «болотистый» рынок труда в сфере тестирования, являются высококвалифицированными специалистами!
Кто они?
Как отличить настоящих джедаев от поддельных тестировщиков?
Результатом раздумий стал СПИСОК ИЗ ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТИРОВЩИКА ОТ ПОДДЕЛЬНОГО.
Настоящие тестировщики не враги программистам. Настоящие тестировщики не ставят своей целью «сломать продукт», после чего ехидно потирать ладоши. Настоящие тестировщики вообще не радуются наличию проблем, багов, дефектов и ошибок!
Чтобы приносить проекту пользу, тестирование должно выступать в роли сервиса. Баги — не продукт, который можно выпустить. Баги не приносят пользы. Пользу приносят только активности, нацеленные на достижение общих целей.
А для этого нужно:
* учитывать цели проекта
* адаптироваться под внешние условия (приоритеты, сроки, цели, верхнеуровневые задачи)
* уметь выяснять: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достигнуть цели?
Если тестирование неэффективно, ошибки находятся поздно, а заводятся низкокачественно, то их будет больше и больше: плохая локализация дефектов отнимает время у разработчиков, а их заведение в неприоритетном порядке ведёт к трудностям в исправлении.
Поэтому, вместо задачи «как бы мне найти кучу багов и заDDOSить разработчиков», настоящие тестировщики думают: «Что сейчас нужно проекту, в каком формате и с какими приоритетами?».
Никакого манкикликинга и быдлотестинга!
Настоящие тестировщики умеют проектировать тесты. Для этого они как минимум зазубрили библию проектирования тестов от Lee Copeland'a, а как максимум — освоили контроль рисков качества.
В зависимости от условий, тестирование может проводиться эксплоративно или по тест-кейсам, но тесты делаются не от балды «понажимаю-ка я кнопочки», а только по результатам анализа: что нужно тестировать, в каком приоритете и каким образом это можно сделать наиболее эффективно?
Для этого любое тестирование начинается с исследования продукта, влияющих на его работу факторов, и их последующего разбиения на классы эквивалентности.
Сначала — думать, потом — тестировать!
Чтобы быть настоящим тестировщиком, вовсе не обязательно быть продвинутым разработчиком. Но для понимания того, как эффективно тестировать ваше приложение, вы просто обязаны знать его архитектуру!
Black-box testing не позволяет детально происследовать продукт, и тестирование только «со стороны пользователя» приводит к тому, что неучтёнными оказываются многие влияющие на работу ПО факторы.
Black-box testing — это тестирование в чёрном ящике без окон и с закрытыми глазами. Вы идёте наощупь, натыкаетесь на какие-то шероховатости в продукте, и заводите на это ошибки «где-то в левом углу что-то не так».
Откройте глаза и включите свет! Посмотрите, что вы тестируете!
Узнав, как работает ПО, вы сможете:
* эффективнее проектировать тесты
* обеспечивать более высокое покрытие, зная влияющие на работу ПО факторы
* точнее и грамотнее локализовывать ошибки — а значит, экономить время разработчиков и проекта в целом!
Кому, как не тестировщикам, приходится нести плохую весть? Самое худшее, что можно сделать, обнаружив дефект — сказать разработчику «Ну ты и накосячил!».
Нам надо не просто найти и зарегистрировать дефект. Нам надо сделать всё для того, чтобы его было легко и приятно исправить.
Каждый исправленный в софте недочёт — это классно, и любой разработчик это понимает.
Только если предварительно ему не сказали, что он «косячит», «бажит» и «глючит»!
О том, как коммуницировать с разработчиками на предмет дефектов — запись выступления Алексея Баранцева на встрече Московского Клуба Тестировщиков.
Как-то раз я проводила аудит процесса тестирования в московской компании, занимающейся разработкой бухгалтерского ПО. По мнению руководства компании, тестировщики пропускали слишком много дефектов. Причина оказалась простой: аналитики компании (2 шт.) писали тест-кейсы для тестировщиков компании (~15 шт.). Тестировщики проходили их и регистрировали все отклонения в поведении ПО от задокументированного в тест-кейсах.
При этом они даже не понимали, что такое сальдо и по какому принципу формируются отчёты!
Естественно, это не могло приносить высокого качества тестирования. Аналитики, не зная подходов к проектированию тестов (так как это не их работа), не могли оптимизировать тестовое покрытие. А горе-тестировщики лишь искали отличия между непрерывно устаревающими тестами и поведением программы. Если что-то шло «не так», и это «не так» не было задокументировано в тестах, то они даже не понимали, что перед ними дефект.
Чтобы такого не происходило, настоящие тестировщики должны знать, как работает продукт. Они должны знать пользователя, его ментальную модель: как используется продукт? В каких условиях? Каким образом?
Если вы слышите слова «я настоящий эксперт!», значит, перед вами ненастоящий тестировщик. Потому что быть экспертом в едва складывающейся отрасли невозможно. Потому что методологическая база ничтожно маленькая, и даже она меняется непрерывно.
С неумолимой скоростью появляются новые техники и подходы. Продвинутые тестировщики всех направлений создают её, создают прямо сейчас!
А как можно быть экспертом в области, которая пока что не сформировалась? Которая слишком гибка, чтобы в ней можно было что-то назвать «правильным»?
«Я эксперт!» = «Я больше не буду развиваться». А это НЕ про настоящих тестировщиков.
Как часто автоматизируются тесты с отрицательным ROI просто потому, что автоматизация — это «круто», а ручное тестирование — это «скучно»? Как часто тесты документируются, превращаясь в ворох бесполезных и неповоротливых бумажек, просто потому, что это «солидно»?
В тестировании (как, наверное, и в других областях?) многие решения принимаются исходя из «круто», «интересно» и «а давайте попробуем?».
Но ведь понятие «крутости» не абсолютно! В каждом проекте, в каждой команде свои условия работы, и эффективное тестирование всегда определяется контекстом!
Когда настоящие тестировщики принимают решение что-либо внедрить, они говорят: «Нашему проекту это будет полезно, потому что ...». И эти слова отличают настоящего тестировщика от поддельного больше, чем что бы то ни было ещё.
Для соответствия десяти задекларированным пунктам, вкратце освещу ещё три:
* Настоящие тестировщики ЛЮБЯТ свою работу, всегда находят в ней творчество, и у них не может быть рутины! Потому что каждая новая задача выполняется лучше, качественнее, эффективнее — а значит, интереснее и интереснее!
* Настоящие тестировщики любят свои продукты. Невозможно тестировать софт и быть деструктивистом. Задача настоящего тестировщика — сокращать количество дефектов, принимать превентивные меры, проводить тестирование на ранних стадиях, так чтобы серьёзные дефекты и не появлялись вовсе. А эти цели несовместимы с деструктивизимом, для их достижения продукт надо не ломать, а любить.
* Настоящие тестировщики непрерывно развиваются. И развивают молодую неокрепшую отрасль!
Настоящие Тестировщики сделают выводы сами :-)
А я просто хочу сказать этим редчайшим людям, которых можно заносить в Красную Книгу: «СПАСИБО!».
Спасибо, что не стоите на месте.
Спасибо, что приносите пользу проектам.
Спасибо, что развиваете отрасль!
Их первоисточником (или, скорее, катализатором) послужило описание сферы тестирования на сайте 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. Настоящие тестировщики любят свою работу, любят свои продукты и непрерывно развиваются.
Для соответствия десяти задекларированным пунктам, вкратце освещу ещё три:
* Настоящие тестировщики ЛЮБЯТ свою работу, всегда находят в ней творчество, и у них не может быть рутины! Потому что каждая новая задача выполняется лучше, качественнее, эффективнее — а значит, интереснее и интереснее!
* Настоящие тестировщики любят свои продукты. Невозможно тестировать софт и быть деструктивистом. Задача настоящего тестировщика — сокращать количество дефектов, принимать превентивные меры, проводить тестирование на ранних стадиях, так чтобы серьёзные дефекты и не появлялись вовсе. А эти цели несовместимы с деструктивизимом, для их достижения продукт надо не ломать, а любить.
* Настоящие тестировщики непрерывно развиваются. И развивают молодую неокрепшую отрасль!
Выводы
Настоящие Тестировщики сделают выводы сами :-)
А я просто хочу сказать этим редчайшим людям, которых можно заносить в Красную Книгу: «СПАСИБО!».
Спасибо, что не стоите на месте.
Спасибо, что приносите пользу проектам.
Спасибо, что развиваете отрасль!
