Which testing process will be good to start building a new product? [closed]

Question

Your company is started building a new product and they are hired you as a Sr. QA position for this new product. As of the companies expectation you have to work on both manual and automation (Selenium). Some other team members are also working with you, but they don't have automation knowledge.

As a Sr.QA you have to start from initial level-starting from deciding framework, writing script, executing, reporting and also creation of manual test cases, test scenarios.

His company follows agile software development process. Then how he could start his work for both manual and automation. Shall he start writing selenium script at initial level or first manual and then Selenium?

Any suggestions would be appreciated?

Answer 1

I think it would be good to start of with Manual and then from there you can maybe start seeing patterns and see which tests can rather be automated. Unless you really know the test cases and scenarios well before hand really well then you can even start with Automation.

Answer 2

In an Agile project you will need multiple levels of test-automation from the start. Adding testing later will not happen, or you will lag behind, often leading to un-refactorable code. You need tests to let the code adapt to new requirements. These tests need to be automated, because refactoring with manual tests is so slow that noone will want todo it. Refactoring is a (primairy) design skill of Agile developers.

These levels of test-automation are described in the Test Pyramid. Add atleast one test in each level. This way you make sure the product is written testable. Agile teams are crossfunctional without disciplines this means everyone on the team should be able to write automated tests. If they can't teach them.

I always like to quote Less.works about technical excelence:

Organizational Agility is constrained by Technical Agility

In other words, when you are slow in making changes to your product, then it doesn’t matter how you structure your teams, your organization or what framework you adopt, you will be slow to respond to changes.

Agile is more than a process, its a mindset that is driven by tests. Practising technical excelence is VERY important if you want to be truly Agile. To quote the Agile manifesto:

Continuous attention to technical excellence and good design enhances agility.

From my perspective the only manual testing that is done during an itteration in an Agile team is exploratory testing (which should lead to more automated tests if needed), usability testing or tests that have extreme costs to automate.

Maybe there is a user-acceptance stage, but preferable you do a continuous deployment strategy. Meaning all code should be production ready!

If you need users to test new incomplete features have a look at feature toggles instead of a seperate testing environment.

Other reads that I think are relevant to your question:

• https://www.thoughtworks.com/insights/blog/agile-tester-30
• http://blog.xebia.com/are-testers-still-relevant/

Answer 3

Given below are the details of each testing step that is carried out in each software quality and testing life cycle specified by IEEE and ISO standards:

1) SRS Review: Review of the software requirement specifications

2) Objectives are set for Major releases

3) Target Date planned for the Releases

4) Detailed Project Plan is built. This includes the decision on Design Specifications

5) Develop Test Plan based on Design Specifications

6) Test Plan: This includes objectives, the methodology adopted while testing, features to be tested and not to be tested, risk criteria, testing schedule, multi-platform support and the resource allocation for testing.

7) Test Specifications This document includes technical details (Software requirements) required prior to testing.

8) Writing of Test Cases

Smoke (BVT) test cases Sanity Test cases Regression Test Cases Negative Test Cases Extended Test Cases 9) Development – Modules are developed one by one

10) Installers Binding: Installers are built around the individual product.

11) Build procedure : A build includes Installers of the available products – multiple platforms.

12) Testing Smoke Test (BVT): Basic application test to take decision on further testing

Testing of new features Cross-browser and cross-platform testing Stress testing and memory leakage testing. 13) Test Summary Report

Bug report and other reports are created 14) Code freezing

No more new features are added at this point. 15) Testing

Build and regression testing. 16) Decision to release the product

17) Post-release scenario for further objectives.

The application which should be automated must have these factors:

• The application should not be in the early stages of its development.(The application should have all or some modules which are stable and tested by manual testers)
• The UI of the application must be stable.(The UI must not change frequently)
• The manual test cases of this application should be in written form.

You can get the most benefit out of your automated testing efforts by automating:

• Repetitive tests that run for multiple builds.
• Tests that tend to cause human error.
• Tests that require multiple data sets.
• Frequently used functionality that introduces high risk conditions.
• Tests that are impossible to perform manually.
• Tests that run on several different hardware or software platforms and configurations.
• Tests that take a lot of effort and time when manual testing.

If manual testers are converted into automation engineers, they have to be trained on automation terminologies and concepts. If automation architect is hired from outside, he must get knowledge about the product to test, the manual testing process and what management is expecting. Good training and strong communication between manual testers, developers and automation team is really necessary.