Большая часть моей работы посвящена обучению, тренировке и оценке тестировщиков. Как гуманисту, мне хочется применить тут эвристику разнообразия: наши различия могут сделать команду сильнее. Это означает, что я не могу выбрать один-единственный тип тестировщиков и оценивать людей согласно этому шаблону. С другой стороны, я вижу интересные модели навыков и темперамента у тестировщиков, и имеет смысл обсудить эти модели в широком ключе. Да, все снежинки различаются, но также верно, что все снежинки похожи друг на друга.
Итак, я выделяю как минимум семь различных типов тестировщиков: административный, технический, аналитический, социальный, эмпатический тестировщик, пользователь и разработчик. Когда я начну углубляться в объяснения, я хочу, чтобы вы поняли следующее: это модель, а не тюрьма. Это кластеры эвристик или – в некоторых случаях – ролей. Ваш стиль работы или ситуация могут подходить для нескольких моделей сразу.
Несмотря на период отпусков, работа над главной конференцией этой осени SQA Days-24 кипит. Уже поступил ряд докладов с очень интересными темами. Также будут участвовать крутые зарубежные спикеры.
Приглашаем присоединиться с докладом. Сроки подачи докладов продлены до 30 сентября.
Согласно CWsites на Mind Eye Web Design, 95% пользователей игнорируют 80% содержания сайта. Эта статистика уже против вас, как же улучшить содержание, дабы убедиться, что пользователи получают от сайта максимум?
В этой статье мы описали 11 советов по улучшению читабельности, удобства и ценности содержания любого сайта.
Нередко бывают ситуации, когда необходимо быстро получить тестовые данные для проверок. И если таких данных нет под рукой, на помощь приходят они — сервисы генерации.
Представляем вашему вниманию небольшую подборку полезных инструментов, которые мы используем в нашей работе.
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
Вопрос «Что именно делает тест хорошим или плохим» задавался недавно не только в Software Testing Clinic, но и на моих личных воркшопах. Я не думаю, что «хорошие» или «плохие» тесты в принципе существуют. Если я прогоняю простейший поверхностный тест и он находит баг, помогает мне сформулировать новую идею или вскрывает новую полезную для меня информацию – это хороший тест. При этом это не означает, что я могу полагаться исключительно на простые или поверхностные тесты.
Разновидностей тестов много, и все из них могут принести тестировщику пользу. При этом я хочу убедиться, что каждый из выбранных мною тестов обладает наивысшим качеством в пределах моих способностей. Качество теста определяет ценность теста. Низкокачественный тест мало что мне сообщает – как правило, или то, о чем я уже знаю, или вообще ничего. Качественный тест помогает мне продолжать тестирование и делиться новой интересной информацией с командой. Давайте разберемся, как создавать качественные тесты.
Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта
О чём это всё
Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.
В этой статье я хотел бы внести ясность и объяснить разницу между этими видами тестирования и попробовать разобраться, провести границы (хоть и условные) где заканчивается один вид тестирования, и начинается другой.
Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?
Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.
Для начала минимизируйте все, что может затруднить вам просмотр. Закройте все, что стучится в сеть, кроме одной вкладки одного браузера. Я выбираю IE из-за приятного плагина, а затем запускаю Fiddler.
Привет, друзья! Меня зовут Роман Савин, я -- автор книги "Тестирование дот ком". Я только что выпустил новый видео-курс для начинающих тестировщиков на английском языке и хочу вам о нем рассказать.
Итак, для чего мы идем на курсы тестирования? Цели две: 1. Получить работу тестировщика и 2. Освоить азы профессии, чтобы после получения работы тебя не выгнали на второй день из-за того, что ты не знаешь, например, разницу между веб-браузером и веб-сервером.
А это значит, что начальное QA образование должно быть сфокусировано на двух вещах: 1. Подготовка к интервью и 2. Основы тестирования и интернета.
Как учитель и автор, я помогаю своим студентам в получении/удержании работы, используя простой язык для моих лекций, практические примеры и тренировочное ПО. Но со временем я понял, что этого мало - нужен новый формат подачи материала и практическая помощь студентам в написании резюме, поиске работы, прохождении интервью и стажировке в софтверной компании.
Чтобы решить эти вопросы, я начал сотрудничество с американской компанией QA Mentor, с которой мы в апреле 2018 выпустили видео-курс по тестированию и разработали методику для помощи студентам в трудоустройстве.
При изучении любой дисциплины самое сложное/главное понять основы, базовые принципы, на пальцах, на школьных примерах, затем, на этот металлический каркас можно навесить тонны бетонной практики, получившийся железобетонный монолит станет гарантией практически не ограниченного технического роста специалиста. Звучит самоочевидно, не правда ли ..? И тем не менее, субъективный опыт автора в проведении собеседований, а это около ~500 специалистов из стран СНГ, Индии, США в Автоматизации тестирования и сопоставимые цифры в С \ С++ мире, говорит, что даже Senior разработчики в большинстве не понимают «физического смысла» ООП, не могут озвучить базовую формулировку одного из «столпов» - инкапсуляции, хотя знают как на 3 языках, 20 способами реализовать интерфейс, класс и объект, а вот вырасти дальше уже не могут, и вынужденно в течении 20 лет топчутся на месте. Вот это досадное карьерное недоразумение мы и постараемся исправить. IMHO тема будет интересна/полезна самому широкому кругу слушателей, от молодых специалистов в Ручном тестировании до Архитекторов в Автоматизации.
Еще не так давно тестирование безопасности (и его не менее пугающий брат, тестирование проникновения) было огромной страшной букой, которую укрощали те, кто в ней разбирался. Им за это очень и очень хорошо платили. Затем жизнь изменилась, и я внезапно обнаружила себя натыкающейся на штуки, которые дорого бы стоили моему работодателю, если бы я их не поймала.
Внезапно я стала больше узнавать о началах тестирования безопасности – никогда не думала, что мне понадобятся такие знания – и это было изматывающе, потрясающе и ужасающе (примерно поровну).
