SQA и не только...

А.П. Прохоров. Русская модель управления

2012-02-05T00:53:00.004+03:00

Прохоров, да не тот, который баллотируется на пост президента нашей страны. Об авторе книги можно почитать вот тут: http://lib.rus.ec/a/64025. На сколько «этот» Прохоров авторитетен, пусть каждый решит сам для себя.

Автор рассматривает особенности управления в нашей стране, начиная от истоков – Древней Руси. Трудно судить объективность выводов Прохорова. Однако для общего развития книгу можно и должно читать.

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

Для заинтересовавшихся приведу содержание книги, с некоторыми цитатами:

1. Парадокс русского управления: неэффективность и результативность («Любую выполняемую в нашей стране работу можно было бы сделать дешевле и с лучшими результатами»);

2. Неконкурентное устройство русского общества («А ведь было еще православие со свойственной ему апологией уравниловки и смирения, были традиции патриархальной семьи с недопущением индивидуальных доходов и сколько-нибудь значительной, необщесемейной собственности»);

3. Факторы успеха («Система управления не давала никаких преимуществ тому, кто экономнее расходовал ресурсы и из меньшего делал большее, так что при принятии решений предстоящие затраты обычно не учитывались»);

4. Причины образования русской модели управления («Текущее, ежедневное управление князь оставляет на долю тех, кто и раньше, до создания государства, этим занимался, - родовым и племенным структурам, впоследствии – общине или артели»);

5. Кластерные структуры и круговая порука («То есть официальная система организации и оплаты труда, с одной стороны, и неформальная система организации и оплаты, действующая внутри кластерной единицы, с другой стороны, по сути противоречат друг другу»);

6. Стабильное и нестабильное состояние системы управления («…популярная русская поговорка «Бей своих, чтобы чужие боялись» косвенно подтверждает мысль о положительном влиянии «управленческого каннибализма» на темпы развития»);

7. Неправовой характер государства и управления («Бешенный успех фильма «Берегись автомобиля» - лучшее доказательство народных корней неправового характера государства и управления»);

8. Дуализм русской души («…русский – это тот, кто может быть в одну эпоху Стахановым или Корчагиным, а в другую эпоху – Чичиковым или бомжом»);

9. Механизм смены режимов функционирования системы управления («…усиление уравнительных настроений способствует стабилизации системы управления, переводу ее в мирное, спокойное состояние, а ослабление стереотипов уравниловки и усиление «конкурентных» правил поведения, требований оплаты по труду – переходу в нестабильный режим»);

10. Неизбежность импорта идей и образцов («Главное управленческое отличие фазы раздробленности – то, что в империи, в условиях централизованного управления, все делается по единому шаблону»);

11. Состояние системы управления как фактор межнациональных отношений в России («Во время нестабильного состояния системы управления каждая из национальных групп преуспевала за счет каких-то своих объективно присущих ей качеств»);

12. Деградация нестабильной фазы в стабильную («В нашей стране мало нарисовать на бумаге оптимальную структуру управления, разработать «правильные» должностные инструкции, положения о стимулировании и уставы, которые идеально бы соответствовали реалиям сегодняшнего дня. Они все равно устареют к моменту их создания»);

13. Низовая солидарность («Успех марксисткой идеологии в России во многом связан с тем, что в менталитете населения изначально было заложено противостояние между «нами» - подчиненными и «ими» - начальниками, представителями системы»);

14. Уравниловка («Уравниловка – защитный механизм, выработанный населением для того, чтобы как можно на дольше оттянуть момент прихода нестабильного состояния системы управления»);

15. Отношение к богатству («Русские богачи потому и ведут себя странно, что долгое время по-настоящему богатых людей просто не существовало»);

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

17. Компромисс между системой и людьми («Система делает вид, что она по-прежнему выполняет управленческие функции в полном объеме, то есть функционирует якобы в аварийном, нестабильном режиме, а исполнители подыгрывают и делают вид, что они соблюдают все эти непомерные требования – демонстрируют энтузиазм, покорность, согласие с тем, что все обстоит как прежде, хотя на самом деле большую часть своих обязанностей они уже игнорируют, выполняют только внешний ритуал»);

18. Перспективы («…время покажет»).

В конце книги весьма внушительный список цитируемой литературы, что весьма полезно.

P.S. Читать – модно, полезно и необходимо.

Цитирую... А.П.Прохоров цитирует Лао-Цзы в книге "Русская модель управления"

2011-10-16T22:11:00.004+03:00

Как будто именно о нестабильных фазах системы управления говорил Лао-Цзы: "Когда правительство деятельно, народ становится несчастным. Лучший правитель тот, о котором народ знает лишь, что он существует".

Harvard Business Review “Эффективное деловое общение”

2011-10-01T16:42:00.004+03:00

Есть у меня дурная привычка - обращать внимание на книги, которые лежат у коллег на столе, а потом еще и брать их почитать :)

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

1. Ральф Дж. Николс, Леонард А. Стивенс «Учимся слушать людей», впервые статья опубликована в 1957 г. О том, как важно слушать и слышать.

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

2. Энтони Джей «Искусство проводить совещания», впервые статья опубликована в 1976 г. О том, зачем проводить совещания и как это делать эффективно.

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

3. Джордж М. Принс « Как сделать совещания творческими через разделение власти», впервые статья опубликована в 1972 г. О том, как вести себя руководителю на совещаниях.

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

4. Фернандо Бартоломе «Никто всецело не доверяет своему шефу. Почему?», впервые статья опубликована в 1989 г. О том, как важно получать достоверную информацию, будучи руководителем.

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

5. Крис Аргирис «Умелая некомпетентность», впервые статья опубликована в 1986 г. О том, что нельзя всегда избегать конфликтов.

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

6. Майкл Б. Маккаски «Тайный язык руководителей», впервые статья опубликована в 1979 г. О том, что коммуникации – это не только слова.

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

7. Т. Дж. Ларкин, Сандар Ларкин «Как достучаться до рядовых сотрудников». О том, как доносить большие изменения в компании до всех и каждого.

Лучший способ объявить рядовым работникам о грядущей серьезной реорганизации – сделать это при личной встрече.

8. Кэтлин М. Эйзенхард, Джин Л. Кавейджи, и Л.Дж.Бурджуа III «Как команда менеджеров может провести отличную схватку», впервые статья опубликована в 1997 г. О том, как оставить спор в конструктивном русле.

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

Хороший сборник для свободного чтения, который заставляет задуматься о «вечных» проблемах и методах и решения.

P.S. Паша, спасибо за книгу, надо еще у тебя на столе порыться ;)

Цитирую... Канер и Ко

2011-10-01T15:21:00.002+03:00

Канер и Ко о качестве продуктов:

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

Сунь Цзы о синергии

2011-03-27T23:30:00.004+03:00

Один из уважаемых ПМов когда-то сказал мне очень хорошую фразу, которую я и сама люблю повторять: «ПМ должен найти правильных людей и не мешать им работать». Было дело, я переводила статью про воителей качества, в которой принципы искусства ведения войны Сунь Цзы прилагались к обеспечению качества. Когда книга «Сунь Цзы: Искусство ведения войны» попалось мне на глаза – я взялась за чтение. И нашла принцип, который имеет много общего со словами ПМа:
«The clever combatant looks to the effect of combined energy, and does not require too much from individuals. Hence his ability to pick out the right men and utilize combined energy.»
Мой вольный перевод: «Умный боец использует эффект синергии, и никогда не требует слишком многого от одного человека. Поэтому обладает способностью выбирать правильных людей и использовать синергию.»
Умный менеджер находит правильных людей и использует эффект синергии, а главное не мешает им работать :) Чего и вам желаю :)

С первым рабочим днем 2011 года :)

2011-01-10T23:33:00.003+02:00

Вот и подходят к завершению новогодние каникулы. 2010 год пролетел, лично у меня :), как и все годы после окончания первой вышки. Река времени лишь набирает свой бег, не останавливаясь и не замедляясь. Жизнь летит, калейдоскоп событий меняется со скоростью света. События происходят разные, и хорошие, и не очень. Хочется сделать так много, но в сутках всего 24 часа, и все-таки нужно иногда спать, кушать и, простите, ходить в туалет, а еще неплохо проводить время с семьей и не забывать друзей :). Вот и блог был заброшен последние полгода... Но ничего, ведь есть желание, найдутся и средства, во всяком случае буду их искать :)

Кстати, коллеги, С НАСТУПИВШИМ 2011 ГОДОМ и РОЖДЕСТВОМ!

Пусть Новый Год принесет Вам много нового, интересного и полезного! Новых возможностей! Новых целей! Развития! И крепкого здоровья, чтобы на все эти "прелести" хватило :)!

Первые 10 дней 2011 года уже пролетели. Кто-то отдыхал, кто-то работал, кто-то планировал 2011 год! А какие цели вы поставили для себя на 2011 год?

Ищем жаждущих работы :)

2010-09-04T10:50:00.003+03:00

Добрый день, коллеги!

В нашей компании (Москва) Отдел тестирования растет, становление процессов в процессе :), работы много и много возможностей! Мы ищем людей с "горящими" глазами, с опытом и без, готовых учиться и развиваться!

Нам очень нужны:

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

2. Тест дизайнеры. Специалисты с опытом написание тестов, тест-кейзов, методик тестирования, умеющие четко формулировать мысли.

3. Тестировщики. Специалисты с опытом и без, работы хватит всем :)

Мы предлагаем:

1. Много работы.

2. Тучу возможностей для развития.

3. Дружный коллектив.

4. Офис на Менделеевской в 3 мин от метро.

