Еще один верный шаг на пути к хорошему тестированию

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

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

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

Уже сейчас на совещаниях с разработчиками я задаю вопросы не потому что мне не понятно как они собираются решать задачу, а потому чтобы заставить их самих сомневаться в правильности своего решения. Если разработчик продумал все "За" и "Против", а значит оценил все риски в используемом подходе, то здесь можно быть спокойным. Тестировщику в этом случае достаточно просто перенести все что говорит разработчик на бумагу в виде TTL/TSO и ждать когда фича или ее кусочки будут готовы к тестированию.

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

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

Agile практики в детском саду

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

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

Что случилось с ответственностью

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

С чего начинается менеджмент

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

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

Управление рисками в баг фиксинге

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