В предыдущей статье я представил Rapid Testing (быстрое тестирование), подход к тестированию программного обеспечения, основанный на тренировке навыков. В нескольких следующих статьях мы рассмотрим один из ключевых навыков Rapid Testing: критическое мышление. Тестировщики предоставляют руководству услуги по добыче информации, которая позволяет менеджерампринимать обоснованные бизнес-решения о программном обеспечении. Как тестировщики, мы предоставляем более полную информацию – и делаем возможным принятие более эффективных решений – когда мы размышляем о программном обеспечении критически.
Что значит мыслить критически? Целью критического мышления являются обоснованные, бесстрастные, тщательные и точные оценки и суждения. Эти оценки основываются на детальных наблюдениях, старательном сборе и взвешивании свидетельств, распознавании значимых сходств и различий, осведомленности о предубеждениях и «слепых пятнах»(и устранение их в максимальной возможной степени), непрерывном повторном применении полученных знаний. Критическое мышление требует от нас рассматривать объект мышления в контексте. А также необходимо изучать, подвергать сомнению и улучшать сами способы размышления и наблюдения.
На встречах, в спецификациях, во время неформальных обсуждений мы часто употребляем слово "пользователь", абстрактный, недифференцированный термин, которым мы определяем всех возможных потребителей нашего продукта. Очень редко проводится хотя бы различие между "новичком" и "опытным пользователем". Тем не менее, некоторые из нас знают, что пользователи так же разнообразны, как птицы.
Люди, мыслящие критически, разбивают более широкие категории на более узкие подкатегории, чтобы выделить существенные сходства и различия.
Мне не раз приходилось сталкиваться с этим в реальных проектах, и меня беспокоило то, что мы рассматривали «пользователей» всех скопом, не вдаваясь в детали и не проводя различий.
Люди, мыслящие критически, исследуют то, что другие принимают как само собой разумеющееся. Я пытался представить себе этих пользователей и старался придумать как можно больше различий, которые могут между ними существовать.
Бытует мнение, что тестировщикам вредно уметь программировать. Якобы это умение мешает им потому, что из-за него они слишком много думают о реализации программы и слишком мало о том, как же её протестировать.
Определенный смысл в этом есть, возможно для кого-то умение программировать действительно служит отвлекающим фактором. Но если вы умеете бороться с искушениями, тогда этот навык может оказаться весьма полезным, потому что он даёт возможность переложить часть своей работы на компьютер.
Да, имеется в виду автоматизацию тестирования. Но под автоматизацией подразумевается не только написание скриптов, которые эмулируют взаимодействие пользователя с графическим интерфейсом программы. Помимо этих скриптов можно автоматизировать генерацию тестовых данных, проверку содержимого базы данных, развёртывание и настройку тестового окружения, проверку отсутствия сообщения об ошибках в лог-файлах, генерацию отчётов, и многое-многое другое.
Сложно ли научиться программировать? Вероятно, бывают люди, для которых алгоритмический стиль мышления абсолютно неприемлем. Но большинство айтишников по крайней мере на интуитивном уровне уже обладают алгоритмическим мышлением. Многие тест-дизайнеры пишут весьма подробные инструкции для ручного тестирования, это почти готовые программы, но предназначенные для "биороботов". Осталось сделать один небольшой шаг и научиться управлять настоящими роботами-компьютерами.
Разучитесь ли вы тестировать, научившись программировать? Вовсе нет, существующие навыки тестировщика от вас никуда не денутся. Но в дополнение к ним в ваших руках появится ещё один инструмент, и весьма мощный. Разумеется, владение навыками программирования не означает, что их нужно применять здесь и там без разбора, стремясь автоматизировать всё подряд. Силу нужно держать под контролем и применять её лишь там, где её применение обосновано. Для этого нужно хорошо овладеть силой, чтобы она подчинялась вам, чтобы это был привычный инструмент с понятными принципами работы, а не магический артефакт, управляемый загадочными заклинаниями.
Ну что ж, довольно слов, пора перейти к делу.
Как и всякий навык, умение программировать нужно тренировать и закреплять. Недостаточно просто прочитать книжку и выучить набор команд. Знать ещё не значит уметь. Поэтому тренинг "Программирование для тестировщиков" будет содержать как теоретические сессии, так и практические задания для самостоятельного выполнения.
Мы уже получили довольно много вопросов когда же начнется следующий курс. Мы не планируем повторять данный курс, так как он не подразумевает большой работы с тренером, постоянных консультаций и множество итераций во время проверки домашнего задания, как например курс "Программирование для тестировщиков", который учит конкретному навыку – программированию автотестов.
Данный курс больше теоретический: про Selenium и про различные фреймворки, библиотеки и вспомогательные инструменты, расширяющие возможности Selenium или упрощающие его использование, поэтому повтора не будет , так как есть записи.
Помимо записей, конечно же, тренер ответит на все вопросы, которые возникнут у слушателей по мере прохождения данного курса.
Как себя вести, когда вообще нет Спека?
2011-04-05 01:45
Я думаю, многие тестировщики сталкивались с такой проблемой, когда нет Спека вообще. К сожалению в компании, где я работаю, это считается нормальным явлением (по правде говоря, спек я видел только раз, за все время работы =(),все сводится к тому, что пока нет времени и нужного человека, который мог бы этим в плотную заняться, есть только что-то похожее на ТЗ, которое может быть полезно только разработчикам . Что более печально, что я начинающий тестировщик и пока единственный в компании, старый тестировщик уволился в тот же день, когда я пришел. Обо всем, что я тестировал мне приходилось узнавать у разработчиков ("которые вечно заняты") в устной форме, в результате о качестве тестов и речи быть не может. За последние две недели, у клиентов проявилось несколько критичных багов, после чего я начал замечать, не совсем доброжелательные взгляды, со стороны "разработки", ведь бонусный бюджет пострадает общий... Подскажите пожалуйста, как быть в такой ситуации? Как повысить качество тестов и тестируемого ПО?