5. Работа по КЗОТ с белой ЗП.

Если Вам интересно, присылайте мне свои резюме на galagalkina@gmail.com c темой письма "РЕЗЮМЕ на <вакансия>".

Спасибо!

Черная риторика

2010-07-28T22:33:00.004+03:00

Слово – это такой инструмент полезный и могучий! Хорошо уметь «говорить» и направлять собеседника в нужное Вам русло. Уметь понять подоплеку сказанного Вам – не менее важно. Вот об этом есть занимательная книга Карстена Бредемайера «Черная риторика. Власть и магия слова».

Сразу хочу отметить прекрасный перевод, текст читается легко, плавно и затягивает. Книга состоит из 5ти глав:

Черная риторика. Своего рода введение в предмет.
Основные правила риторики. Глава раскрывает как, что и когда нужно говорить, как отвечать на вопросы.
Самые яркие манипулятивные, аргументативные и вербальные уловки черной риторики – и как от них защищаться. Глава учит распознавать приемы черной риторики, направленные против Вас и вовремя парировать.
Магическая сила правильной постановки вопросов. Да, да, и с помощью вопросов можно манипулировать.
Магическая сила призыва. Без призывов «ни туды и ни сюды».

Я подобную литературу отношу к «мозгопостановочной», которую читать нужно по возможности всем. Умелое ведение переговоров необходимо в любой сфере деятельности. И IT не исключение, а Тестирование и подавно. Все приемы, описанные в книге, в жизнь не воплотила, надеюсь пока. Часть прижилась сама собой, без усилий. Кстати, в книге после каждой главы представлено краткое содержание и задания для тренировки. Так что, дерзайте.

P.S. Все-таки в перемещении с использованием метро есть определенные плюсы: читать можно гораздо больше.

На озоне есть в виде аудиокниги.

Selenium + JAVA: полезности 2

2010-05-31T17:38:00.007+03:00

В продолжение предыдущего поста, делаем логику «поинтереснее».

Те, кто читал комментарии, думаю, видели, что без полезных советов не обошлось. И это очень радует. Выражаю благодарность Алексею Булату за очень полезный, а главное бесплатный совет:

«не буду вдаваться в подробности обработки исключений в джава, лишь скажу, что может плохого сделать Ваш код:
В случае, если исключение (Exception) случиться в одной из следующих строк кода:
stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("[запрос к БД]");
stmt.close();

строка con.close(); не выполнится, а следовательно соединение с базой не будет закрыто. Таким образом вы можете случайно открыть слишком много соединений и тем самым повалить, скажем базу :). Поэтому, рекомендуется закрывать коннект в блоке finally, который вызывается всегда.

Вот.»

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

import java.sql.*;

public class Query{

public static void main(String[] args){

Connection con = null;

Statement stmt = null;

ResultSet rs = null;

…

try{

//загружаем класс драйвера

Class.forName("com.mysql.jdbc.Driver");

//создаем соединение с БД

con = DriverManager.getConnection("[урл БД]", "[пароль]","[логин]");

stmt = con.createStatement();

//выполняем запрос

rs = stmt.executeQuery("[sql запрос]");

while (rs.next()){

[пользуемся активно результатами запроса]

}

rs.close();

stmt.close();

con.close();

}

//Ловись рыбка

catch(java.lang.ClassNotFoundException e){

System.err.print("ClassNotFoundException: ");

System.err.println(e.getMessage());

}

catch(SQLException ex){

System.err.println("SqlException: " + ex.getMessage());

}

finally {

//Что-то пошло не так? Все проверим!

try {

if (rs != null){

rs.close();

}

if (stmt != null) {

stmt.close();

}

if (con != null) {

con.close();

}

}

catch (SQLException ex) {

ex.printStackTrace();

System.err.println("SqlException: " + ex.getMessage());

}

}

}

}

А теперь представьте: вы сотворили что-то грандиозное, используя связку Selenium IDE + JAVA, а если еще и результаты работы этого «чуда» на почту отправлять, а? Это же полезность еще та! Опять же не без помощи коллективного разума (форум + опытный разработчик) «оно ожило»:

import java.util.Properties;

import javax.mail.*;

import javax.mail.internet.*;

public class Mail {

public static void main( String[] args )

{

// пример для отправителя с gmail.com!!!

final String username = "[почта отправителя]";

final String password = "[пароль]";

Properties props = new Properties();

props.put("mail.smtp.host", "smtp.gmail.com");

props.put("mail.smtp.socketFactory.port", "465");

props.put("mail.smtp.socketFactory.class","javax.net.ssl.SSLSocketFactory");

props.put("mail.smtp.auth", "true");

props.put("mail.smtp.port", "465");

Session session = Session.getDefaultInstance(props,

new javax.mail.Authenticator()

{

protected PasswordAuthentication getPasswordAuthentication()

{ return new PasswordAuthentication(username,password); }

});

try {

Message message = new MimeMessage(session);

message.setFrom(new InternetAddress("[почта отправителя"));

message.setRecipients(Message.RecipientType.TO,

InternetAddress.parse("[почта получателя]"));

message.setSubject("Test Subject!");

message.setText("Test message!");

Transport.send(message);

System.out.println("Done");

} catch (MessagingException e) {

throw new RuntimeException(e);

}

}

}

Надеюсь кому-нибудь, да пригодится. Да и мне как «мемори стик» будет!

Удач и новых свершений!

Selenium + JAVA: Полезные JAVA-методы

2010-04-07T16:31:00.007+03:00

Selenium это конечно хорошо, и запишет, и сравнит, и воспроизведет. А хочется ведь логику «поинтереснее» в тесты добавить, и вот тут весьма слабое знание JAVA мешает (ведь «держала» я её в руках последний раз в университете), но есть поисковики, да и просто хорошие, добрые и профессиональные люди :). Ниже представлены «джава-полезности», которые мне понадобились и пригодились во время доведения до ума скрипта, записанного с помощью Selenium IDE. Конечно же, это только начало «пути» и много нового, непознанного впереди. Возможно, и вам пригодиться, а может что-нибудь еще полезного мне посоветуете.

1. Кодировка.

В идеальном случае все элементы страницы живут с уникальными ID. Но тогда бы все было проще и не так интересно. Случилось у меня следующее: записала скрипт, экспорт сделала, а там… А там вместо русскоязычного словосочетания, «кракозябистость», которая компилируется, но не выполняется как надо. Эх, кодировка при компиляции определяется неправильно. Но мир не без добрых людей и вот компилятор начинает понимать, что мне от него надо:

javac -encoding utf-8

2. Запросы к БД.

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

import java.sql.*;

public class Query{

public static void main(String[] args){

Connection con = null;

Statement stmt;

…

try{

//загружаем класс драйвера

Class.forName("com.mysql.jdbc.Driver");

//создаем соединение с БД

con = DriverManager.getConnection("[url Базы данных]", "[логин]","[пароль]");

stmt = con.createStatement();

//запрос к БД

ResultSet rs = stmt.executeQuery("[запрос к БД]");

// а уже из rs данные и получаем

stmt.close();

con.close();

}

//Отлавливаем исключения

catch(java.lang.ClassNotFoundException e){

System.err.print("ClassNotFoundException: ");

System.err.println(e.getMessage());

}

catch(SQLException ex){

System.err.println("SqlException: " + ex.getMessage());

}

}

}

Подробнее описание пакета, классов и методов смотрим тут: http://java.sun.com/javase/6/docs/api/java/sql/package-summary.html.

3. Работа с датами.

Даты разные нужны, даты всякие важны, а текущая - самая дорогущая. Был в JAVA класс Date, а стал Calendar. Ниже то, что пригодилось мне:

import java.util.Calendar;

…
// Получаем текущую дату
Calendar rightNow = Calendar.getInstance();

// Записываем в переменную типа String

StartDate = String.valueOf(rightNow.get(Calendar.DATE)) + "." + String.valueOf(rightNow.get(Calendar.MONTH)+1) + "." + String.valueOf(rightNow.get(Calendar.YEAR));

// Добавляем к дате 10 дней
rightNow.add(Calendar.DATE,10);

…

Остальные «календарные» возможности и способности смотрим тут: http://java.sun.com/j2se/1.4.2/docs/api/java/util/Calendar.html

Продолжение следует...

Бах: Становясь экспертом в области тестирования

2010-03-29T17:31:00.005+03:00

Оригинал статьи тут.

Обзор: Стать экспертом в области тестирования – это путь постоянного развития. Наличие концепции развития очень помогает направлять свои усилия. Джеймс Бах, весьма известная личность в области тестирования, делится своим взглядом на «экспертность» и предлагает стремящимся к статусу эксперта решить задачу.

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

И достаются нам, в большинстве случаев, кандидаты, которые переоценивают свои способности в нахождении хороших ошибок. Та же ситуации с докладчиками на конференциях. Я встречал десятки интересных людей на конференциях, которые могли дать полезный совет и имели интересный опыт. Но когда я предлагал им встать и сделать доклад или написать статью, большинство говорили: «Я не эксперт. Я не знаю правильных ответов. Я не прочитал всех книг». Таким образом, ценный взгляд изнутри остается закупоренным внутри скептического разума многих отличных тестировщиков, когда многим, говорящим и пишущим, можно было бы чуть больше свои идеи тестировать.

Я считаю себя хорошим тестировщиком. Я могу ошибаться на этот счет. Спросите меня лет через пятнадцать. Что я знаю точно, так это то, что я работаю в направлении достижения статуса эксперта. Как я себя заставляю двигаться вперед? Мне помогает личная концепция. Всем кто желает получить статус эксперта, нужна концепция «экспертности», это двигает нас, ставит высокие стандарты, однако должно быть достижимым за жизнь.

