Како да ја тестирате апликацијата пред лансирање: практичен план

За да ја тестирате апликацијата пред лансирање, наведете ги неколкуте текови што корисникот мора да може да ги заврши, извршете секој како сосем нов корисник на лаптоп и на телефон, па пробајте ги начините на кои можат да згрешат: празни податоци, лоши внесувања, втора сметка, бавна врска. Тестирајте го секое нешто што вклучува пари или приватни податоци со дополнителна грижа, и повторете ги главните текови на живиот URL по објавувањето. На крајот, набљудувајте некој што никогаш не ја видел апликацијата додека се обидува да ја користи.

За ова не ви треба тим за QA или рамка за тестирање. Ви треба список, еден-два часа и дисциплина да навистина кликнете низ него.

Чекор 1: Запишете ги тековите што се важни

Тек е задача од почеток до крај што корисникот доаѓа да ја направи. Повеќето апликации имаат три до шест такви што навистина се важни. За апликација за резервации:

1. Регистрација и потврда на сметката
2. Најдете час и резервирајте го
3. Откажете резервација
4. Платете пакет часови
5. Персонал: видете ги денешните резервации

Ако сте ги напишале корисничките приказни, нивните критериуми за прифаќање се веќе вашите тест-случаи. Ако не, напишете по една линија за секој тек со тоа што значи „успех“.

Рангирајте ги. Тековите што заработуваат пари или што ги погодува секој корисник (регистрација, најава, главното дејство) се тестираат прво и најмногу.

Чекор 2: Тестирајте го среќниот пат како нов корисник

Среќниот пат е текот што оди точно како што е замислен. Тестирајте го како би го доживеал непознат:

• Користете приватен прозорец на прелистувачот, за да не сте најавени и да немате зачувани податоци.
• Користете нова сметка со вистинска е-пошта што можете да ја проверите.
• Започнете од почетната страница или од линк, не од страница што сте ја обележале додека градите.

Новите корисници немаат податоци. Многу грешки се појавуваат тек кога списокот е празен, профилот нема слика или ништо уште не е купено. Вашата сметка, полна со тест-податоци, ги крие.

Чекор 3: Обидете се да ја скршите

Сега повторете го секој тек и направете го погрешното намерно.

Освежувањето вреди да се истакне: ако апликацијата работи кога кликнувате, но освежувањето на подлабока страница дава 404, видете како да поправите грешки 404 по објавување.

Чекор 4: Тестирајте ги дозволите со две сметки

Ова е најважниот тест за секоја апликација со сметки, и најчесто прескокнатиот.

Направете два обични корисници, А и Б, и (ако вашата апликација ги има) администратор.

• Како А, создајте запис. Најавете се како Б. Може ли Б да го види, уреди или избрише? Не би требало, освен ако тоа не е дизајнот.
• Како А, копирајте го URL-то на еден од вашите записи. Најавете се како Б и отворете го директно.
• Како обичен корисник, отворете административни страници со впишување на нивните URL-адреси.
• Одјавете се целосно и пробајте ги истите URL-адреси.

Ако најдете проблем тука, не лансирајте додека не се поправи. Проверката мора да се случи на серверот, не само со скривање на копче. Нашиот безбедносен список за апликации изградени со AI оди подлабоко.

Чекор 5: Тестирајте на вистински уреди

Отворете ја апликацијата на вистински телефон, не само во тесен прозорец на прелистувач.

• Можете ли да допрете секое копче без зумирање?
• Дали тастатурата го покрива полето во кое пишувате?
• Дали табелите и широката содржина се лизгаат или се преломуваат, наместо да ја турнат страницата настрана?
• Дали текстот се чита без штипкање?

Пробајте најмалку еден iPhone (Safari) и еден Android телефон (Chrome), ако можете да позајмите. Safari особено има свои чудности со датуми, видео и елементи со фиксна позиција.

Чекор 6: Тестирајте пари и е-пошта од почеток до крај

Секое нешто што наплатува картички или испраќа е-пошта бара целосен тест.

Плаќања. Користете го тест-режимот на вашиот провајдер за плаќања и тест-броевите на картичките. Проверете успешно плаќање, одбиена картичка и откажана наплата. Потврдете дека нарачката или претплатата се појавува во вашата апликација после плаќањето, не само во таблата на провајдерот. Ако вашата апликација се потпира на webhook-и (пораки што провајдерот ги испраќа до вашиот сервер), проверете дали пристигнуваат на објавената апликација, не само во развојот. Потоа, пред лансирање, префрлете се на живи клучеви и направете една мала вистинска купувачка што ја враќате.

