Доброго времени суток всем! Меня зовут Денис, я руководитель службы тестирования в «БАРС Груп».
Прочитав очень много интересных статей и почерпнув оттуда много полезной информации, захотелось что-то дать взамен. Тогда я начал анализировать темы: одни были уже озвучены, другие слишком просты («как войти в IT?»). P.S. ничьи чувства задеть не хотелось :)
Привет! Меня зовут Роман Иваницкий, я работаю в команде автоматизации тестирования Одноклассников. OK — огромный сервис с более чем 70 миллионами пользователей. Если говорить про мобильные устройства, то большинство пользуется OK.RU на смартфонах под управлением Android. По этой причине мы очень серьёзно относимся к тестированию нашего Android-приложения. В этой статье я расскажу историю развития автоматизированного тестирования у нас в компании.
2012 год, «Одноклассники», компания переживает активный рост числа пользователей и увеличение количества пользовательских фич. Для того, чтобы удовлетворять задачам бизнеса, нужно было сокращать релизный цикл, но это было затруднено тем, что все функциональности тестировались вручную. Решение этой проблемы пришло само собой – нужна автотесты. Таким образом, в 2012 году в «Одноклассниках» появилась команда автоматизации тестирования, и первым шагом было – начать писать тесты.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Недавно я тестировала загрузку файлов, а это всегда увлекательно. Это также очень важно, потому что загрузка вирусного файла – один из способов, путем которых злоумышленник может издеваться над вашим приложением, уронив его или получив доступ к закрытым данным. Сегодня я дам вам шесть советов и расскажу о четырех инструментах, помогающих успешно тестировать загрузку файлов.
Можно ли протестировать техническое задание за полчаса?
Вы уже 18-й день готовите тест-кейсы на новый модуль системы. Написана не одна сотня сценариев. Вдруг обнаруживаете, что один из отчетов накладывает ограничение, которое не было нигде задокументировано. Действительно, аналитик забыл ограничить множество значений, а вам теперь переделывать 30% тестовой документации. Естественно, без возможности увеличить сроки своей работы. И как же теперь быть? Сроки поджимают, заказчик ждет результатов, нехватка времени давит со всех сторон, все злятся друг на друга. Можно ли было этого избежать? Определенно да, если уделить немного времени тестированию технической документации.
Как правило, на тестирование требований не выделяют время проекта. Но есть методы экспресс-оценки, которые позволят без больших трудозатрат выявить большую часть ошибок в требованиях — мы рассмотрим их в порядке увеличения затрачиваемого времени.
Были или планируются у вас сокращения или увольнения в сфере ИТ?
Уже опубликованы предварительные результаты опроса. Чтобы выборка была больше, приглашаем всех присоедениться к опросу, чтобы через 10 дней посмотреть на общую картинку и сравнить свою ситуацию со средним по рынку.
Автор: Рикард Эдгрен (Rikard Edgren) Оригинал Перевод: Ольга Алифанова
Часть тест-дизайна лучше отложить на этап выполнения тестов. Имея под рукой продукт, вы можете лучше принимать решения о деталях, а также поймете, какие вариации и отклонения будут быстрыми и полезными. Вы найдете часть нужной вам информации, а также информацию, о необходимости которой вы и не подозревали. Вы узнаете, какие области подвержены ошибкам, что можно быстро протестировать, о чем стоит узнать больше, что на самом деле можно делать с ПО, как все взаимосвязано, и, возможно, самое важное: что можно улучшить.
Используйте эту информацию в тест-дизайне, пересоздайте и перегруппируйте ваши тесты, вернитесь к источникам информации, которые оказались более важными, чем вы думали изначально.
QA и QC — как камыш и рогоз. Конечно, есть ботаники, которые их различают, но большинство людей всё-таки путают. Иногда самим QA и QC легче согласиться с представлением обывателей, чем пускаться в долгие объяснения, в чём же всё-таки разница. Предлагаю сделать усилие над собой, разобраться с терминами и понятиями, увидеть отличия и больше никогда их не путать.
15-18 июня состоится онлайн-конференция по тестированию Heisenbug 2020 Piter.
Что будет: — Десятки докладов от экспертов со всего мира о практическом и хардкорном тестировании на реальных проектах; — Интервью, развлекательные подкасты, технические ток-шоу и дискуссии со спикерами; — Конференция будет идти 4 дня. Чтобы участники не устали, мы разбили программу на блоки по 4-5 часов; — Каждый день — несколько параллельных треков, между которыми можно переключаться, а доклады перематывать или ставить на паузу; — Розыгрыши с призами от партнеров конференции; — Обсуждение докладов с коллегами и единомышленниками.
Среди спикеров: — Андрей Лушников, разработчик Puppeteer и участник команды разработки Playwright в Microsoft. — Эллиот Расти Гарольд (Elliotte Rusty Harold) — мейнтейнер библиотеки Jaxen XPath, коммитер в проект Apache Maven, автор библиотеки XOM для обработки XML с помощью Java. — Андрей Акиньшин, автор книги «Pro .NET Benchmarking» разработчик проектов BenchmarkDotNet и Rider. — Артем Ерошенко, автор фреймворка для построения отчётов о процессе тестирования Allure. — Адам Торнхилл (Adam Tornhill), специалист по поиску проблем в коде и борьбе с техническим долгом, создатель сервиса для анализа качества кода CodeScene. — Анна Чернышева, Lead Software Test Automation Engineer в EPAM, эксперт в области BDD, одна из создателей Self-healing библиотеки Healenium и BDD-библиотеки Akita.
Автор: Саймон Найт (Simon Knight) Оригинал статьи Перевод: Ольга Алифанова
Если вы в тестировании не первый день, и особенно если вы долго тестируете один и тот же продукт, то вы наверняка заметили, что ваш мозг начинает мыслить о тестируемом продукте определенным устоявшимся образом.
Через какое-то время вы уже знаете, где находятся самые сложные области вашего продукта, и, начиная тестировать, вы сразу нацеливаетесь на эти области, потому что они уже показали себя плодотворной почвой для сочных багов.
Но как же вы попали в эту область системы? Каким маршрутом вы шли, что вы могли упустить по дороге?
Что, если вместо того, чтобы прямой наводкой идти к этой области, вы бы свернули в совершенно ином направлении?
Тестировщики часто сталкиваются с багами, которые зависят от окружения. Иногда приходится долго настраивать все необходимые программы, чтобы проверить какую-то функциональности или запустить автотесты. А уж переезд с одной машины на другую — вечная боль.
Благо, некоторое время назад появился Docker — среда для контейнеризации софта, позволяющая легко создавать и передавать отдельные контейнеры с софтом, которые работают везде одинаково. Долгое время Docker был популярен только среди DevOps, но в последнее время он все чаще используется в тестировании.
И действительно, ведь можно один раз настроить все нужные приложения, положить их в свои контейнеры — а потом запускать где угодно и сколько угодно раз. Это значительно сокращает время тестирования и повышает его удобство.
Про устройство Docker и его преимущества вы можете узнать из видео:
А если вы хотите узнать больше — подписывайтесь на наш youtube-канал и приходите на курс “Docker: инструменты тестировщика”, где вы всего за 2 недели сможете научиться работать с этим инструментом на достаточном для QA уровне.