Личная концепция.

Я могу тестировать все, при любых условиях, за любое время…

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

Давайте добавим:

… в степени относительно…

Моего положения в процессе
Моих познаний о соответствующей технологии
Моего желания преуспеть

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

…Такие как..

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

Теперь концепция в сфере реальности, хотя и является вызовом.

В данном видении экспертизы, «Я могу протестировать» означает «Я могу хорошо выполнять работу тестировщика». Это измеряется человеческим стандартом: поведение лучших экспертов, которых можно найти. С этим стандартом в голове, как эксперты отреагируют на задачу тестирования ядерного реактора за 5 минут? Ответ: люди, которых я уважаю, начнут с использования самого великого инструмента в арсенале тестировщика – «задавания вопросов об ограничениях задачи». Самым лучшим в течение пяти минут будет спросить «Что тут происходит?» или что-то в этом роде. Ну а в данном конкретном случае, «Вы сбрендили?», что хорошо отражает абсурдность ограничения.

В принципе, основной смысл использования концепций в создании привычки при взгляде на каждый продукт задавать вопросы: «Как я буду это тестировать? А что если надо будет тестировать без требований? А что если выделенное время будет вдвое меньше?».

Учитывая выше написанное, вот вам задачка. Шесть лет назад, я написал небольшую виндовую программу как пример для упражнений на занятиях по тестированию. Я использую эту программу и по сей день. Я даю студентам 15 минут на ее тестирование. А если я дам вам всего 3 минуты на ее оценку, что вы будете делать? Мне в голову приходит 4 ответа, которые могут дать эксперты в тестировании…

Подумайте об этом. А тут мой ответ: http://www.satisfice.com/answer1.htm.

Об авторе: Джеймс Бах – основатель компании Satisfice, Inc., занимающейся консалтингом и обучением в области тестирования. Пионер развивающихся дисциплин: Достаточное качество и исследовательское тестирование, Джеймс специализируется на тестировании в хаотических условиях. Джеймс является соавтором (с Кемом Канером и Бретом Петтихордом) книги: Lessons Learned in Software Testing.

Отсебятина: В принципе, по жизни очень полезно знать «Что я хочу? Как выглядит это? Как я буду этого добиваться?». Сложные вопросы, кто-то их задает себе и не знает ответа, кто-то знает ответ, а кто-то и не мучает себя такими вопросами. Желаю Вам задавать вопросы, знать ответы или хотеть их найти :)

Lessons Learned in Software Testing

2010-02-02T16:46:00.006+02:00

Эту книгу можно смело считать очень ценным приобретением для любого специалиста, занимающегося тестированием. В настоящее время книга доступна только на оригинальном языке (вы еще не знаете английский в достаточной мере для чтения книг? Ай-яй-яй, это серьезное упущение). Хоть «уроки» и были изданы в 2001 году, это нисколько не умаляет ценность её содержания.

Книга написана в виде пронумерованных уроков (да-да, тех самых выученных авторами). Авторы предлагают нашему вниманию 11 глав (всего 293 урока):

Роль тестировщика.
Думать как тестировщик.
Техники тестирования.
«Защита» ошибок.
Автоматизация тестирования.
Документирование тестирования.
Взаимодействие с программистами.
Руководство проектом тестирования.
Руководство группой тестирования.
Карьера в тестировании.
Планирование стратегии тестирования.

Кем Канер, Джеймс Бах и Брет Петтихорд являются представителями школы контекстно-ориентированного тестирования, подходы и принципы которой применяются в «уроках».

Книга эта у меня уже давно. Я воспользовалась советом авторов и читала ее НЕ «запоем» (хотя было такое желание), а по одному – двум урокам за раз. Написано легко читабельным языком. Я не нашла в книге чего-либо принципиально нового, на тех или иных этапах профессиональной деятельности все это либо приходило на ум, либо кем-то рассказывалось. Но читать все равно было интересно, т.к. форма уроков лаконична и чтение позволило упорядочить знания. Жаль не было ее у меня, когда я только начинала заниматься тестированием :)

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

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

Хочется немного перефразировать фразу из «физики нереального»: «Умным быть – модно!» в «Читать умные книги – полезно!».

P.S.: книга на амазоне.

P.P.S.: а во тут наши коллеги перевели несколько уроков!

С НОВЫМ ГОДОМ!

2009-12-31T00:19:00.003+02:00

Уважаемые коллеги!
ПОЗДРАВЛЯЮ С НОВЫМ ГОДОМ!
Желаю Вам новых и интересных проектов!
Желаю Вам незаменимых знаний!
Желаю Вам умопомрачительных достижений!
Новых целей и средств их достижения!
Семейного и финансового благополучия!
С НОВЫМ 2010м ГОДОМ ТИГРА!!!

Оцениваем...

2009-12-06T16:33:00.003+02:00

Рано или поздно кто-то пытается оценить работу сотрудников с помощью метрик. Скользкая это тема. Адекватность таких метрик всегда под большим вопросом. Один из аспектов таких метрик освещает цитата Голдратта Элия («Синдром стога сена»):
«Если ты меня оцениваешь нелогично… не жалуйся на мое нелогичное поведение».

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

P.S. Рисунок отсюда.

Для начинающих: Анализ граничных значений aka Boundary Analysis

2009-11-12T14:42:00.003+02:00

Что же это такое, анализ граничных значений? Да-да, техника написания сценариев тестирования. Этот подход очень тесно связан с разбиением на классы эквивалентности, т.к. именно классы являются источником тех самых границ!

Почему может быть полезен данный подход? Как в коде задаются ограничения? Ага, обычно знаками больше, меньше, равно. И ошибку можно «накодить» (практически, можно нашкодить :)) запросто, поставить не то значение в выражении, не тот знак. Вернемся к нашим карандашам (см. Разбиение на классы эквивалентности), в зависимости от заказанного количества карандашей различается стоимость:

1 – 100 – 10 руб. за карандаш;
101 – 200 – 9 руб. за карандаш;
201 - 300 – 8 руб. за карандаш и т.д. С каждой новой сотней, цена уменьшается на рубль.

Максимально можно заказать – 1000 штук. Анализ граничных значений очень интересуют границы интервалов значений, на то он и «анализ граничных». Используя метод эквивалентного разбиения, были выделены следующие классы:

Невалидное значение: >1000 штук;
Невалидное значение: <=0;
Валидное значение: от 1 до 100;
Валидное значение: от 101 до 200;
Валидное значение: от 201 до 300;
Валидное значение: от 301 до 400;
Валидное значение: от 401 до 500;
Валидное значение: от 501 до 600;
Валидное значение: от 601 до 700;
Валидное значение: от 701 до 800;
Валидное значение: от 801 до 900;
Валидное значение: от 901 до 1000.

Самое время взяться за граничные значения этих самых классов. Нужно брать не только само граничное значение, но и отступать на шаг вверх/вниз (на самый, самый малюсенький из возможных шажков). Для выше написанных классов получаем:

999; 1000; 1001;
1; 0; -1;
99; 100; 101;
199; 200; 201;
299; 300; 301;
399; 400; 401;
499; 500; 501;
599; 600; 601;
699; 700; 701;
799; 800; 801;
899; 900; 901;
аналогично классу №1.

Итак, получаем по 3 значения для границ, а также берем по одному значению из «тел» классов эквивалентности, итого: 33 + 12 = берем для проверки 45 значений. М-м-м-м-м, это больше 12, но гораздо меньше 1000. Да еще и проверяем не только валидные значения, но и невалидные! Но это только две техники из… продолжение следует…

Selenium: пробуем "на зуб" вместе

2009-10-07T16:23:00.015+03:00

Автоматизация тестирования, применяемая по месту, по времени и по теме весьма и весьма полезна. А если инструмент автоматизации бесплатный, мммм… «ни в сказке сказать, ни пером описать».

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

Используя надстройку над Firefox Selenium IDE, записываем и воспроизводим тесты. IDE позволяет экспортировать тесты во множество различных языков (включая Ruby, PHP, java, perl, C# и Python). Меня интересует связка Firefox-Selenium-JAVA. Почему? А не скажу, корыстные цели у меня :). Если будут появляться интересные моменты, буду описывать.

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

Скачиваем Selenium IDE & RC, устанавливаем (RC просто распаковываем, место расположения запоминаем). Все что нужно, перезагружаем.
Открываем Firefox. Разворачиваем меню «Инструменты» и о чудо! Видим подменю «SeleniumIDE». Кликаем дрожащей рукой уверенно и радостно. Если SeleniumIDE не видим, то, либо не установили, либо Firefox не перезагрузили.
И вот ОНО, «фриварное» чудо, перед нами. Уже записывающее, между прочим. Дабы остановить/начать необходимо нажимать кнопку с красным кругом :). Предлагаю посмотреть, как ЭТО работает на следующем примере:

Проверяем, что SeleniumIDE пишет (красная кнопка нажата).
В адресной строке Firefox пишем: wikipedia.org.
На заглавной странице в выпадающем меню выбираем язык: English.
В строку поиска вводим: testing. Жмем ввод.
На странице результата поиска кликаем по: Software testing.Заканчиваем запись.
Видим следующее в Selenium IDE:

Полюбовались? Попробуем нажать на кнопочку play? Вау, оно живое! Порадовались? Ну хватит, хватит, давайте продолжать. В IDE в меню файл выбираем Export Test Case As->Java(Junit)-SeleniumRC. Я использую имя: TrySelenium.java. Пойдем посмотрим, чего там на экспортировалось?

package com.example.tests;

