Один из наиболее популярных вопросов от новичков в
тестировании — как устроиться на работу, если никто не зовет после прочтения
резюме? По большей части такой вопрос возникает, если резюме составлено не
очень грамотно и не отражает всех навыков специалиста. Это неудивительно —
навык составления резюме не берется из воздуха, ему тоже нужно учиться. Но вот
если подходить к составлению резюме с умом и избегать популярных ошибок - можно
значительно увеличить свои шансы на собеседование, а значит - быстрее найти
работу.
В этом видео тренер Арсений Батыров представил топ-5 ошибок в резюме junior qa, которые чаще
всего встречаются в резюме новичков, и подсказал способы их исправить.
Допустим, что вы решили начать писать автотесты в Postman-е. Взяли пример из документации:
pm.expect(X).to.eql.;
«Мы ожидаем, что X = Y». Так можно проверить число, строку, и даже объект!
Но как «достать» этот самый X из ответа от сервера? Я видела, как это делают новички — они просто подставляют в переменную Х название нужного поля. Но тест при этом, увы, не работает. Потому что Postman не делает поиск по дереву json в поисках такого названия. Вам нужно указать точный путь к нужному параметру.
И сегодня я научу вас, как это делать. Пойдем от простого к сложному:
Как обычно тестировщик ищет границы в поле? Если в ТЗ есть ограничения, то тестирует их. А если их нет? С нижней границей все понятно — это пустое поле. А как найти верхнюю? Вставляем большую строку и смотрим, сколько символов сохранится. И всё…
И тестировщик должен проверить их все. Почему? Потому что когда мы одно значение дублируем несколько раз в разных местах, велик шанс ошибиться. При этом границу на клиенте очень легко снять. Что будет, если пользователь обойдет границу на клиенте? Не сломает ли он нам сайт большой строкой?
В этой статье я расскажу, как искать границы для поля в веб-формочке. Возьмем для примера форму редактирования пользователя в бесплатной системе Users.
Автор: Пол Симан (Paul Seaman) в соавторстве с Ли Хокинсом (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Недавно мы прочитали статью на сайте QA Revolution под названием "7 веских причин для создания детальных тест-кейсов". Статья утверждает, что дает "значимое обоснование для создания детальных тест-кейсов", и идет дальше, пытаясь "вдохновить вас писать более детализированные кейсы в будущем". Мы категорически не согласны как с предпосылкой, так и с "вескими причинами", и в этой серии статей мы обоснуем свою точку зрения.
Загрузить через любой сервис конвертирования изображения в base64 строку, например, https://www.base64-image.de/
Скопировать полученную строку целиком, включая начало: «data:image/png;base64,iVBORw0KG...»
Вставить в параметр для передачи фото в формате base64
Профит! Инструкция одинаковая для REST и SOAP.
Но смысл этого поста, разумеется, не в инструкции. А в том, чтобы сразу ее применить! Попробовать пощупать самостоятельно. Сделать это можно в API бесплатной системы Shop, метод create или update.
О задачах автоматизации тестирования и случаях, когда она необходима, мы уже писали. А для выбора необходимых проверок удобно иметь под рукой наглядное пособие, не ограничиваясь знаменитой пирамидой автотестов. Предлагаем перевод статьи Кристин Джеквони (Kristin Jackvony), где графически показан еще один метод – колесо автоматизации.
Автоматизация тестирования, как правило, наиболее необходима в масштабных приложениях с большим количеством бизнес-функций, при внедрении CI/CD и регулярных релизов. Подробнее об этом мы рассказывали в статье «Что даёт автоматизация тестирования».
С разрешения Кристин Джеквони – автора блога Think Like a Tester и ряда популярных материалов о тестировании – мы перевели статью «Переосмысление пирамиды автотестов: колесо автоматизации» (Rethinking the Pyramid: The Automation Test Wheel). В конце статьи рассмотрим пример проверок из практики наших специалистов по автоматизации тестирования (SDET).
Считается, что через тестирование можно легко зайти в ИТ. Мы спросили наших специалистов по тестированию, как это реализовать без поступления на профильные программы обучения в вузы. Оказалось, что можно ограничиться базой по информатике, одной книжкой по тестированию и правильным выбором, где получать первый опыт. Правда, приправить это надо собственной заинтересованностью и усердием.
Под катом — наши советы и ответы на распространенные вопросы новичков. Есть немного и о том, куда двигаться дальше, когда кажется, что потолок знаний близко.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Недавно постоянный читатель моего блога показал мне отличную статью о важности технических навыков для тестировщика. Автор проводит прекрасную аналогию: тестировщик, не разбирающийся в технических концепциях, похож на хирурга, не знающего анатомию. Если мы планируем тщательно тестировать наши приложения, то должны понимать базовые системы, заставляющие их работать.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Недавно я тестировала загрузку файлов, а это всегда увлекательно. Это также очень важно, потому что загрузка вирусного файла – один из способов, путем которых злоумышленник может издеваться над вашим приложением, уронив его или получив доступ к закрытым данным. Сегодня я дам вам шесть советов и расскажу о четырех инструментах, помогающих успешно тестировать загрузку файлов.
QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.
