Добрый день. 

Выскажите, пожалуйста, свое мнение.

 

Я учусь в Германии и заинтересовалась тестированием. Взяла книги в библиотеке, по отзывам хорошие,  остановилась на Спильнере и Линце.

Тут на форуме тоже советую начать именно с книг и теории (что очень логично), и потом подключать практику.

 

Тут маленькая ремарка. Мне всегда надо четко изучать-читать один источник (либо книгу, либо материалы курса, либо к преподавателю). Если я одновременно учу одно и то же по 2-3 книгам (в данном случае это основы тестирования), то получается катастрофа. Долго описывать почему так происходит, поверьте на слово.

Жизнь и опыт научили меня - не бери 2 книги по одному предмету! Только одну! Естественно у всех по-разному, у меня так.

 

П.С. естественно я не чураюсь гугла и википедии и непонятные слова или интересные темы ищу и читаю в других источниках. Углубляются знания тоже активно с другими авторами. Но именно основа должна быть одной книгой. Максимально систематично и в одном источнике, а не "эту тему я почитаю тут, эту тему я почитаю там".

 

Так вот, тут настоятельно советуют Савина. Книжка хорошая, я уже пролистала. Но смущает ее объем за 300 страниц (то есть ее надо брать как основную). И она на русском...

Вот сижу в раздумьях. Термины у тестирования имеются, причем в количестве. Имеет ли смысл учить их на русском, чтобы потом переучивать на другом языке?

Конечно хочется читать на родном языке (нюансы понятнее, милее душе). Но практично ли это?

 

Посоветуйте, что бы вы лично делали на моем месте? 

Основы изучали бы по Савину или брали бы книгу на английском или немецком языках, если работу планируете искать не в россии?

У Савина есть расширенный вариант этой книги на английском. Даже более крутой, чем русская версия.

URL учебника: www.qatutor.com.
URL тренировочного сайта: www.sharelane.com (прошу учесть, что нужно взять учебник и используя его уже работать с sharelane.com).

У меня такая просьба, проходил собеседование, сказали нужно подтянуть английский с упором на специфику тестирования. 

Можете посоветовать книгу об основах тестирования на английском. Как то странно в первый раз в жизни ищу книгу не в переводе, а в оригинале))

Alexeysetyamin@gmail.com

Читайте Савина.

URL учебника: www.qatutor.com.
URL тренировочного сайта: www.sharelane.com (прошу учесть, что нужно взять учебник и используя его уже работать с sharelane.com).

И подтягивайте умение находить самому общедоступную информацию.

2. Возможно разработчик ошибся в ссылке - поэтому перешел по ссылке devlab.ru/servise

     Результат: браузер открывает страницу

    Ожидаемый результат: открытие страницы  devlab.ru/servise

      

   

              

       

 

Ещё одна подсказка на какую букву тебе идти обратить внимание в ссылке надо.

Примерно так?

Summary:При переходе на страницу test.devlab.ru/servise браузер отвечает ошибкой 404.

Description:В браузере Opera (версия ХХ) при переходе из сайта  test.devlab.ru на страницу /servise браузер отвечает ошибкой 404

Severity:Blocker

Priority:Medium

Шаги для воспроизведения:Открыть сайт test.devlab.ru

                                                         Перейти/кликнуть  по ссылке/кнопке/вкладке   test.devlab.ru/servise

Результат: браузер возвращает ошибку 404

Ожидаемый результат: открытие страницы  test.devlab.ru/servise

 

Вы важное пропустили - Вам BadMF очень толстую подсказку дал. Внимательно изучите адрес ссылки.

Шаги Ваших действий должны быть:

1. Перешел по ссылке X - ошибка 404

2. Возможно разработчик ошибся в ссылке - поэтому перешел по ссылке X* 

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

Если сайт не открылся - заводить ошибку.

Мне тоже требуется помощь по тестовому заданию.

Суть задания. Есть мобильное приложение для Android и iPhone с релизами в GooglePlay и AppStore соответственно.

Необходимо составить методику тестирования и провести в соответствии с методикой комплексное тестирование, описать баги (последовательность воспроизведения, обоснование, критичность).

Собственно сам процесс тестирования несложен, а вот описание методики вызывает вопросы.

Какие методики тестирования подходят в этом случае. Тупо кинуть на все что можно? Задать корректные и некорректные данные на вход? Намекните, как это красиво описать.

Не зная целей тестирования - смысл браться за задание?

Составить комплексную методику тестирования - какая цель этого методики? Удостоверится, что старые ошибки пофикшены? Удостоверится, что новые функции работают? Стресс-тестирование? Юзабилити? Проверить документацию? Проверить сообщения со страницы приложения о новых ошибках? Регресс? А еще есть приемочное - но тут без знания цели/ей приложения сложно (и цель декларируемая часто отличается от реальных целей)...

Отличное комплексное тестирование займет слишком много времени для тестового задания.