import
com.thoughtworks.selenium.*;
import java.util.regex.Pattern;

public
class TrySelenium extends SeleneseTestCase {
public void setUp() throws
Exception {
setUp("http://wikipedia.org/", "*chrome");
}
public void
testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software
testing");
selenium.waitForPageToLoad("30000");
}
}

Имеем-с класс (название должно совпадать с именем файла!), содержащий последовательность вызовов селениум-методов, реализующих последовательность наших действий. Красота! Однако, хочется все это добро запустить через Selenium RC, а почему? Да потому, что Selenium RC позволяет преобразить записанный тест в оружие автоматизированного тестирования, используя мощь языка программирования и селениумовский библиотечных классов (громко сказано, а? а вдруг и правду может!). Для начала так далеко заходить не будем, а просто немного преобразуем java-код, дабы запускалось через RC.

import com.thoughtworks.selenium.*;
import junit.framework.*;
import java.util.regex.Pattern;

public class TrySelenium extends SeleneseTestCase {
public void setUp() throws Exception {
setUp("http://wikipedia.org", "*chrome");
}
public void testTrySelenium() throws Exception {
selenium.open("/");
selenium.select("language", "label=English");
selenium.type("searchInput", "testing");
selenium.click("go");
selenium.waitForPageToLoad("30000");
selenium.click("link=Software testing");
selenium.waitForPageToLoad("30000");
}
public static Test suite(){
return new TestSuite(TrySelenium.class);
}

public static void main(String args[]){
junit.textui.TestRunner.run(suite());
}
}

Надеюсь, JVM у вас в наличие? Будем считать, что да. Запускаем selenium-server. Открываем терминал, перемещаемся в папку, куда распаковали зипник с Selenium RC. Выполняем: cd selenium-remote-control-1.0-beta-1/selenium-server-1.0-beta-1 (Циферки зависят от скачанной версии!). И запускаем: java -jar selenium-server.jar. Можно запускать и в интерактивном режиме, но пока не трогаем. Смотрим, что не ругается, и радуемся, радуемся. А если ругается, текст ошибки «в зубы» и на просторы Интернета… Добились запуска? А кто бы сомневался.
Пришло время компилировать и запускать java-код. Инструкция (см. выше) предлагает поменять переменные среды, как сказано ранее, идем в обход. В папке, где обитает наш java файлик создаем директорию lib, в нее переписываем следующее добро: 1) Отсюда …/selenium-remote-control-1.0-beta-1/selenium-java-client-driver-1.0-beta-1/selenium-java-client-driver.jar; 2)Junit у Вас есть? Нет, ну так качаем, качаем. Отсюда в папку lib добро копируем …/junit-4.6/junit.jar.
Открываем еще один терминал, компилируем: javac -cp lib\selenium-java-client-driver.jar;lib\junit-4.6.jar TrySelenium.java. Ошибки не выпрыгнули? Хорошо! Выпрыгнули? Читаем, вникаем, в java-файл возвращаемся, исправляем, компилируем, повторяем, пока не перестанут выпрыгивать ошибки!
И вот он! Момент истины. Запускаем наше творение: java -cp .\;lib\selenium-java-client-driver.jar;lib\junit-4.6.jar TrySelenium. Ура! Оно живое! Браузер открывается, в поле текст запроса вводится… А если ошибка вываливается? Опять же читаем, понимаем, ищем решение! А потом радуемся, радуемся, что «каменный цветок» выходит!

Конечно же, приведенный пример очень и очень прост, ничего особенно стоящего он не делает. Но он поможет начать. На сайте Selenium «вагон и маленькая тележка» документации, а на просторах-то «нашего всего» интернета. Дерзайте!

Силы природы

2009-09-19T10:06:00.001+03:00

Снова хочу процитировать Канера и Ко, а именно их «Lessons Learned in Software Testing».

Programmers are like tornadoes. Think of them as forces of nature.
Мой вольный перевод: «Программисты как торнадо. Воспринимайте их как силы природы».

Силы природы, силами природы, конечно. Но не все программисты такие :). Они все разные, как и тестировщики!
Работая в компании, выпускающей коробочный продукт, я себя чувствовала по другую сторону баррикад от разработчиков. Отдел разработки и отдел тестирования имели свои цели. И разработчики воспринимали нас как «врагов» их творчества :) Что-то от сил природы в них было!
А вот в проектной команде разработчики оказались надежными соратниками, «опора» в тестировании так сказать. Правда и я уже была более опытным работником :)
Я сторонник того, что программист - не враг, а отличный коллега. Если разработчик для вас враг, может быть дело в ВАС!

Грех тестировщика

2009-08-02T21:59:00.008+03:00

И опять я хочу процитировать Сема Канера и Ко. Эта фраза повстречалась мне в «Lessons Learned in Software Testing» (кстати, очень советую почитать, лаконично, полезно и, иногда, с юмором).

«It’s not a sin in testing to miss a bug. It’s only a sin to be
careless, thoughtless, or not to learn from your experience».

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

Свое видение действий при попадании ошибки пользователям я описывала ранее в данном блоге.

Если случился такой «грех», важно понять причины и не допустить повторения в будущем.

Вебинары Рекса Блэка на сайте его компании

2009-07-02T15:21:00.002+03:00

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

Рекс Блэк обещался добавлять аудио-версии по мере их готовности. Enjoy :)

Цитирование: о комментариях

2009-06-16T22:49:00.004+03:00

Java™ Tutorial, Third Edition: A Short Course on the Basics By Mary Campione, Kathy Walrath, Alison Huml: "Comments make your code more readable; they help explain your code to others and serve as reminder to yourself when you maintain your own code"

Вольный перевод: "Благодаря комментариям код становится более читабельным, понятным и поддерживаемым".

Не стоит забывать про это и при создании автоматизированных тестов. Если конечно Вы занимаетесь автоматизацией серьезно, а не с целью освоения бюджета :)

P.S. Посмотрела я на блоги коллег и поняла, что с цитатой дня я погорячилась :) Пусть будет просто рубрика "Цитирование", без временных ограничений!

P.S.S. Картинка взята отсюда.

Rex Black: Ten Worst Things For Testing

2009-06-16T22:35:00.005+03:00

Все мы совершаем ошибки, порой очень глупые. Что тут поделаешь? Мы люди, а людям свойственно ошибаться. 9-го июня прошел бесплатный вебинар, на котором небезызвестный Рекс Блэк рассказывал о 10 худших вещах для тестирования (о 10 не очень умных вещах, которые он делал тестируя). Мистер Блэк обещался выложить презентацию в библиотеке сайта своей компании http://www.rbcs-us.com/.

Я же хочу вольно пересказать эти 10 вещей на русском. Приступим.

1. «Тестировать только то, что может инструмент автоматизации». Честно признаюсь, такого я не встречала, но оказывается, бывает.

2. «Не увольнять человека, которого нужно уволить». Часто бывает, что «сантименты» затмевают «бизнес».

3. «Писать «плохие» отчеты об ошибках». А ведь отчет об ошибке – это своего рода «лицо» тестировщика.

4. «Забыть, что тестирование – это услуга». Такого пока тоже не встречала.

5. «Игнорировать ключевых заинтересованных лиц». Это как минимум глупо, ведь эти самые ключевые заинтересованные лица просто кладезь «полезной» для тестировщиков информации.

6. «Сообщать плохие новости «плохо»». Опустить руки и сказать, что все «плохо» - проще всего, а вот предложить варианты выхода из «кризиса» - это уже очень интересно.

7. «Не определить цель тестирования». Вопросы задавать очень полезно, тут не поспоришь.

8. «Брать ответственность за качество только на себя». Качественным продукт может стать только благодаря усилиям всех членов команды, только тестировщики «воз не вытянут».

9. «Изменять процесс без полномочий». «Затычек в каждой бочке» особо никогда не жалуют.

10. «Игнорировать неверные ожидания». Очень часто люди ждут от вас того, что вы сделать не можете. Может, стоит этих людей просветить?

Не скажу, что эти 10 «худших вещей» является открытием или откровением. Каждый из нас встречался с частью, а может и со всеми. Давайте же учиться на чужих ошибках!

А вы совершали ошибки, которые никогда не повторите?

P.S. Ожидаются еще бесплатные вебинары:

Six Surprises from Test Assessments July 1, 2009
ISTQB Advanced Certification August 5, 2009
Five Testing Best Practices September 3, 2009

Дополнительную информацию ищите на сайте компании Рекса Блэка.

P.S.S: картинка взята отсюда.

Цитата дня: о планировании

2009-06-15T22:47:00.007+03:00

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

Эффи Джонс: "Неудачное планирование - это запланированная неудача".

К сожалению, очень часто планированию не уделяют достаточно внимания. Почему? Русская традиция надеяться на "авось"?

Или же планирует только один человек за всех. Но может ли это всегда работать в разработке ПО?

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

P.S. Картинка взята отсюда.

Цитата дня: о тестировании

2009-06-11T10:56:00.004+03:00

Слушала 9-го июня вебинар Рекса Блэка (подробнее напишу в следующем посте). И очень мне понравилось следующее:

"Testing is only valuable when it connects to something the organization and the other stakeholders value".

Без комментариев!

Цитата дня: о требованиях

2009-06-05T22:11:00.005+03:00

James Bach: "Requirements are the result of ongoing struggles between what we want and what we can have".

Мой вольный перевод: "Требования - это результат непрерывной борьбы между тем, что нам хочется, и тем, что можем получить".

В самом деле, требования редко когда стоят на месте. Как только будующий пользователь увидит демо-версию, сразу захочет что-нибудь изменить или добавить :) Да и без демо-версий чего-то все время хочется изменить или добавить :)

