«Мистецтво тестування програмного забезпечення»: огляд книги

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на QA DOU!

Привіт! Мене звати Михайло, сьогодні я хотів би обговорити зі спільнотою третє видання книги «The Art of Software Testing» авторів Glenford J. Myers, Tom Badgett і Corey Sandler — перевидання класичної праці з тестування програмного забезпечення.

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

Думаю, більшість з нас працювало у погано протестованих продуктах, і знають широкий спектр пов’язаних з цим проблем (і прямо на наших очах про них майже щотижнево дізнається Ілон Маск). З іншого боку, правильно заплановане і виконане тестування може стати фундаментом успіху вашого проєкту.

Звісно, я маю на увазі не лише роботу QA-інженерів. Розробка автоматизованих тестів є невід’ємною частиною роботи розробників ПЗ. Ця практика надає нам впевненості у собі та своєму коді, стимулює своєчасний рефакторинг і допомагає писати якісний код (адже неякісний код зазвичай покрити тестами значно складніше).

Окрім того, особисто для мене тести, мабуть, приносять найбільше задоволення в усьому циклі розробки ПЗ, особливо коли я застосовую TDD. Завжди приємно бачити, що тести, які спочатку падали (тому що вони запускалися для «порожнього» класу чи методу), починають проходити. Можливо, такі почуття пов’язані з моїм минулим в олімпіадному програмуванні, хто знає :)

Перейдемо до аналізу самої книжки.

Що мені сподобалося в книзі

1. Опис того, що таке успішний тест. Успішний тест показує, що ваша програма працює НЕ так, як очікувалося, а не навпаки. Зміна мислення навколо цього здається мені дуже важливою.
2. Обговорення психологічних аспектів тестування. Ми, як творці наших програм, на глибоко психологічному рівні не хочемо, щоб тести знаходили помилки, адже це означатиме, що результат нашої роботи неідеальний. З цим можна і треба боротися. Також це додатковий аргумент щодо того, чому програмний продукт повинні тестувати не лише ті, хто його створив.
3. Визначення та приклади типів тестування програмного забезпечення (white-box, black-box; unit, integration, functional, system, acceptance та installation і т.д.).
4. Детальний опис основних методик тестування програмного забезпечення та створення тест-кейсів.
5. Опис того, як дізнатися, коли припинити тестування програми. Детальне обговорення основних метрик code coverage.
6. Спеціальні розділи, які з’явилися в 3-му виданні, присвячені тестуванню веб- і мобільних застосунків.
7. Дискусія про дебагінг.

Що мені не сподобалося в книзі

Я вважаю, що деякі методи, описані в книзі, надто складні, щоб їх застосувати на практиці. Це може звучати як недолуге виправдання моєї ліні, але мені складно уявити, як, наприклад, cause-effect graphing можна застосувати до проєкту з тисячами реквайрментів і сотнями тисяч рядків коду.

Які мої основні висновки

1. Тестування програмного забезпечення складне. Значно складніше, ніж я уявляв.
2. Майже кожен (якщо не кожен) програмний продукт містить баги — навіть той, який виконується в продакшені десятиріччями.
3. Серйозність помилок для користувача сильно відрізняється.
4. Підсумок попередніх двох пунктів: складно визначити, коли програмне забезпечення не має життєво важливих для задовільної взаємодії з користувачем помилок.
5. Тестування програмного забезпечення не можуть проводити тільки розробники.
6. При плануванні і проведенні тестування необхідно враховувати психологічні чинники.
7. Дебагінг — нетривіальний процес. Часто спочатку варто подумати, і лише потім використовувати «традиційні» методи дебагінгу. Знову ж таки, з психологічної точки зору це здається марною тратою часу. Навіщо думати, якщо можна запустити свій улюблений інструмент дебагінгу у своєму улюбленому IDE, переглянути значення деяких змінних та знайти проблему? Основна ідея тут полягає в тому, що спочатку подумавши, можна заощадити багато часу, а також знайти більш фундаментальні помилки.

Чи радив би я прочитати цю книгу

Думаю, що так. Це не найкраща IT-книга в історії Всесвіту, але вона все одно хороша. Коротко кажучи, 4/5, would recommend.

Кому варто прочитати цю книгу

Перш за все, розробникам та QA-інженерам. Але я думаю, що люди, які управляють проєктами, за допомогою цієї книги також можуть поглибити своє розуміння того, як успішно керувати командою.

Книга не важка з технічної точки зору. Якщо ви strong junior engineer або досвідченіший фахівець і цікавитеся темою, книга може бути для вас корисною.

На цьому все. Які ваші думки про тестування програмного забезпечення? Чи достатній його рівень на ваших проєктах? Які книги на цю тему ви б порадили? Чи цікаво вам було б у майбутньому читати подібні огляди класичної IT-літератури?

Не соромтеся поділитися своїми пропозиціями в коментарях і дякую за прочитання цієї статті!