Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Я работаю в IT более 25 лет, и большая часть моего опыта получена в тестировании. Поэтому я редко удивляюсь даже самым идиотским вещам, попадающим на мой виртуальный стол. Зачастую кажется, что что это старые ошибки и ловушки, в которые попадается новое поколение тестировщиков, или что-то старое, прошедшее ребрендинг и ставшее вдруг новеньким и блестящим.
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Команды разработки сталкиваются с самыми разнообразными проблемами. Им нужно изучать новые технологии, одновременно поддерживая работоспособность пожилых проектов. Им нужно балансировать работу над техническим долгом с быстрым добавлением новых фич. Учитывая все эти трудности, почему нас должны волновать названия групп, команд, продуктов или тестов? Вот пять причин, почему.
Автор: Саймон Томс (Simon Tomes) Оригинал статьи Перевод: Ольга Алифанова
Безусловно, для тестировщика-исследователя очень важно находить проблемы. Однако исследовательское тестирование – это куда больше, чем поиск проблем. Мы знаем об этом, но иногда стоит посмотреть в зеркало, чтобы об этом не забывать. Сделайте шаг назад и вспомните о том, что вы не просто магнит для багов!
Автор: Artsiom Rusau @artsiom-rusau
QA Engineer | Автор блога Artsiom Rusau QA Life
Возвращаемся к нашему любимому вопросу — много теории, мало практики. Где тренироваться тестированию самоучке или человеку, которому не хватает практических заданий на курсах?
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Нам, тестировщикам, приходится думать о куче различных вещей. Нам нужно тестировать новые и существующие фичи. Нам нужно убедиться, что разные фичи верно работают сообща. Нам нужно проводить ручные тесты и не забыть проверить, правильно ли работает наша автоматизация. И нам нужно тестировать на разных браузерах и платформах.
Автор: Деннис Мартинез (Dennis Martinez) Оригинал статьи Перевод: Ольга Алифанова
Пересматривали ли вы когда-нибудь повторно тот код, который вы или команда написали для автотестов? Речь не о ревью этих тестов день или даже неделю спустя после их создания – я имею в виду "зарыться в архивы и проверить то, что сделано месяцы или даже годы назад". Если вы похожи на большинство разработчиков и тестировщиков, то ваша реакция будет чем-то средним между "О чем я только думал, когда писал этот код?" и "Я даже не знаю, работает ли это и используется ли вообще сейчас".
Автор: Кристин Джеквони (Kristin Jackvony) Оригинал статьи Перевод: Ольга Алифанова
Пока я не сделала свое собственное веб-приложение, то совсем не понимала важность продакт-оунеров. Это было совсем простенькое приложение (его можно увидеть на https://thinking-tester-contact-list.herokuapp.com), однако мне пришлось разбираться, как переходить со страницы на страницу, и как убедиться, что пользователь никогда не окажется в тупике. Это оказалось сложнее, чем я думала. Тогда я поняла, что работа продакт-оунера – это больше, чем просто дизайн страниц! Это необходимость убедиться, что пользователь получит отличный опыт, решая свои задачи в вашем приложении.
Тестировщики разделяют стремление сделать пользователей счастливыми, поэтому отличной идеей для них будет поработать с продакт-оунером для достижения этой цели! Ниже – четыре шага для такой работы.
Анализ тестов — это выкидывание лишнего из вашего чек-листа. Работа из серии «сесть и подумать»:
какие проверки можно объединить?
какие и вовсе выкинуть?
Было бы здорово дать некий алгоритм, который поможет всегда и везде, но нет, увы. Универсальная фраза здесь только «сесть и ПОДУМАТЬ». А самое главное: «вместе с водой не выплеснуть ребенка». Убирайте тесты аккуратно, особенно в первые годы работы. Возможно, выкинутое было отнюдь не лишним...
Автор: Максим Буранбаев,
Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript
Инфраструктура тестирования обсуждается реже чем проблемы программирования или шестизначные зарплаты. Дьявол кроется в деталях, а если точнее, то дьявол сидит в процессах внутри команды. В небольших командах процессы устраиваются сами собой без обсуждения. Продуктивность команды снижается по мере роста команды и в условиях игнорирования процессов. Статью будет полезно прочитать, если команда испытывает следующие трудности:
тестирование становится бутылочным горлышком и замедляет работу;