Цитата дня

2009-06-04T23:26:00.005+03:00

Доброго времени суток!

Этим постом хочу начать ежедневное (с выходными днями и отпусками:)) цитирование интересных (по моему скромному мнению :)) высказываний, мыслей и т.п.

Приступим-с...

Абрахам Маслоу: "Если молоток - это единственное, что у вас есть, то каждая проблема покажется вам гвоздем".

Частенько встречала, что если есть какой-то тул для автоматизации тестирования, то срочно нужно ВСЁ автоматизировать. А какие "гвозди" и "молотки" встречались в вашей профессиональной деятельности?

Для начинающих: Эквивалентное разбиение, оно же разбиение на классы/по классам эквивалентности aka Equivalence partitioning

2009-05-07T13:56:00.008+03:00

Чтобы тестирование было эффективным необходимы (прошу заметить, что только необходимы, а не достаточны) эффективные сценарии тестирования. Для создания эффективных сценариев тестирования существуют различные подходы, техники, методы. Рассмотрим разбиение на классы эквивалентности.

Согласно толковому словарю Ожегова класс - относительно целостное множество каких-нибудь единиц, существующее в составе сложного единства, расчленяемого на такие множества. Согласно БЭС, эквивалентность – отношение типа равенства.

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

Рассмотрим пример. Допустим, мы тестируем Интернет-магазин, продающий карандаши. В заказе необходимо указать количество карандашей (максиму для заказа – 1000 штук). В зависимости от заказанного количества карандашей различается стоимость:

1 – 100 – 10 руб. за карандаш;
101 – 200 – 9 руб. за карандаш;
201 - 300 – 8 руб. за карандаш и т.д. С каждой новой сотней, цена уменьшается на рубль.

Если тестировать «в лоб», то, чтобы проверить все возможные варианты обработки заказанного количества карандашей, нужно написать очень много тестов (вспоминаем, что можно заказать аж 1000 штук), а потом еще все это и протестировать. Попробуем применить разбиение на классы эквивалентности. Очевидно, что наши входные данные мы можем разделить на следующие классы эквивалентности:

Невалидное значение: >1000 штук;
Невалидное значение: <=0;
Валидное значение: от 1 до 100;
Валидное значение: от 101 до 200;
Валидное значение: от 201 до 300;
Валидное значение: от 301 до 400;
Валидное значение: от 401 до 500;
Валидное значение: от 501 до 600;
Валидное значение: от 601 до 700;
Валидное значение: от 701 до 800;
Валидное значение: от 801 до 900;
Валидное значение: от 901 до 1000.

На основании этих классов мы и составим тестовые сценарии. Итак, если взять по одному представителю из каждого класса, то получаем 12 тестов. 12 – не очень много, но достаточно ли этого? Даст ли гарантию качества такой набор тестов? Давайте рассмотрим следующую технику: анализ граничных значений, и попробуем ответить на эти вопросы. Но об этом в следующий раз.

Приложение.
В качестве дополнения хочу привести парочку определений Equivalence partitioning.

Сем Канер, Джеймс Бах и Брет Петтихорд в Lessons Learned on Software Testing называют эту технику – Анализ классов эквивалентности (Equivalence class analysis) и определяют ее следующим образом:
«Класс эквивалентности – это набор значений переменной, который считается эквивалентным. Тестовые сценарии эквиваленты, если a) они тестируют одно и тоже; b) Если один из них выявляет ошибку, то и остальные выявят ее; c) Если одни из них не выявляет ошибку, то и остальные не выявят. Если определен класс эквивалентности, протестируйте только одно-два значения из него».

RSTQB

определяет технику следующим образом:

«Эквивалентное разбиение: Разработка тестов методом черного ящика, в которой тестовые сценарии создаются для проверки элементов эквивалентной области. Как правило, тестовые сценарии разрабатываются для покрытия каждой области как минимум один раз».

И напоследок, любая поисковая система (я предпочитаю, google) выдаст вам кучу определений, пояснений и примеров.

Exploratory testing

2009-03-15T22:53:00.004+02:00

Согласно он-лайн словарю multitran.ru, exploratory – исследовательский, разведочный. Итак, что же такое exploratory testing. Ниже описано как это вижу я.

Очень полезная техника тестирования. Я люблю называть её «тестирование в свободном полете». Ошибок бесконечное множество. Все найти невозможно (если это конечно не программа «Hello World!»). Мы пишем сценарии тестирования, мы прогоняем их по нескольку раз. Проторенная тропинка – это конечно хорошо, но пользователи все-таки не роботы. Рука может дрогнуть, и очередной клик мыши может привести к появлению сообщения об ошибке. Поэтому неплохо периодически прибегать к свободному полету.

Итак, вы планируете провести несколько раундов тестирования, выделите пару часов (полдня, или день, как позволяет время) на exploratory testing. Допустим, тестировщик «Вася» тестировал функциональность А, а тестировщик «Ира» функциональность В. Пусть в конце раунда «Вася» «потыкает» функциональность В, а «Ира» функциональность А. Только не по тестовым сценариям, а просто так, куда душа пожелает. Пусть они каждое действие свое начинают с вопроса «А что, если … ?», пусть исследуют, разведывают. Мой опыт показывает, что данный подход дает положительный результат. Либо найдется серьезная ошибка – и нужно будет задуматься о качестве тестовых сценариев, либо мелкая, но её исправление удовлетворит заказчика еще больше, чем не исправление, а тем более не нахождение :)

Я не считаю, что exploratory testing можно использовать как самостоятельную технику тестирования, ибо только оооооочень опытный, знающий продукт и предметную область, специалист сможет выдать «хороший» результат. А вот как вспомогательная техника – да, весьма полезная штука. К «свободному полету» следует подключать не только членов команды тестирования, а любого свободного члена проектной команды. Ведь даже PM может находить ошибки, и очень любопытные :)

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

О самореализации...

2009-03-12T14:47:00.001+02:00

Разные люди приходят на собеседование. Но больше всего меня поражают те, что хотят стать разработчиком, но идут на позицию в тестировании, и работают в тестировании не первый год. Да и объяснить, почему это так толком не могут.
Кто же виноват в такой ситуации? Сам человек? Его начальник? Его, так называемый, people manager? А что вы думаете по этому поводу?

Пейсон Хелл: Трудности перевода

2009-02-22T18:22:00.005+02:00

Оригинал статьи: Lost in Translation

Об авторе: Пейсон Хэлл системный инженер и консультирующий руководитель проектов в Catalysis Group в Калифорнии. В течении 26 лет он консультировал различные проекты в частном и государственном секторе в Северной Америке и Европе. Связаться с ним можно по адресу: payson@catalysisgroup.com.

Некоторые уроки на столько важны, что жизнь преподносит возможность их повторения снова и снова. В этой статье, Пейсон Хелл описывает совещание, где он повторяет важный урок коммуникации "о значении слов".

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

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

Система еще не была собрана, однако по слухам производительность уже тестировали, мне не хотелось ставить команду в затруднительное положении прямо на проектном собрании. Вместо этого, я решил разобраться в ситуации и дать им шанс ее разъяснить, для этого я спросил «Когда вы думаете провести тестирование производительности, и сколько оно по вашему займет времени?». Ответ архитектора потряс меня. «А мы уже провели тестирование производительности и результаты хорошие».

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

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

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

Я очень резко поинтересовался у моей знакомой, занимающей пост Руководителя команды «Что он нес? Мы оба знаем что никакого тестирования производительности не проводилось!»

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

И она была права. Я совершенно забыл, что это команда ранее не работала над созданием таких сложных программ. Организация в прошлом создавала небольшие программы с использованием хорошо зарекомендовавших себя технологий. Скорее всего так исторически сложилось, что термин «тестирование производительности» описывает совсем другие активности. Тот факт, что их понимание термина отличается от моего, совсем не означал, что они пытаются ввести меня в заблуждение. Просто мы пользовались различными словарями. Достижение общей цели, особенно сложной, требует общего понимания всех ключевых терминов. Иначе можно не поверить в то, что вам говорят, или решить, что вас пытаются обмануть. Выделите время на обсуждение терминов, чтобы не столкнуться с трудностями перевода.

"Только так из человечка выйдет Человек..."

2009-02-10T10:44:00.003+02:00

Пару месяцев назад на форуме it4business шли дебаты о статье «Нас не учат «как», нас учат «чему-то»» (http://it4business.ru/forum/topic13672.html). А вспомнила я про эти дебаты, слушая с дочкой детские песни. Есть такая песня «Точка, точка, запятая...» и в ней есть замечательный ответ на вопрос зачем нам учить кучу предметов, которыми мы по большой части никогда не будем пользоваться в работе, да и в жизни.

«Что Вы! Что Вы!
Это важно!
Чтобы вырос он отважным
Чтобы мог найти дорогу,
Рассчитать разбег
Это трудно, это сложно
Но иначе- невозможно
Только так из человечка
Выйдет Человек»

Просто в университетах из нас пытаются сделать «Человеков» :) Лично я не жалею, что меня учили сопромату, теормеху, тмм, механике машин и т.д. Я знала куда иду учиться. Да и при правильном подходе данные предметы не вызывают проблем. Зато теперь я знаю, что могу решить поставленную задачу, если захочу :)

Мотивация сотрудников группы тестирования

2008-12-15T17:09:00.005+02:00

Если хотите, чтобы ваши подчиненные хорошо работали их нужно хорошо мотивировать. Что же такое мотивация и как можно мотивировать сотрудников группы тестирования?

