locked
Test Cases to be covered during POC RRS feed

  • Question

  • Hello,

    We are perfoming POC for SCCM 2012

    Can someone please help with test cases to be covered under POC

    Our Plan is to use all below given features

    1. Application Deployment
    2. Package Deployment
    3. Mobile Device Management
    4. Software Update
    6. Inventory
    7. Role Based Administration
    Many more other but needs to be confirmed

    Bandwidth is main constrained in my organiszation, also suggest if you have any method to monitor bandwith while deploymeny of application or software update.

    Tuesday, December 23, 2014 6:37 AM

Answers

  • Great then, I'd just focus on the scenarios as I've said earlier. I don't really see why you would have to customize anything specific for e.g. Application deployments when it comes to error codes. Here's an example scenario:

    - App1 needs to be installed on Windows 8.1 64-bit systems by using the Application Model

    If you go from there, you can build a simple PoC where you deploy App1 to a collection that only contains the specific systems that you want.

    For the PoC, I'd not go into advanced configurations like adding additional custom hardware inventory, but if you're going to need it in the end I guess you have to.


    Nickolaj Andersen | www.scconfigmgr.com | @NickolajA

    • Marked as answer by Daniel JiSun Wednesday, January 7, 2015 7:58 AM
    Tuesday, December 23, 2014 7:59 AM
  • Your test cases should stem from your business requirements and use cases. Testing a random sample of functionality doesn't prove anything. The whole point of a POC is to prove that the product will be beneficial to organization which means that it addresses the organizations needs and requirements when it comes to managing end user devices. Thus, you really need to have those requirements and needs documented and from those you can build your test cases.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Daniel JiSun Wednesday, January 7, 2015 7:57 AM
    Tuesday, December 23, 2014 3:23 PM

All replies

  • Instead of demonstrating all of the features that ConfigMgr has, why not focus on those areas where you're going to use the product for instead. Like most organizations mostly use ConfigMgr for:

    - Operating System Deployment
    - Software Updates Management
    - Hardware/Software inventory
    - Reporting

    If I were you, I'd go through and come up with those scenarios that you have in your organization where ConfigMgr could help you with those, and then install and configure the product to perform a PoC. That's what a PoC is to me at least.


    Nickolaj Andersen | www.scconfigmgr.com | @NickolajA

    Tuesday, December 23, 2014 7:41 AM
  • Thanks Nicolaj,

    We have installed product and also started demonstration of application deployment and other features

    My concern was to check if there is any benefits apart from legacy deploymeny of application or Inventory like customizing error code in Application Deployment

    Customizing inventory as required without modifying MOF's etc.,


    • Edited by gapawar Tuesday, December 23, 2014 7:52 AM
    Tuesday, December 23, 2014 7:51 AM
  • Great then, I'd just focus on the scenarios as I've said earlier. I don't really see why you would have to customize anything specific for e.g. Application deployments when it comes to error codes. Here's an example scenario:

    - App1 needs to be installed on Windows 8.1 64-bit systems by using the Application Model

    If you go from there, you can build a simple PoC where you deploy App1 to a collection that only contains the specific systems that you want.

    For the PoC, I'd not go into advanced configurations like adding additional custom hardware inventory, but if you're going to need it in the end I guess you have to.


    Nickolaj Andersen | www.scconfigmgr.com | @NickolajA

    • Marked as answer by Daniel JiSun Wednesday, January 7, 2015 7:58 AM
    Tuesday, December 23, 2014 7:59 AM
  • Your test cases should stem from your business requirements and use cases. Testing a random sample of functionality doesn't prove anything. The whole point of a POC is to prove that the product will be beneficial to organization which means that it addresses the organizations needs and requirements when it comes to managing end user devices. Thus, you really need to have those requirements and needs documented and from those you can build your test cases.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Daniel JiSun Wednesday, January 7, 2015 7:57 AM
    Tuesday, December 23, 2014 3:23 PM