Есть QA инженеры, которые находят много багов, а есть те, кто находит в разы меньше. Много лет размышляя о том, как же это так у меня получается находить в несколько раз больше багов чем у других(и как у других получается находить больше чем нашел я), я сформулировал список советов, соблюдая которые почти любой человек может находить достаточно много багов.
Советы эти очень простые и проверены многолетней практикой многими QA инженерами, с которыми я обсуждал как они ищут и находят баги:
Фокусируйтесь на поиске багов
Все время держите в голове мысль "так, где-то здесь баги и я должен их найти сейчас". Баги там точно есть, и вы их обнаружите.
Не пропускайте ни один баг (не игнорируйте баги)
Если вы заметили, что что-то не так - сразу пишите баг-репорт. Придумали как можно сделать лучше? - задокументируйте свою идею, пока помните об этом. В результате у вас будет больше найденных багов, и ничего не будет упущено.
Устраивайте короткие сессии поиска багов
Выделяйте по 30-120 минут один раз в день или один раз в неделю - когда вы берете кофе/какао/чаек, одеваете наушники и ищете баги, ни на что не отвлекаясь (никакой почты, разговоров с коллегами, чатиков, социальных сетей - все выключаем и закрываем вкладки - и открываем приложение, которое тестируем).
Делайте такие сессии регулярно, это тоже важно. И при этом не забываем про первые два правила.
Читайте/изучайте теорию тестирования и тест дизайна
Умные люди уже давно все придумали и описали в книжках, не менее умные люди пишут на эти темы блоги, книги и делают выступления на конференциях.
Вам нужна эта информация, и более того - вы должны не просто читать об этом, а обдумать - как зарождалась каждая практика тестирования, где она применима и где она более эффективна, как применить ее на вашем проекте.
Лет десять назад, если вы начинали работать QA инженером, вы могли себе позволить первые пару месяцев не знать о теории тестирования. Сегодня это то, что вас спросят на любом собеседовании, еще до того как вы начнете что-то тестировать )).
Тестируйте разные программы
Не ограничивайтесь тестированием чего-то одного, например, тестированием того проекта, на котором сейчас работаете. Пробуйте тестировать сайты почты, пиццерий, визовых центров, онлайн-кинотеатров, мобильных приложений или чего-то, чем часто пользуетесь или что вам интересно. Изучайте как оно устроено, какие типичные проблемы встречаются на разных ресурсах, какие вообще баги встречаются и какие вы быстрее всего находите.
Общайтесь с другими QA
Общайтесь с другими QA инженерами, пусть они рассказывают вам свои истории поиска бага в три часа ночи, или как что-нибудь выкатили в продакшн без тестирования. Или истории о том, какой фреймворк они написали на своем проекте и какие баги этот фреймворк позволяет находить. При этом можно даже не взаимодействовать с людьми - смотрите youtube видео с выступлениями других людей, посещайте конференции/митапы/сходки/тематические вечера, подпишитесь на QA чатики и блоги - там очень много подобного материала, каждый день что-нибудь новенькое появляется.
Все это общение и информация даст вам постоянно обновляющуюся базу данных, из которых нейронная сеть в голове сконструирует интуицию, которая будет помогать находить баги там, где вы сами сознательно не ожидаете их найти.
Размышляйте
Размышляйте о том, почему люди не могут писать код без багов, о том, почему не получается найти все баги, и почему даже какие-то баги в продакшене - это нормально и не критично (но это не точно). Размышляйте о разных вопросах, связанных с багами - формулируйте собственную философию о таких вопросах, ищите ответы, подкрепляйте ответы реальными историями из жизни. Если ваш мозг постоянно возвращается к таким мыслям, со временем вы меняете свое мышление и начинаете находить все больше и больше багов, и делаете все более и более крутые тесты и проверки.
Делайте что-то новое
Отмечайте хорошо проверенные вами области проекта, и фокусируйтесь на поэтапном тестировании тех областей, которые вы еще не проверяли. Переодически переключайтесь между областями проекта и методами проведения тестов. Уже пол года занимаетесь функциональным тестированием? - найдите возможность на 2-3 недели позаниматься нагрузочным тестированием или тест дизайном (не проверками, а планированием), или например напишите какие-нибудь автотесты для самых критичных, еще не покрытых, областей, просто чтобы переключиться и дать вашему сознанию посмотреть на ваши обычные задачи под другим углом.
Автоматизируйте
Вот серьезно, есть люди (и среди них иногда есть хорошие QA), которые каждый день делают одни и те же тесты руками (совсем грустный кейс - проверка логина/регистрации, каждый день, руками). Если вы узнаете себя в этом описании или вы уже давно подумываете что-то автоматизировать из вашей ежедневной работы - сделайте это, отвлекитесь от всех задач и заскриптуйте (даже если это будет очень топорный и простой скрипт).
Ваш мозг не любит повторяющиеся действия, он на них отключается. А он вам нужен, чтобы найти баг! Используйте свой мозг, следите, чтобы он постоянно был в активном состоянии поиска несоответствий с вашими ожиданиями.
Повторяющиеся проверки перебрасывайте на автоматические скрипты, и давайте вашему мозгу и вашей интуиции работать с чем-то свежим и новым, тут же найдутся новые баги, вот увидите.
Общайтесь с разработчиками и пользователями
Придумайте способ получать возможность общения с вашими разработчиками и пользователями вашего продукта. Читайте их отзывы, спрашивайте о проблемах у команды поддержки пользователей, запишитесь волонтером по обработке пользовательских баг-репортов или пару часов в неделю работайте в команде поддержки пользователей (или просто попросите добавить вас в их чатик).
Иногда самые важные проблемы вы находите именно в момент общения с другими людьми. А те особенности реализации, новые фичи и тот технический долг, о котором вам расскажет программист - отличная почва для размышлений о том, где еще прячутся баги.
Рассказы пользователей о том, как они используют систему - тоже отличный повод пересмотреть свой тест план / чек листы и убедиться, что вы проверяете основные сценарии реальных пользователей. Ведь тут самое важное! А баги могут найтись везде :)
PS: QA Battle - для тех, кто любит искать баги и хочет потренироваться находить как можно больше багов. Мы сейчас работаем над серией обучающих простых уроков с примерами того, где могут прятаться реальные баги. Тренируясь на таких задачках, вы прокачиваете свой скилл и ваш мозг уже интуитивно работает более эффективно когда вы тестируете реальные продукты.
Успехов вам в поисках :)
Советы эти очень простые и проверены многолетней практикой многими QA инженерами, с которыми я обсуждал как они ищут и находят баги:
Фокусируйтесь на поиске багов
Все время держите в голове мысль "так, где-то здесь баги и я должен их найти сейчас". Баги там точно есть, и вы их обнаружите.
Не пропускайте ни один баг (не игнорируйте баги)
Если вы заметили, что что-то не так - сразу пишите баг-репорт. Придумали как можно сделать лучше? - задокументируйте свою идею, пока помните об этом. В результате у вас будет больше найденных багов, и ничего не будет упущено.
Устраивайте короткие сессии поиска багов
Выделяйте по 30-120 минут один раз в день или один раз в неделю - когда вы берете кофе/какао/чаек, одеваете наушники и ищете баги, ни на что не отвлекаясь (никакой почты, разговоров с коллегами, чатиков, социальных сетей - все выключаем и закрываем вкладки - и открываем приложение, которое тестируем).
Делайте такие сессии регулярно, это тоже важно. И при этом не забываем про первые два правила.
Читайте/изучайте теорию тестирования и тест дизайна
Умные люди уже давно все придумали и описали в книжках, не менее умные люди пишут на эти темы блоги, книги и делают выступления на конференциях.
Вам нужна эта информация, и более того - вы должны не просто читать об этом, а обдумать - как зарождалась каждая практика тестирования, где она применима и где она более эффективна, как применить ее на вашем проекте.
Лет десять назад, если вы начинали работать QA инженером, вы могли себе позволить первые пару месяцев не знать о теории тестирования. Сегодня это то, что вас спросят на любом собеседовании, еще до того как вы начнете что-то тестировать )).
Тестируйте разные программы
Не ограничивайтесь тестированием чего-то одного, например, тестированием того проекта, на котором сейчас работаете. Пробуйте тестировать сайты почты, пиццерий, визовых центров, онлайн-кинотеатров, мобильных приложений или чего-то, чем часто пользуетесь или что вам интересно. Изучайте как оно устроено, какие типичные проблемы встречаются на разных ресурсах, какие вообще баги встречаются и какие вы быстрее всего находите.
Общайтесь с другими QA
Общайтесь с другими QA инженерами, пусть они рассказывают вам свои истории поиска бага в три часа ночи, или как что-нибудь выкатили в продакшн без тестирования. Или истории о том, какой фреймворк они написали на своем проекте и какие баги этот фреймворк позволяет находить. При этом можно даже не взаимодействовать с людьми - смотрите youtube видео с выступлениями других людей, посещайте конференции/митапы/сходки/тематические вечера, подпишитесь на QA чатики и блоги - там очень много подобного материала, каждый день что-нибудь новенькое появляется.
Все это общение и информация даст вам постоянно обновляющуюся базу данных, из которых нейронная сеть в голове сконструирует интуицию, которая будет помогать находить баги там, где вы сами сознательно не ожидаете их найти.
Размышляйте
Размышляйте о том, почему люди не могут писать код без багов, о том, почему не получается найти все баги, и почему даже какие-то баги в продакшене - это нормально и не критично (но это не точно). Размышляйте о разных вопросах, связанных с багами - формулируйте собственную философию о таких вопросах, ищите ответы, подкрепляйте ответы реальными историями из жизни. Если ваш мозг постоянно возвращается к таким мыслям, со временем вы меняете свое мышление и начинаете находить все больше и больше багов, и делаете все более и более крутые тесты и проверки.
Делайте что-то новое
Отмечайте хорошо проверенные вами области проекта, и фокусируйтесь на поэтапном тестировании тех областей, которые вы еще не проверяли. Переодически переключайтесь между областями проекта и методами проведения тестов. Уже пол года занимаетесь функциональным тестированием? - найдите возможность на 2-3 недели позаниматься нагрузочным тестированием или тест дизайном (не проверками, а планированием), или например напишите какие-нибудь автотесты для самых критичных, еще не покрытых, областей, просто чтобы переключиться и дать вашему сознанию посмотреть на ваши обычные задачи под другим углом.
Автоматизируйте
Вот серьезно, есть люди (и среди них иногда есть хорошие QA), которые каждый день делают одни и те же тесты руками (совсем грустный кейс - проверка логина/регистрации, каждый день, руками). Если вы узнаете себя в этом описании или вы уже давно подумываете что-то автоматизировать из вашей ежедневной работы - сделайте это, отвлекитесь от всех задач и заскриптуйте (даже если это будет очень топорный и простой скрипт).
Ваш мозг не любит повторяющиеся действия, он на них отключается. А он вам нужен, чтобы найти баг! Используйте свой мозг, следите, чтобы он постоянно был в активном состоянии поиска несоответствий с вашими ожиданиями.
Повторяющиеся проверки перебрасывайте на автоматические скрипты, и давайте вашему мозгу и вашей интуиции работать с чем-то свежим и новым, тут же найдутся новые баги, вот увидите.
Общайтесь с разработчиками и пользователями
Придумайте способ получать возможность общения с вашими разработчиками и пользователями вашего продукта. Читайте их отзывы, спрашивайте о проблемах у команды поддержки пользователей, запишитесь волонтером по обработке пользовательских баг-репортов или пару часов в неделю работайте в команде поддержки пользователей (или просто попросите добавить вас в их чатик).
Иногда самые важные проблемы вы находите именно в момент общения с другими людьми. А те особенности реализации, новые фичи и тот технический долг, о котором вам расскажет программист - отличная почва для размышлений о том, где еще прячутся баги.
Рассказы пользователей о том, как они используют систему - тоже отличный повод пересмотреть свой тест план / чек листы и убедиться, что вы проверяете основные сценарии реальных пользователей. Ведь тут самое важное! А баги могут найтись везде :)
PS: QA Battle - для тех, кто любит искать баги и хочет потренироваться находить как можно больше багов. Мы сейчас работаем над серией обучающих простых уроков с примерами того, где могут прятаться реальные баги. Тренируясь на таких задачках, вы прокачиваете свой скилл и ваш мозг уже интуитивно работает более эффективно когда вы тестируете реальные продукты.
Успехов вам в поисках :)
Спасибо тебе, мил человек!
ОтветитьУдалить