Корнем слова «мотивация» является «мотив». Обратимся к толковому словарю Ожегова: «МОТИВ: побудительная причина, повод к какому-нибудь действию» (http://www.ozhegov.ru/slovo/23779.html). Отсюда следует, что мотивация – это создание этих самых побудительных причин и поводов.

Рассмотрим существующие теории мотивации. Различают содержательные и процессуальные теории мотивации. Содержательные теории основаны на анализе потребностей личности. Процессуальные – основаны на восприятии и ожиданиях личности.

Пожалуй, самой известной содержательной теорией является пирамида потребностей Маслоу. Пирамида состоит из 5 ступеней человеческих потребностей:
1. Физиологические (голод, жажда, физиологический комфорт и т.д.);
2. Безопасность (вне опасности);
3. Любовь/принадлежность к чему-либо (быть членом сообщества, быть принятым);
4. Уважение (быть компетентным, получать одобрение и признание)
5. Самовыражение:
- Познание (Знать, Понимать, Исследовать);
- Эстетические (симметрия, порядок и красота);
- Самоактуализация (самореализация и реализация своего потенциала).
Маслоу относит первые четыре уровня к низшим потребностям. Каждая потребность должна быть удовлетворена последовательно. Последний уровень относится к потребностям развития. По Маслоу только человек, удовлетворивший все низшие потребности, может перейти к удовлетворению потребностей развития.

Еще одной интересной содержательной теорией является теория удовлетворенности/неудовлетворенности работой Фредерика Герцберга. Герцберг рассматривал «удовлетворенность» и «неудовлетворенность» как отдельные показатели. По его теории отсутствие неудовлетворенности не гарантирует удовлетворенность. Факторы, влияющие на «неудовлетворенность» Герцберг назвал «гигиеническими». К ним относятся: удобство рабочего места, отношения с коллегами, с подчиненными, с руководством, уровень заработной платы и т.д. Факторы, влияющие на «удовлетворенность» - мотивационные. К ним относятся: престижность работы, признание, перспективы. По теории Герцберга, прежде всего руководитель должен
позаботиться об отсутствие неудовлетворенности, а затем приступать к мотивации.

Также хочется упомянуть о теории потребностей Клейтона Альдерфера (ERG-теория). Она имеет много общего с теорией Маслоу, в основе лежит три группы потребностей:
- Потребности существования;
- Потребности в связях и отношениях;
- Потребности развития.
Потребности существования совпадают с физиологическими и потребностями безопасности по Маслоу. Потребности в связях и отношениях соответствуют 3ей ступени по Маслоу. Потребности развития соответствуют потребностям уважения и самовыражения по Маслоу. Основное отличие теории Альдерфа – это отрицание последовательного удовлетворения потребностей, и признание неограниченности удовлетворения потребностей (всегда можно усилить степень удовлетворенности).

Не менее интересной является теория приобретенных потребностей Дэвида Макклелланда.
Макклелланд соглашался с наличием физиологических потребностей, и предложил свои
потребности высокого уровня:
1. Стремление к успеху;
2. Стремление к власти;
3. Стремление к причастности.
Согласно теории Макклелланда эти потребности являются приобретенными. А следовательно каждого человека нужно мотивировать по его потребностям.

Перейдем к процессуальным теориям мотивации: теория трудовой мотивации Д. Аткинсона, теория справедливости С. Адамса, теория мотивации В. Врум.

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

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

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

Вышеперечисленные теории мотивации не являются исчерпывающими. Обратившись к поисковику, найдете еще «пачку» теорий. Но не будем их сейчас рассматривать. Перейдем к мотивации в реальности.

В свое время я подняла тему мотивации на форуме портала it4business.ru. В общем, все сошлись на мнении, что одним из самых сильных стимулов являются деньги. И действительно, о каких «высоких материях» может идти разговор, если у человека нет крыши над головой и «мышь в холодильнике повесилась». Но все мы разные, и понятие «крыши» и «мыши» у всех разное. И чтобы понять другого человека, что ему нужно, что он ждет, с ним нужно общаться. «Чужая душа - потемки». Это верно, но помните «Невозможное - возможно», при правильном подходе :). К сожалению, универсального рецепта нет, да и быть не может, иначе все было бы очень просто и неинтересно. Общайтесь с подчиненным, анализируйте применимость к ним теорий мотивации. Не
пытайтесь всех подогнать под одну гребенку. Помните, что всегда есть исключения. Создавайте свои подходы. Все в наших руках.

Чем отличается сотрудник группы тестирования от остальных работников? Если не принимать во внимание профессиональные характеристики – ничем. Он такой же человек, как и все остальные работники компании. Тестировщик хочет кушать, хочет хорошо жить :). Я призываю вас подходить индивидуально к мотивации членов команды. Конечно, это не возможно, если команда у вас большая, но тут вы должны выделить лидеров и периодически прорабатывать с ними вопросы мотивации. Когда все в команде довольны, и работа спорится. Возможно ли, чтобы все были довольны? Да, возможно. Просто нужно захотеть. Вышеперечисленная позиция не является истиной в последней инстанции. Это мой подход. Это то, как я хочу работать с людьми, это то, как я хочу, чтобы работали со мной.

Список использованных ресурсов:
• http://www.fooder.ru/page2/motivac_11.html
• http://www.cfin.ru/encycl/satisfaction.shtml
• http://www.pmsh.ru/articles/motiv.php?id_S=78
• http://www.socioego.ru/teoriya/istoch/zanc/zan_motiv4.html
• http://www.ecsocman.edu.ru/direktor/msg/174890.html
• http://chiron.valdosta.edu/whuitt/col/regsys/maslow.html
• http://psylist.net/uprav/teomot.htm
• http://www.glossary.ru/cgi-bin/gl_sch2.cgi?RPwu.lxxzgr;t:l!yluwoo!suyoig.oo
• http://www.dvgups.ru/METDOC/EKMEN/MEN/MOTIV_MEN/METOD/MELNIKOVA/Gl3.htm
• http://www.vuzlib.net/spou/7.htm
• http://www.cfin.ru/encycl/expectation_theory.shtml

В помощь блоггеру

2008-12-07T09:42:00.004+02:00

Искала как сделать сообщения "под катом" и нашла очень интересный блог On-line помощь при ведении блога на Blogger.com.

Автор пишет доступно и очень подробно. Шаги проиллюстрированы скриншотами. Если что-то не получается, автор всегда поможет советом.

Всем неискушенным в HTML, советую!!!

Каталог блогов на www.it4business.ru

2008-11-24T23:21:00.006+02:00

В рамках проекта www.it4business.ru создается каталог блогов на профессиональные темы. Уже опубликованы ссылки на десяток блогов, и это только начало! Найдется блог на любой "цвет и вкус".

Однако, не только каталогом интересен портал. Здесь можно найти статьи на всевозможные IT-тематики. Можно опубликовать свои статьи. Можно и нужно общаться с коллегами на форуме.

Заходите на портал www.it4business.ru, найдете много интересного!!!

Как ошибка попала в продакшн?

2008-10-24T22:33:00.009+03:00

Итак, релиз выпущен «в открытое плавание». Проходит день, другой. Однажды утром вы открываете почту, и находите письмо от клиента, сообщающее о серьёзной ошибке, найденной в процессе эксплуатации новой версии. Что делать? Рвать на себе волосы? Посыпать голову пеплом? Искать виноватого? Нет, нет и ещё раз нет!

Ниже предлагаю вам алгоритм действия в подобной ситуации.

(кликните по картинке для увеличения)

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

Ошибка, найденная клиентом – это сигнал «тревоги». Что-то в процессе, команде не так. Не является самым главным найти виноватого, важно понять причины возникшей ситуации и постараться устранить «проблемы», чтобы ситуация не повторилась снова.

Найти причину пропуска ошибки – это полдела. Нужно выработать стратегию её ликвидацию и поставки исправления клиенту в кратчайшие сроки и с минимальным риском для качества.

Триаж

2008-10-07T22:11:00.004+03:00

Оригинал статьи : Software Triage
Автор: Девид Вален (david.whalen@comcast.net)
Перевод: Галина Галкина (galinaegalkina@yandex.ru)

Триаж. Если вы увлекались сериалом «MASH», тогда вы знаете термин «Триаж». Его также можно применить к тестированию программного обеспечения.

Если обратиться к Википедии, то «triage» является медицинским термином. Означает подход, используемый в медицине, для определения последовательности оказания помощи пострадавшим в условиях нехватки медицинского персонала.

«Triage» - это французское слово, означающее «сортировка». Медицинская сортировка используется на поле боя, или в случае катастроф. Пострадавшие делятся на группы: нуждающиеся в неотложной помощи, могущие подождать. Иногда доктор может принять решение не оказывать помощь больным в критическом состоянии, не имеющим шансов на выживание, т.к. врачи только потратят время, за которое можно спасти остальных.

Чтобы использовать понятие триаж в тестировании программного обеспечения, давайте немного изменим определение.

«Триаж – это подход, используемый командами разработки программного обеспечения, когда количество ошибок превышает количество доступных ресурсов для их исправления и проверки»

Что-то же – уже лучше.

Если с чем и знакомы тестировщики и руководители групп тестирования, так это с «ограниченными ресурсами». К сожалению, в ограниченное время невозможно протестировать и перепроверить все. Часто мы просим выделить больше времени и больше людей, так? Так!

Так как же лучше использовать ограниченное время и ресурсы? Используйте триаж!

Серьезность и Приоритет
Чтобы триаж был успешен, необходимо использовать две очень близких и все-таки очень разных характеристики ошибки: Серьезность и Приоритет. По подходу Триаж, каждые дефект обладает и Серьезностью и Приоритетом. Многие системы контроля дефектов использует либо одну, либо обе характеристики. Часто они используются взаимозаменяемо. Но все-таки эти характеристики различны. Давайте рассмотрим их подробнее.

