Первая встреча тестировщиков, на которой я побывал, была посвящена планированию тестирования. Ближе к концу отчета о своем опыте, с которого и начался разговор, докладчик процитировал Джеймса Уиттакера, сказав, что «Хороший тестировщик никогда ничего не предполагает». В то время я не знал, кто такой Джеймс Уиттакер, но цитата застряла в моей голове. Мы в итоге подняли эту тему и обсудили ее вкратце, но она спровоцировала для меня длительные размышления о небольших (или больших) допущениях и их месте в тестировании.
В детстве мое знакомство с допущениями началось с расхожей фразы, которую я до сих пор довольно часто слышу – «Когда ты предполагаешь, ты делаешь осла и из себя, и из меня» (игра слов – when you assume, you make an ass out of U and Me – прим. переводчика). Очевидно негативная коннотация и забавная игра слов заставили эту фразу застрять в голове, но если задуматься, неужели допущения – это так плохо? Исходя из фразы, любое предположение будет по умолчанию плохим и иметь негативные последствия. Это было мое первое и единственное знакомство с термином, на основе которого выстроился внутренне отрицательный взгляд на предположения. Причиной, объясняющей это, всегда было то, что предположения – это упражнения в лени, которые тебя в итоге погубят – лучше спроси, чем додумывай.
Здравствуйте. Меня зовут Илья Кудинов, мне 27 лет, и я тестировщик. Все: Здравствуй, Илья!
Мы уже много писали о том, как здорово мы в Badoo тестируем наши продукты. А сегодня я (внезапно!) расскажу о том, как круто тестировать ВООБЩЕ. И когда я встречаю представителей нашей профессии, которые не разделяют эту точку зрения, я всегда стараюсь открыть им глаза на истину. Например, этой самой статьёй.
О чём она будет? Я поделюсь своим личным опытом, расскажу, как развивалась индустрия в течение шести с небольшим лет, что я за ней наблюдаю, и опишу своё видение карьерного пути тестировщика. Устраивайтесь поудобнее, настало время (неразборчиво, зачёркнуто) занимательных историй…
Дисклеймер
Всё, что я напишу в этой статье, основано на моём личном восприятии, опыте и информации, которую я почерпнул на QA-конференциях и митапах. Статья будет интересна начинающим специалистам и тем, кто мечтает работать в IT, но ещё не определился с профессией. И главным образом тем, кто считает, что тестирование — несерьёзная, скучная и рутинная работа.
"Мы знаем больше , чем можем выразить словами". - Майкл Полани (1966)
Читаю превосходную книгу «Явное и неявное знание” Гарри Колинза. Она оказала значительное влияние на мои представления о том, как мы учимся и записываем информацию (знания). Это непростая книга для чтения. Мне потребовалось несколько раз перечитать некоторые разделы, чтобы понять, что имел в виду автор.
Для начала оговорюсь, что эта статья основана на моей собственной интерпретации книги и параллелях, которые я провожу между тем, что пишет автор, и тестированием. Итак, что же мы имеем в виду, когда говорим про явные и неявные знания?
Гарри Коллинз в своей книге подробно описывает, что он подразумевает под этими терминами, но я не могу найти чёткого определения, полезного для этой статьи. Поэтому я взял немного научных ссылок, которыми пользовался во время чтения книги. Одну из лучших я нашёл на этом сайте:
Явные знания: Знания, которые кодифицируются и передаются другим через диалог, демонстрацию или другие носители информации (книги, рисунки, документы и т.п.).
Неявные знания: Глубоко личный опыт, способности, восприятие, озарения и ноу-хау, которые подразумеваются, но не выражаются — они принадлежат отдельным лицам и командам.
Статья написана в соавторстве с Г.А. Агеевой, доцентом кафедры иностранных языков №2 Иркутского национального исследовательского технического университета
Команда – это организм, все части которого дополняют друг друга; это сообщество людей, имеющих единую цель.
У сотрудников в слаженной команде есть одно общее дело, одна на всех задача, которая должна быть решена. Каждый хорошо знает свой участок работы и может помочь другим; они вместе продумывают свои действия. В команде нет чужих, поэтому в ней выстраиваются живые и близкие личные отношения. Равнодушное «это не входит в мои обязанности» в настоящей команде просто невозможно услышать.
Но как добиться такой идиллии в том случае, когда вы, руководитель, не видите свою команду, не имеете возможности пообщаться с людьми вживую, понять их эмоции? Об этом мы и поговорим в статье.
Друзья, тем, кто планирует зарегистрироваться на вторую Международную конференцию TestCon Moscow 2018, которая пройдет 18-19 апреля, напоминаем, что до ее начала осталось всего неделя!
Уже полностью сформирована программа конференции. Более 30 спикеров мировой величины, из таких компаний, как RED HAT, VOLVO Group, CAPGEMINI, CloudBees и многих других поделятся с вами самыми горячими новостями. Докладов ожидается такое множество, что вместо привычного одного дня конференции, на этот раз мы предлагаем вам целых два!
ВАЖНЫЙ МОМЕНТ! На конференции будет предоставлен синхронный перевод докладов.
Напоминаем, что по сложившейся многолетней традиции, накануне конференции (17 апреля) мы проводим практические мастер-классы. На этот раз выбрать вы сможете из пяти разных тем:
Структурированное исследовательское тестирование
От TDD до ATDD
Agile тестировщик
Тестирование usability
Приемочное тестирование
TestCon Moscow 2018 это:
1 день мастер-классов – 17 апреля
2 дня конференции – 18 и 19 апреля
3 параллельных трэка каждый день
Более 30 спикеров
400+ участников
5 мастер-классов
Синхронный перевод докладов
Торопитесь, до конференции осталось всего неделя! Не оставайтесь в стороне!
Переход к модели непрерывной поставки ПО повлиял на растущую популярность автоматического тестирования. DevOps тоже голосуют за слом барьеров между традиционными ролями. Тестировщики, умеющие программировать (на самом деле этим автоматизаторы и являются) очень здорово встраиваются в эту новую парадигму.
Автоматизация тестирования предлагает множество потенциальных выгод, включая повышенную эффективность и предоставление работоспособного метода решения сложных задач тестирования. Автоматизирование тестов также дает повышенную систематичность, позволяя более эффективно использовать ресурсы в период провала нагрузки. Однако автоматизация – не панацея. Дабы осознать потенциал автоматизации, нужно быть в курсе трех распространенных ошибок автоматизации тестирования.
В одной команде, да и в целой компании невозможно найти сотрудников с абсолютно идентичными знаниями. Кто-то знает больше, кто-то меньше; одни больше понимают в исследовательском и скриптовом тестировании, а другие мастерски владеют навыками тест-дизайна и умением грамотно разработать тест-кейсы. Практически каждый сотрудник чего-нибудь не знает, каждый желает подтянуть свои знания, но, к сожалению, не имеет времени на обучение вне работы. В своей статье я хочу на примере нашей распределенной команды рассказать о том, как можно постепенно прокачивать навыки, затрачивая минимум усилий.
Про неформальное общение
Для начала мне хочется указать на одну очень простую вещь – на общение. Ваша команда должна общаться между собой не только по рабочим вопросам, но и «обо всем на свете». Неформальное общение расслабляет человека и увеличивает шанс того, что при возникновении вопросов или проблем он придет к своим коллегам и попросит совета. А это своего рода прокачка
Я начала работу в «Лаборатории качества» совсем зеленым тестировщиком, имея за плечами теоретические знания и лишь немного практики. Конечно, в голове постоянно крутились вопросы «а как правильно?» и «а как лучше?». И вот мой первый проект, первый дефект… первая паника («как лучше описать дефект в баг-трекере?»). После написания черновика мне очень хотелось проконсультироваться с кем-то более опытным и понять, все ли хорошо, и не вернут ли мне разработчики мой дефект с грозными замечаниями. Как вы помните, мы говорим о распределенной команде, в которой все общение происходило в скайпе. Я зашла в наш проектный чат и поняла, что вопросы есть не у меня одной, а более опытные коллеги спокойно отвечают и дают советы. В ответ на свой вопрос я получила ответ и рекомендации, и это уже была пусть и небольшая, но прокачка моих навыков.
