-1

We are a small company and i am a test coordinator appointed to bring a process in testing for the company. We dont have a testing process in place. Development-Deployment and testing happens almost daily and the communication is established over skype or mails. How do i start to bring a testing process in place?

We have operations running in 8 different countries and we dont have a dedicated testing team for testing. The business users are the testers we have. It is crutial for me to get them all to testing when required. So how do i bring that change in the way they work?

Any suggestions or help is kindly appreciated.

user4557522
  • 3
  • 2
  • 4
    I'm voting to close this question as off-topic because it is asking about workplace philosophies, not programming as defined by the Help Center. – TylerH Jan 27 '17 at 17:26

3 Answers3

0

I would suggest to consider Comindware Tracker - workflow automation software. It executes processes you create automatically by assigning tasks to the right team member, only after the previous step in the workflow is completed. Furthermore, you can create forms visually, set your own workflow rules and have your data processed automatically. You can configure Comindware Tracker to send e-mail notifications to users when a particular event occurs with a task or document, or to send scheduled e-mail reports. Discussion threads are available within every task. You can share a document with a team and it will be stored within the task, document versioning is supported.

Perhaps the key reason why small company just starting to optimize workflows should consider Comindware Tracker is its ability in changing workflows in real-time during process execution without the need to interrupt it. As you are likely to make plenty of changes during the course of your starting phase, this solution is worth of attention. This product review might be useful - http://www.brighthubpm.com/software-reviews-tips/127913-comindware-tracker-review/

Disclaimer – I work in Comindware. We use Comindware Tracker to manage workflows within our company. I will be glad to answer any question about the solution, if any should rise.

Elena
  • 36
  • 2
  • Appreciate your time for replying. – user4557522 Feb 13 '15 at 01:05
  • Appreciate your time for replying. What would you recommend is the best practice in a team where deployments to UAT happen every alternate days. Of course performing regression testing after every deployment is not the right option we see. How can testing be scheduled in an environment where deployment to UAT is often happening. Could you please suggest if even the process of deployments should be changed? – user4557522 Feb 13 '15 at 01:20
0

I think the best approach for this changing is show the test value for your managers.

I suppose that without well organized test process the bug finding happens eventually. The value of one crucial issue find by your customer but not by you may lead to the huge impact on the company business. Well, you may wait when it will happen or just start to build the test group.

Also this is the common fact that finding bugs as soon as possible saves a lot of money for the organization. This is mostly because fixing the issue close to the development time requires much less time.

I would recommend Jira as the open source tool which allow to organize the bugs tracking and also supports agile development process.

Eugene
  • 1,791
  • 3
  • 19
  • 22
  • Totally agree to what you say. We use TFS in our project for handling bugs and other test cases. However the test plans in TFS are not organised. We have deployments to UAT happening every alternate days, in which case it is difficult to perform testing without a standard test plan folders in TFS. What do you think is the best way to start organizing the test plans in TFS. Would you recommend to start with the tractability matrix and create test plans accordingly? Or do you see any other ways by which i can say that the test coverage is at acceptable level – user4557522 Feb 13 '15 at 01:19
  • TFS is the good system allows to build the connection between different items. I would suggest start with the project requirements and connect them to the test cases and then connect the bugs. Also TFS allows to connect the source code (in the source control) with the requirements and again with the bugs. These connections are helpful for understanding which code/requirements areas are more problematic . There are a lot of resources on MS site to explain this process. For the beginning please see [here](http://nakedalm.com/requirement-management-in-the-modern-application-lifecycle/) – Eugene Feb 13 '15 at 10:43
  • Then when your tests are cover all the project requirements you can say that your coverage is acceptable. – Eugene Feb 13 '15 at 10:47
  • @user4557522 don't forget to accept the answer if it helped, thanks – Eugene Apr 27 '15 at 05:59
0

If you are looking to release frequently then you should consider using automated regression testing.

This would involve having an automated test for every bit of significant functionality in your applications. In addition, when new functionality is being developed an automated regression test would be written at the same time.

The benefit of the automated regression test approach is that you can get the regression tests running in continuous integration. This allows you to continuosly regression test and uncover any regression bugs soon after the code is written.

Manual regression testing is very difficult to sustain. As you add more and more functionality to the applications the manual regression testing takes longer and makes it very difficult to release frequently. It also means the time spent testing will continually increase.

If your organisation decides not to go with test automation then I would suggest you need to create a delivery pipeline that includes a manual regression testing phase. You might want to consider using an agile framework such as Kanban for this (which typically works well with frequent releases).

Barnaby Golden
  • 3,781
  • 1
  • 19
  • 24