Е-пошта. Регистрирајте се со вистински адреси кај две или три различни провајдери. Проверете дали пораките пристигнуваат, не завршуваат во спам и дали секој линк во нив води до живиот домен, а не до адреса за преглед.

Чекор 7: Проверете брзина и грешки

• Отворете ги алатките за програмери на прелистувачот (десен клик → Inspect) и погледнете го табот Console на секоја главна страница. Црвените грешки вреди да се поправат дури и ако ништо не изгледа расипано.
• Вчитајте ја страницата на телефон со мобилни податоци, не со Wi-Fi. Ако првиот екран трае неколку секунди, прво погледнете ги големините на сликите.
• Пуштете бесплатна проверка како Lighthouse во алатките за програмери на Chrome за брз преглед на перформансите и достапноста.

Чекор 8: Тестирајте ја објавената апликација, не само прегледот

Прегледот и објавената апликација не се иста средина. Пред да им кажете на луѓето за лансирањето, повторете ги главните текови на живата URL-адреса:

• Дали се поставени сите променливи на околината и тајни за објавената апликација?
• Дали користи точна база, со податоците што ги очекувате?
• Дали пренасочувањата при најава и линковите во е-поштата користат живиот домен?
• Дали освежувањето на длабока страница се вчитува правилно?

Чекор 9: Набљудувајте некој друг како ја користи

Дајте им на еден или двајца луѓе цел („резервирајте час јога за сабота“), не упатство. Набљудувајте, не помагајте, и запишувајте каде застануваат. Тоа е најбрзиот начин да најдете нејасни формулации и скриени копчиња. За поголема верзија на ова, погледнете како да спроведете бета тестирање.

Кога ќе наидат на бубачка, запишете ја правилно, со чекори, очекуван резултат и реален резултат. Нашиот водич за како да напишете добар извештај за грешка го покажува форматот.

Користење AI за тестирање

Ако градите со AI, можете да го замолите да помогне во планирањето и извршувањето на тестовите:

Наведи ги главните кориснички текови во оваа апликација и, за секој, рабните случаи што најверојатно ќе пукнат: празни состојби, невалидни внесувања, дозволи и освежување. Стави го во список што можам да го минам.

Најавете се како два различни тест-корисници и проверете дали корисникот Б може да види или промени нешто што го создал корисникот А, вклучително и со директно отворање на URL-адресите на записите на А. Извести што најдовте пред да поправате што било.

Извештајот за тестирање на AI третирајте го како прв премин. Сепак, сами кликнете низ тековите за пари и дозволи.

Тестирање во Mythex

Во Mythex, командата /test ја стартува App Testing: агентот управува прелистувач против вашиот жив преглед, кликнува низ страниците, прави снимки од екранот и ги пријавува расипаните текови во разговорот. Најдобро функционира со конкретен тек, како „тестирај регистрација и резервација на час“. Поправете го она што го најде со /fix или со обична порака, па повторно пуштете /test. App Testing користи преглед, па сами проверете ги главните текови на објавената URL-адреса после објавувањето. Видете App Testing во документацијата, а нашиот водич за дебагирање на апликација изградена со AI е за кога нешто не успева.

Чести грешки

• Тестирање само како себе. Вашата администраторска сметка со многу податоци ги крие грешките со празни состојби и дозволи.
• Тестирање само на лаптоп. Многу посетители на многу страници доаѓаат преку телефон.
• Прескокнување на втората сметка. Податоците што протекуваат меѓу корисниците се најсериозната грешка со која апликацијата може да се лансира.
• Верување на прегледот. Живата апликација има други поставки; тестирајте ја и неа.
• Поправање бубачки без повторно тестирање на соседните делови. Поправка на еден формулар може да расипе друг што дели код.

Список пред лансирање

• Главните текови се наведени и рангирани
• Секој тек поминува како нов корисник во приватен прозорец
• Празни, невалидни, долги и дупликати внесувања се ракуваат
• Освежувањето работи на секоја страница
• Корисниците не можат да ги видат или менуваат податоците на другите, дури ни преку URL
• Административните страници се блокирани за обични корисници и за одјавени посетители
• Работи на вистински iPhone и Android телефон
• Плаќањата тестирани: успех, одбивање, откажување и апликацијата се ажурира после тоа
• Пораките пристигнуваат, не завршуваат во спам и линкуваат до живиот домен
• Нема црвени грешки во конзолата на главните страници
• Главните текови повторени на објавениот URL
• Барем една надворешна личност ја пробала апликацијата додека вие набљудувавте

Прашања