Otomasyon testleri oluşturmaya hangi Agile (SCRUM) aşamasını başlamalıyız?

Biraz arka plan - SCRUM (1-2 hafta sprint) kullanarak Çevik bir ortamda neredeyse 2 yıldır manuel test kullanıcısıyım. Bu yüzden Selenium WebDriver (Java ile) kullanarak yaptığım çalışmalarda otomasyon testi yapmak istiyorum.

Sorum şu, işlevselliği ne zaman manuel olarak test etmeliyim ve otomasyon testi için ne zaman dönüştürmeliyim?

Okudum ve farklı yaklaşımlar alıyorum, örneğin:

1. Yeni bir sprint başladığında, kullanıcı hikayelerini önceki sprint'ten otomatik komut dosyalarına dönüştürün VEYA;
2. Kullanıcı hikayelerini aynı sprint içinde dönüştürün.

Herhangi bir tavsiye / çok takdir edilecektir. Şimdiden teşekkür ederim.

Test otomasyonu (ve diğer tüm testler) tamamlanmış tanımının bir parçası olmalıdır . Bu potansiyel olarak sevk edilebilir bir ürün yapmak için. Test edilmediyse gönderebilir misiniz?

Test aynı zamanda bütün bir ekip yaklaşımı olmalıdır, bu nedenle test otomasyonu testin sorumluluğu değildir. Bu süreçte mümkün olan en kısa sürede test etmeyi düşünmeye başlayın .

Agile'da test otomasyonu çok önemlidir çünkü:

Örgütsel Çeviklik, Teknik Çeviklik ile sınırlıdır

Başka bir deyişle, ürününüzde değişiklik yapmakta yavaş olduğunuzda, ekiplerinizi, kuruluşunuzu veya hangi çerçeveyi benimsediğinizi önemli değil, değişikliklere yanıt vermekte yavaş olursunuz.

https://less.works/less/technical-excellence/index.html

Testi başka bir yinelemeye kadar ertelerseniz, her zaman geride kalırsınız. Ürünün dış davranışını yeniden düzenlemek ve güvenli bir şekilde korumak daha zor olduğundan ürünün yönünü değiştirmeyi zorlaştırmak . Tekrarlayan manuel testlere sahip olmak sizi yavaşlatmanın anahtarıdır, otomasyon!

Birçok test kullanıcısı, ürün arayüzü stabil hale gelene kadar uçtan uca test yapmaya başlamamanız gerektiğini söyleyecektir. Beklemeyin, bunun yerine PageObjects'i iyi kullanın ve testlerinizin sürdürülebilir olduğundan emin olun ve bunları oluşturmak ve düzeltmek için geliştirici sorumluluğu yapın.

Önemli olan, o hikaye için otomatik testler yazmadıkça bir hikayeyi eksiksiz olarak işaretlememenizdir.

Böylece, önceki bir sprint'te tamamlanan bir görev için testler yazdığınız için 1 dışarıda gibi görünüyor. testler başarısız olursa ne olur?

İdeal olarak, otomatik testlerin kodun yazıldığı sprint ile yazılması gerekir. Otomatik testler yazılana kadar kodun "tamamlanmış" olduğu düşünülmemeli ve bir sprint sonunda kodu "tamamlanmış" duruma getirmelisiniz.

Kodu anlamak ve geliştirici olarak ihtiyaçlarınızı anlamalarına yardımcı olmak için geliştiriciyle birlikte çalışarak sprint'in ilk gününde işleme başlamalısınız. Örneğin, web sayfaları oluşturuyorsanız, etkileşim kurmanız gereken her sayfa öğesi için benzersiz tanımlayıcılar ekleme ihtiyacını anlamalarına yardımcı olabilirsiniz.

Scrum'da işinizin test yazmak olmadığını unutmayın. İşiniz sprint hedeflerini tamamlamak için ekiple birlikte çalışmaktır. Bu, sprint'te çok erken gerçekleşmesi gereken iletişim ve işbirliği anlamına gelir. Kod test edilmeye hazır olmadan önce test tasarımları ve test planları üzerinde çalışmaya başlayabilirsiniz.

Otomatik olarak test yapacaksanız, testleri önceden de oluşturabilirsiniz. Bu, hangi davranışı beklediğinizi tanımlamanıza yardımcı olur ve sizi bir istemci gibi düşünmeye teşvik eder, sonunda yazılımınızı daha kullanışlı hale getirmelidir. Ve işlevselliği uygularken testten hemen yararlanacaksınız.

Her ikisini de yapabilirsiniz, ancak tipik olarak otomasyon testleri ile regresyon testini hedeflemek istersiniz. Bu, bir regresyon testi olacak kadar sağlam olduğundan emin oluncaya kadar manuel yapacağım anlamına gelir. Bu, bazı işlevler için bir sprint ortasında olabilir ve diğer işlevler için gelecekteki bir sprint olabilir.

Başka bir cevapta belirtildiği gibi, testin ne zaman yapıldığı, yapılan tanımın bir parçası olmalıdır . Bununla birlikte, bu cevabın bazılarına katılmıyorum, bu yüzden karşılaştığım deneyimlerle genişlemek istedim.

Gerçekten Çevik bir ortamda, herkes her şeyi yapabilir. % 100 test etmeye adanmış biri olmayacak, bazı temel kullanıcı arayüzü çalışmalarına veya başka bir şeye yardımcı olacak beceriler de geliştireceksiniz. Ancak nadiren ideal bir dünyada yaşıyoruz.

Ne tavsiye ederim biraz melez bir yaklaşım yapmak olacaktır. Bitti Tanımı için, manuel testin işin kodlandığı Sprint'in bir parçası olması gerektiğini söyleyebilirim. Sprint sona ermeden önce çalıştığını ve herhangi bir hatanın hemen raporlanabileceğini, muhtemelen düzeltilebileceğini söyleyebilirim. bir. Manuel testlere odaklanarak, kodun ne yapması gerektiğine aşina olacaksınız. Yapacağınız fazla bir şey olmayabileceğiniz bir sonraki Sprint'in başında, regresyon hatalarını önlemek için oluşturma işleminin bir parçası olarak çalışabilecek otomatik testlerinizi ayarlayabilirsiniz.