В задании ничего не сказано об внесении предложений на улучшение продукта.

Что важно проверить? Есть ли подводные камни, о которых мне желательно знать?

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

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

Значит, ответ на вопрос "где та грань технических знаний...?" прост : Когда сам почувствуешь, что готов за это взяться? ;-)

Не боитесь схлопотать эффект Даннинга-Крюгера? 

Спасибо. Начал уже делать. Задам только один вопрос. Возьмем самый распространенный пример - Калькулятор. Скажем я делаю тест кейсы. Я должен проверить абсолютно все возможно варианты? Ну например деление на минус, сложить 2 отрицательных числа и тд? То есть смысл тест кейса это найти все возможные варианты, которые может сделать юзер, верно?

Неверно. Ты полную хрень написал. Ошибившись даже в количестве вопросов.

Тебе к Гудвину обратиться надо за смесью отрубей, булавок и иголок.

И погуглить, найдя ответы на свой вопросы. 

Подсказка:

У тест-кейса обычно есть предусловие(я). Поэтому часть шагов из вашего тест-кейса можно смело вынести в него. Это облегчит понимание теста.

Сделайте ваш тест-кейс удобнее.

Юрий Адлер: 

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

Боюсь Вас расстроить, в конечном счете все делается ради денег.

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

Прибыль может быть различна: деньги, гордость решением сложной задачи, профессиональным и/или карьерном ростом и т.д.

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

Притча:

Zo0, у вас есть возможность уточнить у вашего тренера ПОЧЕМУ он вам сделал данное замечание, с вашими АРГУМЕНТАМИ почему это замечание не соответствует данной ситуации.

Вы МОЖЕТЕ выслушать его объяснение - и СДЕЛАТЬ ВЫВОДЫ или не делать.

Можете также продолжить ДИАЛОГ, используя НОВУЮ ИНФОРМАЦИЮ. 

Это конструктивно.

Обвинять человека тем более не разобравшись до конца в ситуации - неправильно. Зато удобно.

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

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

Крутые названия:

Этот тест не прошел

Быстрые действия приводят к проблемам

Синий экран на второй странице  (Обоземой, фанаты Рекса...)

У меня случайно программа упала 

Где взять тестовую версию приложения

А как запустить автотесты

Баг на баге и багом погоняет 

Что-то где-то у кого-то сломалось - Поздравляем, это крутое название! 

И придет ответ от разработчика на такое: Что-то где-то кому-то починили

PS: 

1. Вводим, как нам советует Багред: "Орфографический баг"

2. Дается совет, что нужно использовать фразу "Слово "выпуск" в названии статьи за июнь 2010 года в "Базе Знаний" в разделе "Обновления" написано с опечаткой"

3. Вводим данную фразу

