Всем привет, меня зовут Александр, и я занимаюсь QA (обеспечением контроля качества) разрабатываемой нами продукции. Наши контрагенты-фабы в юго-восточной Азии, особенно китайцы — ребята резкие, шустрые, и готовы сделать много, быстро, но вот с качеством выходит не всегда. Как мы с этим боремся, попутно экономя деньги компании — написано под катом.
Читать полностью »
Рубрика «Тестирование IT-систем» - 53
Тестирование на фабрике: «Чёрный ящик» и короткий цикл тестирования
2017-08-31 в 4:53, admin, рубрики: qa, QC, Блог компании YADRO, тестирование, Тестирование IT-системКак подготовиться к экзамену ISTQB? Тестировщики краснодарской студии Plarium делятся опытом
2017-08-29 в 11:01, admin, рубрики: ICTQB, qa, Блог компании Plarium, обучение, подготовка, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, Тестирование игр, Тестирование мобильных приложений, экзамен
С середины прошлого века и до наших дней тестирование программного обеспечения проделало немалый путь и стало отдельным направлением IT-индустрии, наравне с программированием и геймдизайном. От десятилетия к десятилетию менялись концепции, методология и инструментарий. Сейчас, будучи частью структуры QA (обеспечение качества), тестирование охватывает все стадии процесса разработки: от проверки документации до анализа готового продукта.
Столь стремительному развитию отрасли неизбежно сопутствует увеличение объема информации, в результате чего возникает потребность в унификации имеющихся знаний и приведении терминологии к единому виду. Благодаря существующим системам сертификации специалисты по всему миру могут не только определять свой профессиональный уровень, но и восполнять пробелы в образовании и получать общее представление о теориях, принципах и технологиях тестирования.
В этой статье сотрудники отдела Quality Assurance краснодарской студии Plarium поделятся опытом подготовки к экзамену ISTQB Foundation Level. Для них он стал еще одной возможностью бросить вызов самим себе и испытать свои силы.
Читать полностью »
Десктопные GUI-тесты на Python. Лекция в Яндексе
2017-08-27 в 11:58, admin, рубрики: accessibility, autohotkey, autoit, GUI, python, pywinauto, ui automation, UI Automation Testing, win32 api, Блог компании Яндекс, десктопное, Тестирование IT-систем, тестирование интерфейсов, тестирование поВасилий Рябов из компании Aquantia объясняет, как с помощью Python можно наладить тестирование десктопных интерфейсов. Из лекции вы узнаете об инструментах open source и поддержке accessibility-технологий в библиотеке pywinauto. Видео и расшифровка в основном предназначены для тех, кто занимается тестированием софта для Windows, но про Linux и macOS автор тоже немного рассказывает.
Юнит тесты. Первый шаг к качеству
2017-08-21 в 7:39, admin, рубрики: automated testing, bdd, software testing, tdd, testing, Тестирование IT-системОднажды меня попросили рассказать о юнит тестировании в javascript, но прежде чем рассказывать о тестировании в мире front-end, надо было сделать небольшой обзор юнит тестирования как такового. В результате чего на свет и появилась эта статья, в которой я попытался рассказать о самых важных моментах в юнит тестировании.
О качестве требований в ИТ проектах, начистоту (с позиции команды разработки). Часть 3
2017-08-21 в 7:13, admin, рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, проектирование по, Промышленное программирование, разработка по, Тестирование IT-систем, тестирование по, управление проектами, формирование требований, функциональное программированиеС частью 1 можно ознакомиться, перейдя по ссылке
С частью 2 можно ознакомиться, перейдя по ссылке
Использование спецификаций требований в управлении проектом
Во вступительной части была упомянута группа участников проекта, для которой мы так же обещали облегчить жизнь и обеспечить условия для эффективного использования требований – это менеджеры проекта. Что получают эти глубокоуважаемые люди при выборе предлагаемого в статье подхода?
Планируя работы по таким детальным спецификациям, еще на ранних стадиях, можно с высокой точностью определить ресурсы и сроки, необходимые для их реализации. Время, которое необходимо затратить на создание Таблицы, Формы, Функции, Отчета и т.д. можно просчитать на примере одного проекта и в дальнейшем использовать эти данные как эталонные. А в наших спецификациях, как раз и перечислены все таблицы, формы, процедуры и т.д. и сосчитать их количество не составляет труда.
Но, естественно есть погрешности и процедура – процедуре рознь, поэтому, для более точного расчета можно использовать коэффициенты сложности для реализуемых объектов. Например, «сложная форма» — 1,5; «обычная форма» — 1; «простая форма» — 0,5. Для каждого типа элемента подбираем свою линейку значений коэффициентов. Полученные таким образом данные можно занести в электронную таблицу и сбить итоговые затраты в человекоднях или человекочасах (как Вам удобнее) по подсистемам и проекту в целом.
Читать полностью »
Мутационное тестирование
2017-08-20 в 20:40, admin, рубрики: AST, coverage, infection, mutant, mutation, mutation-analysis, php, test-framework, testing, Программирование, Тестирование IT-систем
Юнит тесты помогают нам удостовериться, что код работает так, как мы этого хотим. Одной из метрик тестов является процент покрытия строк кода (Line Code Coverage).
Но насколько корректен данный показатель? Имеет ли он практический смысл и можем ли мы ему доверять? Ведь если мы удалим все assert строки из тестов, или просто заменим их на assertSame(1, 1), то по-прежнему будем иметь 100% Code Coverage, при этом тесты ровным счетом не будут тестировать ничего.
Насколько вы уверены в своих тестах? Покрывают ли они все ветки выполнения ваших функций? Тестируют ли они вообще хоть что-нибудь?
Ответ на этот вопрос даёт мутационное тестирование.
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 2
2017-08-19 в 10:50, admin, рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программированиеС частью 1 можно ознакомиться, перейдя по ссылке
Рекомендации по проектированию спецификаций требований с примерами
То, о чем не говорят, каждый понимает по-своему
Как и было анонсировано в предыдущих разделах, мы постараемся преобразовать требования на разработку ПО в такой формат, чтобы они максимально упростили и ускорили работу команды превращающую их в конечный продукт.
Готовим читателей к знакомству со спецификациями
Итак, с чего может начинаться знакомство команды разработки, с представленными требованиями? Непременно с презентации аналитиком своего творения, будущим исполнителям. Для обоих сторон очень важно, насколько успешно будет установлен первый контакт и преодолен барьер вхождения в новый процесс. Но часто, по ряду причин очно это сделать невозможно или проблематично. Поэтому хорошим тоном будет включение в начало документа раздела, с кратким обзором его структуры и представления информации, а также разъяснением, как правильно и эффективно ее использовать.
Пример обзора документа:
Для лучшего восприятия контекста разрабатываемой системы, помимо разделов, отобранных нами в структуру документа — как обязательные, я стараюсь включить в текст информацию о целях, которые должны быть достигнуты в результате разработки целевого продукта или его составного модуля. Разработчики все-таки должны осознавать, чего же желает заказчик получить на выходе проекта. Для описания этого раздела подойдут формализованные Потребности заказчика. Похожий раздел есть в большинстве стандартов, например в ГОСТ-34.602-89 [4] он называется «назначение и цели создания (развития) системы».
Читать полностью »
Mountebank: гибкое мокирование web API
2017-08-18 в 11:04, admin, рубрики: mountebank, pytest, python, qa, qa automation, Разработка веб-сайтов, разработка мобильных приложений, тестирование, Тестирование IT-систем, Тестирование веб-сервисов, Тестирование мобильных приложений
Когда речь заходит о разработке современных IT-систем, вопрос мокирования внешних зависимостей всегда идет где-то рядом. Внешний сервис может быть недоступен на этапе разработки, либо его функционал разрабатывается параллельно и на него нельзя полагаться. Особенно остро этот вопрос встает на этапе написания автотестов, ведь проверять нужно не только штатное поведение вашей системы, но и исключительные случаи: недоступность внешнего сервиса, случаи когда внешний сервис отвечает ошибкой и так далее.
Почему нельзя полагаться на пользовательские отчёты об ошибках
2017-08-17 в 15:14, admin, рубрики: Parallels, баги, Блог компании Parallels, Клиентская оптимизация, отладка, отчетность, Программирование, Тестирование IT-систем
Мы в Parallels достаточно внимательно анализируем пользовательские отчёты об ошибках. У нас на этот счет внедрена автоматизированная система учета и обработки данных. Специально обученные люди работают с информацией и лечат болячки у пользователей. Однако, не все разделяют нашу философию. Под катом интересное мнение Ника Харли на портале Medium. В комментариях можно отлично подискутировать на заданную тему.Читать полностью »
О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 1
2017-08-17 в 13:37, admin, рубрики: Анализ и проектирование систем, оптимизация, Проектирование и рефакторинг, Промышленное программирование, разработка программного обеспечения, Тестирование IT-систем, требования, управление проектами, формирование требований, функциональное программированиеПо мотивам моей статьи, изданной ранее…
Вступление
Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)
В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.
А посему давайте взглянем на качество требований глазами команды исполнителей: разработчиков, специалистов управления качеством, менеджеров проекта. Ведь именно эти люди и являются основными потребителями работы аналитика. И от того насколько точно созданные спецификации подходят конкретной команде для переработки их в готовый программный продукт, зависит качество и конечная себестоимость этого продукта.
Читать полностью »