Как завалить релиз проекта?

Программист: "Можешь не заносить. Сейчас быстро пофиским"

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

Программист: "Все так и должно работать"
Покажи документацию, задачу, ничего нет? Спроси PM, или заводи "баг-вопрос", куда добавь проектного менеджера, разработчика дизайнера (всех заинтересованных в задаче) и пусть ответят в комментариях, как должно работать.

Тестировщик: "Быстренько проверю, зачем еще кейсы писать" -см.п 1

Тестировщик: "Я знаю об этом баге, я его еще в 2014 году завел в баг трекинг, я не виноват, что его никто не заметил"  Приоритезация? Не, не слышал...

Тестировщик:  "Вот сколько багов я завел, пусть теперь разгребают!"
Мое убеждение, что тестировщик НЕ должен радоваться багам. Конечно, когда ты в профессии всего месяц, твоя цель именно в "наплодить" багов и помажорнее!  Но с опытом приоритеты меняются.

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



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

Итак... Программист и Тесировщик...

Давайте жить дружно! Тестировщик должен находить баги раньше, чем их найдет пользователь. Все. Точка. Никаких "доказать", "насолить" программисту быть не должно. Эта извечная война придумана плохими командами и  руководителями команд, которые не могут задать правильную атмосферу и объединить всех одной целью под названием "качественный продукт".

Cтоит ли готовить приложение для FireFox OS? Уже был релиз под другие платформы.

Вопрос: стоит ли готовить приложение для FireFox OS? 

Уже был релиз под другие платформы. Спланировать объем работ.

 1) Если был релиз под другие платформы:

- уже имеется SRS (документ с требованиями к продукту)

- составлены тест-кейсы, тест-сьюты

- имеется тест план с набором этих тест-сьютов со спецификой к каждой платформе;

- настроены тестовые окружения, программистами написаны юнит тесты, есть тестовый сервак и т.д.

- проведено и пройдено acceptance testing (приемочное тестирование = продукт годен к эксплуатации);

- следовательно все вышеописанное можно позаимствовать, немного подстроив под специфику FireFox OS

Пример: разобраться со спецификой FireFox OS и особенностями портирования, возможными изменениями в коде или структуре самого приложения. Взять за основу тестовые сценарии (тест-кейсы) и выбрать подходящие, выбрать степень покрытия, наладить тестовое окружение и тестовый сервер. Выбранные тест-кейсы занести в тест план, указав в нем ответственных за их выполнение, сроки, особенности системы и т.д.

2) Стоит ли готовить приложения для FireFox OS - тут нужно учесть следующее:

- что говорит статистика?

а. сколько пользователей у FireFox OS всего и кто они (возраст, положение в обществе, ЗП и т.д.)

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

- что это даст компании?

а. таким образом вы пытаетесь расширить рынок сбыта, географию, вовлечь новых пользователей.

б. банально заработаете денег, т.к. пользователи FireFox OS привыкли платить за приложения (покупать их).

и стоит ли игра свеч?

а. будет ли прибыль больше затрат на портирование (прогноз)?

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

3) Спланировать объем тестирования, написать тест-план.

4) Что нужно сделать прежде чем сказать, что готовы запускаться под эту систему?

-исследование

-сравнение с другими платформами

-менеджмент по портированию 

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

Пример:табличка сделана два года назад (по вертикали порядка 20 ти пунктов). Решался вопрос о портировании iOS приложения под Android или WinPhone.