Сегодня я не мог уснуть.
Уже не первый день тяжелые мысли омрачают мое бренное существование.
Их первоисточником (или, скорее, катализатором) было описание зоны тестирования на сайте Школы тестирования SQA, расположенной в Силиконовой долине .
В этом описании тестирование представлено как элементарная область, освоить которую можно очень быстро, требует минимум знаний и на которой можно очень хорошо зарабатывать.
Моей первой праведной мыслью было: тестирование обиделось! На смену первому пришел второй, более сбалансированный: то что описано вполне правда .
Устроиться на работу тестировщиком несложно.
Легко быть плохим тестировщиком и при этом не быть уволенным.
Легко не принести проекту ни малейшей пользы и при этом заработать нормальные деньги.
Но есть настоящие гении своего дела, которые пригодятся и, несмотря на «болотистость» рынка труда в сфере тестирования, являются высококвалифицированными специалистами! Кто они? Как отличить настоящих джедаев от фейковых тестировщиков? Результатом обсуждения стало СПИСОК ДЕСЯТИ ОТЛИЧИЙ НАСТОЯЩЕГО ТЕСТЕРА ОТ ПОДДЕЛОЧНОГО ТЕСТЕРА.
1. Настоящие тестировщики едины с проектом.
Настоящие тестировщики — не враги программистам.
Настоящие тестировщики не ставят перед собой задачу «сломать продукт», а затем саркастически потирать руки.
Настоящие тестировщики совсем не радуются наличию проблем, багов, дефектов и ошибок! Чтобы быть полезным для проекта, тестирование должно действовать как услуга.
Баги — это не продукт, который можно выпустить.
Баги не помогают. Только деятельность, направленная на достижение общих целей, приносит пользу.
И для этого вам нужно: * учитывать цели проекта * адаптироваться к внешним условиям (приоритеты, сроки, цели, задачи верхнего уровня) * уметь разобраться: ЧТО нужно сделать СЕЙЧАС, чтобы помочь проекту достичь цели? Если тестирование неэффективно, ошибки обнаруживаются поздно и вносятся некачественно, то их будет все больше: плохая локализация дефектов отнимает время у разработчиков, а их внедрение в неприоритетном порядке приводит к затруднениям в работе.
фиксация.
Поэтому вместо задачи «как найти кучу багов и DDOS у разработчиков», настоящие тестировщики думают: «Что сейчас нужно проекту, в каком формате и с какими приоритетамиЭ»
2. Настоящие тестировщики знают, как разрабатывать тесты.
Никаких маниакальных щелчков и испытаний на скоте! Настоящие тестировщики знают, как разрабатывать тесты.
Для этого они хотя бы запомнили Библия тестового дизайна Ли Коупленда , и максимум - освоил контроль рисков качества .
В зависимости от условий тестирование может проводиться исследовательски или на основе тест-кейсов, но тесты делаются не на ровном месте «дайте я нажму кнопки», а только по результатам анализа: что нужно протестировать, в какой приоритет и как это можно сделать наиболее эффективно? Для этого любое тестирование начинается с изучения изделия, факторов, влияющих на его работу, и последующей их поломки.
Сначала – подумайте, потом – протестируйте!
3. Настоящие тестировщики понимают архитектуру тестируемого программного обеспечения.
Вам не обязательно быть продвинутым разработчиком, чтобы стать настоящим тестировщиком.
Но чтобы понять, как эффективно тестировать свое приложение, вам просто необходимо знать его архитектуру! Тестирование «черного ящика» не позволяет детально изучить продукт, а тестирование только «со стороны пользователя» приводит к тому, что многие факторы, влияющие на работу ПО, не учитываются.
Тестирование «черного ящика» — это тестирование в «черном ящике» без окон и с закрытыми глазами.
Идешь наощупь, натыкаешься на какие-то шероховатости в изделии и начинаешь делать ошибки «где-то в левом углу что-то не так».
Откройте глаза и включите свет! Посмотрите, что вы тестируете! Зная, как работает программа, вы сможете: * разрабатывать тесты более эффективно * обеспечить более широкий охват, зная факторы, влияющие на работу программного обеспечения.
* более точно и грамотно локализовать ошибки – а это значит экономия времени разработчиков и проекта в целом!
4. Настоящие тестировщики — мастера общения.
Кому, как не тестерам, придется нести плохие новости? Худшее, что вы можете сделать, обнаружив дефект, — это сказать разработчику: «Ну ты облажался!» Нам не просто нужно найти и зарегистрировать дефект. Нужно сделать все, чтобы исправить это было легко и приятно.
Каждая исправленная в программе ошибка — это здорово, и это понимает любой разработчик.
Если только Ему заранее не сказали, что он «грязный», «плохой» и «глючный»! Как общаться с разработчиками о дефектах - запись выступления Алексея Баранцева на встрече Московский клуб тестировщиков .
5. Настоящие тестировщики прекрасно разбираются в области применения.
Однажды я проводил аудит процесса тестирования в московской компании, занимающейся разработкой бухгалтерского программного обеспечения.
По словам руководства компании, тестировщики пропустили слишком много дефектов.
Причина оказалась простой: аналитики компании (2 шт.) написали тест-кейсы для тестировщиков компании (~15 шт.).
Тестировщики проходили их и фиксировали все отклонения в поведении ПО от того, что было задокументировано в тест-кейсах.
При этом даже не поняли, что такое баланс и на каком основании формируются отчеты! Естественно, это не могло принести высокого качества тестирования.
Аналитики, не зная подходов к проектированию тестов (поскольку это не их работа), не смогли оптимизировать тестовое покрытие.
А потенциальные тестировщики искали только различия между постоянно устаревшими тестами и поведением программы.
Если что-то шло «не так», и это «не так» не фиксировалось в тестах, то они даже не догадывались, что перед ними дефект.
Чтобы этого не произошло, настоящие тестировщики должны знать, как работает продукт. Они должны знать пользователя, его ментальную модель: как используется продукт? При каких условиях? Как?
6. Настоящие тестировщики не являются экспертами.
Если вы слышите слова «Я настоящий эксперт!», значит, вы не настоящий тестировщик.
Потому что быть экспертом в едва зарождающейся отрасли невозможно.
Потому что методологическая база незначительна, да и то постоянно меняется.
Новые методы и подходы появляются с неумолимой скоростью.
Продвинутые тестировщики всех направлений создают его, создают прямо сейчас! Как можно быть экспертом в области, которая еще не сформировалась? Что слишком гибко, чтобы называться «правильным»? «Я эксперт!» = «Я больше не буду развиваться».
И речь идет НЕ о настоящих тестировщиках.
7. Настоящие тестировщики выбирают цели, а не средства.
Как часто отрицательные тесты автоматизируются? рентабельность инвестиций только потому, что автоматизация — это «круто», а ручное тестирование — «скучно»? Как часто тесты документируются, превращаясь в кучу бесполезных и корявых бумажек просто потому, что они «солидные»? В тестировании (как, возможно, и в других областях?) многие решения принимаются исходя из «круто», «интересно» и «давайте попробуемЭ».
Но понятие «крутость» не абсолютно! У каждого проекта, у каждой команды свои условия работы, и эффективное тестирование всегда необходимо.
определяется контекстом ! Когда настоящие тестировщики решают что-то реализовать, они говорят: «Это будет полезно для нашего проекта, потому что…».
И эти слова больше всего отличают настоящего тестера от подделки.
8,9,10. Настоящие тестировщики любят свою работу, любят свою продукцию и постоянно развиваются.
Для соответствия десяти заявленным пунктам кратко выделю еще три: * Настоящие тестировщики ЛЮБЯТ свою работу, всегда находят в ней творческий подход, и у них не может быть рутины! Потому что каждое новое задание выполняется лучше, качественнее, эффективнее – а значит, интереснее и интереснее! * Настоящие тестировщики любят свою продукцию.
Невозможно тестировать программное обеспечение и быть деструктивистом.
Задача настоящего тестировщика — уменьшить количество дефектов, принять профилактические меры и провести тестирование на ранних стадиях, чтобы серьезные дефекты вообще не проявились.
И эти цели несовместимы с деструктивностью; для их достижения продукт нужно не сломать, а полюбить.
* Настоящие тестировщики постоянно развиваются.
И они развивают молодую, хрупкую индустрию!
выводы
Настоящие тестеры сделают свои выводы :-) И мне просто хочется сказать этим редким людям, которых можно занести в Красную книгу: «СПАСИБО!» Спасибо, что не стоите на месте.Спасибо за пользу проектам.
Спасибо за развитие отрасли! Теги: #тестирование #коммуникации #проекты #тестирование ИТ-систем
-
Ури, Гарольд Клейтон
19 Oct, 24 -
Действительно Ли Seo Имеет Значение?
19 Oct, 24 -
Выпущен Firefox 8.0
19 Oct, 24 -
Мир Intel Завтрашнего Дня
19 Oct, 24 -
История Одной Разработки
19 Oct, 24 -
Что Говорит Статистика О Рынке Iaas
19 Oct, 24
