Уважаемые читатели, прежде всего статья призвана посмотреть на то, чем мы все занимаемся каждый день, глазами разработки, глазами менеджмента и конечно же попытаться пересмотреть подход к традиционному ведению проектов, применимо на всех этапах тестирования.
Итак начнём.
Самое важное, без понимания куда ехать, смысла ехать нет никакого. Нет вы конечно можете применить все имеющиеся у Вас знания и устроить огромное количество тестов не определяющих цель, а просто вынуждающих тестировать, ради тестирования. Ключевым аспектом в данном случае является то, что на этапе формирования дизайн спецификации, QA отдел чаще отключён от этого процесса, что вызывает впоследствии море недопонимания, как со стороны заказчика, так и со стороны QA. Цели-образование в данном случае будет являться более приоритетным моментом нежели задачи.
Самая сложная часть, как показывает практика, даже применяя все расчёты, какие только можно, избежать погрешности просто невозможно. Вы можете прибавить к текущему LOE хоть еще 100%, но вы всегда должны оставить еще чуть чуть, для того что бы успеть докрутить последний винтик. Расчёт рисков, ваша основная задача. Решением этой проблемы занимаются аж 2е школы.
2.1. Трактует постулаты «обрезанного» периода, вынуждая команду работать на максимуме и позволяя «отрезать» шелуху которая тормозит процесс на всех этапах.
2.2. Трактует о закладке максимального LOE с целью учесть всё, что только можно и не пропустить ни единой запятой.
Есть конечно возможность найти, что то среднее, чем, как правило QA Lead's и занимаются. Как ни крути выбирать только Вам.
Да, да, именно так. Разработка, программирование, создание на инструментарном уровне будут только сужать круг вашего обзора набором функций классов, объявления переменных и т.п.
Ваш стратегический взгляд будет только засаливаться возможностями реализации, вы перестанете видеть проект в целом, то как он работает, как взаимодействуют меду собой вызовы процедур, что будет только отвлекать вас от общей картины. Ваша Задача сводится подумать, вместе с разработкой, а не как разработка. Безусловно совсем отдалятся от разработки ни к чему, т.к. не стоит забывать, что вы и «создатели» часть одного процесса и от реализации того, что вы тестируете или чем руководите зависит успех проекта. Как бы то ни было призываю, почаще «взлетать» над проектом и смотреть на происходящее в целом.
Во всём, вообще во всём. Вы тем самым только расширите свой кругозор. Начнёте видеть то чего не видели раньше. Это гарантированно даст вам преимушество перед вами самими + всегда даст возможность на любой стадии проекта подключится к любому не функционирующему или плохо функционирующему элементу и внести поправки, сделать его действительно эффективным, настолько рационально функциональным на сколько вам самим бы хотелось. Учитесь: программировать (но не фанатично), технологиям авто-тестирования, методам функционального и не функционального тестирования, управлять системой на самых разных этапах в самых разных условиях, учитесь чему только можно научится, учитесь работать со всеми типами OS тем самым вы сможете видеть проблемы всех планов, учитесь руководить – на всех этапах, учитесь дружить с вашим персоналом, но не забывайте, что вы ответственны за них.
Нас всех этому учат, Time Managment потрясающий инструмент. Но, не забывайте, что вы один такой умный. Ваша команда, (если таковая имеется) просто может не уметь этого делать или более того даже не знать, как это делается. Научитесь планировать так, что бы вы добились результата, но не в ущерб командному взаимодействию. Выясните, у кого сколько детей, когда у них дни рождения, какая у кого ситуация в семье (если конечно Ваша команда, не состоит из более чем 10 человек).
Не сделав этого вы обрекайте себя на НЕЗНАНИЕ, на те неожиданности которые во время показа конечного продукта выйдут только лишь Вам боком. Спланируйте так, что бы им не нужно было думать, как угодить работе и себе, это Ваша задача и Вас назначили, не только для эффективного ведения проекта, учитесь грамотно распределять время, не в ущерб той команде которая потом, будет писать о Вас же FeedBack.
Отбросьте менталитет и мышление, будьте абсолютны. При хорошем менеджменте персонала, никогда не гнушайтесь, той работы которая Вас совсем недавно оставила. Иногда нужно «выйти в цех». Завершите незаконченное, добейте недобитое, от Вас зависит конечный результат.
Не забывайте, зачем вы на проекте. Хороший менеджмент персонала и рациональное руководство сделают своё дело, вы расслабитесь. Держите себя в форме, будьте в курсе последних событий и Ваш проект не проиграет никогда. Будьте всем в командной работе, пусть Ваша команда доверят Вам, пусть она говорит, что ошиблась не боясь, тирана, а зная, что вы тут же найдёте рациональный выход из ситуации, ведь ошибаются все. Пусть, команда делится с вами успехами, он ждут вашей похвалы и внимания. Будьте серьёзными и смешными. Ваша команда это ваши труды.
Итак начнём.
1. Цели и задачи
Самое важное, без понимания куда ехать, смысла ехать нет никакого. Нет вы конечно можете применить все имеющиеся у Вас знания и устроить огромное количество тестов не определяющих цель, а просто вынуждающих тестировать, ради тестирования. Ключевым аспектом в данном случае является то, что на этапе формирования дизайн спецификации, QA отдел чаще отключён от этого процесса, что вызывает впоследствии море недопонимания, как со стороны заказчика, так и со стороны QA. Цели-образование в данном случае будет являться более приоритетным моментом нежели задачи.
2. Риски
Самая сложная часть, как показывает практика, даже применяя все расчёты, какие только можно, избежать погрешности просто невозможно. Вы можете прибавить к текущему LOE хоть еще 100%, но вы всегда должны оставить еще чуть чуть, для того что бы успеть докрутить последний винтик. Расчёт рисков, ваша основная задача. Решением этой проблемы занимаются аж 2е школы.
2.1. Трактует постулаты «обрезанного» периода, вынуждая команду работать на максимуме и позволяя «отрезать» шелуху которая тормозит процесс на всех этапах.
2.2. Трактует о закладке максимального LOE с целью учесть всё, что только можно и не пропустить ни единой запятой.
Есть конечно возможность найти, что то среднее, чем, как правило QA Lead's и занимаются. Как ни крути выбирать только Вам.
3. Не засоряйте сознание, разработкой
Да, да, именно так. Разработка, программирование, создание на инструментарном уровне будут только сужать круг вашего обзора набором функций классов, объявления переменных и т.п.
Ваш стратегический взгляд будет только засаливаться возможностями реализации, вы перестанете видеть проект в целом, то как он работает, как взаимодействуют меду собой вызовы процедур, что будет только отвлекать вас от общей картины. Ваша Задача сводится подумать, вместе с разработкой, а не как разработка. Безусловно совсем отдалятся от разработки ни к чему, т.к. не стоит забывать, что вы и «создатели» часть одного процесса и от реализации того, что вы тестируете или чем руководите зависит успех проекта. Как бы то ни было призываю, почаще «взлетать» над проектом и смотреть на происходящее в целом.
4. Будьте универсальны
Во всём, вообще во всём. Вы тем самым только расширите свой кругозор. Начнёте видеть то чего не видели раньше. Это гарантированно даст вам преимушество перед вами самими + всегда даст возможность на любой стадии проекта подключится к любому не функционирующему или плохо функционирующему элементу и внести поправки, сделать его действительно эффективным, настолько рационально функциональным на сколько вам самим бы хотелось. Учитесь: программировать (но не фанатично), технологиям авто-тестирования, методам функционального и не функционального тестирования, управлять системой на самых разных этапах в самых разных условиях, учитесь чему только можно научится, учитесь работать со всеми типами OS тем самым вы сможете видеть проблемы всех планов, учитесь руководить – на всех этапах, учитесь дружить с вашим персоналом, но не забывайте, что вы ответственны за них.
5. Планируйте
Нас всех этому учат, Time Managment потрясающий инструмент. Но, не забывайте, что вы один такой умный. Ваша команда, (если таковая имеется) просто может не уметь этого делать или более того даже не знать, как это делается. Научитесь планировать так, что бы вы добились результата, но не в ущерб командному взаимодействию. Выясните, у кого сколько детей, когда у них дни рождения, какая у кого ситуация в семье (если конечно Ваша команда, не состоит из более чем 10 человек).
Не сделав этого вы обрекайте себя на НЕЗНАНИЕ, на те неожиданности которые во время показа конечного продукта выйдут только лишь Вам боком. Спланируйте так, что бы им не нужно было думать, как угодить работе и себе, это Ваша задача и Вас назначили, не только для эффективного ведения проекта, учитесь грамотно распределять время, не в ущерб той команде которая потом, будет писать о Вас же FeedBack.
6. Руководите и завершайте
Отбросьте менталитет и мышление, будьте абсолютны. При хорошем менеджменте персонала, никогда не гнушайтесь, той работы которая Вас совсем недавно оставила. Иногда нужно «выйти в цех». Завершите незаконченное, добейте недобитое, от Вас зависит конечный результат.
7. Работайте
Не забывайте, зачем вы на проекте. Хороший менеджмент персонала и рациональное руководство сделают своё дело, вы расслабитесь. Держите себя в форме, будьте в курсе последних событий и Ваш проект не проиграет никогда. Будьте всем в командной работе, пусть Ваша команда доверят Вам, пусть она говорит, что ошиблась не боясь, тирана, а зная, что вы тут же найдёте рациональный выход из ситуации, ведь ошибаются все. Пусть, команда делится с вами успехами, он ждут вашей похвалы и внимания. Будьте серьёзными и смешными. Ваша команда это ваши труды.