А может кто пояснить, что значит: ставить процесс снизу или сверху?

• Ось "сверху вниз" – определение руководством общего направления и задач реформ
• Ось "снизу вверх" – инициатива рядовых сотрудников, направленная на поиск методов максимизации эффективности бизнеса
• "Горизонтальная" ось – реорганизация ключевых бизнес-процессов 

lurk, вы книгу пишите?

Нет. Я просто делюсь полезной (надеюсь =)), упорядоченной информацией из своей копилки.

Вношу свой небольшой вклад в сообщество тестировщиков. =)

Правда, я решил не выкладывать отсылки на книги и англоязычные статьи, выкладывая свои подборки по нюансам тестирования.

Бонус:

Прочтите это для начала.

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

Судя по количеству вопросов от стажеров - нет.

Опираясь на Ваше мнение - нет.

Вывод очевиден. 

Очевидно, что вы не прочли о задачах книги (5 страница). Вывод о Вас очевиден? 

Выдержка из предисловия от автора или зачем нужна эта книга:

Эта книга не ставит своей задачей полноценное раскрытие всей предметной области со всеми её нюансами, потому не воспринимайте её как учебник или справочник — за десятилетия развития тестирование накопило такой объём данных, что для его формального представления не хватит и десятка книг. Также прочтения лишь этой одной книги вовсе не достаточно, чтобы стать «гуру тестирования».

Тогда зачем же нужна эта книга!?

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

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

В-третьих, эта книга — своего рода «карта», в которой есть ссылки на множество внешних источников информации (которые могут оказаться полезными даже опытным тестировщикам), а также много примеров с пояснениями.

...

Напоследок: ничто в этой книге не является догмой, к любому термину вы можете найти альтернативное определение, к любой рекомендации — контраргументы. И это нормально. Со временем вы станете понимать контекст ситуации и применимость (полезность!) той или иной информации. Итак, приступим!

Книга как опорный материал для тренингов - хороша. (Ставим +)

Книга как карта  и набор полезных ссылок - отлично. (Ставим !)

Первый задача - материал книги для самостоятельно обучения даже для человека, имеющий небольшой опыт в тестировании - слишком объемно и сложно. Поэтому здесь поставлю -+.

Итог: Полезная книга для тестировщика среднего уровня или выше, если речь идет о 2 и 3 задачах книги. Хорошая книга для новичка, если у него есть учитель, который сможет дать ему ответ на возникшие при прочтении книги вопросы. Плохая книга для самостоятельного изучения новичком, но как справочник ему будет полезна.

PS: Печатный вариант книги как-нибудь получить можно не участвуя в тренингах?

Отбор проходил так: взяли количество тем и сообщений от участников за полгода. Темы ценились чуть выше, чем ответы. И да, необъективно наверняка, потому-что отбор был чисто количественный, полезность тем мы не оценивали.

Классно бы увидеть список со значениями (количество тем и сообщений) с формулой расчета.  

