Коллеги, хочу поделиться задачей! =) Ответ пока никак не отгугливается.

Недавно в списке QA должностей нашел вот такую: Senior Director of QA. Интерпретации: Director of QA, QA Director.

Есть ли у Вас кто либо под такой должностью? А чем он занимается?

 

 

На главной странице портала (http://software-testing.ru/index.php) присутствуют ссылки на «очные курсы».
Кликаю по той, что обещает тренинг по исследовательскому тестированию в Санкт-Петербурге 11 сентября.
Результат — попадаю на страницу с описанием тренинга в Екатеринбурге.
 
Давным-давно уже бага висит, странно что до сих пор не пофиксили.

Приглашаем Вас посетить семинар «Domain-тестирование», организуемый независимым сообществом тестировщиков Санкт-Петербурга 15 июля. С докладом выступит Широчкина Марина, ведущий инженер по тестированию компании Яндекс. На этот раз помещение и оборудование предоставляет компания Bercut, занимающаяся разработкой решений в области телекоммуникаций.

Более подробную информацию и форму регистрации вы можете найти у нас на сайте: http://sqagroup.spb.ru/annonces/domain-testing/

Благодаря проходящему сейчас чемпионату мира по футболу, я попал на сайт “Советский спорт”, и каково же было мое удивление, когда в меню, где перечислены разные виды спорта, я увидел пункт “Фэнтези”!


Разумеется, я тут же забыл про ЧМ и немедленно кликнул по этой ссылке. Пока загружалась страничка, в голове пролетали разные мысли, я гадал, что же это за вид спорта такой – стрельба из эльфиских луков? бой гномов на топорах? магические поединки?

Конечно же оказалось, что это никакой не вид спорта, а игра для болельщиков – футбол виртуальными командами, набранными из реальных игроков, которые, играя в реальной жизни, зарабатывают баллы для владельцев этих виртуальных команд.

Но написать заметку я решил вовсе не для того, чтобы рассказать вам про новый прикольный способ тратить свободное время и деньги (впрочем, похоже, что некоторые на этой игре неплохо зарабатывают). И уж тем более неспроста я поместил её в Панбагон.

Как в меню, где перечислены виды спорта, попал этот пункт, который явно вносит логический диссонанс, нарушая принципы классификации? Ладно, можно было бы его поместить как подпункт в разделе футбол. Или поместили бы его в конце меню, где находятся пункты “Футбольный симулятор” и “Магазин”. Ну ведь явный же баг!

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

Коллеги, приходилось ли вам сталкиваться с такими нелогичностями в интерфейсе программы, которые вроде бы выглядят как неправильность, дефект, но в действительности сделаны намеренно для достижения некоторой неочевидной цели?

Мой опыт руководства функциональным тестированием можно в большей степени отнести к аналитической (Analytic) и стандартной (Standard) школам тестирования в классификации Bret Pettichord. Эти школы тестирования проповедуют строгий контроль тестового покрытия и соблюдения всех предусмотренных процедур при выполнении тестирования.

Процесс тестирования в этом случае выглядит следующим образом:

• Анализ функциональных требований (текст -> мозг)
• Формирование вопросов и замечаний (или тестовых требований) по функциональным требованиям (текст <- мозг)
• Изучение актуализированного функционального (или тестового) требования (текст -> мозг)
• Разработка ручного тестового сценария (текст <- мозг)
• Прочтение текста тестового сценария (текст -> мозг)
• Выполнение действий изложенных в тестовом сценарии (действия <- мозг)
• Анализ результатов выполненных действий (текст и изображения -> мозг)
• Документирование результатов выполненных действий (текст <- мозг)
• Регистрация дефекта (текст <- мозг)

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

Если развернуть перечисленные выше пункты в одну цепочку преобразований, то получится следующая картина:


ФТ — функциональные требования
ТТ — тестовые требования
ТС — тестовые сценарии
результаты' — задокументированные результаты

На мой взгляд пути сокращения трудоемкости ручного функционального тестирования лежат в сокращении степени участия мозга в выполнении приведенных выше преобразований вплоть до полной их автоматизации.

В настоящий момент есть следующие идеи:

• Автоматическая регистрация дефектов на основе выполненных действий (реализовано в Microsoft Test and Lab)
• Генерация тестовых сценариев на основе формализованных функциональных требований (пример реализации: http://dmugtasimov.scienceontheweb.net)
• Генерация тестовых сценариев на основе исходных функциональных требований (например, по ключевым словам)
• Использование типовых проверок для типовых сущностей информационных систем (пример типовых проверок для экранных форм: http://dmugtasimov-pro.livejournal.com/974.html)

Существует еще другой, более радикальный вариант — это исключение всех промежуточных артефактов и сокращение процесса до следующего вида:


К сожалению, этот вариант не подходит, когда нужно осуществлять строгий контроль процесса тестирования. Конечно отдельный вопрос: а нужно ли такой контроль осуществлять? :)

© 2010 Дмитрий Мугтасимов

Перепост, оригинал здесь: dmugtasimov-pro.livejournal.com/1549.html

Новое сообщество разработчиков программного обеспечения Девелозавр — develosaur.ru приглашает авторов статей по разработке и тестированию программного обеспечения! Так же у нас вы можете задавать вопросы сообществу по интересующим вас направлениям разработки и тестирования ПО.

Уважаемые коллеги!

10 июня состоится первый семинар, организуемый профессиональным сообществом тестировщиков Петербурга.
Благодорим компанию Yota, которая предоставляет нам свои помещения для проведения мероприятия.

Читайте подробный анонс:
http://sqagroup.spb.ru/annonces/5th-meeting/

Ждем вас!

За последние несколько лет я встречаюсь с разными представлениями о функциональном тестировании. При этом периодически возникает вопрос о целесообразности написания тестовых сценариев. В этом посте хочу сформулировать свои соображения на этот счет.


( Читать дальше )

Так сложилось, что в моей повседневной работе кнопки {Alt,Shift} + Prt Sc, Ctrl+C одни из самых часто используемых. Обычно после этого открывается Paint, вставляется картинка и файл сохраняется. Если это разовая работа, то нет никаких проблем. Если это делать по нескольку раз в день, то shortcut keys значительно ускоряет работу. Но если вам за день надо сделать десятки, а то сотни снимков, то в голову начинают приходить не хорошие мысли.
В результате этих мыслей возникают небольшие проэкты, типа ClipSa .

Программа предназначена для [очень] быстрого сохранения картинки из буфера обмена в файл.

Цель программы: максимально сократить количество действий (кликов) при сохранении картинки в файл. Вы помещаете картинку в буфер. Жмёте на Save. Картинка сохраняется в файле.
Никаких промежуточных телодвижений (Paint, Photo Editor, ACDC и т. п.) не требуется.

Программа работает как в ручном, так и в автоматическом режиме. Ручной режим позволяет сохранять графический файл через стандартный диалог «Save As».
В автоматическом режиме файлы сохраняются в каталоге, который указан в настройках. Параметры (формат графического файла, шаблон имен файлов, автонумерация) также задаются в настройках.

Кому еще, может на мой взгляд пригодиться программа:
— Технические писатели. Которые делают множество snapshot-ов для дальнейшего их включения в документацию.
— Тестеры. Которые описывают баги и составляют описания для тесткейсов.
— Блогеры. Которые из файла с множеством картинок нарезают отдельные графические файлы для последующей публикации в вебе.
— Люди, которые не хотят возиться с Paint-ом или другим графическим редактором, а хотят быстро и просто получить желаемое (файлик с картинкой).

Буду рад отзывам и пожеланиям.

Вчера я написал пост на форуме uTest про дефекты, которые отвергаются с причиной «Out of scope», и решил, что для укрепления аргументации будет полезно обсудить эту тему ещё и здесь. Ниже примерное изложение того, что я там написал, только на русском языке.

Думаю, многие, кто участвовал в проектах uTest, сталкивались с тем, что зарегистрированные ими дефекты отвергаются с указанием причины «Out of scope». Во всяком случае у меня такое случалось поначалу. Роман Твердохлебов тоже писал об этом.

Я прекрасно понимаю, что это вполне достаточное и убедительное основание для отказа, поскольку заказчик знает, что он хочет получить и за что он готов платить.

Но я чувствую дискомфорт, когда я нахожу дефект и не могу сообщить об этом заказчику, потому что я заранее знаю, что он будет отвергнут и мой рейтинг от этого пострадает (так устроена система рейтингования в uTest). То есть с одной стороны я хочу сообщить об обнаруженной проблеме, потому что это соответствует моему представлению об этике тестировщика, а с другой стороны я не хочу о ней сообщать, потому что это наносит удар по моему рейтингу. Неудобная ситуация.

Я считаю, что крайне вредно подавлять в тестировщиках стремление к исследованию. А тут мы сталкиваемся с тем, что это стремление не только не поощряется, но наказывается — вот что самое ужасное!

И у меня есть предложение, как можно это исправить.


( Читать дальше )