Серьезность используется для определения степени влияния ошибки на пользователя или заказчика. «Степень влияния» возможно, было бы лучшим термином. Мы приписываем ошибке Серьезность, чтобы определить важность проблемы.

Сколько же значений серьезности необходимо? Как в сказке «Златовласка и 3 медведя» - 6 слишком много, 3 – слишком мало.

Я предпочитаю использовать четное количество значений. Нечетное количество часто ведет к уклонению от прямого решения (например, для 5 значений, слишком много ошибок бывают с серьезностью = 3). Может быть слишком много значений? Абсолютно! А слишком мало? Конечно. Если значений слишком много, управление дефектами превращается в ночной кошмар. Если слишком мало – тяжело определить степень влияния ошибки. Я работал в проекте, где было около 15 значений Серьезности (3 значения критических, 3 серьезных и т.д.). Со временем показатель Серьезности перестал что-либо означать.

Я пытаюсь не использовать только номер для обозначения серьезности. Обычно я использую номер с описанием (1-Критично, 2-Серьезно, 3-Косметическая проблема, и т.д.). Значения, выражаемые только числом, могут вводить в заблуждение (что более серьезно 1 или 4). Кто-то использует 1 для обозначения самой высокой степени Серьезности, кто-то наоборот. Независимо от того, как использовать обозначения, очень важно определить и задокументировать критерий определения каждого значения Серьезности ошибки. Значения серьезности ошибки изначально определяет тестировщик, который заносит ошибку в систему управления ошибками; тем не менее, занесенные ошибки должны проверяться и исправляться при необходимости. Вернемся к этому позднее.

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

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

Уровни Приоритета, как и уровни Серьезности должны быть определены и задокументированы. Мне нравится использовать 3 уровня Приоритета (1-Высокий, 2-Средний, и 3-Низкий), потому что это просто и понятно большинству членов команды. 1-Высокий – ошибки, которые нужно исправлять срочно, 3-Низкий – ошибки, которые не мешают работе. Обычно ошибки с низким приоритетом переносят на следующий релиз.

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

Уровни приоритета полезны в определение готовности релиза или качества (но это уже другая статья).

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

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

Руководитель группы менеджмента продукта/бизнез анализа. Менеджеры продукта или бизнес аналитики, представляют интересы заказчика. Именно они могут лучше всего оценить степень влияния с точки зрения заказчика.

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

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

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

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

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

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

Процедура проведения Триажа
Подход к проведению триажа может меняться, я стараюсь концентрироваться на следующих аспектах.

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

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

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

Частота проведения Триажей
Меня часто спрашивают: «Как часто нужно проводить Триаж совещание?». Обычно я отвечаю: «Зависит от многого». Зависит от того, как влияет совещание на график работ команды, на доступность членов команды. Зависит от графика работ всего проекта. Зависит от этапа жизненного цикла разработки, на котором находимся. Зависит от количества ошибок. «Зависит от многого» - это лучший ответ, который я могу дать.

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

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

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

Фредерик Брукс "Мифический человеко-месяц"

2008-09-09T23:04:00.004+03:00

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

Если есть свободное время, читайте полностью, все-таки «международный бестселлер». А для общего ознакомления достаточно прочитать главы 18 и 19.

Получение гражданства РФ для новорожденного

2008-09-04T22:21:00.003+03:00

В заметке рассматривается случай, когда оба родителя – граждане РФ и имеют постоян-ную регистрацию. Зачем нужно получить гражданство для малыша? Для того чтобы впи-сать ребенка в заграничный паспорт.

Исходный статус: есть свидетельство о рождении и ребенок прописан. Итак, для начала вам нужно узнать, где находится ОУФМС вашего района (по месту постоянной регистра-ции). Далее необходимо узнать, когда и в каком кабинете принимают по вопросам приоб-ретения гражданства (к сожалению, часто это можно узнать только на месте). Теперь не-обходимо подготовить документы:
- Свидетельство о рождении и ксерокопия;
- Паспорт матери ребенка и ксерокопия (обязательна копия страницы с пропиской);
- Паспорт отца ребенка и ксерокопия (обязательна копия страницы с пропиской).

Можно отправляться в ФМС и получать гражданство для малыша. Там же можно вписать ребенка в общегражданский паспорт. Не забывайте, что у нас в стране в таких учреждени-ях ВСЕГДА очереди. Сама же процедура займет не более пяти минут и вам поставят «за-ветный штамп о гражданстве на свидетельство о рождении».

В заключение информация для жителей района Щукино города Москвы. ОУФМС нахо-дится по адресу ул. Гамалеи, 23, корпус 1. Для приобретения гражданства малышу обра-щайтесь в кабинет №5 по вторникам и четвергам с 15:00 по 18:00.

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

2008-08-27T19:09:00.001+03:00

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

Роман Савин "Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах"

2008-08-23T15:25:00.011+03:00

Tестирование dot com или пособие по жесткому обращению с багами в интернет-стартапах. Так называется книга Романа Савина. Хочется сразу сказать, что "жесткого обращение с багами" в книге я не увидела. Минусом считаю определение тестирования, данное в книге. Слишком много печатного места посвящено описанию занесения багов в bug tracking систему.

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

А вот "послесловие" советую прочитать всем! Праввильно написано, ППКС, как говорится :)

Воители обеспечения качества: часть1 – боевые стратегии для высоко-производительных тестировщиков

2008-08-19T19:24:00.006+03:00

Автор: Лаура Роуз, руководитель программ Design Partner, IBM Rational Software Group

Перевод: Галина Галкина (выражаю особую благодарность Артему Бабамуратову за помощь и критику)

Лаура Роуз является экспертом в области обеспечения качества, отвечает за инструменты обеспечения качества в IBM Rational. Лаура обладает 13-ти летним опытом программирования и 10-ти летним опытом руководства тестированием. Она была членом Американского Общества Качества (American Society for Quality), Трехстороннего совета по качеству (Triangle Quality Council) и Трехсторонней ассоциации по обеспечению качества информационных систем (Triangle Information Systems Quality Association), имеет публикации, участвовует в различных конференциях по качеству и тестированию. Вы можете связаться с Лаурой по электронной почте: llrose@us.ibm.com.

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

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

1. Краткое введение в искусство войны

Сунь Цзы (Sun Tsu) был философом-практиком, один из его трудов - «Искусство войны» создан примерно в 500 году до н. э. Веками «Искусством войны» пользовались китайские и японские военные, и политические стратеги. В 2001 году Джеральд Михаэльсон (Gerald Michaelson) изложил «Искусство войны» применительно к бизнесу в своей книге «Искусство войны для менеджеров».

Существует множество книг, проводящих аналогию между бизнесом и жизнью в обществе (например, «100 простых секретов успешных людей», «7 привычек высокоэффективных людей», «Переговоры без поражений. Гарвардский метод»). Однако я думаю, что возвращение к первоисточнику весьма увлекательно и нет ничего лучше фундаментальных принципов, изложенных Сунь Цзы.

Михаэльсон преобразовал стратегии Сунь Цзы в 13 глав книги для бизнесменов. Заимствуя его идеи, я перевела эту работу для инженеров тестирования программного обеспечения. Категории Михаэльсона мне кажутся удачными, и я структурировала свой рассказ в том же ключе:

- Построение планов

- Оценка условий

- Сравнение свойств

- Поиск стратегических решений

- Ведение войны

- Использование разумного количества ресурсов

- Сделайте время союзником

- Каждый должен получить выгоду от победы

- Знайте ваши сильные стороны

- Атака с использование военной хитрости

- Победа без боя

- Сила против слабости – всегда

- Обходите стороной глупцов

- Следуйте фундаментальным принципам

На этом закончится часть 1. Последующие части покроют оставшиеся темы:

- Дислокация военных сил

- Использование энергии

- Слабость и сила

- Маневрирование

- Разновидности тактик

- Марш

- Местность

- 9 переменных расположения

- Атакуем огнем

- Нанимаем секретных агентов

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

2. Построение планов

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

- Детальная оценка условий

- Сравнение свойств

- Поиск стратегических решений

2.1. Оценка условий

«Хорошая оценка – фундамент успешной операции»¹

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

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

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

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

