Перейти к содержимому

Аудит и оптимизация QA-процессов
онлайн, начало 4 декабря
Практикум по тест-дизайну 2.0
онлайн, начало 4 декабря
Школа Тест-Аналитика
онлайн, начало 9 декабря
Школа тест-менеджеров v. 2.0
онлайн, начало 9 декабря

Публикации tjupka

9 публикаций создано tjupka (учитываются публикации только с 04 декабря 2019)


#177534 Тестирование геймплея в RPG игре.

Отправлено автор: tjupka 17 сентября 2020 - 11:57 в Тест-дизайн и ручное тестирование

Морозов Артем Александрович и все будущие тестировщики любых компаний по производству ПО, обращаюсь к вам от имени составителей подобных тестовых заданий. Если потенциальный работодатель предлагает вам поработать, потестировать, дописать ПО, которое уже продаётся, а вы - лишь кандидат на вливание в команду разработки, то этим заданием рекрутёр желает выяснить весь спектр ваших возможностей, а не улучшить продукт за счёт бесплатников. Так что, выписывайте все типы, методы, принципы тестирования, которые вам известны (не важно в теории или на практике), и постарайтесь применить все из них к предложенному продукту. Если вы в тест-отчёте укажете, какой из пунктов вашего списка не подошёл и почему, то это лишь станет плюсиком вашего резюме.
А по конкретной практической части гейм-тестирования можно послушать пару-тройку докладов из архивов sqadays (например
https://sqadays.com/ru/talk/18529).




#177405 Как лучше всего организовать процесс отслеживания багов и мониторить к

Отправлено автор: tjupka 21 августа 2020 - 16:28 в Управление тестированием

Jira - шикарный инструмент для визуализации работы команды. Странно, что вы зациклились лишь на возвратах головной задачи - Story.

Можно же определить набор критериев для приёмочного тестирования и помечать их оговоренным образом: зелёная галка - сделано и работает после теста, красный минус - не сделано, знак вопроса - требуется доработка. При этом головную задачу держать в статусе ТЕСТИРОВАНИЕ до полной реализации, а все баги и доработки оформлять линкованными блокерами к этой головной Story. В этом случае у вас не то что месячный, а ежедневный отчёт по состоянию задачи получится с количеством открытых проблем.

Если мой вариант вам не подходит, то почитайте инструкции к Jira - там много хороших решений уже есть для мониторинга процесса разработки ПО.




#177348 тестировании во время простоя

Отправлено автор: tjupka 16 августа 2020 - 09:28 в Начинающему тестировщику

У истого тестировщика никогда нет времени на простои:
* Тесты нагрузки и производительности отнимают большую часть времени.
* Тесты безопасности приносят ощутимую прибыль бизнесу.
* Тесты по неявным требованиям расширяют ваши собственные знания о продукте и его области применения.




#177083 Помогите понять различие

Отправлено автор: tjupka 29 июня 2020 - 12:15 в Про тестирование обо всём подряд

Тестирование взаимодействия (сокращу - ВЗ) подразумевает входные данные в виде имён продуктов взаимодействия, их версий, объёмов передаваемых данных и тому подобного. Выходные данные такого функционального теста тоже разнообразны: наличие отклика, время отклика, точность совпадения ожидаемых данных фактическим и прочие подобные.
Тестирование совместимости (сокращу - СВ) не причисляют к функциональному, потому что результат теста можно получить без проведения действий над продуктом, а именно - прочитать технические характеристики в хелпе. Выходными данными у СВ являются лишь два значения - ДА и НЕТ, тогда как у ВЗ выходные данные (результат теста) обладают множеством критериев (есть/нет контакта, быстро/медленно, точность и корректность "2+2=4 или 2+2=5", и т.д.).

Основная разница между СВ и ВЗ в объёмах входных данных и результатах тестов. Например, СВ - запустится ли Windows-приложение на Linux-сервере (ответ один - ДА или НЕТ), ВЗ - как быстро запустится Windows-приложение на Linux-сервере (ответов много, потому что придётся учитывать параметры "железа" - количство ядер процессора, размер оперативной памяти, скорость маршрутизатора и иное)

Примером СВ может служить ограничение аудиоплеера на типы файлов, которые можно открыть в нём.

ВЗ-тест этого же плеера на видеофайлах даст либо сообщение об ошибочности входных данных, либо откроет только звуковую дорожку без видео-полосы, либо раскадрирует ролик и прочее. А выходными данными ВЗ-теста следует считать скорость открытия файлов разных аудио-расширений, высоту и громкость звука, перекодирование форматов аудио и тому подобное.  

По результатам СВ вы можете дать рекомендации тех.писателю расширить или ограничить пункты "Технические характеристики" или "Системные требования" в документации к продукту. А результатами ВЗ можно обогатить хелп продукта и инструкцию пользователя в главах "Примеры", "Ограничения", "Исключения" в работе приложения. 




#177082 Стоит ли начинать вход в профессию?

Отправлено автор: tjupka 29 июня 2020 - 11:40 в Начинающему тестировщику

Кроме переводчиков, в чём соглашусь с Gleb_Kazarkin, группам разработки ПО часто нужны тех.писатели. А вот специалист вашего уровня (английский + некоторые технические знания) весьма может быть востребован в компаниях с совместным (иностранным) производством. Не оглядывайтесь только на российские компании, поищите по всему миру сотрудничества.
Как факт - в компанию взяли девочку после лингвистического ВУЗа на роль переводчика документации и проверки переписки тех.поддержки, а уже через два года она стала главой над всеми тестировщиками.




#176208 Что делать с багами, которые пропадают после перезапуска системы?

Отправлено автор: tjupka 13 апреля 2020 - 15:50 в Начинающему тестировщику

В вашем конкретном примере явно сбивается сохранение и восстановление параметров пользователя. Пока идёт просмотр видео, параметры пользователя накапливаются в оперативной памяти. А при перезапуске окна, модуля или системы состояние параметров пользователя (позиция на кадр, разрешение видео-потока и прочее) происходит их сброс из оперативки в постоянку. Если эти "сбросы" производятся регулярно, например, до и после прокручивания рекламы или каждые N-минут/секунд, то пользователю нет необходимости восстанавливать свои параметры только перезапуском системы.
Как ещё тестировать опции? Читайте "Cheat sheet for options".
 




#175219 Баг или не баг

Отправлено автор: tjupka 19 января 2020 - 09:49 в Начинающему тестировщику

В качестве примера автор вопроса дал вариант заполнения поля значением, превышающим видимую область.
Если внутренние стандарты интерфейса у компании-производителя оговаривают полную видимость вводимых или отображаемых значений, то в данном случае в начале или конце строки (либо показать начало и конец, а середину заменить на троеточие), в зависимости от точки скрытия, должны появляться спец.символы, принятые во внутренних стандартах интерфейса. А полный текст в рамках подобного стандарта выводится в хинте к этому интерфейсному элементу.
Да, пользователь может не заметить, что набрал все символы, но они не все видны. И может набирать текст сверх положенного и видимого, тем самым ведя себя же к ошибке при передаче данных (переполнение, обрезание). Поэтому в описанных случаях некоторые показывают троеточие, кто-то сигнализирует звуком.
Рекомендация автору вопроса: исследуйте ту часть программы, где введённые значения обрабатываются, и если невидимые при вводе значения приводят к проблемам, то оформляйте свой скриншот как причину бага с предложениями по предотвращению пользовательских неудобств. 




#174591 ИЗ разработчика В тестировщики

Отправлено автор: tjupka 25 ноября 2019 - 13:51 в Личный рост, карьера, развитие

По-моему, забыта одна разница между программистом и тестировщиком: кто-то создаёт, а кто-то разрушает продукт.
Если вы по-жизни терминатор и критик, то не менжуйтесь и прыгайте в наш водоворот бурной и разноплановой деятельности! Как только перейдёте психологический барьер о своём месте "чистильщика" в команде разработки (тестировщик ежедневно и ежечасно сталкивается с недоделками и прочей грязью кода), у вас проявится второе дыхание и станете замечать, что именно из-за вас продукт заблестел лоском!  




#174590 проверки, которые надо проводить,если сайт будет установлен на сервер

Отправлено автор: tjupka 25 ноября 2019 - 13:30 в Начинающему тестировщику

При смене версии БД открываете пресс-релиз вендора, например, у Oracle в документации всегда есть статья "New features". Выписываете себе в первый список те фичи, которые претерпели изменение в базе и используются в вашем приложении. В другой список выпишите те, которые по вашему мнению могли бы быть внедрены или использованы вашим приложением. Возьмите карту (или список) модулей вашего приложения и наложите на неё первый список. Получится чек-лист обязательных проверок. Наложив на карту модулей второй список, получите чек-лист дополнительных проверок.
Если база меняется с одной на другую, например Oracle на Postgress, то в документации "новой" базы, если она более крутая, обязательно найдёте сравнительную таблицу (например, https://info.enterpr...prise-ebook.pdf ). Такую таблицу уже надо накладывать не только на список модулей приложения, но и на связи межмодульные и интеграционные.
Также поступайте и с операционными системами. Первый шаг - поиск сравнительной таблицы на сайте вендора или просторах интернета. Второй шаг - с помощью разработчиков отсеиваете "свои" фичи. Третий - сами определяете объём тестов, после изучения "букварей".





Яндекс.Метрика
Реклама на портале