4. И Багред говорит, что это не крутая фраза =(

Продолжаем:

Работал - программа вылетела - Поздравляем, это крутое название!

Что-то пошло не так - Поздравляем, это крутое название!

Оно само упало, я его не трогал - Поздравляем, это крутое название!

1. Для начала можно организовать критерий приёмки проекта в тестирование.

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

3. Гнать впереди паровоза тоже не нужно -  есть менеджер, который отвечает за проект и за программистов. Вы не СПАСИТЕЛЬ ПРОЕКТА и КРИЧАТЬ ЧТО ВСЕ ПЛОХО И МЫ ПРОПАЛИ не ваша обязанность - вы должны обеспечить свою часть работы в виде тестирование.

4. Предполагаю вы знаете, что от вас ожидает руководство. Объясните им, что вы в текущих условиях сможете сделать это и это, а вот это уже не реально сделать за отведенное время. И это нужно сделать сразу, а не если вдруг проект провалиться. 

5. Зарубите идею о KPI до тех пор пока все не станет рельсы. 

6. На эти 3-4 недели до дедлайна ваш процесс должен быть максимально прозрачен, чтобы ваш руководитель был в курсе, что вы делаете и почему ИМЕННО ЭТО вы делаете.

Сценарий 1. Сотрудник без контрольный и не самоорганизованный.

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

Работодатель не дает задания. Сотрудник в результате привычки не проявляет инициативы (например, что бы оптимизировать какую-то свою деятельность, да муды всякие поискать), забивает на какие-то старые задачи (они и так тянутся давно, нафиг никому не нужны), а продолжает сидеть в ВК.

 

Сценарий 2. Сотрудник без контрольный и самоорганизованный.

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

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

 

Сценарий 3. Сотрудник подконтрольный и не самоорганизованный.

Работодатель дает задание, сотрудник выполняет. Все ясно как ясный пень на лугу березовой рощи.

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

 

Сценарий 4. Сотрудник подконтрольный и самоорганизованный.

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

 

По мне так, 4 сценарий самый продуктивный для бизнеса и самый не любимый среди сотрудников. Оптимальный же получается 2 и 3 сценарий.

Говоря другими словами, контроль нужен, ибо мало людей на столько самоорганизованы, что смогут обеспечивать не только других работой, но и самого себя на 100%:

Сценарий 5. Процесс работы налажен. Работа сотрудника прозрачна для заинтересованных лиц. Она выполняется качественно и в срок. Никто не занимается имитацией бурной деятельности. Все счастливы. 

Выстраивание процесса работы уже задача менеджмента.

Кейс:

Предусловие: Два сотрудника с одинаковой должностью, обязанностями, зарплатой и времени работы в компании. Выполняют поставленные перед ними задачи качественно.

Первый сотрудник потратил на работу 30 часов за контрольную неделю. Как вы будете оптимизировать его рабочий день? 

Второй сотрудник выполнил аналогичную работу за 45 часов. Второй сотрудник имеет право отгулять 5 часов переработки на следующей неделе?

Вопросы к Вам:

Как вы будете учитывать неизмеримые показатели? 

Из за чего возникла идея оптимизации рабочего дня сотрудника? 

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

Имея на руках расписанный день сотрудника - можно смотреть на него с целью оптимизации.

Если вы отработали 45 часов за неделю - соответственно эти 5 часов можно отгулять на след неделе.

Дисклеймер. Не путайте оптимизацию рабочего дня и соблюдение ТК РФ. 

Статья 152 ТК РФ. Оплата сверхурочной работы.

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

PS2:

При попытке впихнуть невпихуемое выпихивается ранее впихнутое. Кроме того, сам процесс впихивания невпихуемого уменьшает предел впихуемости.

©Дорофеев.

По-моему, работы должно быть всегда столько, что бы сотрудник не успевал все сделать за день, но и мучался тем, что ее слишком много. Тогда самоорганизация его не позволяла бы ему пинать балду свыше какой-то нормы.
Если работы нет столько, то нужно контролировать его временные затраты кем-то стороны, вплоть до почасового контроля (например ежедненвые/еженедельные таймшиты с часовой разбивкой). Ибо его самоорганизация начала бы уделять работе не более 4-6 часов в день и качество его работы, как следствие, начало бы падать.

 

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

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

Для фирмы лучше когда работник занят всего 2 часа в день при условии, что свои обязанности он выполняет качественно и в срок, чем если он перегружен и не успевает выполнять свои задания. При перегрузке долг работника накапливается, его производительность и мотивация падает. Человек должен гордиться своей работой, а вы ставите его в условия, когда работа начинает его угнетать.

Бизнесу пофиг, есть у тебя работа прямо сейчас или нет. Его волнует, чтобы задачи поставленные перед сотрудником были выполнены качественно и в срок.

Придумывать себе работу - очень плохо. Ибо потом вы и спросите с сотрудника почему он эту херню делал все это время - место того, чтобы заняться "полезными вещами".

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

PS: Прочитайте "Цель" Голдратта для начала.

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

Предположение. Может вам нужна не регистрация времени, а повышение прозрачности процесса? 

Рекс Блэк: "Ключевые процессы тестирования".

Ну же! Неужели никому не интересно просветится на этот вопрос? Или все всё знают про процессы в тестировании а я тут чушь какую-то несу? Ну так направьте меня на путь истинный, приведите хоть один нормальный пример, что есть такое процесс!

Рис.1. Процесс «Обработка заказа»

Следующие темы от Dananas:

1. На какой планете живут самые позитивные тестировщики

2. На какой планете живут самые оптимистичные тестировщицы

3. Чем отличается тестирование по вторникам от тестирования по четвергам

Какой женщине, например, будет легче родить ребенка 50 летней или 20 летней? Какого возраста сотрудник будет более обучаем: 20 летний или 50 летний? У кого больше риска, что он уйдет в декрет или в армию? Это же все риски и при найме это все учитывается. Так почему бы не начать учитывать тогда такое физиологическое качество как усидчивость, стабильность и прочее более присуще (как показывает даже текущий опрос) представителям нашего прекрасного женского пола?

 

Люди разные - от них и надо исходить, а не от пола. Исключение Статья 253 ТК РФ. Работы, на которых ограничивается применение труда женщин. 

2. Какой продукт сдают продукт заказчику (Вид снаружи) и Как обстоит ситуация с продуктом для команды разработки (Вид изнутри)

5. Тестирование по старым чек-листам и Тестирование наобум

6. Картины: Автоматизаторы готовят расстрел багов и Бокс Тестировщика-Исследователя против Противника-Тяжеловеса 

7. Тестировщик  в музее Багов смотрит на мотылька обнаруженного 9 сентября 1945 в машине Mark II Aiken Relay Calculator и думает, а что будет если... - Результат его действий отображен на рисунке 2

8. Тестирование нового функционала и Тестирование критичного функционала

10. Канер в молодости; Канер на пенсии

PS: Как вариант Александров. Он дедушка русского тестирования. =)