Кроме того, высокопроизводительный тестировщик отслеживает сообщения от заказчика, чтобы проверить, не пропущена ли какая-нибудь тестовая область. Он рассматривает «ошибку пилота» (см. http://en.wikipedia.org/wiki/Pilot_error) или «ошибку заказчика» как что-то двусмысленное и неопределенное в продукте. Он уменьшает стоимость и скорость обучения клиента с помощью публикаций документации, FAQов и статей. Он избегает будущих проблем, оформляя свои знания о продукте в базу знаний в виде статей, презентаций, аудио и видео файлов.

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

2.2. Сравнение свойств

«Сравните свои сильные и слабые стороны с конкурентами»

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

В то же самое время, он реалистично смотрит на свою ценность и свой вклад. Лучший исполнитель понимает, что ограничивает его полный потенциал. Он реалистично смотрит на свой карьерный путь и своё образование. Он выделяет «гуру» в области тестирования и стремится их превзойти. Он считает сертификацию в сфере качества и тестирования, соответствующей его карьерными целями. Он понимает, что внешняя сертификация даст ему дополнительную узнаваемость. Каждая преодоленная ступень карьерной лестницы открывает новую перспективу на профессию. С каждой новой перспективой, лучший исполнитель ставит для себя новые цели.

2.3. Поиск стратегических решений

«Разрабатывайте стратегии, идущие впереди традиционных правил».

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

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

2.4. Применение знаний

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

Вот некоторые способы:

- Пишите статьи, создавайте презентации и FAQ’и, основанные на опыте тестирования и использования продукта;

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

- Ездите в командировки к заказчику, чтобы провести тестирование в реальном окружении;

- Проходите сертификацию.

3. Ведение войны

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

3.1. Использование разумного количества ресурсов

«Инвестируйте только столько ресурсов, сколько необходимо для поддержания активности»

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

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

Учитывая написанное выше - что более соответствует развитию вашей карьеры: подготовка к использованию новой технологии или реализации далеко идущих идей?

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

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

Лучший исполнитель также контролирует время. Он мастер в управлении временем. Мы подошли к следующему пункту.

3.2. Сделайте время союзником

«Ключ в том, чтобы быстро стать эффективным и продуктивным»

Именно быстрая победа особенно ценится в войне. Лучший исполнитель быстро преобразует рабочую идею в измеримый и полезный результат для организации.

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

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

3.3. Каждый должен получить выгоду от победы

«Усиливайте человеческие и материальные ресурсы с каждой победой»

В войне успешная команда – это команда, в которой каждый выигрывает. Когда нанесено поражение врагу, вы получаете трофеи; вы комбинируете свои и чужие ресурсы, вы добры к пленникам, вы добавляете их к своим силам.

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

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

Ниже приведена пара примеров.

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

Пример 2. Мы обнаружили, что ввести процедуру инспекций кода в текущую культуру разработки достаточно сложно. У разработчиков всегда были готовы отговорки, начиная с «под проверки кода не выделено времени в плане» и заканчивая «мы не готовы к такому уровню зрелости процессов». Мы ввели проверки тест планов и тестовых сценариев и привлекли к ним разработчиков. Это само собой привело к инспекциям кода. Это стало победой для нас, т.к. таким образом, мы значительно улучшили тестовую документацию, и это была победа для разработчиков, т.к. инспекции были введены в процесс без ощущения, что инспектировать хотят самих разработчиков.

3.4. Знайте ваши сильные стороны

«Изучайте то, что необходимо для победы»

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

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

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

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

3.5. Применение знания

В этом разделе приведены идеи ведения войны Лао Цзы и адаптированы к реальности тестирования программного обеспечения. Вот несколько практических применения этих идей:

- Найдите «гуру» в области и следуйте за ним;

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

- Объединяйтесь с коллегами для подготовки к сертификации;

- Стройте и поддерживайте взаимовыгодные отношения;

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

4. Атака с использованием военной хитрости

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

4.1. Победа без боя

«Безоговорочная победа – это победа без конфликта»

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

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

4.2. Сила против слабости – всегда

«Битвы выигрываются концентрацией силы»

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

Ниже несколько примеров:

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

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

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

4.3. Обходите стороной глупцов

«Прежде чем действовать, узнайте все о ситуации»

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

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

В разработке программного обеспечения целью не является следование определенным процедурам или соответствие заданным критериям. Цель – создать качественный продукт. Все остальное – инструменты достижения цели (повторяемые процедуры, метрики, критерии начала и окончания работ). Но иногда мы так увлекаемся инструментами, что забываем цель.

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

10% изменений влекут за собой новые ошибки.⁷ Проведение повторного тестирования к определенной дате позволяет обнаружить и исправить эти «добавленные» ошибки. Закрытие ошибок без проверки совсем не соответствует целям качества.

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

4.4. Следуйте фундаментальным принципам

«Шансы на провал будут высоки, если не следовать правилам, обеспечивающим победу»

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

4.5. Применение знаний

В этом разделе описаны основные концепции стратегии. Практическое применение:

- Понимайте цель метрик и процедур;

- Предпочитайте личное общение почте;

- Оценивайте необходимость собраний и задач, посещайте и делайте только то, что принесет пользу;

- Взаимодействуйте с другими командами;

- Проводите анализ возможности ротации для временного увеличения количества ресурсов;

- Цените своё время, используйте его в соответствии с вашими целями.

5. Заключение

Это статья будет продолжена. В части 1 приводятся несколько практических советов, как увеличить производительность тестирования. Как я упоминала во введении, следующие части будут посвящены остальным стратегиям трактата Сунь Цзы применимым к области тестирования. Оставайтесь на связи!

Ссылки

¹Цитаты приведены из книги «Сунь Цзы: Искусство войны для менеджеров» Джеральда Михаэльсона

²Один из примеров, проверка системы на ошибку «нет свободного места на диске».

³ «Переговоры без поражений. Гарвардский метод» Роджер Фишер, Вилльям Ури.

⁴ «7 привычек высокоэффективных людей» Стивен Ковей

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

⁶ «Искусство войны для менеджеров» Джеральд Михаэльсон

⁷ Статистика показывает, что если необходимо проверить 100 исправленных ошибок, вы найдете как минимум 10 новых.

Список использованной литературы

The Effective Executive: The Definitive Guide to Getting the Right Things Done (Harperbusiness Essentials) by Peter F. Drucker, HarperCollins Publishers Inc, 2002

Sun Tzu: The Art of War for Managers; 50 Strategic Rules by Sun-tzu and Gerald A. Michaelson, Adams Media Corporation 2001The Top Ten Mistakes Leaders Make by Hans Finzel, Davide C cook Distribution Canada, 2007

A Whack on the Side of the Head: How you can be More Creative by Roger Von Oech, 3rd Edition, Warner, 1998Bookis INc

Smart Moves for People in Charge: 130 Checklists to Help You Be a Better Leader by Sam Deep and Lyle Sussman, Perseus Book Group, 1998

The One Minute Manager Meets the Monkey by Kenneth Bnanchard, Blanchard Family Partnership, 1989

The Seven Spiritual Laws of Success A Practical Guide to the Fulfillment of Your Dreams by Deepak Chopra, Pgw, 1995

The Tao of Leadership by John Heider, Lightning Source Inc, 1984

The 7 Habits of Highly Effective People by Stephen R. Covey, Free Press, 2004

The 100 Simple Secrets of Successful People by David Niven, PH. D, HarperCollins Publications, 2006

Getting to Yes: Negotiating Agreement Without Giving In by Roger Fisher and William Ury, Penguin Group USA, 1991

Managing Your Mouth by Robert L. Genua, Amacom Books, 1993

Правила тестирования

2008-08-16T23:04:00.006+03:00

Не смотря на то, что тестирование процесс творческий - в проектах по производству ПО он ограничен жесткими временными рамками. Для любого тест-менеджера важно правильно рассчитать, спланировать трудозатраты, чтобы «уложиться» в отведенные под тестирование сроки. Как этого достичь?

Первое правило: никогда не «прогибайтесь» под временные рамки проекта. Оценка трудоемкости цикла тестирования должна быть полной. Руководитель проекта и Заказчик должны понимать, что тестировать приложение полностью – «дорого», поэтому важно доносить до них информацию о том, сколько и как можно протестировать за выделенное время. Хороший план – это залог успеха. А хороший план можно составить только на основании реальных оценок.

Второе правило: расставляйте приоритеты. Очень неприятна ситуация, когда находится ошибка на этапе использования продукта конечными пользователями. И ситуация эта усугубляется, когда оказывается, что функционал используемый пользователями чаще всего, тестировался меньше всего. Плотно работайте с аналитиками, требуйте приоритизации требований - это позволяет легче приоритизировать сценарии тестирования (test cases). На первом раунде цикла тестирования выполняйте сначала тесты с более высоким приоритетом. На последующих раундах следует начинать с верификации исправления ошибок и областей вокруг, далее снова приниматься за высокоприоритетные тесты.

Третье правило: покрывайте требования тестами в зависимости от приоритетов. Написание тестовых сценариев вещь полезная, однако, весьма трудоемкая. Покрывайте тестами только то, что будете тестировать.

Четвертое правило: внимательно читайте требования. Если есть хотя бы малейшая неоднозначность, не стесняйтесь лишний раз спросить. Цена неточности возникшей в начале цикла разработки, с каждым шагом, этапом, раундом - повышается. Лучше задать глупый вопрос и быть уверенным в ожидаемом результате, чем на последних раундах жизненного цикла проекта/релиза судорожно выяснять, как же должна работать программа. Следите, чтобы требования и test case’ы были в актуальном состоянии.

Пятое правило: проводите раунды тестирования «в свободном полете». Другое название – exploratory testing. Штука весьма и весьма полезная. Протестировать все по test case’ам конечно хорошо. Но пользователи не роботы, а живые люди и они могут сделать что-то не так, не по сценарию. Отсюда следует, что иногда полезно пройтись по приложению в отрыве от test case’ов и «копать» в наиболее часто используемых пользователями местах.

Шестое правило: ведите тест-логи (test logs) аккуратно. Тест-лог – это официальный документ. Он подтвердит результаты проверки, и как следствие – общее качество разработанного продукта. Лог должен вестись добросовестно. Самая неприятная ситуация, когда тест помечен как успешно пройденный, а на деле получается, что этот кусок функциональности не работает совсем, и работать ранее не мог. Прививайте культуру ведения тест-логов в вашей команде.

Седьмое правило: все ошибки должны быть зарегистрированы (записаны, занесены в систему управления дефектами). Прививайте культуру фиксации дефекта сразу после его обнаружения. Ошибки должны исправляться, но откладывание занесения ошибки, а, следовательно, её «обнародования» сдвинет момент исправления. В результате риск сорвать сроки увеличивается.

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

И я туда же...

2008-08-13T10:04:00.001+03:00

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