Если верить этой статье (http://habrahabr.ru/post/254209/)

А вы этой статье верите?

После того как автор написал, что

Ошибка – несоответствие производимого продукта требованиям, прямым или косвенным. И это единственный правильный ответ.

Цель тестирования – предоставление актуальной информации о соответствии производимого продукта требованиям. Всё. Не больше и не меньше. 

 я отрицаю существование негативных проверок, поскольку:

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

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

На сколько я понимаю, стратегия тестирования описывает что и как делаем в рамках одной задачи, а не в рамках всего проекта. Поведение в рамках проекта описывается регламентом.

Но не об этом.

 

Я хочу собрать полный спектр навыков и умений от А до Я. От стажера до рук отд тестирования. Что бы было наглядно каждому, что он знает сейчас, над чем он может работать дальше, какие знания нужны лиду и т.д.

Да, я понимаю, что смешал вчера документы по типам в одну кучу, но потому я и спросил, что может ли кинуть в меня кто-нибудь чем-нибудь полезным по документации в тестировании.

Попробуйте, проведите исследование. Сомневаюсь, что у вас выйдет что-то внятное.

Если человеку сказать, что пока он делает А (свою работу) - он получает X денег, а если он хочет получать 2Х - то ему нужно будет делать Б. То часто он будет стараться учить-делать Б, забивая на А.

Вам для размышления статья: Тест-дизайн тест-менеджерам не нужен.

Начал шаманить и сразу ступор: какая бывает документация в тестировании?

Если верить этой статье (http://habrahabr.ru/post/254209/), то документация бывает внешней и внутренней. И с этим вроде понятно. Но не понятно куда тогда относить такие документы как Стратегия тестирования, различные регламенты (работы отдела, работы с ошибками, написания сценариев и пр), различные учебные материалы?

 

Может ли кто покидаться умными вещами в меня относительно видов документации? Способов их деления и т.д.?

Вариант 1. Гугл или Яндекс на ваш выбор.

Вариант 2. Устроится на работу/обучение к опытному наставнику и узнать у него.

Вариант 3. Разобраться самому - сделать выводы - и выводы уже уточнить в этой теме.

Какова же степень важности роли тестировщика в IT-компании?

Предупреждение: Сложная тема. 

Тестирование на основе модели (model-based testing): Тестирование, основанное на модели исследуемого компонента или системы. Например: модели роста надежности, моделей использования (таких как функциональный разрез) или поведенческих моделей (таких как таблицы альтернатив или таблиц переходов состояний). [ISTQB Стандартный глоссарий терминов, используемых в тестировании программного обеспечения Версия 2.2]

Видео:

1. Тестирование на основе моделей: "ужас-ужас" или всё не так страшно? (Алексей Баранцев SQA Days 15)

2. Применение MBT для генерации тестовых сценариев для ручного и автоматического тестирования (Юлия Саенко SQA Days 13)

3. Micro Model Based Testing (Роман Иовлев SQA Days 17)

4. Тестирование на основе моделей (3 лекции Виктор Кулямин)

5. Тестирование на основе Модели (Александр Боциев - Intel, г. Нижний Новгород встреча QA Alliance 21 марта 2015)

6. Вы можете купить видео "Функциональное тестирование на основе моделей" (Алексей Баранцев).

Статьи:

1. Тестирование на основе моделей (Александр Петренко, Елена Бритвина, Сергей Грошев, Александр Монахов, Ольга Петренко)

2. Архитектура автоматизированных функциональных тестов: прагматичный подход к использованию Model-Based техник автоматизированного тестирования (Михаил Давыдов)

3. Тестирование на основе моделей (к.ф.-м.н. В. В. Кулямин) - можно скачать лекции по данному курсу

4. Метод разработки тестов для программных интерфейсов приложений на основе конечно-автоматной модели тестирования (К. В. Рубинов, В. В. Веденеев)

Цитаты:

В качестве бонуса про model-based тестирование уже - Томми Такала и Мико Катара из Техноголического Университета Тампере применяя свой model-based-testing софт для BBC News виджета на Андроиде сообщили следующие цифры - 2/3 обнаруженных этим методом проблем были обнаружены в процессе составления модели, а еще 1/3 после прогона этих тестов. Это не повод не заниматься этим в принципе, но повод составить модель даже если у вас нет ПО или ресурсов на полноценную автоматизацию (да, я знаю что в model-based тестировании составление модели это чуть ли не самая затратная часть). (Сергей Высоцкий) - Отсюда.

Перед тем, как погрузиться в обучения нового сотрудника: Продумайте, что Вам от него нужно - какая цель его обучения? Что он должен уметь, чтобы наносить наибольшую пользу фирме при справедливых (но умещающихся в бюджет) затратах на него? Чему его выгоднее обучать? Кто будет его обучать? Может эффективнее и дешевле послать его на курсы? 

Небольшой квест для Вас: 245 урок поможет Вам узнать направления внутри технической и управленческой ветки.

Если решите квест и копнете глубже - узнаете много полезного. 

1. Ещё раз про pairwise (Алексей Баранцев)

2. Разработка тест кейсов по методике pair wise (Никита Постолакий)

3. Обзор 4. Никита Постолакий "Разработка тест кейсов по методике pairwise" (Андрей Ладутько)

4. Pairwise testing with PICT (Алексей Федорко)

5. Метод попарного тестирования (Александр Федоров)

6. Что такое Pairwise Testing, и с чем его едят (Lena)

7. Тестируйте не числом, а умением (Scott Sehlhorst)

8. Pairwise testing: добиваемся оптимального покрытия различных тестовых комбинаций (Timur Gilmullin)

9. Pairwise testing. Part 1 - Orthogonal Arrays (вольный перевод Chapter 6 из книги "A Practitioner'S Guide To Software Test Design" by Lee Copeland) (Pasha Ivanyushyn)

10. Pairwise testing. Part 2 - AllPairs Algorithm  (Pasha Ivanyushyn)

Прочее: Available Tools - инструменты. Если не знаете, что выбрать используйте PICT или ALLPAIRS.

Жирным выделены ссылки на видео.

На доу в QA дайджест #10 написано, что "Беглый просмотр показал, что материал достойный, спешите изучать!". Качество материала включенного в дайджест сильно разнится - от "полная чушь" до "полезно", касается всех выпусков дайджеста.

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

Можете использовать:

1. Специалист по тестированию в области информационных технологий (Профессиональный стандарт)

2. Junior, Middle, Senior, Lead, etc – в чем разница? (Сергей Макаров)

3. Прочитайте главу 8 Ключевые процессов тестирования

4. Как оценить команду тестирования и как направить их развитие в нужное русло (Юлия Свистунова) - доклад с SQA Days 16 

5. Готовим тестировщика. С нуля и до… необходимого уровня (Святослав Куликов, SQADays-2011) +  это

[ссылка сейчас не работает - ищете в кеше гугла данную статью]

6. О планировании карьеры, плане профессионального развития и не только... (Статья 2007 года)

Дисклеймер, что должен уметь джун - если он хочет хорошо зарабатывать:

1-3 Подвешенный язык 

1-4 Знание английского языка

1-3 Автоматизация тестирования 

3-4 Уметь тестировать

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

Тема на хабре.

В библиотеке 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: от старта проекта до финальных отчетов

Если курс не выделен жирным - то в материалах курса доступен только тест для проверки знаний.

Про уровень качества и полезности материала не имею информации. Так что используйте при желании на свой страх и риск.  

На одном из мест работы, нас, сопляков, просили делать отчетный документ со скриншотами, что все работает согласно заявленным требованиям. В случае обнаружения ошибки на продакшене, поднимались эти отчеты. Если данная проверка была выполнена, но результат отличный от боевого, то шло разбирательство в сторону не обманул ли тестировщик или это проблема боевой среды. Если такой проверки не было озвучено в отчете, то выговор тестировщику и/или аналитику о том, что не подумали про это.

Примерно как-то так.

Если ошибка специфическая или плавающая кому попадало?

Как определяли кто виноват тестировщик или аналитик, если не была озвучена проверка в отчете?

PS: Если организация так любит отчетность полезно вначале отдавать документ с тестами на рецензирование и утверждение вышестоящим заинтересованным лицам под подпись - с конечным утверждением от непосредственного руководителя проекта. Чтобы не возникло ситуации обвиняем невиновных. 

PS2: Были ситуации когда тестировщик обманывал?

1. Орфографию

2. Используйте Ситечко для создания чек-листов

3. Если Ситечко сложно, используйте один из шаблонов чек-листов от Наташи Руколь

4. Лучшее враг хорошего

5. Лучше меньше, да больше

По желанию:

1. Посмотреть доклад Владимира Мозжечкова на SQA Days-16.

Оптимальный метод проверки исключение проверки из процесса работы.

PS:

По факту Мне не хватает условий кейса. Вы знаете возможности команды или нет? Насколько хорошо Вы знаете продукт? Насколько команда знает продукт? Команда собрана с нуля или давно работает в таком составе? Какие задачи руководство планирует решить с помощью Вас? Какие задачи Вы планируете решить с помощью этой проверки? 

Ужасная заготовка. Объем задания напоминает развод либо от вас, либо от работодателя.

PS: Сколько времени вы планируете потратить на составление чек-листа? Сколько уже потратили?

Юрий Адлер: 

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

Для начала надо уточнить почему клиент звонит Мне, а не техподдержке, аналитику, внедренцу, ПМ... 

Или вы пошли на собеседование где роль тестировщика и техподдержки объединена?

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

Тут вам могут сказать, что да, не клиент звонит - а таск пришел с данной проблемой. 

Тогда вы говорите - насколько в таске проблема локализована:

Что за сайт? (у вас он может быть не один). На каком устройстве возникает проблема? (У клиента вполне может быть мобильное устройство и плохой интернет) Окружение? (Не все окружения поддерживаются) Соединение с сетью? Воспроизводится ли у нас данная проблема? (При 80% fail - она вполне должна и у нас воспроизводится) Антивирус?...

Также в реале у вас должна быть информация:

Известна ли вам данная проблема? Способ её решения? и так далее.

PS:

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

Поэтому для начала попросите собеседующего на бумаге - написать ответ на неё. Чтобы как только вы нашли решение данной проблемы - можно было обсудить его. Или если не нашли, то почему.

п.1-4 - Если вы не знаете на ком эти вещи лежат в фирме, в которой вы работаете, то я тем более этого не могу знать   

п. 5 - да, если считаете, что это нужно. 

PS:

- Скажите,пожалуйста, как бы мне отсюда выбраться?
- Это в значительной степени зависит от того, куда ты хочешь попасть, - ответил Кот.
- Мне, пожалуй, все равно куда, - сказала Алиса.
- В таком случае не имеет значения куда ты попадешь, - сказал Кот.
- ...лишь бы добраться куда-нибудь, - добавила Алиса в качестве пояснения своих намерений.
- Ну, ты обязательно придешь куда-нибудь, - заметил Кот, - если будешь идти достаточно долго.

© Льюис Кэрролл