Написано
19 января 2016 - 17:24
Здравствуйте!Подскажите пожалуйста, как в тестировании можно применять Firebug в Firefox?Спасибо!
Звучит как: Здравствуйте! Подскажите пожалуйста, как в тестировании можно применять голову? Спасибо!
PS: Можно применять его с пользой, без пользы, с нанесением вреда или вообще не применять. Перед освоением firebug, я бы освоил поиск в гугле.
PS2: Поэтому давайте погуглим: Firebug для тестирования
Написано
24 декабря 2015 - 04:29
Спасибо. Начал уже делать. Задам только один вопрос. Возьмем самый распространенный пример - Калькулятор. Скажем я делаю тест кейсы. Я должен проверить абсолютно все возможно варианты? Ну например деление на минус, сложить 2 отрицательных числа и тд? То есть смысл тест кейса это найти все возможные варианты, которые может сделать юзер, верно?
Неверно. Ты полную хрень написал. Ошибившись даже в количестве вопросов.
Тебе к Гудвину обратиться надо за смесью отрубей, булавок и иголок.
И погуглить, найдя ответы на свой вопросы.
Написано
15 декабря 2015 - 21:12
2. Возможно разработчик ошибся в ссылке - поэтому перешел по ссылке devlab.ru/servise
Результат: браузер открывает страницу
Ожидаемый результат: открытие страницы devlab.ru/servise
Написано
12 декабря 2015 - 19:17
Написано
10 ноября 2015 - 16:28
Какой женщине, например, будет легче родить ребенка 50 летней или 20 летней? Какого возраста сотрудник будет более обучаем: 20 летний или 50 летний? У кого больше риска, что он уйдет в декрет или в армию? Это же все риски и при найме это все учитывается. Так почему бы не начать учитывать тогда такое физиологическое качество как усидчивость, стабильность и прочее более присуще (как показывает даже текущий опрос) представителям нашего прекрасного женского пола?
Люди разные - от них и надо исходить, а не от пола. Исключение Статья 253 ТК РФ. Работы, на которых ограничивается применение труда женщин. 
Написано
05 ноября 2015 - 22:24
Следующие темы от Dananas:
1. На какой планете живут самые позитивные тестировщики
2. На какой планете живут самые оптимистичные тестировщицы
3. Чем отличается тестирование по вторникам от тестирования по четвергам
Написано
21 сентября 2015 - 17:07
В голове тестировщика крутится огромное количество информации. И если начинающий тестировщик допускает ошибки из-за незнания, то опытный тестировщик обладает глубинной знаний допускает часть ошибок из-за того, что некоторые моменты остаются за границами его внимания. Случаются ситуации, когда пропускается базовое тривиальное, но важное действие. Мощная практика составление контрольных вопросов для процесса позволит снизить фатальные ошибки от досадных пропусков.
Про практику контрольных вопросов прочтите главу 9 книги “Системноинженерное мышление в управлении жизненным циклом” (Анатолий Левенчук).
Про успешные примеры внедрения чеклистов узнаете из книги “Чек-лист: Как избежать глупых ошибок, ведущих к фатальным последствиям” (Атул Гаванде).
Чеклисты для тестирования найдете в книге “Ключевые процессы тестирования” (Рекс Блэк).
Заключение: Для важных процессов, в которых банальная ошибка приводит к плачевному результату контрольные вопросы ваш хранитель.
Дополнительная информация:
1. Чек лист процесса: Initiation - Planning - Execution - Finalization - Closure (Александр Селяев)
2. Как с помощью простого чек-листа можно повысить эффективность простого процесса (Валерий Казарин)
3. Все лето в один день (Рэй Брэдбери)
PS: Благодарю Алексея Фёдорова за рецензирование.
Написано
15 сентября 2015 - 15:52
lurk, вы книгу пишите?
Нет. Я просто делюсь полезной (надеюсь =)), упорядоченной информацией из своей копилки.
Вношу свой небольшой вклад в сообщество тестировщиков. =)
Правда, я решил не выкладывать отсылки на книги и англоязычные статьи, выкладывая свои подборки по нюансам тестирования.
Написано
13 сентября 2015 - 21:09
Бонус:
Вы правильно понимаете общий смысл. Модель, стратегия, бла-бла-бла, птичьи слова, я бы лучше сказал просто план - хорошее, годное, понятное слово.
Что бы сделал я? Взял бы пару листов А3 и написал:
- Что вообще можно тестировать - вообще все знакомые слова - юзабилити, орфографию, логику, регрессию, безопасность, нагрузочное тестирование, боевой сервер, тестовый стенд. Слов 20.
- Как я могу тестировать: пецкать руками, найтирабовбета тестеров, написать автотесты, записать сценарии, столкнуть работу на коллегу,
- Когда я буду это делать? Ночами, по утрам, 4 часа в день, срок - ближайший месяц, день, год. Исходя из сроков вычеркнуть нереальное из первых двух пунктов.
- Узнать, на кой это все надо. Чего от меня ждут. Может ждут сто багов. Может ждут качество. Может ждут отчет. С учетом этой строки - пересортировать все, что выше.
- Представить себе конечный результат. Список багов? Где этот список? На листочке? В трекере? Налаженный процесс разработки и тестирования? Как выглядит налаженность? Отчет? В экселе, в ворде? Как выдадут бабло? На карту, налом, вебманями?
Написано
13 сентября 2015 - 19:36
Прочтите это для начала.
Написано
31 августа 2015 - 15:54
Предупреждение: Сложная тема.
Тестирование на основе модели (model-based testing): Тестирование, основанное на модели исследуемого компонента или системы. Например: модели роста надежности, моделей использования (таких как функциональный разрез) или поведенческих моделей (таких как таблицы альтернатив или таблиц переходов состояний). [ISTQB Стандартный глоссарий терминов, используемых в тестировании программного обеспечения Версия 2.2]
Видео:
1. Тестирование на основе моделей: "ужас-ужас" или всё не так страшно? (Алексей Баранцев SQA Days 15)
3. Micro Model Based Testing (Роман Иовлев SQA Days 17)
4. Тестирование на основе моделей (3 лекции Виктор Кулямин)
6. Вы можете купить видео "Функциональное тестирование на основе моделей" (Алексей Баранцев).
Статьи:
3. Тестирование на основе моделей (к.ф.-м.н. В. В. Кулямин) - можно скачать лекции по данному курсу
Цитаты:
Ага, я понял. Сергей, Вы смешиваете два понятия -- анализ моделей (model checking) и тестирование на основе моделей (model-based testing).
Анализ моделей -- это техника, цель которой состоит в моделировании какого-либо явления и изучения этой модели на полноту, непротиворечивость и т.д. Здесь действительно довольно хорошо работают методы логического программирования.
Тестирование на основе моделей -- это несколько другая техника, которая не занимается изучением того, хороша модель или плоха. Модель принимается за эталон, и задача ставится иначе -- проверить, что данная реализация соответствует модели (в более общем случае -- проверить соответствие двух моделей разного уровня абстракции, ибо реализацию тоже можно трактовать как модель). Для этого, конечно, тоже можно применять методы формального анализа (то есть формально выводить, что если некоторое свойство выполняется в одной модели, то оно выполняется и в другой), но, к сожалению, если на относительно простых моделях эти методы работают, применять их к реальным программам не удается из-за очень высокой сложности. Поэтому применяются другие методы и термин "тестирование на основе моделей" обычно относится именно к этим другим.
Чтобы понять разницу более фактурно, представьте, что Вы разработали замечательную модель, включающую всё, что Вам хочется (в том числе стихийные бедствия, пожары и т.д. :)), потом проверили, что эта модель действительно удовлетворяет всем требованиям, короче -- конфетка. А потом Ваши программисты разработали реальную программную систему, которая ЯКОБЫ реализует эти требования и ЯКОБЫ должна соответствовать модели. А как проверить, соответствует ли на самом деле? Вот этим и занимается model-based testing.
Здравствуйте!
Давно интересует вопрос, использует ли кто-то на практике тестирование на основе моделей (Model-Based Testing). Я имею в виду, для действительно сложных случаев, когда автоматически сформированные тестовые последовательности было бы сложно реализовать вручную.
Фактически, MBT соответствует технике тест-дизайна с применением диаграммы состояний и переходов.
Так вот, на практике встречал 3 случая:
1) Пытаются применить для автоматизации обхода очень простого набора состояний, для которого не составляет сложности написать кейсы вручную.
2) Учитывается состояние многих элементов интерфейса. В результате, количество комбинаций растет как степенная функция, и полный обход схемы выдает десятки тысяч кейсов. Если это кейсы на UI, время выполнения получается абсолютно нереальное. В итоге, всё равно начинаем искать основные маршруты с помощью человеческого разума, и составляем кейсы вручную.
3) Юнит-тесты, которые проходят за мгновения, поэтому несколько тысяч тестов - не проблема.
Интересно, в каких случаях возможно применение MBT, так, чтобы диаграмма была и не слишком простая, и не астрономически сложная.
Или же это всё миф, и концепт не имеет практического применения для "медленных" UI-тестов.
В качестве бонуса про model-based тестирование уже - Томми Такала и Мико Катара из Техноголического Университета Тампере применяя свой model-based-testing софт для BBC News виджета на Андроиде сообщили следующие цифры - 2/3 обнаруженных этим методом проблем были обнаружены в процессе составления модели, а еще 1/3 после прогона этих тестов. Это не повод не заниматься этим в принципе, но повод составить модель даже если у вас нет ПО или ресурсов на полноценную автоматизацию (да, я знаю что в model-based тестировании составление модели это чуть ли не самая затратная часть). (Сергей Высоцкий) - Отсюда.
Написано
28 августа 2015 - 05:50
Тема на хабре.
В библиотеке Self-learning представлено более 20 курсов начального уровня по направлениям: «Разработка ПО», «Тестирование», «Управление IT-сервисами», «Системный и бизнес-анализ» и др.
Список курсов:
1. Использование техники Mind Maps
2. Разработка приложений для Windows Phone
3. Модульное тестирование на платформе .Net
4. Разработка программного обеспечения на платформе .NET (для нетехнических специалистов)
5. Основы финансовых рынков. Инвестиционный банкинг
6. Введение в технологии разработки ПО
7. Обзор методологий разработки программного обеспечения
8. Асинхронное будущее в .NET
9. Подбор эффективной команды тестировщиков
10. Основы тестирования производительности
11. Введение в метрики тестирования
12. Введение в тест-менеджмент
13. Мастерская по разработке и управлению требованиями. UML и Модель сценариев использования (Use Case Model)
14. Оценка, планирование и контроль исполнения проекта
15. Обзор JAVA-технологий разработки ПО
16. Основы тестирования для не тестировщиков
17. Метрики для оценки качества продукта и процесса
18. Школа тестирования. Часть 2. Управление дефектами
19. Введение в процессы сопровождения ИС – ITIL/ITSM – Управление сервисами
20. Метрики для управления тестированием
21. Школа тестирования. Часть 6. Тестирование Web-приложений
22. Тестирование производительности с использованием jMeter: от старта проекта до финальных отчетов
Если курс не выделен жирным - то в материалах курса доступен только тест для проверки знаний.
Про уровень качества и полезности материала не имею информации. Так что используйте при желании на свой страх и риск.
Написано
18 августа 2015 - 02:29
Для начала надо уточнить почему клиент звонит Мне, а не техподдержке, аналитику, внедренцу, ПМ...
Или вы пошли на собеседование где роль тестировщика и техподдержки объединена?
Если Моя роль не подразумевает техподдержку - надо вежливо посоветовать обратиться к отвечающим за этот процесс лицам (Техподдержка, например) и поговорить со своим руководителем почему звонят Мне. За выход за рамки полномочий можно справедливо получить по шапке.
Тут вам могут сказать, что да, не клиент звонит - а таск пришел с данной проблемой.
Тогда вы говорите - насколько в таске проблема локализована:
Что за сайт? (у вас он может быть не один). На каком устройстве возникает проблема? (У клиента вполне может быть мобильное устройство и плохой интернет) Окружение? (Не все окружения поддерживаются) Соединение с сетью? Воспроизводится ли у нас данная проблема? (При 80% fail - она вполне должна и у нас воспроизводится) Антивирус?...
Также в реале у вас должна быть информация:
Известна ли вам данная проблема? Способ её решения? и так далее.
PS:
Задачка из разряда - мы придумали в голове правильное решение этой задачи - а вы должны угадать, что мы придумали - при этом мы всегда можем изменить правильный ответ.
Поэтому для начала попросите собеседующего на бумаге - написать ответ на неё. Чтобы как только вы нашли решение данной проблемы - можно было обсудить его. Или если не нашли, то почему.
Написано
12 августа 2015 - 18:50
Осторожно. Сумбурное рассуждение.
Вы тестировщик(ца). Вы находите баги. Вы красиво оформляете эти баги в отчет. Программисты радуются хорошо составленному отчету - и исправляют баг. Качество продукта становится выше. Что в этом плохого?
Почему вы считаете, что вы их случайно нашли. Мне приходят в голову два варианта вашей ситуации.
Первый: А что будет если я сделаю - эту "фигню". Упс, ошибка. - Это не случайное нахождение - вы продумали тест - и исполнили его - и он выявил ошибку.
Второй: Вы что-то, например, случайно нажали и что-то отвалилось. Тут уже нужно проводить анализ. А что еще может отвалится при аналогичном сценарии, но в другом месте? А что будет, если нажать вот это и т.д.
PS: Я не знаю с чем связаны ваши случайные "ужасные" баги - поэтому я не знаю куда вам копать =)
В любом случае лучше найденный и с любовью описанный вами баг, чем этот же баг найденный огорченными пользователями программы.
PS2: Как вы находите эти баги без проверок и исследования продукта?
Написано
10 августа 2015 - 05:14
Че ж ты такой сцуко сволочной? У тебя лучший друг не Карлсон случайно? Просто почитай, за наложение я понял. Спасибо.
Сценка 2. Недалекое будущее. Вы и ваш QA Lead. Бокс по телефону. Переписка.
Вы: Запуск я проверил. Теперь точно все работает.
QA Lead: Хм, а почему при старте программы на весь экран выходит надпись с тремя известными буквами?
Вы: Начальник, да что же ты за тиран? У тебя лучший друг не Папо Карло случаем? А то пилишь и пилишь. Спасибо. Ошибку про три буквы разработчики исправили.
PS: Увидел Bicycle tours в хобби - первая мысль, что за новый тур от Уиттакера, и почему я о нем не в курсе?
Community Forum Software by IP.Board Русификация от IBResource
Лицензия зарегистрирована на: Software-Testing.Ru
Публикации
Мужчина
