Техника тест-дизайна «Таблица решений» - одна из самых сложных для применения, но одна из самых удобных для тестирования сложных бизнес-фич, когда есть более одного условия и одно/несколько действий системы как результат выполнения или не выполнения этих условий.
В этой статье речь пойдет о составлении таблицы решений для тестирования фильтрации с зависимыми фильтрами.
Изучая европейский рынок IT-вакансий, я заметила, что частым пунктом в списке пожеланий работодателей является наличие у кандидата сертификата ISTQB Tester Foundation Level. В некоторых крупных компаниях в области здравоохранения или финансов это было даже обязательным пунктом. Так что при всей моей нелюбви ко всякого рода экзаменам, я решила смахнуть пыль со своего старого намерения сертифицироваться и прикрепить заветную электронную бумажку к своему LinkedIn аккаунту. Действительно ли сертификат дает какое-то преимущество на рынке труда, это конечно отдельный вопрос, и его я затрагивать в этой статье не буду.
Как человек обстоятельный и весьма осторожный я готовилась довольно тщательно, и теперь могу сказать, что во многом излишне тщательно. Так что я поделюсь своей системой подготовки и если вы более рисковый человек, еще и одаренный прекрасной памятью, можете смело делить мой план на два.
Итак, из каких этапов состояла моя подготовка и сколько занял каждый этап?
Всем привет! Команда тестирования производительности Тинькофф продолжает цикл статей о нагрузочном тестировании различных протоколов с помощью Gatling.
В прошлой статье мы показали, как протестировать JDBC-протокол с помощью Gatling. В этой — разберем протокол gRPC.
Здравствуйте, меня зовут Екатерина, уже 11 лет я работаю учителем в школе. Почти год назад я решила сменить профессию и пошла на курсы тестировщиков в одну разрекламированную онлайн школу, разочаровалась в ней, а теперь учусь в другой. Мне стало интересно сравнить методики преподавания, чтобы понять, что-то не так со мной или с курсом? Предыдущую часть можно посмотреть здесь.
Привет! Меня зовут Наталья, в QA я с 2010 года. За это время была тестировщиком, QA, QA Lead, спикером на курсах по тестированию, ментором. С 2018 года возглавляю группу менторов в направлении QA компании SimbirSoft. Мы с командой развиваем внутреннюю программу обучения для новых сотрудников (Примечание. Ниже по тексту мы их иногда будем называть менти). В статье расскажем, какие подходы оказались эффективными у нас – возможно, они будут полезны и вам.
Наш опыт учитывает особенности заказной разработки: нужны специалисты, готовые влиться в самые разные проекты – от банков до промышленного ПО, с командами от 3 до 100+ человек. В статье рассмотрим, что нужно знать менторам в QA, как составить программу обучения, выстроить непрерывный процесс передачи знаний и погружения в проект. Также наши коллеги поделятся своими лайфхаками.
Как быть, когда вокруг вроде бы девопсы, аджайлы и скрамы, но разработка и тестирование по-прежнему не живут в одном пайплайне душа в душу?
Из-за того, что необходимо преодолевать эту стену и находить общий язык, мы даже создали конференцию Heisenbug, предназначенную одновременно для тестировщиков и разработчиков. А ещё мы проводим Java-конференции, и осенью Артём Ерошенко выступил там с докладом «Как правильно (не) использовать тестировщиков». На примере Java-проекта он поделился своей болью и рассказал, что считает нужным делать.
И теперь, в преддверии нового Heisenbug и нового JPoint (обе конференции пройдут в формате «офлайн + онлайн»), мы решили сделать хабрапост на основе его доклада. Дальше повествование от имени Артёма.
Стажёр-тестировщик — это новичок, у которого нет реальной практики в тестировании. Потому что одно дело решать учебные проекты, пусть даже и приближённые к боевым задачам, а другое дело — работать в большом реальном проекте, в котором много сложных бизнес-процессов.
Расскажу, с какими сложностями сталкиваются стажёры, и как мы помогаем эти сложности преодолеть и погрузиться в сложный проект.
Меня зовут Марина, я наставник и тимлид в команде тестировщиков. Когда ко мне в проект приходят стажёры-тестировщики, я их обучаю и помогаю им адаптироваться.
Уверена, что мой опыт пригодится наставникам и тимлидам, которые также вводят новых QA. Делитесь в комментариях и своим опытом.
Я бы хотел поделиться с тобой личной историей.
Всего пять лет назад, я находился в состоянии глубокого внутреннего кризиса.
Я не знал, что мне делать.
2017 год, мне 27, я принял решение что-то в жизни поменять, но не знал, как.
Мне нужен был план. Пути назад не было, да и вперед тоже.
Прошлая жизнь, работы, дела, люди — всё осталось позади.
Мне нужны были перемены.
Мне нужна была цель.
Я смотрел в окно съемной квартиры в чужом городе и пытался понять,
зачем я здесь.
Окей, мне хочется пожить в другой стране — это раз. Меня всегда привлекали странствия.
Хочу иметь интересную профессию, мне нравятся технологии — это два.
Хочу приносить пользу, делать что-то особенное, быть ключевым человеком
в своем деле.
Это три.
И жить в кайф.
Получить какую-то рабочую или учебную визу сходу не получилось,
гринку в очередной раз не выиграл, даже туристическую визу не дали.
Чего-то не хватало, было ощущение, что я упускаю какой-то важный этап — мне нужен был фундамент здесь и сейчас, перепрыгнуть не удавалось, стартовать необходимо было из текущей позиции.
Про QA я знал только, что вновь приехавшие в штаты жить, люди, осваивали эту специальность, успешно адаптировались в новой стране и были безумно довольны своей работой.
Что же, почему я не могу сделать тоже самое, только сначала здесь?
А потом, когда мне откроется новый мир технологий, полезности
и востребованности, все пути будут открыты.
Я открыл сайт с вакансиями — весной 2017 года в Казани, где я находился,
было около 20 вакансий на позицию QA Engineer, опыт требовался от трех лет.
Привет! Меня зовут Александра, я работаю в отделе тестирования производительности Тинькофф. Этот текст — часть цикла статей, посвященных тестированию производительности с помощью инструмента Gatling. В предыдущей статье мы с командой рассказали о работе Gatling с HTTP. Еще мы написали вводную статью, из которой можно узнать, что такое Gatling и как мы его используем. В этой статье мы поговорим о работе Gatling с протоколом JDBC.
Или нюансы тестирования и разработки голосового помощника в банковском приложении.
А нюансов достаточно. Например, однажды мы тестировали модуль Яндекса, который закрывает звёздочками нецензурные слова в диалоге с голосовым помощником. Он работает в нашем приложении Альфа-Мобайл с октября 2021 и его зовут Альф (Alf). Он умеет оплачивать счета, переводить на телефон и озвучивает курс доллара голосом Геральта — Всеволода Кузнецова.
В статье мы расскажем как устроен голосовой помощник, как мы тестируем его навыки (даже после лечения зубов), зачем нужны автотесты для проверки работоспособности голосового помощника и где они находятся в пирамиде тестирования, что такое сенситивы и для чего используем нейросеть CAILA (спойлер: от неудобных вопросов).
Грандиозная кибербитва The Standoff пройдет уже 18 и 19 мая на PHDays.
160 исследователей безопасности соберутся, чтобы найти слабые места в защищенности виртуальных компаний из разных отраслей экономики, и попытаются парализовать жизнь виртуального Государства F. А пять команд защитников в режиме реального времени выяснят, как недопустимое стало возможным.
Ситуации, как и раньше, взяты из жизни, но масштаб возможных катастроф растет: вирус-шифровальщик останавливает нефтепровод и создает тотальный дефицит топлива в стране, атаки на систему управления электроподстанциями приводят к перебоям в подаче водопроводной воды в жилые дома и в поставках лекарств.
Последствия атак зрители и участники смогут наблюдать на макете Государства F офлайн или онлайн на сайте события.
В конце прошлого года я выпустила свою первую книгу по тестированию — «Курс молодого бойца». Хочу поделиться опытом — как это было.
Рассказ свой я разбила на цикл статей. В этой статье я расскажу вам о том, как искала себе фриланс-художников. Какое тестовое давала, как его выполняли, и чего мы только не навидались за тот год :-)
С нарастающими скоростями и распределёнными системами всё сложнее бывает создать приложение удобным для конечного пользователя. Программы обладают кучей фич. Но выполняют ли они то, что нужно юзерам? А скорость их выполнения достаточная? А производительность при выполнении не хромает? На эти вопросы помогает ответить нагрузочное тестирование (НТ).
Меня зовут Саша, я работаю в команде тестирования Ozon Fintech и расскажу про разнообразный спектр вариантов НТ: как именно мы его применяем и какие инструменты используем. Статья будет полезна тем, кто уже что-то слышал про НТ и хочет добавить его в свой проект, но пока страшновато. Давайте разбираться!
Здравствуйте, меня зовут Екатерина, уже 11 лет я работаю учителем в школе. Почти год назад я решила сменить профессию и пошла на курсы тестировщиков в одну разрекламированную онлайн школу, разочаровалась в ней, а теперь учусь в другой. Мне стало интересно сравнить методики преподавания, чтобы понять, что-то не так со мной или с курсом? Предыдущую часть можно посмотреть здесь.
Программа получается отличной: Андрей Цветцких (Тинькофф), Дмитрий Цепелев (Злые Марсиане), Серёжа Попов (HTML Academy), Андрей Смирнов (X5), Алексей Бородкин (Ozon), Елена Насыбуллина (Selectel), Дмитрий Калаев (ФРИИ), Максим Рогожников (Тинькофф), Антон Назаров (Autodesk), Александр Кириллов (Evrone), Филипп Терехов (Уфимский городской планетарий) — и это не всё. Под катом — подробности программы.
Автоматизация тестирования абсолютно неотъемлема и необходима в современной разработке программного обеспечивания. Ее преимущества известны всем, что делает автоматизацию тестирования желанным для применения. Факт, отказ от ручного тестирования, сокращение затрат и автоматизация в спринте (in-sprint automation) подталкивают компании внедрять автоматизацию как можно скорее в собственные проекты. У каждой компании свой подход к достижению цели. Однако, они все совершают одинаковые ошибки в процессе внедрения автоматизированного тестирования.
Новые времена создают новые вызовы. Но то, что для одних является препятствием, неудобством и потерями, для других - дополнительные возможности и открытие новых горизонтов. Система образования для начинающих тестировщиков в ближайшие год-два претерпит определенные изменения - возможно, значительные. Но этому IT-сегменту не привыкать, ведь по сути, изменения здесь происходят с конца 90-х годов.
Последние два десятилетия для многих русскоязычных тестировщиков движение в профессии выглядело как “обучение → получение первого опыта на русскоязычном проекте → получение опыта на англоязычном проекте”.
В марте 2022 года число вакансий в российской ИТ-отрасли сократилось на 25%, а число резюме выросло на 15%. Можно предположить, что число вакансий и резюме в следующие полгода сбалансируется, но более интересные с точки зрения развития и зарплаты проекты будут доступны в основном для неплохо говорящих по-английски QA-трейни и QA-джунов. Таким образом, для чуть более амбициозных вышеуказанная последовательность сократится до более короткой “обучение → получение опыта на англоязычном проекте”. Но она и более сложная.
Давайте посмотрим на то, какие есть варианты обучения у IT-новичков и какие варианты может им предложить рынок в очередной “новой нормальности.”
Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.
Это та причина, по которой многие подрядчики стараются избегать таких требований, как огня, что перекладывает риски во времени на более поздние этапы и на заказчика.
Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.
Стандарты по программной и системной инженерии предлагают десятки видов атрибутов качества системы, а заказчики требуют, чтобы система была удобной, быстрой, надёжной и безопасной.
При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?
С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».
Пока что умение специалистов и команд выявлять и формулировать такие ограничения представляет собой скорее искусство, а не ремесло, и не инженерию.
Давайте попробуем сделать это хотя бы ремеслом.
Привет, Хабр!
Вам наверняка знакома ситуация, когда обновления, которые необходимо выкатить, — это россыпь отдельных файлов, которую надо соединить, протестировать на всех видах продуктов и поддерживаемых ОС, а потом загрузить на серверы, чтобы апдейты получили конечные пользователи.
Но что, если обновлений насчитывается 250+ типов? А если поддерживаемых ОС — порядка 250? И для тестирования требуется 7500+ тестовых машин? Такой вот типичный хайлоад. Который должен постоянно масштабироваться…
Я — Иван Лауре, менеджер по тестированию в «Лаборатории Касперского». Именно так, как я описал выше, выстроено «выкатывание» у нас. В этой статье я расскажу о центральной части всего процесса — как мы тестируем обновления для более чем 500 уникальных версий ПО, да и саму распределенную систему тестирования. Не сомневаюсь, что наш опыт будет вам полезен.
Привет, Хабр!
На связи Руслан Остропольский, Директор по производству ИТ в СберЗдоровье. Он расскажет, как команда сэкономила кучу времени и денег и добилась колоссального роста производительности благодаря грамотному подходу к автоматизации UI-тестов.
